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.

Bewährte Methoden für Netzwerke

Es ist wichtig, Kubernetes-Netzwerke zu verstehen, um Ihren Cluster und Ihre Anwendungen effizient zu betreiben. Pod-Networking, auch Cluster-Networking genannt, ist das Zentrum von Kubernetes-Netzwerken. Kubernetes unterstützt Container Network Interface (CNI) -Plugins für Cluster-Netzwerke.

Amazon EKS unterstützt offiziell das Amazon Virtual Private Cloud (VPC) CNI-Plugin zur Implementierung von Kubernetes-Pod-Netzwerken. Das VPC CNI bietet eine native Integration mit AWS VPC und arbeitet im Underlay-Modus. Im Underlay-Modus befinden sich Pods und Hosts auf derselben Netzwerkschicht und teilen sich den Netzwerk-Namespace. Die IP-Adresse des Pods ist aus Cluster- und VPC-Perspektive konsistent.

In diesem Handbuch wird das Amazon VPC Container Network Interface (VPC CNI) im Kontext von Kubernetes-Cluster-Netzwerken vorgestellt. Das VPC CNI ist das von EKS unterstützte Standard-Netzwerk-Plugin und steht daher im Mittelpunkt des Handbuchs. Das VPC CNI ist hochgradig konfigurierbar, um verschiedene Anwendungsfälle zu unterstützen. Dieses Handbuch enthält außerdem spezielle Abschnitte zu verschiedenen VPC-CNI-Anwendungsfällen, Betriebsmodi und Unterkomponenten, gefolgt von den Empfehlungen.

Amazon EKS führt Upstream-Kubernetes aus und ist als Kubernetes-konform zertifiziert. Sie können zwar alternative CNI-Plugins verwenden, dieser Leitfaden enthält jedoch keine Empfehlungen für die Verwaltung alternativer CNIs. In der Dokumentation zu EKS Alternate CNI finden Sie eine Liste von Partnern und Ressourcen für die effektive Verwaltung alternativer CNIs.

Kubernetes-Netzwerkmodell

Kubernetes stellt die folgenden Anforderungen an Cluster-Netzwerke:

Einzelheiten darüber, was Kubernetes von kompatiblen Netzwerkimplementierungen erwartet, finden Sie im Kubernetes-Netzwerkmodell. Die folgende Abbildung veranschaulicht die Beziehung zwischen Pod-Netzwerk-Namespaces und dem Host-Netzwerk-Namespace.

Container-Netzwerkschnittstelle (CNI)

Kubernetes unterstützt CNI-Spezifikationen und Plugins zur Implementierung des Kubernetes-Netzwerkmodells. Ein CNI besteht aus einer Spezifikation (aktuelle Version 1.0.0) und Bibliotheken zum Schreiben von Plugins zur Konfiguration von Netzwerkschnittstellen in Containern sowie einer Reihe unterstützter Plugins. CNI befasst sich ausschließlich mit der Netzwerkkonnektivität von Containern und dem Entfernen zugewiesener Ressourcen, wenn der Container gelöscht wird.

