View a markdown version of this page

Comparaison de la capacité EKS pour ACK à celle d'ACK autogéré - Amazon EKS
Différences par rapport à l'ACK en amontParcours de migrationContrôleurs de prévisualisation et promotion automatiqueÉ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 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 à celle d'ACK autogéré

La capacité EKS pour ACK fournit les mêmes fonctionnalités que les contrôleurs ACK autogérés, mais présente des avantages opérationnels significatifs. Pour une comparaison générale entre les capacités d'EKS et les solutions autogérées, consultezConsidérations relatives aux fonctionnalités EKS. Cette rubrique met l'accent sur ACK-specific les différences.

Différences par rapport à l'ACK en amont

La capacité EKS pour ACK est basée sur des contrôleurs ACK en amont mais 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.

Tags de session  : la fonctionnalité gérée définit automatiquement des 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. Configurer les autorisations ACKPour en savoir plus sur l'utilisation des balises de session dans les politiques IAM, consultez la section.

Balises de ressources  : cette fonctionnalité applique aux AWS ressources des balises par défaut différentes de celles de 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 l'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. Cette fonctionnalité utilise les mêmes API et CRD Kubernetes, de sorte que des outils comme celui-ci kubectl fonctionnent de la même manière. La fonctionnalité prend en charge uniquement les contrôleurs et les ressources qui sont généralement disponibles (GA) dans l'ACK en amont. La fonctionnalité n'inclut pas les contrôleurs qui sont en prévisualisation en amont. L'état d'un contrôleur peut passer de l'état de prévisualisation à l'état GA en amont au fil du temps, et la fonctionnalité peut alors commencer à le gérer automatiquement. Si vous exécutez un contrôleur de prévisualisation autogéré en plus de cette fonctionnalité, vérifiez-le Contrôleurs de prévisualisation et promotion automatique avant de procéder à la migration.

Pour une documentation ACK complète et des guides spécifiques aux services, consultez la documentation ACK sur le site Web d'ACK.

Parcours de migration

Vous pouvez migrer de l'ACK autogéré vers la fonctionnalité gérée en perturbant le moins possible vos AWS ressources. La migration repose sur l'élection du leader de Kubernetes : le contrôleur autogéré et la fonctionnalité se disputent le même bail, de sorte qu'un seul d'entre eux concilie une ressource donnée à la fois. Pour que cela fonctionne, les deux doivent partager un bail dans le même espace de noms. La fonctionnalité ne prend pas le bail d'un contrôleur autogéré en fonctionnement. Vous pouvez donc contrôler le moment du transfert en réduisant la taille du contrôleur autogéré.

Important

Avant de commencer, accordez au rôle de capacité IAM des autorisations équivalentes à celles que vos contrôleurs autogérés utilisent aujourd'hui. La fonctionnalité s'authentifie grâce à un rôle de capacité dédié via le principal de capabilities.eks.amazonaws.com service, plutôt que via le mécanisme que vos contrôleurs autogérés utilisent aujourd'hui, comme IRSA ou EKS Pod Identity (voir). Configurer les autorisations ACK Si le rôle de capacité ne dispose pas d'autorisations, la capacité adopte vos ressources. Il ne parvient alors pas à les réconcilier et enregistre AccessDenied les erreurs.

Procédez comme suit pour effectuer la migration. Les étapes utilisent le contrôleur S3 (ack-s3-controller) comme exemple. Répétez-les pour chaque contrôleur ACK autogéré que vous souhaitez migrer vers la fonctionnalité, en remplaçant le nom du contrôleur et le graphique Helm correspondants.

Note

