Wie wähle ich bestimmte IP-Subnetze aus, die für Pods in meinem Amazon-EKS-Cluster verwendet werden sollen?

Lesedauer: 6 Minute
0

Ich möchte benutzerdefinierte Subnetze oder IP-Bereiche für meine Pods in Amazon Elastic Kubernetes Service (Amazon EKS) verwenden.

Kurzbeschreibung

Manchmal verwenden Pods nicht alle verfügbaren Subnetze in Ihrem Amazon-EKS-Cluster. Dies passiert, wenn einige Knotensubnetze keine verfügbaren IP-Adressen haben, andere Subnetze in der Amazon Virtual Private Cloud (Amazon VPC) jedoch nicht ausreichend genutzt werden.

Knoten und Pods in Amazon EKS verwenden IP-Adressen aus demselben Adressraum: die IP-CIDR-Bereiche, die der Cluster-VPC zugeordnet sind. Insbesondere weist Amazon EKS IPs für Pods aus demselben Subnetz des Worker-Knotens zu, in dem die Pods geplant sind.

Nehmen wir zum Beispiel an, dass node-1 in subnet-1 gestartet wird. Das heißt, die primäre elastische Netzwerkschnittstelle des Knotens befindet sich in subnet-1. Später kann pod-A eingesetzt und für node-1 geplant werden. Standardmäßig weist das Amazon-VPC-CNI-Plugin sekundäre elastische Netzwerkschnittstellen und IPs in subnet-1 zu, um pod-A eine IP-Adresse zuzuweisen.

Daher haben Benutzer keine direkte Kontrolle über die benutzerdefinierte Zuweisung von Pods zu IP-Subnetzen, da Pods und Knoten dasselbe Subnetz verwenden. Wenn Knoten über ausreichend Rechenkapazität verfügen, um viele Pods auszuführen, verwenden Pods möglicherweise alle verfügbaren IP-Adressen im Knotensubnetz. Neue Pods können nicht ausgeführt werden, da die IP-Adressen im Knotensubnetz erschöpft sind. Dies tritt auch dann auf, wenn andere Subnetze in Amazon VPC möglicherweise über verfügbare IP-Adressen verfügen.

Lösung

Sie können dieses Problem beheben, indem Sie die benutzerdefinierte Netzwerkkomponente von Amazon VPC CNI verwenden. Mit dieser Funktion können Sie bestimmte Subnetze im Amazon-VPC-Cluster definieren, die von Ihren Pods verwendet werden. Es unterscheidet Ihre Subnetze von denen, die von den Worker-Knoten verwendet werden. Als zusätzlichen Vorteil können Sie Sicherheitsgruppen für Ihre Pods definieren. Weitere Informationen zu Anwendungsfällen für benutzerdefinierte Netzwerke finden Sie unter Tutorial: Benutzerdefiniertes Netzwerk.

Voraussetzung

Bevor Sie beginnen, gehen Sie wie folgt vor:

Es hat sich bewährt, sicherzustellen, dass in Ihrem Cluster die neueste Version des Amazon-VPC-CNI-Plug-ins ausgeführt wird. Führen Sie den folgenden Befehl aus, um die Version in Ihrem Amazon-VPC-Cluster zu überprüfen:

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

Hinweis: Weitere Informationen zur am besten zu verwendenden Version finden Sie unter Aktualisieren des Amazon-VPC-CNI-Plug-ins für ein selbstverwaltetes Add-on.

Ihr benutzerdefiniertes Subnetz und Ihre IP-Bereiche konfigurieren

Gehen Sie wie folgt vor, um die benutzerdefinierte Netzwerkfunktion Amazon VPC CNI zu verwenden:

1.    Schalten Sie die benutzerdefinierte Netzwerkfunktion Amazon VPC CNI ein:

kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true

2.    Erstellen Sie ENIConfig-Objekte, um Subnetze und Sicherheitsgruppen für die zu verwendenden Pods zu definieren.

Ein ENIConfig-Objekt definiert ein Subnetz und eine Liste von Sicherheitsgruppen. Wenn ein Knoten nur mit einem ENIConfig-Objekt annotiert oder beschriftet ist, verwenden alle für diesen Knoten geplanten Pods die in diesem ENIConfig-Objekt definierten Subnetz- und Sicherheitsgruppen.

Sie können ein ENIConfig-Objekt automatisch oder manuell mit einem Knoten verknüpfen.

ENIConfig-Objekte automatisch mit Knoten verknüpfen

Diese Option erlaubt nur ein ENIConfig-Objekt (ein Subnetz) pro Availability Zone (AZ). Der ENIConfig-Name muss der Name der AZ sein.

1.    Erstellen Sie ENIConfig-Objekte mit dem AZ-Namen:

cat <<EOF  | kubectl apply -f -
apiVersion: crd.k8s.amazonaws.com/v1alpha1
kind: ENIConfig
metadata:
 name: us-east-2a
spec:
  securityGroups: 
    - sg-xxxxxxxxxxxx
  subnet: subnet-XXXXXXXX
EOF


cat <<EOF | kubectl apply -f -
apiVersion: crd.k8s.amazonaws.com/v1alpha1
kind: ENIConfig
metadata:
 name: us-east-2b
spec:
  securityGroups: 
    - sg-xxxxxxxxxxxx
  subnet: subnet-YYYYYYYYY
EOF

2.    Aktivieren Sie Amazon-VPC-CNI, um Knoten automatisch mit dem ENIConfig-Objekt zu kennzeichnen, das dem Knoten AZ entspricht.

kubectl set env daemonset aws-node -n kube-system ENI_CONFIG_LABEL_DEF=topology.kubernetes.io/zone

ENIConfig-Objekte manuell mit Knoten verknüpfen

