Mise en réseau personnalisée pour les pods - Amazon EKS
Étape 1 : créer un VPC test et un clusterÉtape 2 : configuration de votre VPCÉtape 3 : Configuration des ressources KubernetesÉtape 4 : déploiement de nœuds Amazon EC2Étape 5 : suppression des ressources du didacticiel

Aidez à améliorer cette page

Vous souhaitez contribuer à ce guide de l'utilisateur ? Faites défiler cette page vers le bas et sélectionnez Modifier cette page sur GitHub. Vos contributions aideront à améliorer notre guide de l'utilisateur pour tout le monde.

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.

Mise en réseau personnalisée pour les pods

Par défaut, lorsque le Amazon VPC CNI plugin for Kubernetes crée des interfaces réseau élastiques secondaires (interfaces réseau) pour votre nœud Amazon EC2, il les crée dans le même sous-réseau que l'interface réseau principale du nœud. Il associe également les mêmes groupes de sécurité à l'interface réseau secondaire, qui sont associés à l'interface réseau principale. Pour une ou plusieurs des raisons suivantes, vous voudrez peut-être que le plugin crée des interfaces réseau secondaires dans un sous-réseau différent ou associe différents groupes de sécurité aux interfaces réseau secondaires, ou les deux :

  • Il y a un nombre limité d'adresses IPv4 disponibles dans le sous-réseau dans lequel se trouve l'interface réseau principale. Cela peut limiter le nombre de Pods que vous pouvez créer dans le sous-réseau. En utilisant un sous-réseau différent pour les interfaces réseau secondaires, vous pouvez augmenter le nombre d'adresses IPv4 disponibles pour les Pods.

  • Pour des raisons de sécurité, vos Pods doivent utiliser d'autres groupes de sécurité ou sous-réseaux que l'interface réseau principale du nœud.

  • Les nœuds sont configurés dans des sous-réseaux publics et vous souhaitez placer les Pods dans des sous-réseaux privés. La table de routage associée à un sous-réseau public comprend une route vers une passerelle Internet. La table de routage associée à un sous-réseau privé ne comprend pas une route vers une passerelle Internet.

Considérations

  • Lorsque la mise en réseau personnalisée est activée, aucune adresse IP attribuée à l'interface réseau principale n'est affectée aux Pods. Seules les adresses IP des interfaces réseau secondaires sont attribuées aux Pods.

  • Si votre cluster utilise la famille IPv6, vous ne pouvez pas utiliser de mise en réseau personnalisée.

  • Si vous prévoyez d'utiliser une mise en réseau personnalisée uniquement pour pallier à l'épuisement des adresses IPv4, vous pouvez plutôt créer un cluster à l'aide de la famille IPv6. Pour plus d’informations, consultez IPv6adresses pour les clustersPods, et services.

  • Même si les Pods déployés sur des sous-réseaux spécifiés pour les interfaces réseau secondaires peuvent utiliser des sous-réseaux et des groupes de sécurité différents de ceux de l'interface réseau principale du nœud, les sous-réseaux et les groupes de sécurité doivent se trouver dans le même VPC que le nœud.

Prérequis

  • Maîtriser la façon dont le Amazon VPC CNI plugin for Kubernetes crée des interfaces réseau secondaires et attribue des adresses IP aux Pods. Pour de plus amples informations, veuillez consulter Allocation ENI sur GitHub.

  • Version 2.12.3 ou ultérieure ou version 1.27.160 ou ultérieure du AWS Command Line Interface (AWS CLI) installé et configuré sur votre appareil ou AWS CloudShell. Pour vérifier votre version actuelle, utilisez aws --version | cut -d / -f2 | cut -d ' ' -f1. Les gestionnaires de package, par exemple yum, apt-get, Homebrew ou macOS, sont souvent antérieurs de plusieurs versions à la AWS CLI. Pour installer la dernière version, consultez Installation, mise à jour et désinstallation de l’ AWS CLI et Configuration rapide avec aws configure dans le Guide de l’utilisateur AWS Command Line Interface . La AWS CLI version installée AWS CloudShell peut également avoir plusieurs versions de retard par rapport à la dernière version. Pour le mettre à jour, consultez la section Installation AWS CLI dans votre répertoire personnel dans le guide de AWS CloudShell l'utilisateur.

  • L'outil de ligne de commande kubectl est installé sur votre appareil ou AWS CloudShell. La version peut être identique à la version Kubernetes de votre cluster ou être maximum une version mineure antérieure ou ultérieure. Par exemple, si la version de votre cluster est 1.29, vous pouvez utiliser la version kubectl 1.28, 1.29 ou 1.30. Pour installer ou mettre à niveau kubectl, veuillez consulter Installation ou mise à jour de kubectl.

  • Nous vous recommandons de terminer les étapes de cette rubrique dans un shell Bash. Si vous n'utilisez pas de shell Bash, certaines commandes de script telles que les caractères de continuation de ligne et la façon dont les variables sont définies et utilisées nécessitent un ajustement pour votre shell. En outre, les règles de votre shell en matière de guillemets peuvent être différentes. Pour plus d'informations, consultez la section Utilisation de guillemets avec des chaînes AWS CLI dans le Guide de AWS Command Line Interface l'utilisateur.

