Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi.

Référence de configuration du cluster EKS

Accès au compte

Remplissez chaque menu déroulant et champ en utilisant les informations obtenues pour votre stratégie IAM.

Paramètre Description

Région

Dans le menu déroulant, choisissez la région géographique dans laquelle vous souhaitez construire votre cluster.

Identifiants Cloud

Sélectionnez les identifiants cloud que vous avez créés pour votre stratégie IAM. Pour plus d’informations sur la création d’identifiants cloud dans Rancher, consultez cette page.

Rôle de service

Choisissez un rôle de service.

Rôle de service Description

Standard : Rôle de service généré par Rancher

Si vous choisissez ce rôle, Rancher ajoute automatiquement un rôle de service à utiliser avec le cluster.

Personnalisé : Choisissez parmi vos rôles de service existants

Si vous choisissez ce rôle, Rancher vous permet de choisir parmi les rôles de service que vous avez déjà créés dans AWS. Pour plus d’informations sur la création d’un rôle de service personnalisé dans AWS, consultez la documentation Amazon.

Chiffrement des secrets

Facultatives : Pour chiffrer les secrets, sélectionnez ou entrez une clé créée dans AWS Key Management Service (KMS)

Accès au point de terminaison du serveur API

La configuration de l’accès API public/privé est un cas d’utilisation avancé. Pour plus de détails, consultez la documentation sur le contrôle d’accès au point de terminaison du cluster EKS.

Points de terminaison API privés uniquement

Si vous activez l’accès aux points de terminaison API privés et désactivez l’accès public lors de la création d’un cluster, il y a une étape supplémentaire à suivre pour que Rancher puisse se connecter au cluster avec succès. Dans ce cas, une fenêtre contextuelle s’affichera avec une commande que vous exécuterez sur le cluster pour l’enregistrer auprès de Rancher. Une fois le cluster provisionné, vous pouvez exécuter la commande affichée depuis n’importe où où vous pouvez vous connecter à l’API Kubernetes du cluster.

Il existe deux façons d’éviter cette étape manuelle supplémentaire :

  • Vous pouvez créer le cluster avec un accès aux points de terminaison API privés et publics lors de la création du cluster. Vous pouvez désactiver l’accès public après la création du cluster et lorsqu’il est en état actif, et Rancher continuera à communiquer avec le cluster EKS.

  • Vous pouvez vous assurer que Rancher partage un sous-réseau avec le cluster EKS. Ensuite, des groupes de sécurité peuvent être utilisés pour permettre à Rancher de communiquer avec le point de terminaison API du cluster. Dans ce cas, la commande pour enregistrer le cluster n’est pas nécessaire, et Rancher pourra communiquer avec votre cluster. Pour plus d’informations sur la configuration des groupes de sécurité, consultez la documentation sur les groupes de sécurité.

Points de terminaison d’accès public

Limitez éventuellement l’accès au point de terminaison public via des blocs CIDR explicites.

Si vous limitez l’accès à des blocs CIDR spécifiques, il est recommandé d’activer également l’accès privé pour éviter de perdre la communication réseau avec le cluster.

L’une des conditions suivantes est requise pour activer l’accès privé :

  • L’IP de Rancher doit faire partie d’un bloc CIDR autorisé

  • L’accès privé doit être activé, et Rancher doit partager un sous-réseau avec le cluster et avoir un accès réseau au cluster, ce qui peut être configuré avec un groupe de sécurité.

Pour plus d’informations sur l’accès public et privé au point de terminaison du cluster, consultez la documentation Amazon EKS.

IPv6 / Réseau à double pile

Rancher prend en charge le provisionnement et la gestion des clusters Amazon EKS avec le routage réseau IPv6. Lorsque l’IPv6 est activé, les pods et services Kubernetes se voient attribuer des adresses IPv6. Cependant, les nœuds de travail EC2 sous-jacents fonctionnent en mode dual-stack (recevant à la fois des adresses IPv4 et IPv6). Cette architecture à double pile garantit que les nœuds peuvent toujours communiquer avec l’API AWS et le plan de contrôle Kubernetes via IPv4, tandis que vos charges de travail d’application communiquent via IPv6.