Diese Option erlaubt mehrere ENIConfig-Objekte pro Availability Zone. Beachten Sie, dass Sie für jedes ENIConfig-Objekt einen benutzerdefinierten Namen verwenden können. Stellen Sie sicher, dass sich der Knoten und das zugehörige ENIConfig-Objekt in derselben Availability Zone befinden.

Hinweis: Sie können nur einen Knoten mit einem ENIConfig-Objekt annotieren, aber Sie können mehrere Knoten mit demselben ENIConfig-Objekt annotieren.

1.    Erstellen Sie ENIConfig-Objekte mit benutzerdefinierten Namen wie folgt:

cat <<EOF  | kubectl apply -f -
apiVersion: crd.k8s.amazonaws.com/v1alpha1
kind: ENIConfig
metadata:
 name: my-conf-1-us-east-2a
spec:
  securityGroups: 
    - sg-xxxxxxxxxxxx
  subnet: subnet-XXXXXXXX
EOF


cat <<EOF | kubectl apply -f -
apiVersion: crd.k8s.amazonaws.com/v1alpha1
kind: ENIConfig
metadata:
 name: my-conf-2-us-east-2a
spec:
  securityGroups: 
    - sg-xxxxxxxxxxxx
  subnet: subnet-ZZZZZZZZZZ
EOF

2.    Kommentieren Sie Knoten manuell mit ENIConfig-Objekten. Stellen Sie sicher, dass sich der Knoten und das Subnetz im zugehörigen ENIConfig-Objekt in derselben Availability Zone befinden.

kubectl annotate node ip-192-168-0-126.us-east-2.compute.internal k8s.amazonaws.com/eniConfig=my-conf-1-us-east-2a

Diese manuelle Anmerkung hat Vorrang vor der automatisch von Amazon VPC CNI hinzugefügten Bezeichnung.

Neue Knoten starten, um den aktuellen Worker-Knoten zu ersetzen

Bestehende Worker-Knoten verfügen möglicherweise über sekundäre elastische Netzwerkschnittstellen und IPs aus dem Knotensubnetz, bevor Sie die benutzerdefinierte Netzwerkfunktion in Amazon VPC CNI aktiviert haben. Aus diesem Grund müssen Sie neue Knoten starten, damit diese sekundäre elastische Netzwerkschnittstellen und IPs aus den Subnetzen zuweisen können, die in dem dem Knoten zugeordneten ENIConfig-Objekt definiert sind.

1.    Überprüfen Sie, ob Sie eine der folgenden Knotengruppenoptionen verwenden:

  • selbstverwaltete Knotengruppe
  • verwaltete Knotengruppe mit benutzerdefinierter AMI-ID

Hinweis: Wenn Sie Knoten in diesen Knotengruppentypen erstellen, fahren Sie mit Schritt 2 fort, um die maximale Anzahl von Pods für Ihre Knoten manuell zu definieren. Wenn Sie Knoten in der Managed Nodes Group starten, ohne ein benutzerdefiniertes AMI anzugeben, aktualisiert Amazon EKS automatisch die maximale Anzahl von Pods für Ihre Knoten. Weitere Informationen finden Sie unter Verwaltete Knotengruppen.

2.    Ermitteln Sie die maximale Anzahl von Pods pro Knoten. Bei der Verwendung benutzerdefinierter Netzwerke wird die primäre Netzwerkschnittstelle des Knotens nicht für Pod-IPs verwendet. Informationen zur Bestimmung des Max-Pods-Werts mithilfe des Max-Pods-Berechnungsskripts finden Sie unter Von Amazon EKS empfohlene maximale Pods für jeden EC2-Instance-Typ.

Hinweis: Verwenden Sie das Flag cni-custom-networking-enabled mit dem obigen Skript, um Pods in einem anderen Subnetz als Ihrer eigenen Instance zu starten.

3.    Aktualisieren Sie das Benutzerdatenskript auf Ihren neuen Knoten, sodass es die erforderlichen Flags enthält. Beispiel:

#!/bin/bash
/etc/eks/bootstrap.sh my_cluster_name --use-max-pods false --kubelet-extra-args '--max-pods=20'

Hinweis: Ersetzen Sie my-cluster-name durch Ihren EKS-Clusternamen. Weitere Informationen zur Bootstrap-Funktionalität finden Sie unter awslabs/amazon-eks-ami auf der GitHub-Website.

4.    Erstellen Sie die Pods neu, um die neue benutzerdefinierte Pod-Netzwerkkonfiguration zu verwenden.

Weitere Überlegungen

  • Standardmäßig verwendet der Datenverkehr von Pods zu IP-Adressen außerhalb des Cluster-VPC-CIDR die Hauptschnittstelle und IP-Adresse des Knotens. Daher verwendet dieser Datenverkehr nicht die in der ENIConfig definierten Subnetz- und Sicherheitsgruppen. Stattdessen verwendet der Datenverkehr die Sicherheitsgruppen und das Subnetz der primären Netzwerkschnittstelle des Knotens. Weitere Informationen finden Sie unter SNAT für Pods.
  • Wenn Sie auch Sicherheitsgruppen für Pods verwenden, wird die in einer SecurityGroupPolicy angegebene Sicherheitsgruppe anstelle der in den ENIConfig-Objekten angegebenen Sicherheitsgruppe verwendet .
  • Die neuesten Updates auf der GitHub-Website finden Sie unter Vereinfachen des benutzerdefinierten Netzwerks.
  • Um Ihrer VPC weitere IP-CIDR-Bereiche hinzuzufügen, folgen Sie den Schritten unter Wie verwende ich mehrere CIDR-Bereiche in Amazon EKS?

AWS OFFICIAL
AWS OFFICIALAktualisiert vor einem Jahr