Como posso automatizar a configuração do proxy HTTP para nós de contêineres do Amazon EKS?
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
- Especifique containerd como o runtime em seu grupo de nós gerenciados. Em userdata, use a opção --container-runtime=containerd para bootstrap.sh.
- 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.
- 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.
- 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
Conteúdo relevante
- AWS OFICIALAtualizada há um ano
- AWS OFICIALAtualizada há 2 anos
- AWS OFICIALAtualizada há um ano
- AWS OFICIALAtualizada há 2 anos