Comment automatiser la configuration du proxy HTTP pour les nœuds containerd Amazon EKS ?

Brève description

Pour les groupes de nœuds gérés créés dans les versions 1.23 ou antérieures d'Amazon EKS, l’environnement d'exécution du conteneur par défaut est Docker. Si ce scénario correspond à votre cas d'utilisation, suivez toutes les étapes de la résolution pour spécifier un environnement d'exécution containerd. Pour les groupes de nœuds gérés créés dans les versions 1.24 ou ultérieures d’Amazon EKS, l’environnement d'exécution du conteneur par défaut est containerd.

Pour utiliser containerd dans votre groupe de nœuds géré au lieu de dockerd, vous devez spécifier un environnement d'exécution containerd dans userdata.

Après avoir basculé votre groupe de nœuds gérés vers un environnement d'exécution containerd, vous devez créer un modèle de lancement personnalisé avec l’ID de votre Amazon Machine Image (AMI). Configurez ensuite les paramètres de votre proxy HTTP et les valeurs d'environnement de votre cluster.

Remarque : dans le cas de nœuds avec un environnement d'exécution Docker, consultez la page Comment automatiser la configuration du proxy HTTP pour les composants master Amazon EKS avec Docker ?

Résolution

Création d’un modèle de lancement personnalisé

Pour spécifier containerd comme environnement d'exécution et créer un modèle de lancement personnalisé, procédez comme suit :

1. Spécifiez containerd comme environnement d'exécution dans votre groupe de nœuds gérés. Dans userdata, utilisez l'option --container-runtime=containerd pour bootstrap.sh.

2. Créez un modèle de lancement personnalisé avec l'ID de l'AMI. Dans le cas contraire, le groupe de nœuds gérés fusionnera automatiquement userdata.

3. Définissez la configuration du proxy sur containerd, sandbox-image et kubelet.
   Remarque : sandbox-image est l'unité de service qui extrait l'image de l'environnement de test (sandbox) pour containerd.