Pour provisionner un cluster à double pile depuis l’interface utilisateur de Rancher :

  1. Lors de la création du cluster, développez la section Réseau.

  2. Sous Famille IP, sélectionnez le bouton radio IPv6.

    Changer la famille IP efface toutes les sélections de sous-réseau que vous avez faites dans le formulaire.

  3. Sous VPC et sous-réseaux, choisissez soit de créer automatiquement un nouveau VPC et un sous-réseau ou de sélectionner parmi les sous-réseaux existants.

    Avertissement pour les VPC personnalisés

    Si vous choisissez de sélectionner des sous-réseaux existants, vous devez sélectionner des sous-réseaux à double pile. Les sous-réseaux sélectionnés doivent avoir à la fois un bloc CIDR IPv4 et un bloc CIDR IPv6. Les sous-réseaux uniquement IPv6 ne sont pas pris en charge.

  4. Complétez le reste de la configuration du cluster (Groupes de nœuds, etc.).

  5. Cliquez sur Create.

Le paramètre de Famille IP est immuable. Après la création d’un cluster EKS, vous ne pouvez pas convertir un cluster IPv4 en IPv6, ni convertir un cluster IPv6 en IPv4.

Importation de clusters IPv6 existants

Rancher prend entièrement en charge l’enregistrement (importation) de clusters Amazon EKS existants qui ont été configurés avec un réseau IPv6 en dehors de Rancher (par exemple, via Terraform ou la console AWS).

Lorsque vous enregistrez un cluster EKS existant :

  1. Suivez le processus standard d’enregistrement de cluster (Gestion des clusters > Ajouter un cluster > Générique).

  2. Rancher interroge l’API AWS EKS pour lire l’état en amont du cluster.

  3. Rancher détecte automatiquement si le cluster a été provisionné avec IPv6.

Lors de la configuration d’un cluster IPv6, plusieurs comportements automatisés et exigences strictes s’appliquent :

  • CIDR de service : AWS attribue automatiquement le CIDR de service à partir d’une plage IPv6 fixe (fd00::/108). Vous ne pouvez pas personnaliser le CIDR de service pour un cluster IPv6.

  • Exigence du fournisseur OIDC (IRSA) : Dans un cluster IPv6, le plugin Amazon VPC CNI exige strictement des autorisations IAM pour attribuer des préfixes IPv6 aux interfaces réseau élastiques (ENI). Cette authentification est gérée via des rôles IAM pour les comptes de service (IRSA). Par conséquent, un fournisseur OIDC IAM est obligatoire et est automatiquement activé par Rancher lors du provisionnement d’un cluster IPv6. Sans cela, les pods échouent à acquérir des adresses IP.

Exemple de référence EKSClusterConfig (IPv6)

Si vous déployez des clusters EKS par programme en utilisant la ressource personnalisée eksclusterconfigs.eks.cattle.io, vous pouvez activer IPv6 en définissant le champ ipFamily sur ipv6.

Voici un exemple d’un EKSClusterConfig minimal configuré pour IPv6. Remarquez que le ipFamily est défini, et que les champs IPv4 standard comme serviceCidr sont omis car AWS les gère automatiquement en mode IPv6.

apiVersion: eks.cattle.io/v1
kind: EKSClusterConfig
metadata:
  name: my-ipv6-cluster
  namespace: cluster-fleet-default
spec:
  amazonCredentialSecret: cattle-global-data/my-aws-credentials
  displayName: my-ipv6-cluster
  region: us-west-2
  imported: false
  kubernetesVersion: "1.33"
  ipFamily: "ipv6" # Enables Dual-Stack IPv6 networking. Triggers automatic OIDC creation.
  nodeGroups:
    - nodegroupName: initial-nodegroup
      desiredSize: 2
      maxSize: 3
      minSize: 1
      instanceType: t3.medium
      diskSize: 20
      requestSpotInstances: false
      version: "1.33"
  privateAccess: false
  publicAccess: true
  secretsEncryption: false

Sous-réseau

Option Description

Standard : VPC et sous-réseau générés par Rancher

Lors du provisionnement de votre cluster, Rancher génère un nouveau VPC avec 3 sous-réseaux publics.

Personnalisé : Choisissez parmi votre VPC et vos sous-réseaux existants

Lors du provisionnement de votre cluster, Rancher configure votre plan de contrôle et vos nœuds pour utiliser un VPC et un sous-réseau que vous avez déjà créés dans AWS.

Pour plus d’informations, consultez la documentation AWS pour Considérations sur le VPC du cluster. Suivez l’un des ensembles d’instructions ci-dessous en fonction de votre sélection à l’étape précédente.

Avertissement pour les VPC personnalisés

Si vous avez sélectionné IPv6 comme votre famille IP et que vous apportez un VPC personnalisé, vous devez sélectionner des sous-réseaux Dual-Stack. Les sous-réseaux sélectionnés doivent avoir à la fois un bloc CIDR IPv4 et un bloc CIDR IPv6. Les sous-réseaux "IPv6 uniquement" ne sont pas pris en charge par EKS ; les nœuds de travail EC2 nécessitent toujours une adresse IPv4 pour rejoindre le cluster et communiquer avec les services AWS.

Groupe de sécurité

Documentation Amazon :

Consignation

Configurez les journaux du plan de contrôle pour les envoyer à Amazon CloudWatch. Vous êtes facturé des coûts standard d’ingestion et de stockage des données des journaux CloudWatch pour tous les journaux envoyés à CloudWatch Logs depuis vos clusters.

Chaque type de journal correspond à un composant du plan de contrôle Kubernetes. Pour en savoir plus sur ces composants, consultez Composants Kubernetes dans la documentation Kubernetes.

Pour plus d’informations sur la journalisation du plan de contrôle EKS, reportez-vous à la documentation officielle.

Groupes de nœuds gérés

Les groupes de nœuds gérés Amazon EKS automatisent le provisionnement et la gestion du cycle de vie des nœuds (instances Amazon EC2) pour les clusters Kubernetes Amazon EKS.

Pour plus d’informations sur le fonctionnement des groupes de nœuds et leur configuration, consultez la documentation EKS.

Modèles de lancement fournis par l’utilisateur

Vous pouvez fournir votre propre ID de modèle de lancement et version pour configurer les instances EC2 dans un groupe de nœuds. Si vous fournissez le modèle de lancement, aucun des paramètres du modèle ne sera configurable depuis Rancher. Vous devez définir toutes les options requises énumérées ci-dessous dans votre modèle de lancement.

De plus, si vous fournissez le modèle de lancement, vous ne pouvez mettre à jour que la version du modèle, pas l’ID du modèle. Pour utiliser un nouvel ID de modèle, créez un nouveau groupe de nœuds gérés.

Option Description Obligatoire/facultatif

Type d’instance

Choisissez les spécifications matérielles pour l’instance que vous provisionnez.

Requis

ID d’image

Spécifiez un AMI personnalisé pour les nœuds. Les AMIs personnalisés utilisés avec EKS doivent être configurés correctement

Facultatif

Taille du volume de nœud

Le modèle de lancement doit spécifier un volume EBS avec la taille souhaitée

Requis

Clé SSH

Une clé à ajouter aux instances pour fournir un accès SSH aux nœuds

Facultatif

Données utilisateur

Script d’initialisation cloud en format MIME multi-part

Facultatif

Étiquettes de ressources d’instance

Étiquetez chaque instance EC2 et ses volumes dans le groupe de nœuds

Facultatif

Vous ne pouvez pas mettre à jour directement un groupe de nœuds vers une version Kubernetes plus récente si le groupe de nœuds a été créé à partir d’un modèle de lancement personnalisé. Vous devez créer un nouveau modèle de lancement avec la version Kubernetes appropriée et associer le groupe de nœuds au nouveau modèle.

Modèles de lancement gérés par Rancher

Si vous ne spécifiez pas de modèle de lancement, vous pourrez configurer les options ci-dessus dans l’interface utilisateur de Rancher et toutes pourront être mises à jour après la création. Pour profiter de toutes ces options, Rancher créera et gérera un modèle de lancement pour vous. Chaque cluster dans Rancher aura un modèle de lancement géré par Rancher et chaque groupe de nœuds géré qui n’a pas de modèle de lancement spécifié aura une version du modèle de lancement géré. Le nom de ce modèle de lancement aura le préfixe "rancher-managed-lt-" suivi du nom d’affichage du cluster. De plus, le modèle de lancement géré par Rancher sera étiqueté avec la clé "rancher-managed-template" et la valeur "do-not-modify-or-delete" pour aider à l’identifier comme géré par Rancher. Il est important que ce modèle de lancement et ses versions ne soient pas modifiés, supprimés ou utilisés avec d’autres clusters ou groupes de nœuds gérés. Cela pourrait entraîner la "dégradation" de vos groupes de nœuds, nécessitant leur destruction et leur recréation.

AMIs personnalisés

Si vous spécifiez une AMI personnalisée, que ce soit dans un modèle de lancement ou dans Rancher, l’image doit être configurée correctement et vous devez fournir des données utilisateur pour démarrer le nœud. Ceci est considéré comme un cas d’utilisation avancé et comprendre les exigences est impératif.