Pour ce tutoriel, nous vous recommandons d'utiliser les example values, sauf lorsqu'il est noté de les remplacer. Vous pouvez remplacer n'importe quel example value lors des étapes propres à un cluster de production. Nous vous recommandons de terminer toutes les étapes dans le même terminal. En effet, les variables sont définies et utilisées tout au long des étapes et n'existent pas dans différents terminaux.

Les commandes de cette rubrique sont mises en forme selon les conventions répertoriées dans Utilisation des AWS CLI exemples. Si vous exécutez des commandes depuis la ligne de commande sur des ressources dont la valeur est différente de Région AWS celle Région AWS définie par défaut dans le AWS CLI profil que vous utilisez, vous devez les ajouter --region region-code aux commandes.

Lorsque vous souhaitez déployer une mise en réseau personnalisée sur votre cluster de production, passez à Étape 2 : configuration de votre VPC.

Étape 1 : créer un VPC test et un cluster

Pour créer un cluster

Les procédures suivantes vous aident à créer un VPC test et un cluster et à configurer une mise en réseau personnalisée pour ce cluster. Nous ne recommandons pas d'utiliser le cluster test pour les charges de travail de production, car plusieurs fonctionnalités non liées que vous pouvez utiliser sur votre cluster de production ne sont pas couvertes dans cette rubrique. Pour plus d’informations, consultez Création d'un cluster Amazon EKS.

  1. Définissez quelques variables à utiliser dans les étapes restantes.

    export cluster_name=my-custom-networking-cluster
account_id=$(aws sts get-caller-identity --query Account --output text)

  2. Créez un VPC.

    1. Créez un VPC à l'aide d'un modèle Amazon EKS AWS CloudFormation .

      aws cloudformation create-stack --stack-name my-eks-custom-networking-vpc \
  --template-url https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/amazon-eks-vpc-private-subnets.yaml \
  --parameters ParameterKey=VpcBlock,ParameterValue=192.168.0.0/24 \
  ParameterKey=PrivateSubnet01Block,ParameterValue=192.168.0.64/27 \
  ParameterKey=PrivateSubnet02Block,ParameterValue=192.168.0.96/27 \
  ParameterKey=PublicSubnet01Block,ParameterValue=192.168.0.0/27 \
  ParameterKey=PublicSubnet02Block,ParameterValue=192.168.0.32/27

      La création de la AWS CloudFormation pile prend quelques minutes. Utilisez la commande suivante pour vérifier le statut du déploiement de la pile.

      aws cloudformation describe-stacks --stack-name my-eks-custom-networking-vpc --query Stacks\[\].StackStatus  --output text

      Ne passez pas à l'étape suivante tant que la sortie de la commande n'est pas CREATE_COMPLETE.

    2. Définissez des variables avec les valeurs des ID de sous-réseau privé créés par le modèle.

      subnet_id_1=$(aws cloudformation describe-stack-resources --stack-name my-eks-custom-networking-vpc \
    --query "StackResources[?LogicalResourceId=='PrivateSubnet01'].PhysicalResourceId" --output text)
subnet_id_2=$(aws cloudformation describe-stack-resources --stack-name my-eks-custom-networking-vpc \
    --query "StackResources[?LogicalResourceId=='PrivateSubnet02'].PhysicalResourceId" --output text)

    3. Définissez des variables avec les zones de disponibilité des sous-réseaux récupérés lors de l'étape précédente.

      az_1=$(aws ec2 describe-subnets --subnet-ids $subnet_id_1 --query 'Subnets[*].AvailabilityZone' --output text)
az_2=$(aws ec2 describe-subnets --subnet-ids $subnet_id_2 --query 'Subnets[*].AvailabilityZone' --output text)

  3. Créez un rôle IAM de cluster.

    1. Exécutez la commande suivante pour créer un fichier JSON de politique d'approbation IAM. 

      cat >eks-cluster-role-trust-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "eks.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
