Passer au contenu

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

Lecture de 13 minute(s)
0

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

  1. Ouvrez la console Amazon EC2.
  2. Dans le volet de navigation, choisissez Launch Templates (Modèles de lancement).
  3. Choisissez Create launch template (Créer un modèle de lancement).
  4. Dans Launch template name (Nom du modèle de lancement), entrez un nom pour votre modèle.
  5. 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.
  6. 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é.
  7. Développez Advanced details (Détails avancés).
  8. Dans User data (Données utilisateur), entrez la configuration suivante :
    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==--
    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.
  9. 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 :

  1. Pour vérifier l'état des nœuds, exécutez la commande suivante :

    kubectl get nodes -o wide
  2. 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

  1. Créez un nouveau rôle Gestion des identités et des accès AWS (IAM) pour le composant master avec les politiques requises.

  2. 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 EC2

    Remarque : 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

  1. Ouvrez la console Amazon EC2.
  2. Dans le volet de navigation, choisissez Launch Templates (Modèles de lancement).
  3. Choisissez Create launch template (Créer un modèle de lancement).
  4. Dans Launch template name (Nom du modèle de lancement), entrez un nom pour votre modèle.
  5. 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.
  6. 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é.
  7. Développez Advanced details (Détails avancés).
  8. Dans User data (Données utilisateur), entrez la configuration suivante :
    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==--
    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.
  9. 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 :

  1. Pour vérifier l'état des nœuds, exécutez la commande suivante :

    kubectl get nodes -o wide
  2. 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

  1. Ouvrez la console Amazon EC2.

  2. Dans le volet de navigation, choisissez Launch Templates (Modèles de lancement).

  3. Choisissez Create launch template (Créer un modèle de lancement).

  4. Dans Launch template name (Nom du modèle de lancement), entrez un nom pour votre modèle.

  5. 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.

  6. 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é.

  7. Développez Advanced details (Détails avancés).

  8. 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=true

    Remarque : 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
  9. 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 :

  1. Pour vérifier l'état des nœuds, exécutez la commande suivante :

    kubectl get nodes -o wide
  2. 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 :

  1. Pour vérifier l'état des nœuds, exécutez la commande suivante :

    kubectl get nodes -o wide
  2. 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
  3. 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

AWS OFFICIELA mis à jour il y a 10 mois