Como posso automatizar a configuração do proxy HTTP para nós containerd do Amazon EKS?

5 minuto de leitura
0

Quero automatizar a configuração do proxy HTTP para os nós do Amazon Elastic Kubernetes Service (Amazon EKS) com runtime containerd.

Breve descrição

Para grupos de nós gerenciados que você criou nas versões 1.23 ou anteriores do Amazon EKS, o runtime de contêiner padrão é Docker. Se esse for seu caso de uso, siga todas as etapas da resolução para especificar um runtime containerd. Para grupos de nós gerenciados criados na versão 1.24 ou posterior do Amazon EKS, o runtime de contêiner padrão em containerd.

Para usar containerd em seu grupo de nós gerenciados em vez de dockerd, você deve especificar um runtime containerd userdata.

Depois de mudar seu grupo de nós gerenciados para um runtime containerd, crie um modelo de lançamento personalizado com seu ID da imagem de máquina da Amazon (AMI). Em seguida, você pode definir as configurações do proxy HTTP e os valores de ambiente do cluster.

Observação: Para nós com ambiente de execução do Docker, consulte Como automatizar a configuração do proxy HTTP para nós trabalhadores do Amazon EKS com Docker?

Resolução

Crie um modelo de lançamento personalizado

Para especificar containerd como o runtime e criar um modelo de lançamento personalizado, conclua as seguintes etapas:

  1. Especifique containerd como o runtime em seu grupo de nós gerenciados. Em userdata, use a opção --container-runtime=containerd para bootstrap.sh.

  2. Crie um modelo de lançamento personalizado com o ID da AMI. Se você não fizer isso, o grupo de nós gerenciados mesclará o userdata automaticamente.

  3. Defina a configuração do proxy como containerd, sandbox-image e kubelet.
    Observação: Sandbox-image é a unidade de serviço que extrai a imagem da sandbox para containerd.

  4. Descreva seu userdata com os seguintes campos:

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

    Observação: Substitua XXXXXXX:3128, YOUR_CLUSTER_CA, API\ _SERVER_ENDPOINT e EKS_CLUSTER\ _NAME pelo proxy, autoridade de certificação (CA) do cluster, endpoint do servidor e nome do cluster relevantes. Depois de criar os endpoints de nuvem privada virtual (VPC), adicione endpoints de serviço da AWS a NO_PROXY ed no_proxy.

Defina a configuração de proxy para aws-node e kube-proxy

Observação: se você rotear o tráfego do cluster para a Internet por meio de um proxy HTTP e seu endpoint EKS for público, deverá concluir essas etapas. Se você tiver uma configuração diferente, essas etapas serão opcionais.

Crie um ConfigMap para configurar os valores do ambiente. Em seguida, aplique o ConfigMap em seu cluster. Use o script a seguir como exemplo para seu 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

Observação: substitua KUBERNETES_SERVICE_CIDR_RANGE e VPC_CIDR_RANGE pelos valores relevantes para seus intervalos CIDR. Depois de criar os endpoints de VPC, adicione endpoints de serviço da AWS a NO_PROXY e no_proxy.

Em seguida, defina a configuração do proxy HTTP como aws-node e 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

Crie um grupo de nós gerenciados

Crie um novo grupo de nós gerenciados que use o modelo de lançamento personalizado que você criou anteriormente.

Teste seu proxy

Para verificar o status dos seus nós, execute os seguintes comandos:

$ kubectl get nodes

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

$ kubectl get pods -A

Você recebe uma saída semelhante ao exemplo a seguir:

$ 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

Verifique seu registro de proxy para obter informações adicionais sobre a conectividade dos seus nós:

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 -

Informações relacionadas

Como conceder acesso a outros usuários e perfis do IAM após a criação de um cluster no Amazon EKS?

AWS OFICIAL
AWS OFICIALAtualizada há 8 meses