Plan de contrôle et nœuds de travail EKS

Amazon Elastic Kubernetes Service (EKS) est un service Kubernetes entièrement géré qui vous évite d’installer, d’exploiter et de maintenir le plan de contrôle Kubernetes. AWS exécute, met à l’échelle et met à niveau le plan de contrôle dans plusieurs zones de disponibilité, offrant ainsi un point de terminaison de cluster hautement disponible. Vous pouvez vous concentrer entièrement sur le déploiement et la gestion de vos charges de travail applicatives.

Le plan de contrôle EKS se compose du serveur d’API, d’etcd, du gestionnaire de contrôleurs et du planificateur, tous gérés par AWS. Ces composants s’exécutent dans des comptes appartenant à AWS, ce qui signifie que vous ne vous y connectez jamais en SSH. AWS garantit un SLA de 99,95 % pour le point de terminaison de l’API EKS et remplace automatiquement les nœuds défaillants du plan de contrôle. Vous payez un tarif fixe par cluster et par heure pour le plan de contrôle.

Vous pouvez créer un cluster EKS à l’aide de la console AWS, d’eksctl ou de CloudFormation. Le cluster nécessite un VPC avec des sous-réseaux répartis dans au moins deux AZ ainsi qu’un rôle IAM autorisant le plan de contrôle Kubernetes à appeler les API AWS. Une fois créé, le point de terminaison du cluster est une URL HTTPS que vous configurez dans votre kubeconfig.

Après avoir créé le cluster, mettez à jour votre kubeconfig local afin que kubectl sache comment accéder au serveur d’API EKS. AWS CLI génère automatiquement l’entrée nécessaire. Le serveur d’API EKS utilise AWS IAM pour l’authentification : votre utilisateur ou rôle IAM est associé à une identité RBAC Kubernetes via le aws-auth ConfigMap.

Les groupes de nœuds gérés permettent à AWS de provisionner, d’enregistrer et de gérer le cycle de vie des nœuds de travail EC2 pour votre compte. Lorsque vous demandez une mise à jour ou un remplacement, EKS vide automatiquement les pods, remplace l’instance et l’enregistre à nouveau, sans intervention manuelle. Les groupes de nœuds gérés utilisent des Auto Scaling Groups en interne, ce qui vous donne le contrôle de la capacité minimale, maximale et souhaitée, ainsi qu’une intégration avec Cluster Autoscaler.

Avec les groupes de nœuds autogérés, vous lancez vous-même les instances EC2 (via CloudFormation ou Terraform) et les enregistrez dans le cluster EKS en exécutant le script Bootstrap. Cela offre une flexibilité maximale : vous pouvez utiliser des AMI personnalisées, des types d’instances GPU ou des configurations de noyau hautement personnalisées ; en revanche, vous êtes entièrement responsable de la mise à jour corrective, du vidage et du remplacement des nœuds.

Chaque nœud de travail doit s’exécuter avec un profil d’instance EC2 associé à trois politiques gérées par AWS : AmazonEKSWorkerNodePolicy, AmazonEKS_CNI_Policy et AmazonEC2ContainerRegistryReadOnly. Elles permettent au nœud de rejoindre le cluster, de gérer le réseau des pods avec le module d’extension VPC CNI et d’extraire des images depuis ECR. Sans ces politiques, les nœuds ne pourront pas s’enregistrer.

EKS utilise le ConfigMap aws-auth dans l’espace de noms kube-system pour associer les utilisateurs et rôles IAM aux noms d’utilisateur et groupes Kubernetes. Lorsque vous créez un cluster, seule l’identité IAM de son créateur reçoit automatiquement un accès administrateur. Pour permettre à d’autres utilisateurs ou rôles CI/CD d’accéder au cluster, vous devez ajouter des entrées à ce ConfigMap avec les clés mapRoles ou mapUsers appropriées.

Les modules complémentaires EKS sont des composants logiciels sélectionnés et validés par AWS, tels que le VPC CNI, CoreDNS et kube-proxy, qu’EKS peut installer et maintenir à jour pour votre compte. Lorsque vous mettez à niveau la version Kubernetes de votre cluster, mettez d’abord à jour le plan de contrôle, puis chaque groupe de nœuds géré vers la version correspondante. EKS prend en charge un écart maximal d’une version mineure entre le plan de contrôle et les nœuds pendant la fenêtre de déploiement.

Le point de terminaison du serveur d’API EKS peut être configuré en mode public uniquement, privé uniquement ou dans les deux modes. Les points de terminaison publics sont sécurisés par l’authentification IAM ; les points de terminaison privés uniquement exigent que votre kubeconfig accède au VPC via un VPN ou Direct Connect. Vous pouvez également activer le chiffrement par enveloppe des secrets Kubernetes au repos à l’aide d’une clé AWS KMS, ce qui ajoute une couche de protection pour les données de configuration sensibles.

Le Cluster Autoscaler est un pod Kubernetes qui surveille les pods impossibles à planifier et ajuste automatiquement la taille des groupes de nœuds gérés Auto Scaling Groups. Lorsque des pods ne peuvent pas être planifiés en raison de ressources insuffisantes, Cluster Autoscaler augmente la capacité. Lorsque des nœuds sont sous-utilisés et que leurs pods peuvent être replanifiés ailleurs, il réduit la capacité. Il nécessite des autorisations IAM pour appeler l’API Auto Scaling EC2 via IRSA.

Dans cette leçon, vous avez appris que : AWS gère le plan de contrôle EKS avec un SLA de 99,95 %, que les groupes de nœuds gérés permettent à AWS de gérer le cycle de vie des nœuds tandis que les groupes autogérés offrent une personnalisation maximale, et que le ConfigMap aws-auth associe les identités IAM à RBAC Kubernetes pour contrôler l'accès au cluster. Nous allons maintenant découvrir les profils Fargate pour l'exécution serverless des pods.