Wie kann ich die Konfiguration des HTTP-Proxys für Amazon EKS-Container-Knoten automatisieren?
Ich möchte die Konfiguration des HTTP-Proxys für Amazon Elastic Kubernetes Service (Amazon EKS)-Knoten mit Container-Laufzeit automatisieren.
Kurzbeschreibung
Für verwaltete Knotengruppen, die Sie in Amazon EKS Version 1.23 oder früher erstellt haben, ist die Standard-Container-Laufzeit Docker. Wenn dies auf Sie zutrifft, 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 AMI ID. Anschließend können Sie die Einstellungen für Ihren HTTP-Proxy und die Umgebungswerte Ihres Clusters konfigurieren.
Hinweis: Die folgende Lösung gilt nur für Knoten, bei denen die zugrunde liegende Laufzeit containerd ist, und gilt nicht für Knoten mit Docker-Laufzeit. Informationen zu Knoten mit Docker-Laufzeit finden Sie unter Wie kann ich die Konfiguration des HTTP-Proxys für Amazon-EKS-Worker-Knoten mit Docker automatisieren?
Lösung
Erstellen Sie eine benutzerdefinierte Startvorlage
- Geben Sie containerd als Laufzeit in Ihrer verwalteten Knotengruppe an. Verwenden Sie in userdata die Option --container-runtime=containerd für bootstrap.sh.
- Erstellen Sie eine benutzerdefinierte Startvorlage mit der AMI ID. Andernfalls führt die Gruppe der verwalteten Knoten Benutzerdaten automatisch zusammen, wenn die AMI ID nicht angegeben ist.
- Stellen Sie die Proxykonfiguration auf containerd, sandbox-image und kubelet ein. Sandbox-Image ist die Serviceeinheit, die das Sandbox-Image für containerd abruft. Informationen zum Einstellen dieser Konfiguration finden Sie in den Skripten sandbox-image.service und pull-sandbox-image.sh auf GitHub.
- Sie können Ihre Benutzerdaten nun mit den folgenden Feldern beschreiben:
**Hinweis:**Ersetzen Sie XXXXXXX:3128, YOUR_CLUSTER_CA, API_SERVER_ENDPOINT und EKS_CLUSTER_NAME durch Ihren entsprechenden Proxy, Cluster CA, Serverendpunkt und Clustern-Namen. Sie können AWS-Serviceendpunkte zu NO_PROXY und no_proxy hinzufügen, nachdem Sie ihre VPC-Endpunkte erstellt haben.
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==--
Konfigurieren Sie die Proxy-Einstellung für aws-node und kube-proxy
Erstellen Sie eine ConfigMap, um die Umgebungswerte zu konfigurieren. Wenden Sie sie dann in Ihrem Cluster an. Verwenden Sie das folgende Skript als Beispiel für Ihre ConfigMap: **Hinweis:**Ersetzen Sie KUBERNETES_SERVICE_CIDR_RANGE und VPC_CIDR_RANGE durch die entsprechenden Werte für Ihre CIDR-Bereiche. Ersetzen Sie beispielsweise KUBERNETES_SERVICE_CIDR_RANGE durch 10.100.0.0/16 und VPC_CIDR_RANGE durch 192.168.0.0/16. Sie können AWS-Serviceendpunkte zu NO_PROXY und no_proxy hinzufügen, nachdem Sie ihre VPC-Endpunkte erstellt haben.
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
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 zuvor erstellte benutzerdefinierte Startvorlage verwendet. Folgen Sie den Schritten unter Eine verwaltete Knotengruppe erstellen.
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 der folgenden ä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
Relevanter Inhalt
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor 9 Monaten