Come posso automatizzare la configurazione del proxy HTTP per i nodi containerd di Amazon EKS?
Desidero automatizzare la configurazione del proxy HTTP per i nodi di Amazon Elastic Kubernetes Service (Amazon EKS) con il runtime containerd.
Breve descrizione
Per i gruppi di nodi gestiti che hai creato nelle versioni 1.23 o precedenti di Amazon EKS, il runtime del container predefinito è Docker. Se questo è il tuo caso, assicurati di seguire tutti i passaggi della risoluzione per specificare un runtime containerd. Per i gruppi di nodi gestiti creati nella versione 1.24 o successiva di Amazon EKS, il runtime predefinito del container è containerd.
Per utilizzare containerd anziché dockerd nel tuo gruppo di nodi gestito, devi specificare un runtime containerd in userdata.
Dopo aver cambiato il gruppo di nodi gestito in un runtime containerd, crea un modello di avvio personalizzato con il tuo ID AMI. È quindi possibile configurare le impostazioni per il proxy HTTP e i valori di ambiente del cluster.
Nota: la seguente risoluzione si applica solo ai nodi in cui il runtime sottostante è containerd e non si applica ai nodi con runtime Docker. Per i nodi con runtime Docker, consulta Come posso automatizzare la configurazione del proxy HTTP per i nodi worker di Amazon EKS con Docker?
Risoluzione
Crea un modello di avvio personalizzato
- Specifica containerd come runtime nel gruppo di nodi gestito. In userdata, usa l'opzione --container-runtime=containerd per bootstrap.sh.
- Crea un modello di avvio personalizzato con l'ID AMI. Altrimenti, il gruppo di nodi gestiti unisce automaticamente userdata quando l'ID AMI non è specificato.
- Imposta la configurazione del proxy su containerd, sandbox-image e kubelet. Sandbox-image è l'unità di servizio che recupera l'immagine dell'ambiente di sperimentazione per il containerd. Per impostare questa configurazione, consulta gli script sandbox-image.service e pull-sandbox-image.sh su GitHub.
- Ora puoi descrivere i tuoi userdata con i seguenti campi:
Nota: Sostituisci XXXXXXX:3128, YOUR_CLUSTER_CA, API_SERVER_ENDPOINT e EKS_CLUSTER_NAME con il proxy, la CA del cluster, l'endpoint del server e il nome del cluster pertinenti. Puoi aggiungere gli endpoint dei servizi AWS a NO_PROXY e no_proxy dopo aver creato i relativi endpoint 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==--
Configurare l'impostazione del proxy per aws-node e kube-proxy
Crea una ConfigMap per configurare i valori dell'ambiente. Quindi, applicala nel tuo cluster. Usa lo script seguente come esempio per la tua ConfigMap: Nota: Sostituisci KUBERNETES_SERVICE_CIDR_RANGE e VPC_CIDR_RANGE con i valori pertinenti per i tuoi intervalli CIDR. Ad esempio, sostituisci KUBERNETES_SERVICE_CIDR_RANGE con 10.100.0.0/16 e sostituisci VPC_CIDR_RANGE con 192.168.0.0/16. Puoi aggiungere gli endpoint dei servizi AWS a NO_PROXY e no_proxy dopo aver creato i relativi endpoint 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
Quindi, imposta la configurazione del proxy HTTP su 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
Creare un gruppo di nodi gestito
Crea un nuovo gruppo di nodi gestito che utilizzi il modello di avvio personalizzato creato in precedenza. Segui i passaggi descritti in Creazione di un gruppo di nodi gestito.
Testa il tuo proxy
Per verificare lo stato dei tuoi nodi, esegui i seguenti comandi:
$ kubectl get nodes $ kubectl run test-pod --image=amazonlinux:2 --restart=Never -- sleep 300 $ kubectl get pods -A
Riceverai un output simile a quello nell'esempio seguente:
$ 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
Controlla il log del proxy per ulteriori informazioni sulla connettività dei tuoi nodi:
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 -
Informazioni correlate
Contenuto pertinente
- AWS UFFICIALEAggiornata 2 anni fa
- AWS UFFICIALEAggiornata un anno fa
- AWS UFFICIALEAggiornata un anno fa