EOF

    2. Créez le rôle IAM de cluster Amazon EKS. Si nécessaire, faites précéder eks-cluster-role-trust-policy.json par le chemin d'accès sur votre ordinateur sur lequel vous avez enregistré le fichier lors de l'étape précédente. La commande associe la politique d'approbation que vous avez créée lors de l'étape précédente à ce rôle. Pour créer un rôle IAM, le principal IAM qui crée le rôle doit se voir attribuer l'action (autorisation) IAM iam:CreateRole.

      aws iam create-role --role-name myCustomNetworkingAmazonEKSClusterRole --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"

    3. Attachez la politique gérée par Amazon EKS appelée AmazonEKSClusterPolicy au rôle. Pour attacher une politique IAM à un principal IAM, le principal qui attache la politique doit se voir attribuer l'une des actions (autorisations) IAM iam:AttachUserPolicy ou iam:AttachRolePolicy.

      aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy --role-name myCustomNetworkingAmazonEKSClusterRole

  4. Créez un cluster Amazon EKS et configurez votre appareil pour qu'il communique avec lui.

    1. Créer un cluster.

      aws eks create-cluster --name my-custom-networking-cluster \
   --role-arn arn:aws:iam::$account_id:role/myCustomNetworkingAmazonEKSClusterRole \
   --resources-vpc-config subnetIds=$subnet_id_1","$subnet_id_2
      Note

      Il est possible que vous receviez un message d'erreur indiquant que l'une des zones de disponibilité de votre demande ne dispose pas d'une capacité suffisante pour créer un cluster Amazon EKS. Si cela se produit, la sortie de l'erreur contient les zones de disponibilité qui peuvent prendre en charge un nouveau cluster. Essayez à nouveau de créer votre cluster avec au moins deux sous-réseaux situés dans les zones de disponibilité prises en charge pour votre compte. Pour plus d’informations, consultez Capacité insuffisante.

    2. La création du cluster prend quelques minutes. Utilisez la commande suivante pour vérifier le statut du déploiement du cluster.

      aws eks describe-cluster --name my-custom-networking-cluster --query cluster.status

      Ne passez pas à l'étape suivante tant que la sortie de la commande n'est pas "ACTIVE".

    3. Configurez kubectl pour communiquer avec votre cluster.

      aws eks update-kubeconfig --name my-custom-networking-cluster

Étape 2 : configuration de votre VPC

Dans ce didacticiel, vous devez disposer du VPC créé dans Étape 1 : créer un VPC test et un cluster. Pour un cluster de production, ajustez les étapes en conséquence pour votre VPC en remplaçant toutes les example values par vos propres valeurs.

  1. Confirmez que la version de votre Amazon VPC CNI plugin for Kubernetes actuellement installée est la plus récente. Pour déterminer la version la plus récente du type de module complémentaire Amazon EKS et mettre à jour votre version en conséquence, consultez Mise à jour d'un module complémentaire. Pour déterminer la version la plus récente du type de module complémentaire autogéré et mettre à jour votre version en conséquence, consultez Utilisation du module complémentaire Amazon VPC CNI plugin for Kubernetes Amazon EKS.

  2. Récupérez l'ID du VPC de votre cluster et stockez-le dans une variable pour une utilisation ultérieure. Pour un cluster de production, remplacez my-custom-networking-cluster par le nom de votre cluster.

    vpc_id=$(aws eks describe-cluster --name my-custom-networking-cluster --query "cluster.resourcesVpcConfig.vpcId" --output text)

  3. Associez un bloc de routage inter-domaines sans classe (CIDR) supplémentaire au VPC de votre cluster. Le bloc CIDR ne peut pas se chevaucher avec des blocs CIDR associés existants.

    1. Affichez les blocs CIDR actuels associés à votre VPC.

      aws ec2 describe-vpcs --vpc-ids $vpc_id \
    --query 'Vpcs[*].CidrBlockAssociationSet[*].{CIDRBlock: CidrBlock, State: CidrBlockState.State}' --out table

      L'exemple qui suit illustre un résultat.

      ----------------------------------
|          DescribeVpcs          |
+-----------------+--------------+
|    CIDRBlock    |    State     |
+-----------------+--------------+
|  192.168.0.0/24 |  associated  |
+-----------------+--------------+

    2. Associez un bloc CIDR supplémentaire à votre VPC. Pour plus d'informations, veuillez consulter la section Associer des blocs d'adresse CIDR IPv4 supplémentaires à votre VPC dans le Guide de l'utilisateur Amazon VPC.

      aws ec2 associate-vpc-cidr-block --vpc-id $vpc_id --cidr-block 192.168.1.0/24

    3. Vérifiez que le nouveau bloc est associé.

      aws ec2 describe-vpcs --vpc-ids $vpc_id --query 'Vpcs[*].CidrBlockAssociationSet[*].{CIDRBlock: CidrBlock, State: CidrBlockState.State}' --out table

      L'exemple qui suit illustre un résultat.

      ----------------------------------
