Comment automatiser la configuration du proxy HTTP pour les nœuds containerd Amazon EKS ?
Je souhaite automatiser la configuration du proxy HTTP pour les nœuds Amazon Elastic Kubernetes Service (Amazon EKS) avec un environnement d'exécution containerd.
Brève description
Vous pouvez automatiser la configuration du proxy HTTP pour les nœuds Amazon EKS à l'aide d'un modèle de lancement personnalisé qui inclut des paramètres de proxy dans les données utilisateur. L'approche de configuration varie en fonction de la famille d'AMI : Amazon Linux 2, Amazon Linux 2023 ou Bottlerocket.
Remarque : pour les clusters Amazon EKS version 1.24 et versions ultérieures, containerd est le moteur d'exécution du conteneur par défaut.
Résolution
Pour configurer votre groupe de nœuds gérés avec des paramètres de proxy HTTP, créez un modèle de lancement personnalisé avec votre identifiant Amazon Machine Image (AMI). Configurez ensuite les paramètres appropriés du proxy HTTP et les valeurs d'environnement du cluster.
Choisissez l'approche de configuration en fonction de votre famille d'AMI :
Configurer le proxy HTTP pour les nœuds Amazon Linux 2
Créer le modèle de lancement
- Ouvrez la console Amazon EC2.
- Dans le volet de navigation, choisissez Launch Templates (Modèles de lancement).
- Choisissez Create launch template (Créer un modèle de lancement).
- Dans Launch template name (Nom du modèle de lancement), entrez un nom pour votre modèle.
- Dans Application and OS Images (Amazon Machine Image) (Images d'application et du système d'exploitation, Amazon Machine Image), choisissez l'identifiant d'AMI Amazon Linux 2.
- Configurez les options suivantes : Dans Instance type (Type d'instance), choisissez le type d'instance requis. Dans Key pair name (Nom de la paire de clés), choisissez votre paire de clés SSH Amazon EC2. Dans Security groups (Groupes de sécurité), choisissez vos groupes de sécurité.
- Développez Advanced details (Détails avancés).
- Dans User data (Données utilisateur), entrez la configuration suivante :
Remarque : remplacez XXXXXXX:3128 par le nom d'hôte et le port du proxy. Remplacez YOUR_CLUSTER_CA par l'autorité de certification (CA) du cluster. Remplacez API_SERVER_ENDPOINT par le point de terminaison du serveur. Remplacez EKS_CLUSTER_NAME par le nom de votre cluster.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://[IP_ADDRESS]/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` MAC=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" -v -s http://[IP_ADDRESS]/latest/meta-data/mac/) VPC_CIDR=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" -v -s http://[IP_ADDRESS]/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 #[Optional] 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,[IP_ADDRESS],[IP_ADDRESS],[IP_ADDRESS],.internal,.eks.amazonaws.com NO_PROXY=$VPC_CIDR,[IP_ADDRESS],[IP_ADDRESS],[IP_ADDRESS],.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 --==BOUNDARY==-- - Choisissez Create launch template (Créer un modèle de lancement).
Vérifier la configuration
Après avoir créé le groupe de nœuds gérés à l'aide du modèle de lancement, vérifiez la configuration du proxy :
-
Pour vérifier l'état des nœuds, exécutez la commande suivante :
kubectl get nodes -o wide -
Pour vérifier que les variables d'environnement du proxy sont définies, connectez-vous à un nœud et exécutez la commande suivante :
systemctl show containerd | grep Environment
La sortie montre les variables d'environnement proxy configurées pour containerd.
Configurer le proxy HTTP pour les nœuds Amazon Linux 2023
Remarque : si des erreurs surviennent lorsque vous exécutez des commandes de l'interface de la ligne de commande AWS (AWS CLI), consultez la section Résolution des erreurs de l'AWS CLI. Vérifiez également que vous utilisez bien la version la plus récente de l'AWS CLI.
Amazon Linux 2023 utilise un nouveau processus d'initialisation de nœuds nodeadm qui utilise un schéma de configuration YAML. Pour ce processus, nodeadm s'exécute en deux phases : configuration et exécution. La phase nodeadm-config s'exécute avant cloud-init, alors que nodeadm-run s'exécute après cloud-init.
Pendant la phase nodeadm-config, le système appelle le service Amazon EC2 pour récupérer les détails de l'instance. Pour empêcher l'appel Amazon EC2 avant la configuration des paramètres du proxy, utilisez la fonctionnalité InstanceIdNodeName dans nodeadm.
Créer un rôle IAM de composant master
-
Créez un nouveau rôle Gestion des identités et des accès AWS (IAM) pour le composant master avec les politiques requises.
-
Utilisez l'une des options suivantes pour fournir au rôle IAM du composant master l'accès approprié :
Option 1 : Créer une entrée EKS Access
Pour créer une entrée d'accès de type EC2, exécutez la commande create-access-entry de l'AWS CLI suivante :
aws eks create-access-entry --cluster-name EKS_CLUSTER_NAME --principal-arn WORKER_NODE_IAM_ROLE_ARN --type EC2Remarque : remplacez EKS_CLUSTER_NAME par le nom de votre cluster. Remplacez WORKER_NODE_IAM_ROLE_ARN par l'ARN du rôle IAM du composant master.
Option 2 : Mettre à jour la ConfigMap aws-auth
Ajoutez la configuration suivante à la ConfigMap aws-auth au format YAML :
- groups: - system:bootstrappers - system:nodes rolearn: ROLE_ARN username: system:node:{{SessionName}}Remarque : remplacez ROLE_ARN par l'ARN du rôle IAM du composant master. Cette configuration accorde les autorisations Kubernetes RBAC nécessaires au rôle IAM du composant master.
Créer le modèle de lancement
- Ouvrez la console Amazon EC2.
- Dans le volet de navigation, choisissez Launch Templates (Modèles de lancement).
- Choisissez Create launch template (Créer un modèle de lancement).
- Dans Launch template name (Nom du modèle de lancement), entrez un nom pour votre modèle.
- Dans Application and OS Images (Amazon Machine Image) (Images d'application et du système d'exploitation, Amazon Machine Image), choisissez l'identifiant d'AMI Amazon Linux 2023.
- Configurez les options suivantes : Dans Instance type (Type d'instance), choisissez le type d'instance requis. Dans Key pair name (Nom de la paire de clés), choisissez votre paire de clés SSH Amazon EC2. Dans Security groups (Groupes de sécurité), choisissez vos groupes de sécurité.
- Développez Advanced details (Détails avancés).
- Dans User data (Données utilisateur), entrez la configuration suivante :
Remarque : remplacez XXXXXXX:3128 par le nom d'hôte et le port du proxy. Remplacez YOUR_CLUSTER_CA par l'autorité de certification (CA) du cluster. Remplacez API_SERVER_ENDPOINT par le point de terminaison du serveur. Remplacez EKS_CLUSTER_NAME par le nom de votre cluster. Remplacez KUBERNETES_SERVICE_CIDR_RANGE par la plage d'adresses CIDR de service du cluster. Si le CIDR du service n'est pas fourni dans les données utilisateur, la phase nodeadm-config échoue.MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==BOUNDARY==" --==BOUNDARY== Content-Type: text/cloud-boothook; charset="us-ascii" #!/bin/bash #Set the proxy hostname and port PROXY=XXXXXXX:3128 TOKEN=`curl -X PUT "http://[IP_ADDRESS]/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` MAC=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" -v -s http://[IP_ADDRESS]/latest/meta-data/mac/) VPC_CIDR=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" -v -s http://[IP_ADDRESS]/latest/meta-data/network/interfaces/macs/$MAC/vpc-ipv4-cidr-blocks | xargs | tr ' ' ',') #[Optional] 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,[IP_ADDRESS],[IP_ADDRESS],[IP_ADDRESS],.internal,.eks.amazonaws.com NO_PROXY=$VPC_CIDR,[IP_ADDRESS],[IP_ADDRESS],[IP_ADDRESS],.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 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: application/node.eks.aws --- apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: featureGates: InstanceIdNodeName: true cluster: name: EKS_CLUSTER_NAME apiServerEndpoint: API_SERVER_ENDPOINT certificateAuthority: YOUR_CLUSTER_CA cidr: KUBERNETES_SERVICE_CIDR_RANGE --==BOUNDARY==-- - Choisissez Create launch template (Créer un modèle de lancement).
Vérifier la configuration
Après avoir créé le groupe de nœuds gérés à l'aide du modèle de lancement, vérifiez la configuration du proxy :
-
Pour vérifier l'état des nœuds, exécutez la commande suivante :
kubectl get nodes -o wide -
Pour vérifier que les variables d'environnement du proxy sont définies, connectez-vous à un nœud et exécutez la commande suivante :
systemctl show containerd | grep Environment
La sortie montre les variables d'environnement proxy configurées pour containerd.
Configurer le proxy HTTP pour les nœuds Bottlerocket
Créer le modèle de lancement
-
Ouvrez la console Amazon EC2.
-
Dans le volet de navigation, choisissez Launch Templates (Modèles de lancement).
-
Choisissez Create launch template (Créer un modèle de lancement).
-
Dans Launch template name (Nom du modèle de lancement), entrez un nom pour votre modèle.
-
Dans Application and OS Images (Amazon Machine Image) (Images d'application et du système d'exploitation, Amazon Machine Image), choisissez votre identifiant d'AMI Bottlerocket.
-
Configurez les options suivantes : Dans Instance type (Type d'instance), choisissez le type d'instance requis. Dans Key pair name (Nom de la paire de clés), choisissez votre paire de clés SSH Amazon EC2. Dans Security groups (Groupes de sécurité), choisissez vos groupes de sécurité.
-
Développez Advanced details (Détails avancés).
-
Dans User data (Données utilisateur), entrez la configuration suivante :
[settings.kubernetes] "cluster-name" = "EKS_CLUSTER_NAME" "api-server" = "API_SERVER_ENDPOINT" "cluster-certificate" = "YOUR_CLUSTER_CA" [settings.network] no-proxy = ["VPC_CIDR_RANGE","[IP_ADDRESS]","[IP_ADDRESS]","[IP_ADDRESS]",".internal",".eks.amazonaws.com"] https-proxy = "XXXXXXX:3128"Remarque : remplacez XXXXXXX:3128 par le nom d'hôte et le port du proxy. Remplacez YOUR_CLUSTER_CA par l'autorité de certification (CA) du cluster. Remplacez API_SERVER_ENDPOINT par le point de terminaison du serveur. Remplacez EKS_CLUSTER_NAME par le nom de votre cluster. Remplacez VPC_CIDR_RANGE par le CIDR du VPC. Bottlerocket configure automatiquement les paramètres du proxy pour les services containerd et kubelet.
Pour ajouter des certificats autosignés à vos instances Bottlerocket, utilisez la configuration suivante dans la section des données utilisateur :
[settings.pki.proxy-bundle] data="ENCODED_CA_DATA" trusted=trueRemarque : remplacez ENCODED_CA_DATA par les données de certificat codées en base64.
Pour encoder le fichier de certificat, exécutez la commande suivante :
base64 -i FILE -w0 -
Choisissez Create launch template (Créer un modèle de lancement).
Vérifier la configuration
Après avoir créé le groupe de nœuds gérés à l'aide du modèle de lancement, vérifiez la configuration du proxy :
-
Pour vérifier l'état des nœuds, exécutez la commande suivante :
kubectl get nodes -o wide -
Pour vérifier les paramètres du proxy, connectez-vous à un nœud Bottlerocket à l'aide du gestionnaire de session AWS Systems Manager et exécutez la commande suivante :
apiclient get settings.network
La sortie indique les paramètres de proxy configurés pour le nœud.
Créer le groupe de nœuds gérés
Après avoir créé le modèle de lancement, créez un nouveau groupe de nœuds gérés qui utilise le modèle de lancement personnalisé.
Pour plus d'informations sur la création de groupes de nœuds gérés à l'aide de modèles de lancement, consultez la section Personnaliser les nœuds gérés à l'aide de modèles de lancement.
Configurer le proxy pour les clusters entièrement privés
Important : Lorsque vous utilisez les associations d'identités de pod EKS avec une configuration de proxy, vous devez également inclure [IP_ADDRESS] (IPv4) ou [[IP_ADDRESS]] (IPv6) dans les variables d'environnement no_proxy/NO_PROXY.
Les clusters Amazon EKS dont le point de terminaison du serveur d'API est privé, qui utilisent des sous-réseaux privés et qui n'ont pas accès à Internet nécessitent des points de terminaison supplémentaires. Si vous créez un cluster avec la configuration précédente, vous devez créer et ajouter des points de terminaison pour les services suivants :
- Amazon EC2
- Amazon Elastic Container Registry pour extraire des images de conteneur
- Amazon Elastic Load Balancing pour les Application Load Balancers et les Network Load Balancers
- Amazon CloudWatch Logs
- Service de jetons de sécurité AWS lorsque vous utilisez des rôles IAM pour des comptes de service
- Amazon EKS Auth lorsque vous utilisez des associations d'identités du pod
- Amazon EKS
Après avoir créé ces points de terminaison, configurez les variables NO_PROXY et no_proxy dans les données utilisateur du modèle de lancement d'instance Amazon EC2. Incluez les sous-domaines de point de terminaison publics spécifiques à votre région et à vos services AWS.
Exemple :
Pour Amazon S3 :
- Si le compartiment se trouve dans us-east-1, ajoutez : .s3.us-east-1.amazonaws.com
- Si le compartiment se trouve dans eu-west-1, ajoutez : .s3.eu-west-1.amazonaws.com
Pour Amazon EKS lorsque vous utilisez un accès à un point de terminaison privé :
- Si le cluster se trouve dans us-east-1, ajoutez : .us-east-1.eks.amazonaws.com
- Si le cluster se trouve dans eu-west-1, ajoutez : .eu-west-1.eks.amazonaws.com
Remarque : remplacez les identifiants de région par la région AWS dans laquelle vous avez déployé vos ressources et ajoutez ces points de terminaison aux variables NO_PROXY et no_proxy. En fonction de la charge de travail et des modules complémentaires du cluster, ajoutez d'autres services à la configuration du proxy.
Configurer le proxy pour les clusters publics
Remarque : si vous utilisez un autre type de configuration, ces étapes sont facultatives.
Si vous acheminez le trafic du cluster vers Internet via un proxy HTTP et que le point de terminaison Amazon EKS est public, effectuez la tâche suivante.
Pour créer un ConfigMap afin de configurer les valeurs de l'environnement, exécutez la commande suivante :
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,[IP_ADDRESS],[IP_ADDRESS],VPC_CIDR_RANGE,[IP_ADDRESS],.internal,.eks.amazonaws.com,ec2.us-east-1.amazonaws.com no_proxy: KUBERNETES_SERVICE_CIDR_RANGE,[IP_ADDRESS],[IP_ADDRESS],VPC_CIDR_RANGE,[IP_ADDRESS],.internal,.eks.amazonaws.com,ec2.us-east-1.amazonaws.com
Remarque : remplacez KUBERNETES_SERVICE_CIDR_RANGE et VPC_CIDR_RANGE par les valeurs correspondant aux plages CIDR. Après avoir créé les points de terminaison de VPC (Amazon EKS et Amazon EC2), ajoutez les points de terminaison de service AWS à NO_PROXY et no_proxy.
Pour vérifier le ConfigMap, exécutez la commande suivante :
kubectl apply -f proxy-configmap.yaml
Configurer aws-node et kube-proxy
Pour définir la configuration du proxy HTTP sur aws-node et kube-proxy, exécutez les commandes suivantes :
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
Vérifier la configuration du proxy
Pour vérifier que la configuration du proxy fonctionne correctement, procédez comme suit :
-
Pour vérifier l'état des nœuds, exécutez la commande suivante :
kubectl get nodes -o wide -
Pour tester la connectivité du pod via le proxy, exécutez les commandes suivantes :
kubectl run test-pod --image=amazonlinux:2 --restart=Never -- sleep 300 kubectl get pods -A -
Consultez le journal de proxy pour obtenir des informations supplémentaires sur la connectivité des nœuds. Les journaux doivent indiquer les connexions réussies (TCP_TUNNEL/200) aux points de terminaison du registre de conteneurs.
Exemple de sortie :
[IP_ADDRESS] TCP_TUNNEL/200 6230 CONNECT registry-1.docker.io:443 - HIER_DIRECT/XX.XX.XX.XX - [IP_ADDRESS] TCP_TUNNEL/200 10359 CONNECT auth.docker.io:443 - HIER_DIRECT/XX.XX.XX.XX -
Informations connexes
Effectuer une mise à niveau d'Amazon Linux 2 vers Amazon Linux 2023
Créer des nœuds Bottlerocket autogérés
Autoriser les utilisateurs IAM à accéder à Kubernetes avec des entrées d'accès EKS
- Sujets
- Containers
- Langue
- Français

Contenus pertinents
demandé il y a 3 ans
demandé il y a 4 ans
demandé il y a un an
demandé il y a 8 mois
demandé il y a 2 ans
AWS OFFICIELA mis à jour il y a 3 ans
AWS OFFICIELA mis à jour il y a 9 mois