4. Décrivez vos userdata à l’aide des champs suivants :

   MIME-Version: 1.0
   Content-Type: multipart/mixed; boundary="==BOUNDARY=="
   
   --==BOUNDARY==
   Content-Type: text/cloud-boothook; charset="us-ascii"
   
   #Set the proxy hostname and port
   PROXY=XXXXXXX:3128
   TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`
   MAC=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" -v -s http://169.254.169.254/latest/meta-data/mac/)
   VPC_CIDR=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" -v -s http://169.254.169.254/latest/meta-data/network/interfaces/macs/$MAC/vpc-ipv4-cidr-blocks | xargs | tr ' ' ',')
   
   #Create the containerd and sandbox-image systemd directory
   mkdir -p /etc/systemd/system/containerd.service.d
   mkdir -p /etc/systemd/system/sandbox-image.service.d
   
   #[Option] Configure yum to use the proxy
   cloud-init-per instance yum_proxy_config cat << EOF >> /etc/yum.conf
   proxy=http://$PROXY
   EOF
   
   #Set the proxy for future processes, and use as an include file
   cloud-init-per instance proxy_config cat << EOF >> /etc/environment
   http_proxy=http://$PROXY
   https_proxy=http://$PROXY
   HTTP_PROXY=http://$PROXY
   HTTPS_PROXY=http://$PROXY
   no_proxy=$VPC_CIDR,localhost,127.0.0.1,169.254.169.254,.internal,.eks.amazonaws.com
   NO_PROXY=$VPC_CIDR,localhost,127.0.0.1,169.254.169.254,.internal,.eks.amazonaws.com
   EOF
   
   #Configure Containerd with the proxy
   cloud-init-per instance containerd_proxy_config tee <<EOF /etc/systemd/system/containerd.service.d/http-proxy.conf >/dev/null
   [Service]    
   EnvironmentFile=/etc/environment
   EOF
   
   #Configure sandbox-image with the proxy
   cloud-init-per instance sandbox-image_proxy_config tee <<EOF /etc/systemd/system/sandbox-image.service.d/http-proxy.conf >/dev/null
   [Service]    
   EnvironmentFile=/etc/environment
   EOF
   
   #Configure the kubelet with the proxy
   cloud-init-per instance kubelet_proxy_config tee <<EOF /etc/systemd/system/kubelet.service.d/proxy.conf >/dev/null
   [Service]
   EnvironmentFile=/etc/environment
   EOF
   
   cloud-init-per instance reload_daemon systemctl daemon-reload
   
   --==BOUNDARY==
   Content-Type:text/x-shellscript; charset="us-ascii"
   
   #!/bin/bash
   set -o xtrace
   
   #Set the proxy variables before running the bootstrap.sh script
   set -a
   source /etc/environment
   
   #Run the bootstrap.sh script
   B64_CLUSTER_CA=YOUR_CLUSTER_CA
   API_SERVER_URL=API_SERVER_ENDPOINT
   
   /etc/eks/bootstrap.sh EKS_CLUSTER_NAME --b64-cluster-ca $B64_CLUSTER_CA --apiserver-endpoint $API_SERVER_URL --container-runtime containerd
   
   --==BOUNDARY==--

   Remarque : remplacez XXXXXXX:3128, YOUR_CLUSTER_CA, API_SERVER_ENDPOINT et EKS_CLUSTER_NAME par votre proxy, votre autorité de certification (CA) de cluster, votre point de terminaison de serveur et votre nom de cluster. Une fois les points de terminaison du cloud privé virtuel (VPC) créés, ajoutez les points de terminaison du service AWS à NO_PROXY et no_proxy.

Configuration des paramètres du proxy pour aws-node et kube-proxy

Remarque : si vous acheminez le trafic du cluster vers Internet via un proxy HTTP et que votre point de terminaison EKS est public, vous devez suivre ces étapes. Si vous utilisez un autre type de configuration, ces étapes sont facultatives.

Créez une ConfigMap pour configurer les valeurs de l'environnement. Appliquez ensuite la ConfigMap à votre cluster. Le script suivant est un exemple de ConfigMap :

apiVersion: v1
kind: ConfigMap

metadata:

   name: proxy-environment-variables

   namespace: kube-system

data:

   HTTP_PROXY: http://XXXXXXX:3128

   HTTPS_PROXY: http://XXXXXXX:3128

   NO_PROXY: KUBERNETES_SERVICE_CIDR_RANGE,localhost,127.0.0.1,VPC_CIDR_RANGE,169.254.169.254,.internal

Remarque : remplacez KUBERNETES_SERVICE_CIDR_RANGE et VPC_CIDR_RANGE par les valeurs correspondant à vos plages CIDR. Après avoir créé les points de terminaison d’un VPC, ajoutez les points de terminaison du service AWS à NO_PROXY et no_proxy.

Définissez ensuite la configuration de votre proxy HTTP sur aws-node et kube-proxy:

$ kubectl patch -n kube-system -p '{ "spec": {"template":{ "spec": { "containers": [ { "name": "aws-node", "envFrom": [ { "configMapRef": {"name": "proxy-environment-variables"} } ] } ] } } } }' daemonset aws-node
$ kubectl patch -n kube-system -p '{ "spec": {"template":{ "spec": { "containers": [ { "name": "kube-proxy", "envFrom": [ { "configMapRef": {"name": "proxy-environment-variables"} } ] } ] } } } }' daemonset kube-proxy

Création d’un groupe de nœuds géré

Créez un nouveau groupe de nœuds gérés qui utilise le modèle de lancement personnalisé que vous avez créé.

Test de votre proxy

Exécutez les commandes suivantes pour vérifier l'état de vos nœuds :

$ kubectl get nodes

$ kubectl run test-pod --image=amazonlinux:2 --restart=Never -- sleep 300

$ kubectl get pods -A

Vous recevez une sortie similaire à l'exemple suivant :

$ kubectl get nodes -o wide
NAME                                                 STATUS   ROLES    AGE     VERSION                INTERNAL-IP       EXTERNAL-IP   OS-IMAGE         KERNEL-VERSION                 CONTAINER-RUNTIME

ip-192-168-100-114.ap-northeast-1.compute.internal   Ready    <none>   2m27s   v1.23.13-eks-fb459a0   192.168.100.114   <none>        Amazon Linux 2   5.4.219-126.411.amzn2.x86_64   containerd://1.6.6



$ kubectl run test-pod --image=amazonlinux:2 --restart=Never -- sleep 300

pod/test-pod created



$ kubectl get pods -A

NAMESPACE     NAME                       READY   STATUS    RESTARTS   AGE

default       test-pod                   1/1     Running   0          14s

kube-system   aws-node-cpjcl             1/1     Running   0          3m34s

kube-system   coredns-69cfddc4b4-c7rpd   1/1     Running   0          26m

kube-system   coredns-69cfddc4b4-z5jxq   1/1     Running   0          26m

kube-system   kube-proxy-g2f4g           1/1     Running   0          3m34s

Consultez votre journal de proxy pour obtenir des informations supplémentaires sur la connectivité de vos nœuds :

192.168.100.114 TCP_TUNNEL/200 6230 CONNECT registry-1.docker.io:443 - HIER_DIRECT/XX.XX.XX.XX -
192.168.100.114 TCP_TUNNEL/200 10359 CONNECT auth.docker.io:443 - HIER_DIRECT/XX.XX.XX.XX -
192.168.100.114 TCP_TUNNEL/200 6633 CONNECT registry-1.docker.io:443 - HIER_DIRECT/XX.XX.XX.XX -
192.168.100.114 TCP_TUNNEL/200 10353 CONNECT auth.docker.io:443 - HIER_DIRECT/XX.XX.XX.XX -
192.168.100.114 TCP_TUNNEL/200 8767 CONNECT registry-1.docker.io:443 - HIER_DIRECT/XX.XX.XX.XX -

Informations connexes

Comment fournir un accès à d’autres utilisateurs et rôles IAM après la création d’un cluster dans Amazon EKS ?