|          DescribeVpcs          |
+-----------------+--------------+
|    CIDRBlock    |    State     |
+-----------------+--------------+
|  192.168.0.0/24 |  associated  |
|  192.168.1.0/24 |  associated  |
+-----------------+--------------+

    Ne passez pas à l'étape suivante tant que le State de votre nouveau bloc CIDR n'est pas associated.

  4. Créez autant de sous-réseaux que vous souhaitez utiliser dans chaque zone de disponibilité dans laquelle se trouvent vos sous-réseaux existants. Spécifiez un bloc CIDR qui se trouve dans le bloc CIDR que vous avez associé à votre VPC lors d'une étape précédente.

    1. Créez de nouveaux sous-réseaux. Les sous-réseaux doivent être créés dans un bloc CIDR VPC différent de celui de vos sous-réseaux existants, mais dans les mêmes zones de disponibilité que vos sous-réseaux existants. Dans cet exemple, un sous-réseau est créé dans le nouveau bloc CIDR de chaque zone de disponibilité dans laquelle les sous-réseaux privés actuels existent. Les ID des sous-réseaux créés sont stockés dans des variables pour être utilisés ultérieurement. Les valeurs Name correspondent aux valeurs affectées aux sous-réseaux créés à l'aide du modèle Amazon EKS VPC lors d'une étape précédente. Les noms ne sont pas obligatoires. Vous pouvez utiliser des noms différents. 

      new_subnet_id_1=$(aws ec2 create-subnet --vpc-id $vpc_id --availability-zone $az_1 --cidr-block 192.168.1.0/27 \
    --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=my-eks-custom-networking-vpc-PrivateSubnet01},{Key=kubernetes.io/role/internal-elb,Value=1}]' \
    --query Subnet.SubnetId --output text)
new_subnet_id_2=$(aws ec2 create-subnet --vpc-id $vpc_id --availability-zone $az_2 --cidr-block 192.168.1.32/27 \
    --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=my-eks-custom-networking-vpc-PrivateSubnet02},{Key=kubernetes.io/role/internal-elb,Value=1}]' \
    --query Subnet.SubnetId --output text)
      Important

      Par défaut, vos nouveaux sous-réseaux sont implicitement associés à la table de routage principale de votre VPC. Cette table de routage permet la communication entre toutes les ressources déployées dans le VPC. Toutefois, elle n'autorise pas la communication avec des ressources dont les adresses IP se trouvent en dehors des blocs CIDR associés à votre VPC. Vous pouvez associer votre propre table de routage à vos sous-réseaux pour modifier ce comportement. Pour plus d'informations, consultez Tables de routage de sous-réseau dans le Guide de l'utilisateur Amazon VPC.

    2. Affichez les sous-réseaux actuels dans votre VPC.

      aws ec2 describe-subnets --filters "Name=vpc-id,Values=$vpc_id" \
    --query 'Subnets[*].{SubnetId: SubnetId,AvailabilityZone: AvailabilityZone,CidrBlock: CidrBlock}' \
    --output table

      L'exemple qui suit illustre un résultat.

      ----------------------------------------------------------------------
|                           DescribeSubnets                          |
+------------------+--------------------+----------------------------+
| AvailabilityZone |     CidrBlock      |         SubnetId           |
+------------------+--------------------+----------------------------+
|  us-west-2d      |  192.168.0.0/27    |     subnet-example1        |
|  us-west-2a      |  192.168.0.32/27   |     subnet-example2        |
|  us-west-2a      |  192.168.0.64/27   |     subnet-example3        |
|  us-west-2d      |  192.168.0.96/27   |     subnet-example4        |
|  us-west-2a      |  192.168.1.0/27    |     subnet-example5        |
|  us-west-2d      |  192.168.1.32/27   |     subnet-example6        |
+------------------+--------------------+----------------------------+

      Vous pouvez voir que les sous-réseaux se trouvant dans le bloc CIDR 192.168.1.0 que vous avez créé se trouvent dans les mêmes zones de disponibilité que les sous-réseaux dans le bloc d'adresse CIDR 192.168.0.0.

Étape 3 : Configuration des ressources Kubernetes

Pour configurer les ressources Kubernetes

  1. Définissez la variable d'environnement AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG sur true dans le aws-node DaemonSet.

    kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true

  2. Récupérez l'ID de votre groupe de sécurité de cluster et stockez-le dans une variable pour une utilisation ultérieure. Amazon EKS crée automatiquement ce groupe de sécurité lorsque vous créez votre cluster.

    cluster_security_group_id=$(aws eks describe-cluster --name $cluster_name --query cluster.resourcesVpcConfig.clusterSecurityGroupId --output text)

  3. Créez une ressource personnalisée ENIConfig pour chaque sous-réseau dans lequel vous souhaitez déployer les Pods.

    1. Créez un fichier unique pour chaque configuration d'interface réseau.

      Les commandes suivantes créent des fichiers ENIConfig distincts pour les deux sous-réseaux créés à l'étape précédente. La valeur pour name doit être unique. Le nom est le même que la zone de disponibilité dans laquelle se trouve le sous-réseau. Le groupe de sécurité de cluster est affecté au ENIConfig.

      cat >$az_1.yaml <<EOF
apiVersion: crd.k8s.amazonaws.com/v1alpha1
kind: ENIConfig
metadata: 
  name: $az_1
spec: 
  securityGroups: 
    - $cluster_security_group_id
  subnet: $new_subnet_id_1
EOF

      cat >$az_2.yaml <<EOF
apiVersion: crd.k8s.amazonaws.com/v1alpha1
kind: ENIConfig
metadata: 
  name: $az_2
spec: 
  securityGroups: 
    - $cluster_security_group_id
  subnet: $new_subnet_id_2
