Personnalisation de l’interface réseau secondaire sur les nœuds Amazon EKS

Si vous effectuez un déploiement sur un système de test, 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 l’état 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 le résultat de la commande n’est pas CREATE_COMPLETE.

Définissez les variables avec les valeurs du sous-réseau privé IDs créé 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)

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)

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

{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "eks.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

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"

Associez la politique gérée par Amazon EKS nommée Amazon EKSCluster Policy 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

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"

La création du cluster prend quelques minutes. Utilisez la commande suivante pour vérifier l’état 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 le résultat de la commande n’est pas "ACTIVE".

Configurez kubectl pour communiquer avec votre cluster.

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

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  |
+-----------------+--------------+

Associez un bloc CIDR supplémentaire à votre VPC. Remplacez la valeur du bloc CIDR dans la commande suivante. Pour plus d'informations, consultez Associer des blocs IPv4 CIDR 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

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  |
+-----------------+--------------+

Créez de nouveaux sous-réseaux. Remplacez les valeurs du bloc CIDR dans la commande suivante. 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 IDs sous-réseaux créés sont stockés dans des variables à utiliser lors des étapes ultérieures. 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)

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.

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 :

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

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

Pour un cluster de production, vérifiez si une annotation contenant la clé de la variable k8s.amazonaws.com/eniConfig d' ENI_CONFIG_ANNOTATION_DEF environnement 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é.

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

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

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

{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

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

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

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 myCustomNetworkingNodeRole
aws iam attach-role-policy \
  --policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryReadOnly \
  --role-name myCustomNetworkingNodeRole
aws iam attach-role-policy \
    --policy-arn arn:aws: iam::aws:policy/AmazonEKS_CNI_Policy \
    --role-name myCustomNetworkingNodeRole

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

Déterminez dans quelle zone de disponibilité se trouve chaque nœud. Exécutez la commande suivante pour chaque nœud renvoyé précédemment, en remplaçant les adresses IP selon le résultat précédent.

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"
    }
]

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 exemples de valeurs par les vôtres.

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

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

Cordonnez et videz les nœuds pour arrêter les pods de manière contrôlée. Pour plus d'informations, consultez Drainer un nœud en toute sécurité dans la documentation Kubernetes.

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. Exécutez la commande suivante.

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

Détachez les politiques du rôle.

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

Supprimez le rôle.

aws iam delete-role --role-name myCustomNetworkingNodeRole

Détachez les politiques du rôle.

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

Supprimez le rôle.

aws iam delete-role --role-name myCustomNetworkingAmazonEKSClusterRole