Benutzerdefinierte CNI-Netzwerke - Amazon EKS

Benutzerdefinierte CNI-Netzwerke

Wenn Pods neue Netzwerkschnittstellen zugewiesen werden, verwendet ipamD standardmäßig die Sicherheitsgruppen und das Subnetz der primären Netzwerkschnittstelle des Knotens. Möglicherweise möchten Sie, dass Ihre Pods eine andere Sicherheitsgruppe oder ein anderes Subnetz innerhalb derselben VPC wie Ihre Sicherheitsgruppe der Steuerebene verwenden. Beispiel:

  • Es gibt nur eine begrenzte Anzahl verfügbarer IP-Adressen in einem Subnetz. Dadurch könnte die Anzahl der Pods eingeschränkt werden, die im Cluster erstellt werden können. Durch die Verwendung von unterschiedlichen Subnetzen für Pods können Sie die Anzahl der verfügbaren IP-Adressen erhöhen.

  • Aus Sicherheitsgründen müssen Ihre Pods andere Sicherheitsgruppen oder Subnetze als die primäre Netzwerkschnittstelle des Knotens verwenden.

  • Die Knoten sind in öffentlichen Subnetzen konfiguriert und die Pods sollen mit einem NAT-Gateway in privaten Subnetzen platziert werden. Weitere Informationen finden Sie unter Externes Source Network Address Translation (SNAT).

Considerations

  • Die Verfahren in diesem Thema erfordern das Amazon VPC CNI-Plug-In für Kubernetes Version 1.4.0 oder höher.

  • Durch Aktivieren dieser Funktion wird bewirkt, dass eine verfügbare Network-Schnittstelle (und alle ihre verfügbaren IP-Adressen für Pods) von jedem Knoten, der diese nutzt, entfernt wird. Die primäre Netzwerkschnittstelle des Knotens wird nicht für die Pod-Platzierung verwendet, wenn diese Funktion aktiviert ist.

  • Das Verfahren in diesem Thema weist das Amazon-VPC-CNI-Add-on an, den sekundären Netzwerkschnittstellen andere Sicherheitsgruppen zuzuordnen als der primären Netzwerkschnittstelle in der Instance. Alle Pods, die die sekundären Netzwerkschnittstellen verwenden, teilen sich weiterhin die sekundären Netzwerkschnittstellen und verwenden alle dieselben Sicherheitsgruppen.

    Wenn Sie einzelnen Pods unterschiedliche Sicherheitsgruppen zuweisen möchten, können Sie Sicherheitsgruppen für Pods verwenden. Sicherheitsgruppen für Pods erstellen zusätzliche Netzwerkschnittstellen, denen jeweils eine eindeutige Sicherheitsgruppe zugewiesen werden kann. Sicherheitsgruppen für Pods können mit oder ohne benutzerdefinierten verwendet werden. Die sekundären Netzwerkschnittstellen verwenden weiterhin die sekundären Netzwerkschnittstellen und verwenden alle dieselben Sicherheitsgruppen. Wenn Sie einzelnen Pods unterschiedliche Sicherheitsgruppen zuweisen möchten, können Sie Sicherheitsgruppen für Pods verwenden. Sicherheitsgruppen für Pods erstellen zusätzliche Netzwerkschnittstellen, denen jeweils eine eindeutige Sicherheitsgruppe zugewiesen werden kann. Sicherheitsgruppen für Pods können mit oder ohne benutzerdefiniertes Netzwerk verwendet werden.

