Como posso automatizar a configuração do proxy HTTP para nós de contêineres 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 isso se aplica a você, 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 AMI. Em seguida, você pode definir as configurações do proxy HTTP e os valores de ambiente do cluster.

Observação: a resolução a seguir se aplica somente aos nós em que o runtime subjacente seja containerd e não se aplica aos nós com runtime Docker. Para nós com runtime do Docker, consulte Como posso automatizar a configuração do proxy HTTP para nós de processamento do Amazon EKS com o Docker?

Resolução

Crie um modelo de lançamento personalizado

  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. Caso contrário, o grupo de nós gerenciados mesclará os userdata automaticamente quando o ID da AMI não for especificado.
  3. Defina a configuração do proxy como containerd, sandbox-image e kubelet. Sandbox-image é a unidade de serviço que extrai a imagem da sandbox para containerd. Para definir essa configuração, consulte os scripts sandbox-image.service e pull-sandbox-image.sh no GitHub.
  4. Agora você pode descrever seus userdata com os seguintes campos:
    Observação: Substitua XXXXXXX:3128, YOUR_CLUSTER_CA, API\ _SERVER_ENDPOINT e EKS_CLUSTER\ _NAME pelo proxy, CA do cluster, endpoint do servidor e nome do cluster relevantes. Você pode adicionar endpoints de serviço da AWS a NO_PROXY e no\ _proxy depois de criar seus endpoints da 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==--

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

Crie um ConfigMap para configurar os valores do ambiente. Em seguida, aplique-o em seu cluster. Use o script a seguir como exemplo para seu ConfigMap: **Observação:**Substitua KUBERNETES_SERVICE_CIDR_RANGE e VPC_CIDR\ _RANGE pelos valores relevantes para seus intervalos CIDR. Por exemplo, substitua KUBERNETES_SERVICE_CIDR_RANGE por 10.100.0.0/16 e substitua VPC_CIDR_RANGE por 192.168.0.0/16. Você pode adicionar endpoints de serviço da AWS a NO_PROXY e no\ _proxy depois de criar seus endpoints da 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

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. Siga as etapas em Criação de um grupo de nós gerenciados.

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 à seguinte:

$ 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 faço para fornecer acesso a outros usuários e funções do AWS Identity and Access Management (IAM) após a criação do cluster no Amazon EKS?

AWS OFICIAL
AWS OFICIALAtualizada há um ano