Wie kann ich die Konfiguration des HTTP-Proxys für Amazon EKS-Container-Knoten automatisieren?

Kurzbeschreibung

Für verwaltete Knotengruppen, die Sie in Amazon EKS Versionen 1.23 oder früher erstellt haben, ist die Standard-Container-Laufzeit Docker. Wenn dies Ihr Anwendungsfall ist, befolgen Sie unbedingt alle Schritte in der Lösung, um eine containerd-Laufzeit anzugeben. Für verwaltete Knotengruppen, die in Amazon EKS Version 1.24 oder höher erstellt wurden, ist die Standard-Container-Laufzeit containerd.

Um containerd in Ihrer verwalteten Knotengruppe anstelle von dockerd zu verwenden, müssen Sie in userdata eine containerd-Laufzeit angeben.

Nachdem Sie Ihre verwaltete Knotengruppe auf eine Containerd-Laufzeit umgestellt haben, erstellen Sie eine benutzerdefinierte Startvorlage mit Ihrer Amazon Machine Image (AMI)-ID. Anschließend konfigurieren Sie die Einstellungen für Ihren HTTP-Proxy und die Umgebungswerte Ihres Clusters.

Hinweis: Informationen zu Knoten mit Docker-Laufzeit finden Sie unter Wie die Konfiguration des HTTP-Proxys für Amazon-EKS-Worker-Knoten mit Docker zu automatisieren?

Lösung

Erstellen Sie eine benutzerdefinierte Startvorlage

Gehen Sie wie folgt vor, um containerd als Laufzeit anzugeben und eine benutzerdefinierte Startvorlage zu erstellen:

1. Geben Sie containerd als Laufzeit in Ihrer verwalteten Knotengruppe an. Verwenden Sie in userdata die Option --container-runtime=containerd für bootstrap.sh.

2. Erstellen Sie eine benutzerdefinierte Startvorlage mit der AMI-ID. Wenn Sie dies nicht tun, führt die Gruppe der verwalteten Knoten automatisch userdata zusammen.

3. Stellen Sie die Proxykonfiguration auf containerd, sandbox-image und kubelet ein.
   Hinweis: Sandbox-image ist die Serviceeinheit, die das Sandbox-Image für containerd abruft.

4. Beschreiben Sie Ihre userdata mit den folgenden Feldern:

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

   Hinweis: Ersetzen Sie XXXXXXX:3128, YOUR_CLUSTER_CA, API_SERVER_ENDPOINT und EKS_CLUSTER_NAME durch Ihren Proxy, Cluster-Zertifizierungsstelle (CA), Serverendpunkt und Clustern-Namen. Nachdem Sie die Virtual Private Cloud (VPC)-Endpunkte erstellt haben, fügen Sie AWS-Serviceendpunkte zu NO_PROXY und no_proxy hinzu.

Konfigurieren Sie die Proxy-Einstellung für aws-node und kube-proxy

Hinweis: Wenn Sie den Datenverkehr vom Cluster über einen HTTP-Proxy zum Internet weiterleiten und Ihr EKS-Endpunkt öffentlich ist, müssen Sie diese Schritte ausführen. Wenn Sie eine andere Konfiguration haben, sind diese Schritte optional.

Erstellen Sie eine ConfigMap, um die Umgebungswerte zu konfigurieren. Wenden Sie dann die ConfigMap in Ihrem Cluster an. Verwenden Sie das folgende Skript als Beispiel für Ihre 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

Hinweis: Ersetzen Sie KUBERNETES_SERVICE_CIDR_RANGE und VPC_CIDR_RANGE durch die Werte für Ihre CIDR-Bereiche. Sie können AWS-Serviceendpunkte zu NO_PROXY und no_proxy hinzufügen, nachdem Sie ihre VPC-Endpunkte erstellt haben.

Stellen Sie dann Ihre HTTP-Proxykonfiguration auf aws-node und kube-proxy ein:

$ 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

Eine verwaltete Knotengruppe erstellen

Erstellen Sie eine neue verwaltete Knotengruppe, die die erstellte benutzerdefinierte Startvorlage verwendet.

Testen Sie Ihren Proxy

Führen Sie die folgenden Befehle aus, um den Status Ihrer Knoten zu überprüfen:

$ kubectl get nodes

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

$ kubectl get pods -A

Sie erhalten eine Ausgabe, die dem folgenden Beispiel ähnelt:

$ 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

Weitere Informationen zur Verbindung Ihrer Knoten finden Sie in Ihrem Proxyprotokoll:

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 -

Ähnliche Informationen

Wie gewähre ich anderen IAM-Benutzern und -Rollen nach der Cluster-Erstellung in Amazon EKS Zugriff?