Como posso automatizar a configuração do proxy HTTP para nós containerd 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 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:
-
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. Se você não fizer isso, o grupo de nós gerenciados mesclará o userdata automaticamente.
-
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. -
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?
Conteúdo relevante
- AWS OFICIALAtualizada há 9 meses
- AWS OFICIALAtualizada há 2 anos
- AWS OFICIALAtualizada há 9 meses
- AWS OFICIALAtualizada há 2 anos