EOF

      Pour un cluster de production, vous pouvez apporter les modifications suivantes aux commandes précédentes :

      • Remplacez $cluster_security_group_id par l'ID d'un groupe de sécurité existant que vous souhaitez utiliser pour chaque ENIConfig.

      • Nous vous recommandons de nommer vos ENIConfigs de la même façon que la zone de disponibilité pour laquelle vous allez utiliser le ENIConfig, chaque fois que c'est possible. Vous devrez peut-être utiliser pour vos ENIConfigs des noms différents de ceux des zones de disponibilité pour diverses raisons. Par exemple, si vous avez plus de deux sous-réseaux dans la même zone de disponibilité et que vous souhaitez les utiliser tous les deux avec une mise en réseau personnalisée, vous avez besoin de plusieurs ENIConfigs pour la même zone de disponibilité. Puisque chaque ENIConfig nécessite un nom unique, vous ne pouvez nommer plus d'un de vos ENIConfigs en utilisant le nom de la zone de disponibilité.

        Si vos noms ENIConfig ne sont pas tous les mêmes que les noms de zone de disponibilité, remplacez $az_1 et $az_2 par vos propres noms dans les commandes précédentes et annotez vos nœuds avec le ENIConfig plus tard dans ce didacticiel.

      Note

      Si vous ne spécifiez pas de groupe de sécurité valide à utiliser avec un cluster de production et que vous utilisez :

      • la version 1.8.0 ou une version ultérieure du Amazon VPC CNI plugin for Kubernetes, alors les groupes de sécurité associés à l'interface réseau Elastic principale du nœud sont utilisés.

      • une version du Amazon VPC CNI plugin for Kubernetes antérieure à la version 1.8.0, le groupe de sécurité par défaut du VPC est attribué aux interfaces réseau secondaires.

      Important

      • AWS_VPC_K8S_CNI_EXTERNALSNAT=false est un paramètre par défaut dans la configuration du plugin CNI Amazon VPC pour Kubernetes. Si vous utilisez le paramètre par défaut, le trafic destiné aux adresses IP qui ne se trouvent pas dans l'un des blocs CIDR associés à votre VPC utilise les groupes de sécurité et les sous-réseaux de l'interface réseau principale de votre nœud. Les sous-réseaux et les groupes de sécurité définis dans vos ENIConfigs qui sont utilisés pour créer des interfaces réseau secondaires ne sont pas utilisées pour ce trafic. Pour plus d'informations sur ce paramètre, consultez SNAT pour Pods.

      • Si vous utilisez également des groupes de sécurité pour des Pods, le groupe de sécurité spécifié dans un SecurityGroupPolicy est utilisé à la place du groupe de sécurité spécifié dans les ENIConfigs. Pour plus d’informations, consultez Groupes de sécurité pour Pods.

    2. Appliquez chaque fichier de ressource personnalisé que vous avez créé à votre cluster à l'aide des commandes suivantes.

      kubectl apply -f $az_1.yaml
kubectl apply -f $az_2.yaml

  4. Confirmez que vos ENIConfigs ont été créés.

    kubectl get ENIConfigs

    L'exemple qui suit illustre un résultat.

    NAME         AGE
us-west-2a   117s
us-west-2d   105s

  5. Si vous activez la mise en réseau personnalisée sur un cluster de production et que vous avez nommé vos ENIConfigs autrement qu'avec le nom de la zone de disponibilité pour laquelle vous les utilisez, passez à l'étape suivante pour déployer des nœuds Amazon EC2.

    Permettez à Kubernetes d'appliquer automatiquement le ENIConfig pour une zone de disponibilité pour tous les nouveaux nœuds Amazon EC2 créés dans votre cluster.

    1. Pour le cluster test de ce didacticiel, passez à l'étape suivante.

      Pour un cluster de production, vérifiez si une annotation avec clé k8s.amazonaws.com/eniConfig pour la variable d'environnement ENI_CONFIG_ANNOTATION_DEF existe dans la spécification du conteneur pour le aws-node DaemonSet.

      kubectl describe daemonset aws-node -n kube-system | grep ENI_CONFIG_ANNOTATION_DEF

      Si la sortie est renvoyée, l'annotation existe. Si aucune sortie n'est renvoyée, la variable n'est pas définie. Pour un cluster de production, vous pouvez utiliser ce paramètre ou le paramètre de l'étape suivante. Si vous utilisez ce paramètre, il remplace le paramètre de l'étape suivante. Dans ce didacticiel, le paramètre de l'étape suivante est utilisé.

    2. Mettez à jour votre aws-node DaemonSet pour appliquer automatiquement le ENIConfig pour une zone de disponibilité pour tous les nouveaux nœuds Amazon EC2 créés dans votre cluster.

      kubectl set env daemonset aws-node -n kube-system ENI_CONFIG_LABEL_DEF=topology.kubernetes.io/zone

Étape 4 : déploiement de nœuds Amazon EC2

