Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
SNAT für Pods
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 IPv6 -Adressen für ClusterPods, und services.
Standardmäßig ist jedem Pod in Ihrem Cluster eine private IPv4
-Adresse von einem Classless Inter-Domain Routing (CIDR)-Block zugewiesen, der mit der VPC verknüpft ist, in der der Pod bereitgestellt wird. Pods in derselben VPC kommunizieren miteinander, indem sie diese privaten IP-Adressen als Endpunkte verwenden. 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 Pod's 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 sie ausgeführt werden, eine öffentliche oder elastische IP-Adresse zugeordnet ist und sie sich in einem öffentlichen Subnetz befinden. 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.0
kö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 zu diesen 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 CNI-Konfigurationsvariablen AWS_VPC_K8S_CNI_EXTERNALSNAT
und AWS_VPC_K8S_CNI_EXCLUDE_SNAT_CIDRS
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.
*Wenn die Spezifikationen eines Pod's hostNetwork=true
enthalten (der Standard ist false
) wird die IP-Adresse nicht in eine andere Adresse übersetzt. Das gilt standardmäßig für die kube-proxy
- und Amazon VPC CNI plugin for 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 Pod's nicht übersetzt. Weitere Informationen zu einer -Pod'shostNetwork
Einstellung finden Sie unter PodSpec v1 core