Unterstützung für die Verbesserung dieser Seite beitragen
Um zu diesem Benutzerhandbuch beizutragen, klicken Sie auf den Link Diese Seite auf GitHub bearbeiten, der sich im rechten Bereich jeder Seite befindet.
Aktivierung des ausgehenden Internetzugangs für Pods
Gilt für: Linux-IPv4-Fargate-Knoten, Linux-Knoten mit Amazon-EC2-Instances
Wenn Sie Ihren Cluster mit der IPv6-Familie bereitgestellt haben, treffen die Informationen in diesem Thema nicht auf Ihren Cluster zu, da für IPv6-Adressen keine Netzwerkübersetzung möglich ist. Weitere Informationen zur Verwendung von IPv6 mit Ihrem Cluster finden Sie unter Informationen zu IPv6-Adressen für Cluster, Pods und Services.
Standardmäßig wird jedem Pod in Ihrem Cluster eine private IPv4-Adresse aus einem Classless Inter-Domain Routing (CIDR)-Block zugewiesen, der mit der VPC verknüpft ist, in welcher der Pod bereitgestellt wird. Pods im selben VPC kommunizieren miteinander und verwenden diese privaten IP-Adressen als Endpunkte. Wenn ein Pod mit einer IPv4-Adresse kommuniziert, die nicht Teil eines mit Ihrer VPC verknüpften CIDR-Blocks ist, übersetzt das Amazon-VPC-CNI-Plugin (für sowohl LinuxIPv4-Adresse des standardmäßig in die primäre private IPv4-Adresse der primären Elastic-Network-Schnittstelle des Knotens, auf dem der Pod ausgeführt wird *.
Anmerkung
Bei Windows-Knoten sind zusätzliche Details zu beachten. Standardmäßig ist das VPC CNI-Plugin für Windows
Folgen dieses Verhaltens:
-
Ihre Pods können nur dann mit Internetressourcen kommunizieren, wenn dem Knoten, auf dem er ausgeführt wird, eine öffentliche oder elastische IP-Adresse zugeordnet ist und er sich in einem öffentlichen Subnetz befindet. Eine Routing-Tabelle, die einem öffentlichen Subnetz zugeordnet ist, verfügt über eine Route zu einem Internet-Gateway. Wir empfehlen, Knoten nach Möglichkeit in privaten Subnetzen bereitzustellen.
-
Bei Versionen des Plugins vor
1.8.0können Ressourcen in Netzwerken oder VPCs, die über VPC-Peering, eine Transit-VPC oder AWS Direct Connect mit Ihrer Cluster-VPC verbunden sind, keine Kommunikation mit Ihren Pods hinter sekundären elastischen Netzwerkschnittstellen initiieren. Ihre Pods können jedoch eine Kommunikation an diese Ressourcen initiieren und Antworten von ihnen erhalten.
Wenn eine der folgenden Aussagen in Ihrer Umgebung zutrifft, ändern Sie die Standardkonfiguration mit dem folgenden Befehl.
-
Sie haben Ressourcen in Netzwerken oder VPCs, die über VPC-Peering, eine Transit-VPC oder AWS Direct Connect mit Ihrer Cluster-VPC verbunden sind und die Kommunikation mit Ihren Pods über eine
IPv4-Adresse initiieren müssen, und Ihre Plugin-Version ist älter als1.8.0. -
Ihre Pods befinden sich in einem privaten Subnetz und müssen ausgehend mit dem Internet kommunizieren. Das Subnetz hat eine Route zu einem NAT-Gateway.
kubectl set env daemonset -n kube-system aws-node AWS_VPC_K8S_CNI_EXTERNALSNAT=true
Anmerkung
Die AWS_VPC_K8S_CNI_EXTERNALSNAT- und AWS_VPC_K8S_CNI_EXCLUDE_SNAT_CIDRS-CNI-Konfigurationsvariablen gelten nicht für Windows-Knoten. Die Deaktivierung von SNAT wird für Windows nicht unterstützt. Was den Ausschluss einer Liste von IPv4-CIDRs aus SNAT angeht, können Sie dies definieren, indem Sie im Windows-Bootstrap-Skript den ExcludedSnatCIDRs-Parameter angeben. Weitere Informationen zur Verwendung dieses Parameters finden Sie unter Bootstrap-Skript-Konfigurationsparameter.
Host-Netzwerk
* Wenn die Spezifikation eines Pods hostNetwork=true enthält (Standard ist false), wird seine IP-Adresse nicht in eine andere Adresse übersetzt. Dies ist standardmäßig der Fall für die kube-proxy und Amazon-VPC-CNI-Plugin für Kubernetes-Pods, die in Ihrem Cluster ausgeführt werden. Für diese Pods ist die IP-Adresse dieselbe wie die primäre IP-Adresse des Knotens. Daher wird die IP-Adresse des Pods nicht übersetzt. Weitere Informationen über die hostNetwork-Einstellungen eines Pods finden Sie unter PodSpec v1 core