Pour déployer des nœuds Amazon EC2

  1. Créez un rôle IAM de nœud.

    1. Exécutez la commande suivante pour créer un fichier JSON de politique d'approbation IAM.

      cat >node-role-trust-relationship.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
EOF

    2. Exécutez la commande suivante pour définir une variable pour votre nom de rôle. Vous pouvez remplacer myCustomNetworkingAmazonEKSNodeRole par n'importe quel nom que vous choisissez.

      export node_role_name=myCustomNetworkingAmazonEKSNodeRole

    3. Créez le rôle IAM et stockez son Amazon Resource Name (ARN) renvoyé dans une variable pour une utilisation ultérieure.

      node_role_arn=$(aws iam create-role --role-name $node_role_name --assume-role-policy-document file://"node-role-trust-relationship.json" \
    --query Role.Arn --output text)

    4. Attachez trois politiques gérées IAM requises au rôle IAM.

      aws iam attach-role-policy \
  --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy \
  --role-name $node_role_name
aws iam attach-role-policy \
  --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly \
  --role-name $node_role_name
aws iam attach-role-policy \
    --policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy \
    --role-name $node_role_name
      Important

      Pour simplifier ce tutoriel, la politique AmazonEKS_CNI_Policy est attachée au nœud du rôle IAM. Toutefois, dans un cluster de production, nous recommandons de rattacher la politique à un rôle IAM distinct utilisé uniquement avec le Amazon VPC CNI plugin for Kubernetes. Pour plus d’informations, consultez Configuration de l'utilisation Amazon VPC CNI plugin for Kubernetes des rôles IAM pour les comptes de service (IRSA).

  2. Créez l'un des types de groupes de nœuds suivants. Pour déterminer le type d'instance que vous souhaitez déployer, consultez Choix d'un type d'instance Amazon EC2. Pour ce didacticiel, terminez l'option Gérée, Sans modèle de lancement ou avec un modèle de lancement sans ID d'AMI spécifié. Si vous comptez utiliser le groupe de nœuds pour les charges de travail de production, nous vous recommandons de vous familiariser avec toutes les options de groupe de nœuds gérés et autogérés avant de déployer le groupe de nœuds.

    • Géré : déployez votre groupe de nœuds à l'aide de l'une des options suivantes :

      • Sans modèle de lancement ou avec un modèle de lancement sans ID d'AMI spécifié : exécutez la commande suivante. Pour ce didacticiel, utilisez example values. Pour un groupe de nœuds de production, remplacez toutes les example values par vos propres valeurs. Le nom du groupe de nœuds ne peut pas dépasser 63 caractères. Il doit commencer par une lettre ou un chiffre, mais peut également inclure des tirets et des traits de soulignement pour les autres caractères.

        aws eks create-nodegroup --cluster-name $cluster_name --nodegroup-name my-nodegroup \
    --subnets $subnet_id_1 $subnet_id_2 --instance-types t3.medium --node-role $node_role_arn

      • Avec un modèle de lancement avec un ID AMI spécifié

        1. Déterminez le nombre maximal de Pods recommandé par Amazon EKS pour vos nœuds. Suivez les instructions de la section Nombre maximal de Pods recommandé par Amazon EKS pour chaque type d'instance Amazon EC2, en ajoutant --cni-custom-networking-enabled à l'étape 3 de cette rubrique. Notez la sortie pour l'utiliser lors de l'étape suivante.

        2. Dans votre modèle de lancement, spécifiez un ID d'AMI optimisé pour Amazon EKS ou une AMI personnalisée créée à partir de l'AMI optimisée pour Amazon EKS, puis déployez le groupe de nœuds avec un modèle de lancement et fournissez les données utilisateur suivantes dans le modèle de lancement. Ces données utilisateur transmettent des arguments dans le fichier bootstrap.sh. Pour plus d'informations sur le fichier d'amorçage, consultez bootstrap.sh sur GitHub. Vous pouvez remplacer 20 par la valeur de l'étape précédente (recommandé) ou par votre propre valeur.

          /etc/eks/bootstrap.sh my-cluster --use-max-pods false --kubelet-extra-args '--max-pods=20'

          Si vous avez créé une AMI personnalisée qui n'est pas créée à partir de l'AMI optimisée pour Amazon EKS, vous devez créer vous-même la configuration.

    • Autogéré

      1. Déterminez le nombre maximal de Pods recommandé par Amazon EKS pour vos nœuds. Suivez les instructions de la section Nombre maximal de Pods recommandé par Amazon EKS pour chaque type d'instance Amazon EC2, en ajoutant --cni-custom-networking-enabled à l'étape 3 de cette rubrique. Notez la sortie pour l'utiliser lors de l'étape suivante.

      2. Déployez le groupe de nœuds à l'aide des instructions contenues dans Lancement de nœuds Amazon Linux autogérés. Spécifiez le texte suivant pour le BootstrapArgumentsparamètre. Vous pouvez remplacer 20 par la valeur de l'étape précédente (recommandé) ou par votre propre valeur.

        --use-max-pods false --kubelet-extra-args '--max-pods=20'
    Note

    Si vous souhaitez que les nœuds d'un cluster de production prennent en charge un nombre significativement plus élevé de Pods, exécutez à nouveau le script dans Nombre maximal de Pods recommandé par Amazon EKS pour chaque type d'instance Amazon EC2. Ajoutez également l'option --cni-prefix-delegation-enabled à la commande. Par exemple, 110 est renvoyé pour un type d'instance m5.large. Pour obtenir des instructions sur la façon d'activer cette capacité, consultez Augmenter le nombre d'adresses IP disponibles pour vos nœuds Amazon EC2. Vous pouvez utiliser cette capacité avec une mise en réseau personnalisée.

    La création d'un groupe de nœuds dure plusieurs minutes. Vous pouvez vérifier l'état de la création d'un groupe de nœuds géré à l'aide de la commande suivante.

    aws eks describe-nodegroup --cluster-name $cluster_name --nodegroup-name my-nodegroup --query nodegroup.status --output text

    Ne passez pas à l'étape suivante tant que la sortie retournée n'est pas ACTIVE.

  3. Pour le didacticiel, vous pouvez ignorer cette étape.

    Pour un cluster de production, si vous n'avez pas nommé vos ENIConfigs de la même manière que la zone de disponibilité pour laquelle vous les utilisez, vous devez annoter vos nœuds avec le nom ENIConfig qui doit être utilisé avec le nœud. Cette étape n'est pas nécessaire si vous n'avez qu'un seul sous-réseau dans chaque zone de disponibilité et que vous avez nommé vos ENIConfigs avec les mêmes noms que vos zones de disponibilité. Cela est dû au fait que le Amazon VPC CNI plugin for Kubernetes associe automatiquement le bon ENIConfig avec le bon nœud si vous l'y avez autorisé lors d'une étape précédente.

    1. Obtenez la liste des nœuds de votre cluster.

      kubectl get nodes

      L'exemple qui suit illustre un résultat.

      NAME                                          STATUS   ROLES    AGE     VERSION