Das CNI-Plugin wird aktiviert, indem Kubelet die Befehlszeilenoption übergeben wird. --network-plugin=cni Kubelet liest eine Datei aus --cni-conf-dir (Standard/etc/cni/net.d) und verwendet die CNI-Konfiguration aus dieser Datei, um das Netzwerk jedes Pods einzurichten. Die CNI-Konfigurationsdatei muss der CNI-Spezifikation entsprechen (mindestens v0.4.0) und alle erforderlichen CNI-Plugins, auf die in der Konfiguration verwiesen wird, müssen im Verzeichnis vorhanden sein (Standard//bin). --cni-bin-dir opt/cni Wenn das Verzeichnis mehrere CNI-Konfigurationsdateien enthält, verwendet das Kubelet die Konfigurationsdatei, deren Name in lexikografischer Reihenfolge an erster Stelle steht.

Amazon Virtual Private Cloud (VPC) CNI

Das AWS-provided VPC CNI ist das Standard-Netzwerk-Add-On für EKS-Cluster. Das VPC CNI-Add-on wird standardmäßig installiert, wenn Sie EKS-Cluster bereitstellen. VPC CNI läuft auf Kubernetes-Worker-Knoten. Das VPC CNI-Add-on besteht aus der CNI-Binärdatei und dem IP-Adressverwaltungs-Plugin (ipamd). Das CNI weist einem Pod eine IP-Adresse aus dem VPC-Netzwerk zu. Die ipamd verwaltet AWS Elastic Networking Interfaces (ENIs) zu jedem Kubernetes-Knoten und verwaltet den warmen IP-Pool. Das VPC CNI bietet Konfigurationsoptionen für die Vorabzuweisung von ENIs und IP-Adressen für schnelle Pod-Startzeiten. Empfohlene Best Practices für die Plugin-Verwaltung finden Sie auf Amazon VPC CNI.

Amazon EKS empfiehlt, bei der Erstellung eines Clusters Subnetze in mindestens zwei Availability Zones anzugeben. Amazon VPC CNI weist Pods IP-Adressen aus den Knotensubnetzen zu. Wir empfehlen dringend, die Subnetze auf verfügbare IP-Adressen zu überprüfen. Bitte beachten Sie die VPC- und Subnetzempfehlungen, bevor Sie EKS-Cluster bereitstellen.

Amazon VPC CNI weist einen warmen Pool von ENIs und sekundären IP-Adressen aus dem Subnetz zu, das mit der primären ENI des Knotens verbunden ist. Dieser Modus von VPC CNI wird als sekundärer IP-Modus bezeichnet. Die Anzahl der IP-Adressen und damit die Anzahl der Pods (Pod-Dichte) wird durch die Anzahl der ENIs und die IP-Adresse pro ENI (Grenzwerte) definiert, wie sie durch den Instance-Typ definiert sind. Der sekundäre Modus ist der Standard und eignet sich gut für kleine Cluster mit kleineren Instance-Typen. Bitte erwägen Sie, den Präfixmodus zu verwenden, wenn Sie Probleme mit der Pod-Dichte haben. Sie können auch die verfügbaren IP-Adressen auf dem Knoten für Pods erhöhen, indem Sie ENIs Präfixe zuweisen.

Amazon VPC CNI lässt sich nativ in AWS VPC integrieren und ermöglicht es Benutzern, bestehende bewährte AWS-VPC-Netzwerk- und Sicherheitsmethoden für den Aufbau von Kubernetes-Clustern anzuwenden. Dazu gehört die Möglichkeit, VPC-Flussprotokolle, VPC-Routing-Richtlinien und Sicherheitsgruppen für die Isolierung des Netzwerkverkehrs zu verwenden. Standardmäßig wendet das Amazon VPC CNI die Sicherheitsgruppe, die der primären ENI auf dem Knoten zugeordnet ist, auf die Pods an. Erwägen Sie die Aktivierung von Sicherheitsgruppen für Pods, wenn Sie einem Pod unterschiedliche Netzwerkregeln zuweisen möchten.

Standardmäßig weist VPC CNI Pods IP-Adressen aus dem Subnetz zu, das der primären ENI eines Knotens zugewiesen ist. Beim Betrieb großer Cluster mit Tausenden von Workloads kommt es häufig zu einem Mangel an IPv4-Adressen. Mit AWS VPC können Sie verfügbare IPs erweitern, indem Sie sekundäre CIDRs zuweisen, um die Erschöpfung der IPv4-CIDR-Blöcke zu umgehen. Mit AWS VPC CNI können Sie einen anderen Subnetz-CIDR-Bereich für Pods verwenden. Diese Funktion von VPC CNI wird als benutzerdefiniertes Netzwerk bezeichnet. Sie könnten erwägen, benutzerdefinierte Netzwerke 100.64.0.0/10 und 198.19.0.0/16 CIDRs (CG-NAT) mit EKS zu verwenden. Auf diese Weise können Sie effektiv eine Umgebung schaffen, in der Pods keine RFC1918-IP-Adressen mehr von Ihrer VPC verbrauchen.

Benutzerdefinierte Netzwerke sind eine Option, um das Problem der IPv4-Adressüberflutung zu lösen, aber sie erfordern betrieblichen Mehraufwand. Wir empfehlen IPv6-Cluster gegenüber benutzerdefinierten Netzwerken, um dieses Problem zu lösen. Insbesondere empfehlen wir die Migration zu IPv6-Clustern, wenn Sie den gesamten verfügbaren IPv4-Adressraum für Ihre VPC vollständig ausgeschöpft haben. Prüfen Sie die Pläne Ihres Unternehmens zur Unterstützung von IPv6 und überlegen Sie, ob sich Investitionen in IPv6 langfristig lohnen könnten.

Die Unterstützung von EKS für IPv6 konzentriert sich auf die Lösung des Problems der IP-Erschöpfung, das durch einen begrenzten IPv4-Adressraum verursacht wird. Als Reaktion auf Kundenprobleme mit IPv4-Erschöpfung hat EKS Pods Vorrang IPv6-only vor Dual-Stack-Pods eingeräumt. Das heißt, Pods können möglicherweise auf IPv4-Ressourcen zugreifen, ihnen wird jedoch keine IPv4-Adresse aus dem VPC-CIDR-Bereich zugewiesen. Die VPC-CNI weist Pods IPv6-Adressen aus dem von AWS verwalteten VPC-IPv6-CIDR-Block zu.

Subnetz-Rechner

Dieses Projekt enthält ein Excel-Dokument für den Subnetzrechner. Dieses Rechendokument simuliert den IP-Adressverbrauch eines bestimmten Workloads unter verschiedenen ENI-Konfigurationsoptionen wie WARM_IP_TARGET und. WARM_ENI_TARGET Das Dokument umfasst zwei Blätter, ein erstes für den Warm-ENI-Modus und ein zweites für den Warm-IP-Modus. Weitere Informationen zu diesen Modi finden Sie in den VPC CNI-Leitlinien.

Eingänge:

Ausgaben: