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.

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