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

Brève description

Le moteur d'exécution du conteneur par défaut est Docker en ce qui concerne les groupes de nœuds gérés que vous avez créés dans les versions 1.23 ou antérieures d'Amazon EKS. Si c'est votre cas, suivez toutes les étapes de résolution pour spécifier un environnement d'exécution containerd. Concernant les groupes de nœuds gérés créés dans Amazon EKS version 1.24 ou ultérieure, le moteur d'exécution du conteneur par défaut est containerd.

Si vous voulez utiliser containerd dans votre groupe de nœuds gérés au lieu de dockerd, vous devez d'abord spécifier un environnement d'exécution contenerd 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 votre identifiant d'AMI. Ensuite, vous pouvez configurer les paramètres de votre proxy HTTP et les valeurs d'environnement de votre cluster.

Remarque : la résolution suivante ne s'applique qu'aux nœuds dont l'exécution sous-jacente est containerd, et ne s'applique pas aux nœuds dont l'exécution est Docker. Pour les nœuds dotés du moteur d'exécution Docker, reportez-vous à Comment puis-je automatiser la configuration du proxy HTTP pour les composants master Amazon EKS avec Docker ?

Résolution

Créer un modèle de lancement personnalisé

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 d'AMI. Dans le cas contraire, le groupe de nœuds gérés fusionne automatiquement les données utilisateur lorsque l'ID d'AMI n'est pas spécifié.
3. Définissez la configuration du proxy sur containerd, sandbox-image et kubelet. Sandbox-image est l'unité de service qui extrait l'image de l'environnement de test (sandbox) pour containerd. Pour définir cette configuration, reportez-vous aux sandbox-image.service et pull-sandbox-image.sh sur GitHub.
4. Vous pouvez désormais décrire vos données utilisateur à l'aide des champs suivants :
   Remarque : remplacez XXXXXXX:3128, YOUR_CLUSTER_CA, API_SERVER_ENDPOINT, et EKS_CLUSTER_NAME par votre proxy, autorité de certification de cluster, point de terminaison de serveur et nom de cluster pertinents. Vous pouvez ajouter des points de terminaison de service AWS à NO_PROXY et no_proxy après avoir créé leurs points de terminaison d'un VPC.

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

Configurez les paramètres du proxy pour aws-node et kube-proxy

Créez une ConfigMap pour configurer les valeurs de l'environnement. Ensuite, appliquez-le à votre cluster. Le script suivant sert d'exemple pour votre ConfigMap : Remarque : remplacez KUBERNETES_SERVICE_CIDR_RANGE et VPC_CIDR_RANGE par les valeurs pertinentes pour vos plages CIDR. Par exemple, remplacez KUBERNETES_SERVICE_CIDR_RANGE par 10.100.0.0/16, et remplacez VPC_CIDR_RANGE par 192.168.0.0/16. Vous pouvez ajouter des points de terminaison de service AWS à NO_PROXY et no_proxy après avoir créé leurs points de terminaison d'un VPC.

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,.eks.amazonaws.com

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éer 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é créé précédemment. Suivez les étapes décrites dans la section Création d'un groupe de nœuds géré.

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 obtenez un résultat 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 avoir 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 puis-je fournir un accès à d'autres utilisateurs et rôles AWS Identity and Access Management (IAM) après la création d'un cluster dans Amazon EKS ?