L'exécution d'un contrôleur autogéré parallèlement à cette fonctionnalité est conçue comme un état temporaire pendant la migration, et non comme une configuration à long terme. Lorsque les deux sont en cours d'exécution, une interruption de part et d'autre (telle qu'un déploiement de fonctionnalités ou une mise à niveau du contrôleur autogéré) peut annuler le bail et permettre à l'autre partie de l'acquérir, provoquant un basculement inattendu entre les deux parties. Effectuez la migration pour chaque contrôleur plutôt que de l'exécuter de manière autonome parallèlement à la fonctionnalité pour une durée indéfinie.

  1. Activez l'élection du leader sur votre contrôleur ACK autogéré et transférez son bail à kube-system :

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

    Vous devez définir les deux valeurs. Dans les graphiques ACK Helm, le --leader-election-namespace drapeau n'est appliqué que lorsqu'il l'leaderElection.enabledesttrue, et l'élection du leader est désactivée par défaut. Le réglage leaderElection.namespace seul n'a aucun effet. Le contrôleur continue de fonctionner sans contrat de location et les deux contrôleurs réconcilient les mêmes ressources en même temps après la création de la fonctionnalité. Cela s'applique à tous les graphiques de contrôleurs de service ACK, et pas seulement à S3.

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

  2. Créez la fonctionnalité ACK sur votre cluster (voirCréation d'une fonctionnalité ACK). La fonctionnalité démarre et fait l'objet d'une demande de location, mais le contrôleur autogéré la détient toujours. Votre contrôleur autogéré ne cesse de réconcilier vos ressources, et la capacité attend la direction plutôt que de forcer une prise de contrôle.

  3. Lorsque vous êtes prêt à commencer la migration, redimensionnez le contrôleur autogéré jusqu'à ce qu'il n'y ait aucune réplication. Cela libère le bail afin que la capacité puisse acquérir le leadership et prendre en charge la réconciliation :

    kubectl scale deployment ack-s3-controller \
  --namespace ack-system --replicas=0

    Une fois que vous avez réduit la taille du contrôleur autogéré, la fonctionnalité acquiert le contrat de location et commence le rapprochement, généralement dans un court laps de temps. La mise à l'échelle de la sauvegarde du contrôleur autogéré ne rétablit pas le bail, car la capacité continue de détenir et de renouveler le bail. Pour rétablir la réconciliation avec le contrôleur autogéré, redimensionnez-le à au moins une réplique, puis supprimez la fonctionnalité ACK. Une fois la fonctionnalité supprimée, le contrôleur autogéré acquiert de nouveau le bail et reprend le rapprochement.

    Lors de son adoption, la fonctionnalité applique ses propres balises de ressources par défaut (eks:préfixées) à la place des services.k8s.aws/ balises utilisées par l'ACK autogéré (voirConsidérations relatives à l'ACK pour EKS). Attendez-vous à recevoir une série unique d'appels d'API de balisage pour les ressources que vous avez adoptées, et mettez à jour tous les outils de répartition des coûts ou de politique qui utilisent le préfixe de la services.k8s.aws/ balise.

  4. Vérifiez que la fonctionnalité est saine et qu'elle a pris en charge la réconciliation de vos ressources. Vérifiez que les ressources signalent un Synced état des erreurs True et que la fonctionnalité n'enregistre pas AccessDenied les erreurs.

  5. Après avoir vérifié que la fonctionnalité gère correctement vos ressources, supprimez le contrôleur autogéré :

    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 capacité gérée utilise des ressources précédemment gérées par des contrôleurs autogérés après la libération du bail, garantissant ainsi une réconciliation continue sans conflits.

Contrôleurs de prévisualisation et promotion automatique

Cette fonctionnalité ne prend en charge que les contrôleurs GA dans l'ACK en amont. Une manette qui est en version préliminaire aujourd'hui peut être promue en GA en amont ultérieurement. Lorsque cela se produit, la fonctionnalité commence à gérer ce contrôleur automatiquement, sans aucune action de votre part.

Cela crée un risque si vous exécutez un contrôleur de prévisualisation autogéré sur un cluster qui utilise également les fonctionnalités d'autres contrôleurs. Vous pouvez exécuter le contrôleur de prévisualisation en tant que réplique unique avec l'élection du leader désactivée, car il n'y a aucun autre contrôleur avec lequel vous pouvez vous coordonner. Lorsque ce contrôleur est promu GA, la fonctionnalité commence à le gérer. À ce stade, deux conciliateurs agissent sur les mêmes ressources sans aucun bail partagé pour les coordonner. Il en résulte le même conflit de double réconciliation que les étapes de migration visent à éviter. Les deux réconciliateurs émettent des appels d' AWS API concurrents et rédigent des mises à jour contradictoires pour l'état des ressources personnalisées.

Pour éviter cela, avant d'exécuter un contrôleur de prévisualisation autogéré en plus de cette fonctionnalité :

  • Activez l'élection du leader sur le contrôleur de prévisualisation autogéré et signez son bail àkube-system, en utilisant les mêmes leaderElection.namespace=kube-system paramètres leaderElection.enabled=true et les mêmes paramètres que ceux indiqués dans les étapes de migration. Cela garantit que si le contrôleur est promu et que la capacité prend le relais, les deux se coordonnent dans le cadre d'un bail partagé plutôt que de se réconcilier en parallèle.

  • Suivez le statut GA en amont de tous les contrôleurs de prévisualisation dont vous dépendez et planifiez de les migrer en suivant le chemin de migration lorsqu'ils seront promus. Vous pouvez vérifier l'état actuel de chaque contrôleur sur la page des services ACK sur le site Web d'ACK.

Étapes suivantes