Comparaison de la capacité EKS pour ACK à une solution ACK autogérée - Amazon EKS
Différences par rapport à l'ACK en amontVoie de migrationÉtapes suivantes

Aidez à améliorer cette page

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Comparaison de la capacité EKS pour ACK à une solution ACK autogérée

La capacité EKS pour ACK fournit les mêmes fonctionnalités que les contrôleurs ACK autogérés, mais avec des avantages opérationnels significatifs. Pour une comparaison générale des fonctionnalités EKS par rapport aux solutions autogérées, voirConsidérations relatives aux fonctionnalités EKS. Cette rubrique se concentre sur les différences spécifiques à ACK.

Différences par rapport à l'ACK en amont

La capacité EKS pour ACK est basée sur les contrôleurs ACK en amont, mais elle diffère en termes d'intégration IAM.

Rôle de capacité IAM : la fonctionnalité utilise un rôle IAM dédié avec une politique de confiance qui autorise le principal du capabilities.eks.amazonaws.com service, et non l'IRSA (rôles IAM pour les comptes de service). Vous pouvez associer des politiques IAM directement au rôle de capacité sans avoir à créer ou à annoter des comptes de service Kubernetes ou à configurer des fournisseurs OIDC. Une bonne pratique pour les cas d'utilisation en production consiste à configurer les autorisations de service à l'aide deIAMRoleSelector. Pour plus d’informations, consultez Configurer les autorisations ACK.

Balises de session : la fonctionnalité gérée définit automatiquement les balises de session pour toutes les demandes d' AWS API, ce qui permet un contrôle d'accès et un audit précis. Les balises incluent eks:eks-capability-arneks:kubernetes-namespace, eteks:kubernetes-api-group. Cela diffère de l'ACK autogéré, qui ne définit pas ces balises par défaut. Consultez Configurer les autorisations ACK pour plus de détails sur l'utilisation des balises de session dans les politiques IAM.

Balises de ressources : la fonctionnalité applique des balises par défaut différentes aux AWS ressources par rapport à l'ACK autogéré. La fonctionnalité utilise des balises eks: préfixées (telles queeks:kubernetes-namespace,eks:eks-capability-arn) au lieu des services.k8s.aws/ balises utilisées par ACK autogéré. Consultez Considérations relatives à l'ACK pour EKS la liste complète des balises de ressources par défaut.

Compatibilité des ressources : les ressources personnalisées ACK fonctionnent de la même manière que les ressources ACK en amont, sans aucune modification de vos fichiers YAML de ressources ACK. La fonctionnalité utilise les mêmes Kubernetes APIs et CRDs les outils kubectl fonctionnent donc de la même manière. Tous les contrôleurs GA et les ressources de l'ACK en amont sont pris en charge.

Pour consulter la documentation complète d'ACK et les guides spécifiques aux services, consultez la documentation ACK.

Voie de migration

Vous pouvez passer d'un ACK autogéré à une fonctionnalité gérée sans aucune interruption de service :

  1. Mettez à jour votre contrôleur ACK autogéré pour l'utiliser kube-system pour les baux électoraux des dirigeants, par exemple :

    helm upgrade --install ack-s3-controller \
  oci://public.ecr.aws/aws-controllers-k8s/s3-chart \
  --namespace ack-system \
  --set leaderElection.namespace=kube-system

    Cela déplace le bail du contrôleur verskube-system, ce qui permet à la capacité gérée de se coordonner avec celui-ci.

  2. Créez la fonctionnalité ACK sur votre cluster (voirCréation d'une fonctionnalité ACK)

  3. La fonctionnalité gérée reconnaît les AWS ressources existantes gérées par ACK et prend en charge le rapprochement

  4. Diminuez ou supprimez progressivement les déploiements de contrôleurs autogérés :

    helm uninstall ack-s3-controller --namespace ack-system

Cette approche permet aux deux contrôleurs de coexister en toute sécurité pendant la migration. La fonctionnalité gérée adopte automatiquement les ressources précédemment gérées par des contrôleurs autogérés, garantissant ainsi un rapprochement continu sans conflits.

Étapes suivantes