ip-192-168-0-126.us-west-2.compute.internal   Ready    <none>   8m49s   v1.22.9-eks-810597c
ip-192-168-0-92.us-west-2.compute.internal    Ready    <none>   8m34s   v1.22.9-eks-810597c

    2. Déterminez dans quelle zone de disponibilité se trouve chaque nœud. Exécutez la commande suivante pour chaque nœud qui a été renvoyé lors de l'étape précédente.

      aws ec2 describe-instances --filters Name=network-interface.private-dns-name,Values=ip-192-168-0-126.us-west-2.compute.internal \
--query 'Reservations[].Instances[].{AvailabilityZone: Placement.AvailabilityZone, SubnetId: SubnetId}'

      L'exemple qui suit illustre un résultat.

      [
    {
        "AvailabilityZone": "us-west-2d",
        "SubnetId": "subnet-Example5"
    }
]

    3. Annotez chaque nœud avec le ENIConfig que vous avez créé pour l'ID de sous-réseau et la zone de disponibilité. Vous ne pouvez annoter un nœud qu'avec un seul ENIConfig, bien que plusieurs nœuds puissent être annotés avec le même ENIConfig. Remplacez les example values par vos propres valeurs.

      kubectl annotate node ip-192-168-0-126.us-west-2.compute.internal k8s.amazonaws.com/eniConfig=EniConfigName1
kubectl annotate node ip-192-168-0-92.us-west-2.compute.internal k8s.amazonaws.com/eniConfig=EniConfigName2

  4. Si vous aviez des nœuds dans un cluster de production avec des Pods en cours d'exécution avant de passer à l'utilisation de la fonctionnalité de mise en réseau personnalisée, exécutez les tâches suivantes :

    1. Assurez-vous que vous disposez de nœuds disponibles utilisant la fonctionnalité de mise en réseau personnalisée.

    2. Bouclez et videz les nœuds pour arrêter gracieusement les Pods. Pour plus d'informations, consultez Drainer un nœud en toute sécurité dans la documentation Kubernetes.

    3. Mettez fin aux nœuds. Si les nœuds se trouvent dans un groupe de nœuds géré existant, vous pouvez supprimer le groupe de nœuds. Copiez la commande qui suit sur votre appareil. Si nécessaire, apportez les modifications suivantes à la commande, puis exécutez la commande modifiée :

      • Remplacez my-cluster par le nom de votre cluster.

      • Remplacez my-nodegroup par le nom de votre groupe de nœuds.

      aws eks delete-nodegroup --cluster-name my-cluster --nodegroup-name my-nodegroup

    Seuls les nouveaux nœuds enregistrés auprès du label k8s.amazonaws.com/eniConfig utilisent la fonctionnalité de réseaux personnalisés.

  5. Confirmez que les Pods se voient attribuer une adresse IP à partir d'un bloc CIDR associé à l'un des sous-réseaux que vous avez créés lors d'une étape précédente.

    kubectl get pods -A -o wide

    L'exemple qui suit illustre un résultat.

    NAMESPACE     NAME                       READY   STATUS    RESTARTS   AGE     IP              NODE                                          NOMINATED NODE   READINESS GATES