So konfigurieren Sie benutzerdefinierte CNI-Netzwerke

  1. Bestätigen Sie, dass Ihre aktuell installierte Amazon VPC CNI-Version 1.9.0 oder höher ist.

    kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2

    Ausgabe:

    amazon-k8s-cni:1.9.0-eksbuild.1

    Wenn Ihre Version älter als 1.4.0 ist, müssen Sie sie aktualisieren. Weitere Informationen finden Sie in den Aktualisierungsabschnitten von Verwalten des Amazon VPC CNI-Add-ons.

  2. Verknüpfen Sie einen sekundären CIDR-Block mit der VPC Ihres Clusters. Weitere Informationen finden Sie unter Zuordnen eines sekundären IPv4-CIDR-Blocks zu Ihrer VPC im Amazon-VPC-Benutzerhandbuch.

  3. Erstellen Sie mithilfe Ihres sekundären CIDR-Blocks für jede Availability Zone ein Subnetz in Ihrer VPC. Ihre benutzerdefinierten Subnetze müssen aus einem anderen VPC-CIDR-Block stammen als das Subnetz, in dem Ihre Knoten gestartet wurden. Weitere Informationen finden Sie unter Erstellen eines Subnetzes in Ihrer VPC im Amazon-VPC-Benutzerhandbuch.

  4. Legen Sie die AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG-Umgebungsvariable im true-DaemonSet auf aws-node fest:

    kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true
  5. Erstellen Sie eine benutzerdefinierte ENIConfig-Ressource für jedes Subnetz, in dem Sie Pods planen möchten.

    1. Erstellen Sie für jede Konfiguration der Netzwerk-Schnittstelle eine eindeutige Datei. Jede Datei muss den unten angegebenen Inhalt mit einem eindeutigen Wert für name enthalten. Es wird dringend empfohlen, einen Wert für name zu verwenden, der der Availability Zone des Subnetzes entspricht, da dies die Bereitstellung von Auto-Scaling-Gruppen mit mehreren Verfügbarkeitszonen einfacher macht (siehe Schritt 5c unten).

      In diesem Beispiel wird eine Datei mit dem Namen us-west-2a.yaml erstellt. Ersetzen Sie die <example values> (einschließlich <>) für name, subnet und securityGroups durch Ihre eigenen Werte. In diesem Beispiel folgen wir bewährten Verfahren und setzen den Wert für name auf die Availability Zone, in der sich das Subnetz befindet. Wenn Sie noch keine bestimmte Sicherheitsgruppe besitzen, die Sie für Ihre Pods anfügen möchten, brauchen Sie an dieser Stelle noch keinen Wert anzugeben. Später geben Sie die Knotensicherheitsgruppe in ENIConfig an.

      apiVersion: crd.k8s.amazonaws.com/v1alpha1 kind: ENIConfig metadata: name: <us-west-2a> spec: securityGroups: - <sg-0dff111a1d11c1c11> subnet: <subnet-011b111c1f11fdf11>
      Anmerkung
      • Für jede Kombination von Subnetz und Sicherheitsgruppe wird eine eigene benutzerdefinierte Ressource benötigt. Wenn Sie über mehrere Subnetze in derselben Availability Zone verfügen, verwenden Sie den folgenden Befehl, um die Knoten in jedem Subnetz mit dem entsprechenden Konfigurationsnamen zu versehen.

        kubectl annotate node <node-name>.<region>.compute.internal k8s.amazonaws.com/eniConfig=<subnet1ConfigName>
      • Wenn Sie keine gültige Sicherheitsgruppe für die VPC angeben, wird die Standardsicherheitsgruppe für die VPC sekundären ENIs zugewiesen.

    2. Wenden Sie jede benutzerdefinierte Ressourcendatei, die Sie zuvor erstellt haben, mit dem folgenden Befehl auf Ihren Cluster an:

      kubectl apply -f <us-west-2a>.yaml
    3. (Optional, aber empfohlen für Multi-Availability Zone-Knotengruppen) Standardmäßig wendet Kubernetes die Availability Zone eines Knotens auf die failure-domain.beta.kubernetes.io/zone-Markierung an. Wenn Sie Ihre benutzerdefinierten ENIConfig-Ressourcen nach jeder Availability Zone in Ihrer VPC benannt haben, wie in Schritt 5a empfohlen, dann können Sie Kubernetes mit dem folgenden Befehl die automatische Anwendung der entsprechenden ENIConfig für die Availability Zone des Knotens ermöglichen.

      kubectl set env daemonset aws-node -n kube-system ENI_CONFIG_LABEL_DEF=failure-domain.beta.kubernetes.io/zone
      Anmerkung

      Stellen Sie sicher, dass keine Anmerkung mit dem Schlüssel k8s.amazonaws.com/eniConfig für die ENI_CONFIG_ANNOTATION_DEF-Umgebungsvariable in der Containerspezifikation für den aws-node Daemonset vorhanden ist. Wenn dies doch der Fall ist, überschreibt sie den ENI_CONFIG_LABEL_DEF-Wert und sollte entfernt werden. Sie können überprüfen, ob die Variable mit dem kubectl describe daemonset aws-node -n kube-system | grep ENI_CONFIG_ANNOTATION_DEF-Befehl gesetzt ist. Wenn keine Ausgabe zurückgegeben wird, wird die Variable nicht gesetzt.

  6. Wenn Sie planen, eine verwaltete Knotengruppe ohne Startvorlage bereitzustellen oder mit einer Startvorlage, in der Sie keine AMI-ID angegeben haben, fahren Sie mit Schritt 7 fort und verwenden Sie Verwaltet, Ohne Startvorlage oder mit Startvorlage ohne eine von der AMI-ID angegebene Option. Verwaltete Knotengruppen berechnen automatisch den maximalen Pod-Wert für Sie.

    Wenn Sie eine selbstverwaltete Knotengruppe oder eine verwaltete Knotengruppe mit einer Startvorlage bereitstellen, in der Sie eine AMI-ID angegeben haben, müssen Sie die von Amazon EKS empfohlene Anzahl der maximalen Pods für Ihre Knoten ermitteln. Befolgen Sie die Anweisungen in Von Amazon EKS empfohlene maximale Pods für jeden Amazon-EC2-Instance-Typ und fügen Sie --cni-custom-networking-enabled zu Schritt 3 hinzu. Notieren Sie sich die Ausgabe zur Verwendung in einem späteren Schritt.

  7. Erstellen Sie einen der folgenden Typen von Knotengruppen. Weitere Kriterien zur Instance-Auswahl finden Sie unter Auswählen eines Amazon-EC2-Instance-Typs. Ersetzen Sie die Optionen, die <20> (einschließlich <>) enthalten, entweder durch den Wert aus dem vorherigen Schritt (empfohlen) oder Ihren eigenen Wert.

    • Selbstverwaltet – Stellen Sie die Knotengruppe mithilfe der Anweisungen in Starten selbstverwalteter Amazon Linux-Knoten bereit. Geben Sie nicht die Subnetze an, die Sie in den bereitgestellten ENIConfig-Ressourcen angegeben haben. Geben Sie den folgenden Text für den Parameter BootstrapArguments an.

      --use-max-pods false --kubelet-extra-args '--max-pods=<20>'
    • Verwaltet – Stellen Sie Ihre Knotengruppe mit einer der folgenden Optionen bereit:

      • Ohne Startvorlage oder mit Startvorlage ohne angegebene AMI-ID – Führen Sie das Verfahren in Erstellen einer verwalteten Knotengruppe aus. Verwaltete Knotengruppen berechnen automatisch den von Amazon EKS empfohlenen maximalen Pod-Wert für Sie.

      • Mit einer Startvorlage mit einer angegebenen AMI-ID – Geben Sie in Ihrer Startvorlage eine Amazon EKS-optimierte AMI-ID oder ein benutzerdefiniertes AMI an, das auf dem Amazon EKS-optimierten AMI basiert, stellen Sie dann die Knotengruppe mithilfe einer Startvorlage bereit und geben Sie die folgenden Benutzerdaten an in der Startvorlage. Diese Benutzerdaten übergeben Argumente an die bootstrap.sh-Datei. Weitere Informationen zur Bootstrap-Datei finden Sie unter bootstrap.sh auf GitHub.

        /etc/eks/bootstrap.sh <my-cluster> \ --kubelet-extra-args '--max-pods=<20>'

        Wenn Sie ein benutzerdefiniertes AMI erstellt haben, das nicht auf dem für Amazon EKS optimierten AMI erstellt wurde, müssen Sie die Konfiguration selbst erstellen.

    Anmerkung

    Wenn Ihre Knoten eine deutlich höhere Anzahl von Pods unterstützen sollen, führen Sie das Skript Von Amazon EKS empfohlene maximale Pods für jeden Amazon-EC2-Instance-Typ erneut aus und fügen Sie dem Befehl die --cni-prefix-delegation-enabled-Option hinzu. Beispielsweise wird 110 für einen m5.large-Instance-Typ zurückgegeben. Informationen zum Aktivieren dieser Funktion finden Sie unter Erhöhen Sie die Anzahl der verfügbaren IP-Adressen für Ihre Amazon-EC2-Knoten. Sie können dies verwenden

    Fähigkeit mit benutzerdefinierten Netzwerken.

  8. Nachdem Ihre Knotengruppe erstellt wurde, zeichnen Sie die Sicherheitsgruppe auf, die für das Subnetz erstellt wurde, und wenden Sie die Sicherheitsgruppe auf das zugehörige ENIConfig. Bearbeiten Sie jede ENIConfig mit dem folgenden Befehl, und ersetzen Sie dabei <eniconfig-name> durch Ihren Wert:

    kubectl edit eniconfig.crd.k8s.amazonaws.com/<eniconfig-name>

    Wenn Sie die bewährten Methoden in Schritt 5 befolgt haben, entspricht das eniconfig-name dem Namen der Availability Zone.

    Der spec-Abschnitt sollte wie in der folgenden Beispielspezifikation aussehen:

    spec: securityGroups: - <sg-0dff222a2d22c2c22> subnet: <subnet-022b222c2f22fdf22>
    Anmerkung

    Wenn Sie die erstellte Sicherheitsgruppe verwenden, stellen Sie sicher, dass die empfohlenen oder mindestens erforderlichen Sicherheitsgruppeneinstellungen für die Cluster-, Steuerebene- und Knotensicherheitsgruppen erfüllt sind. Weitere Informationen finden Sie unter Überlegungen zur Amazon-EKS-Sicherheitsgruppe.

  9. Wenn in Ihrem Cluster Knoten mit ausgeführten Pods vorhanden waren, bevor Sie zur benutzerdefinierten CNI-Netzwerkfunktion gewechselt haben, sollten Sie die Knoten absperren und entleeren, um die Pods ordnungsgemäß herunterzufahren und dann die Knoten zu beenden. Nur neue Knoten, die mit der Bezeichnung k8s.amazonaws.com/eniConfig registriert sind, verwenden die neue benutzerdefinierte Netzwerkfunktion.