Si vous spécifiez un modèle de lancement qui ne contient pas d’AMI personnalisée, Amazon utilisera l’AMI optimisée pour EKS pour la version de Kubernetes et la région sélectionnée. Vous pouvez également sélectionner une instance avec GPU activé pour les charges de travail qui en bénéficieraient.

Le paramètre d’instance avec GPU activé dans Rancher est ignoré si une AMI personnalisée est fournie, que ce soit dans le menu déroulant ou dans un modèle de lancement.

Instances Spot

Les instances Spot sont désormais prises en charge par EKS. Si un modèle de lancement est spécifié, Amazon recommande que le modèle ne fournisse pas de type d’instance. Au lieu de cela, Amazon recommande de fournir plusieurs types d’instances. Si la case "Demander des instances Spot" est activée pour un groupe de nœuds, vous aurez la possibilité de fournir plusieurs types d’instances.

Toute sélection que vous avez faite dans le menu déroulant des types d’instances sera ignorée dans cette situation et vous devez spécifier au moins un type d’instance dans la section "Types d’instances Spot". De plus, un modèle de lancement utilisé avec EKS ne peut pas demander d’instances Spot. La demande d’instances Spot doit faire partie de la configuration EKS.

Paramètres du groupe de nœuds

Les paramètres suivants sont également configurables. Tous ces paramètres, sauf le "Nom du groupe de nœuds", sont modifiables après la création du groupe de nœuds.

Option Description

Nom du groupe de nœuds

Le nom du groupe de nœuds.

Taille ASG souhaitée

Le nombre souhaité d’instances.

Taille ASG maximale

Le nombre maximal d’instances. Ce paramètre ne prendra effet qu’après l’installation du Cluster Autoscaler.

Taille ASG minimale

Le nombre minimal d’instances. Ce paramètre ne prendra effet qu’après l’installation du Cluster Autoscaler.

Libellés

Étiquettes Kubernetes appliquées aux nœuds du groupe de nœuds géré.

Balises

Ce sont des balises pour le groupe de nœuds géré et ne se propagent à aucune des ressources associées.

Nœuds Amazon Linux autogérés

Vous pouvez enregistrer un cluster EKS contenant des nœuds Amazon Linux autogérés. Vous devez configurer ce type de cluster selon les instructions de la documentation officielle AWS pour le lancement de nœuds Amazon Linux autogérés. Les clusters EKS contenant des nœuds Amazon Linux autogérés sont généralement gérés par le projet Karpenter. Après avoir provisionné un cluster EKS contenant des nœuds Amazon Linux autogérés, enregistrez le cluster afin qu’il puisse être géré par Rancher. Cependant, les nœuds ne seront pas visibles dans l’interface utilisateur de Rancher.

Rôles IAM pour les comptes de service

Un déploiement d’application fonctionnant sur un cluster EKS peut faire des demandes aux services AWS via des autorisations IAM. Ces applications doivent signer leurs demandes avec des identifiants AWS. Les rôles IAM pour les comptes de service gèrent ces identifiants en utilisant un point de terminaison OIDC AWS. Plutôt que de distribuer des identifiants AWS aux conteneurs ou de s’appuyer sur le rôle d’une instance EC2, vous pouvez lier un rôle IAM à un compte de service Kubernetes et configurer vos Pods pour utiliser ce compte.

La liaison à un rôle IAM n’est pas prise en charge pour les pods Rancher dans un cluster EKS.

Pour activer les rôles IAM pour les comptes de service :

  1. Créer un fournisseur OIDC IAM pour votre cluster

  2. Configurer un compte de service Kubernetes pour assumer un rôle IAM

  3. Configurer les Pods pour utiliser un compte de service Kubernetes

  4. Utiliser un SDK AWS pris en charge

Configuration de l’intervalle de rafraîchissement

Le paramètre eks-refresh-cron a cessé d’être pris en charge. Il a été migré vers le paramètre eks-refresh, qui est un entier représentant des secondes.

La valeur par défaut est de 300 secondes.

L’intervalle de synchronisation peut être modifié en exécutant kubectl edit setting eks-refresh.

Si le paramètre eks-refresh-cron était précédemment défini, la migration se fera automatiquement.

Plus la fenêtre de rafraîchissement est courte, moins il est probable que des conditions de concurrence se produisent, mais cela augmente la probabilité de rencontrer des limites de demande qui peuvent être en place pour les API AWS.