kube-system   aws-node-2rkn4             1/1     Running   0          7m19s   192.168.0.92    ip-192-168-0-92.us-west-2.compute.internal    <none>           <none>
kube-system   aws-node-k96wp             1/1     Running   0          7m15s   192.168.0.126   ip-192-168-0-126.us-west-2.compute.internal   <none>           <none>
kube-system   coredns-657694c6f4-smcgr   1/1     Running   0          56m     192.168.1.23    ip-192-168-0-92.us-west-2.compute.internal    <none>           <none>
kube-system   coredns-657694c6f4-stwv9   1/1     Running   0          56m     192.168.1.28    ip-192-168-0-92.us-west-2.compute.internal    <none>           <none>
kube-system   kube-proxy-jgshq           1/1     Running   0          7m19s   192.168.0.92    ip-192-168-0-92.us-west-2.compute.internal    <none>           <none>
kube-system   kube-proxy-wx9vk           1/1     Running   0          7m15s   192.168.0.126   ip-192-168-0-126.us-west-2.compute.internal   <none>           <none>

    Vous pouvez voir que les Pods coredns sont attribuées à des adresses IP à partir du bloc d'adresse CIDR 192.168.1.0 que vous avez ajouté à votre VPC. Sans mise en réseau personnalisée, des adresses auraient été attribuées à partir du bloc CIDR 192.168.0.0, car il s'agissait du seul bloc CIDR initialement associé au VPC.

    Si un spec Pod's contient hostNetwork=true, l'adresse IP principale du nœud lui est attribuée. Aucune adresse ne lui est attribuée à partir des sous-réseaux que vous avez ajoutés. Par défaut, cette valeur indique false. Cette valeur est définie sur true pour le kube-proxy et les Pods du Amazon VPC CNI plugin for Kubernetes (aws-node) qui s'exécutent sur votre cluster. C'est pourquoi le kube-proxy et les Pods du plugin aws-node n'ont pas d'adresses 192.168.1.x attribuées dans la sortie précédente. Pour plus d'informations sur un Pod's hostNetwork paramètre, voir PodSpec v1 core dans la référence de l'KubernetesAPI.

Étape 5 : suppression des ressources du didacticiel

Une fois le didacticiel terminé, nous vous recommandons de supprimer les ressources que vous avez créées. Vous pouvez ensuite ajuster les étapes pour activer la mise en réseau personnalisée pour un cluster de production.

Pour supprimer les ressources du didacticiel

  1. Si le groupe de nœuds que vous avez créé n'était qu'à des fins de test, supprimez-le.

    aws eks delete-nodegroup --cluster-name $cluster_name --nodegroup-name my-nodegroup

    Même une fois que le AWS CLI résultat indique que le cluster est supprimé, le processus de suppression peut ne pas être terminé. Le processus de suppression prend quelques minutes. Vérifiez qu'il est terminé en exécutant la commande suivante.

    aws eks describe-nodegroup --cluster-name $cluster_name --nodegroup-name my-nodegroup --query nodegroup.status --output text

    Ne continuez pas tant que la sortie renvoyée n'est pas similaire à la sortie suivante.

    An error occurred (ResourceNotFoundException) when calling the DescribeNodegroup operation: No node group found for name: my-nodegroup.

  2. Si le groupe de nœuds que vous avez créé n'était qu'à des fins de test, supprimez le rôle IAM du nœud.

    1. Détachez les politiques du rôle.

      aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy

    2. Supprimez le rôle.

      aws iam delete-role --role-name myCustomNetworkingAmazonEKSNodeRole

  3. Supprimez le cluster.

    aws eks delete-cluster --name $cluster_name

    Vérifiez que le cluster est supprimé avec la commande suivante.

    aws eks describe-cluster --name $cluster_name --query cluster.status --output text

    Lorsqu'une sortie similaire à la suivante est renvoyée, le cluster est correctement supprimé.

    An error occurred (ResourceNotFoundException) when calling the DescribeCluster operation: No cluster found for name: my-cluster.

  4. Supprimez le rôle IAM de cluster.

    1. Détachez les politiques du rôle.

      aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSClusterRole --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy

    2. Supprimez le rôle.

      aws iam delete-role --role-name myCustomNetworkingAmazonEKSClusterRole

  5. Supprimez les sous-réseaux que vous avez créés à l'étape précédente.

    aws ec2 delete-subnet --subnet-id $new_subnet_id_1
aws ec2 delete-subnet --subnet-id $new_subnet_id_2

  6. Supprimez le VPC que vous avez créé.

    aws cloudformation delete-stack --stack-name my-eks-custom-networking-vpc