Benutzerdefinierte Netzwerke für Pods - Amazon EKS
Schritt 1: Erstellen einer Test-VPC und eines ClustersSchritt 2: Konfigurieren Ihrer VPCSchritt 3: Konfigurieren von Kubernetes-RessourcenSchritt 4: Bereitstellen von Amazon-EC2-KnotenSchritt 5: Löschen von Tutorial-Ressourcen

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.

Benutzerdefinierte Netzwerke für Pods

Standardmäßig erstellt das Amazon VPC CNI plugin for Kubernetes sekundäre Elastic-Network-Schnittstellen (Netzwerkschnittstellen) für Ihren Amazon EC2-Knoten im gleichen Subnetz wie die primäre Netzwerkschnittstelle des Knotens. Es verknüpft auch dieselben Sicherheitsgruppen mit der sekundären Netzwerkschnittstelle, die mit der primären Netzwerkschnittstelle verknüpft sind. Aus einem oder mehreren der folgenden Gründe möchten Sie möglicherweise, dass das Plugin sekundäre Netzwerkschnittstellen in einem anderen Subnetz erstellt oder Sie möchten den sekundären Netzwerkschnittstellen oder beiden verschiedene Sicherheitsgruppen zuordnen:

  • Es gibt eine begrenzte Anzahl IPv4-Adressen, die in dem Subnetz verfügbar sind, in dem sich die primäre Netzwerkschnittstelle befindet. Dies könnte die Anzahl der Pods einschränken, die Sie in dem Subnetz erstellen können. Durch Verwendung eines anderen Subnetzes für sekundäre Netzwerkschnittstellen können Sie die Anzahl der verfügbaren IPv4-Adressen für Pods erhöhen.

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

  • Die Knoten sind in öffentlichen Subnetzen konfiguriert und die Pods sollen in privaten Subnetzen platziert werden. Die einem öffentlichen Subnetz zugeordnete Routing-Tabelle enthält eine Route zu einem Internet-Gateway. Die einem privaten Subnetz zugeordnete Routing-Tabelle enthält keine Route zu einem Internet-Gateway.

Überlegungen

  • Wenn benutzerdefinierte Netzwerke aktiviert sind, werden Pods keine IP-Adressen zugewiesen, die der primären Netzwerkschnittstelle zugewiesen sind. Pods werden nur IP-Adressen von sekundären Netzwerkschnittstellen zugewiesen.

  • Wenn Ihr Cluster die IPv6-Familie verwendet, können Sie keine benutzerdefinierten Netzwerke verwenden.

  • Wenn Sie vorhaben, benutzerdefinierte Netzwerke zu verwenden, um die IPv4-Adresserschöpfung zu verhindern, können Sie stattdessen einen Cluster über die IPv6-Familie erstellen. Weitere Informationen finden Sie unter IPv6 -Adressen für ClusterPods, und services.

  • Auch wenn in Subnetzen für sekundäre Netzwerkschnittstellen bereitgestellte Pods andere Subnetz- und Sicherheitsgruppen verwenden können als die primäre Netzwerkschnittstelle des Knotens, müssen sich die Subnetze und Sicherheitsgruppen in derselben VPC befinden wie der Knoten.

Voraussetzungen

  • Sie müssen damit vertraut sein, wie das Amazon VPC CNI plugin for Kubernetes sekundäre Netzwerkschnittstellen erstellt und Pods IP-Adressen zuweist. Weitere Informationen finden Sie unter ENI-Zuweisung auf GitHub.

  • Version 2.12.3 oder höher oder Version 1.27.160 oder höher der AWS Command Line Interface (AWS CLI), die auf Ihrem Gerät oder installiert und konfiguriert ist AWS CloudShell. Um Ihre aktuelle Version zu überprüfen, verwenden Sie aws --version | cut -d / -f2 | cut -d ' ' -f1. Paket-Manager wie yum, apt-get oder Homebrew für macOS sind oft mehrere Versionen hinter der neuesten Version von AWS CLI. Informationen zur Installation der neuesten Version von finden Sie unter Installation, Aktualisierung und Deinstallation der AWS CLI und Schnellkonfiguration mit aws configure im AWS Command Line Interface -Benutzerhandbuch. Die in installierte AWS CLI Version liegt AWS CloudShell möglicherweise auch hinter der neuesten Version. Informationen zum Aktualisieren finden Sie unter Installieren AWS CLI von in Ihrem Stammverzeichnis im AWS CloudShell -Benutzerhandbuch.

  • Das kubectl-Befehlszeilen-Tool ist auf Ihrem Gerät oder in der AWS CloudShell installiert. Die Version kann der Kubernetes-Version Ihres Clusters entsprechen oder eine Nebenversion älter oder neuer sein. Wenn Ihre Clusterversion beispielsweise 1.28 ist, können Sie kubectl-Version 1.27, 1.28, oder 1.29 damit verwenden. Informationen zum Installieren oder Aktualisieren von kubectl finden Sie unter Installieren oder Aktualisieren von kubectl.

  • Wir empfehlen, dass Sie die Schritte in diesem Thema in einer Bash-Shell ausführen. Wenn Sie keine Bash-Shell verwenden, erfordern einige Skriptbefehle wie Zeilenfortsetzungszeichen und die Art und Weise, wie Variablen gesetzt und verwendet werden, eine Anpassung für Ihre Shell. Darüber hinaus können die Zitier- und Escape-Regeln für Ihre Shell unterschiedlich sein. Weitere Informationen finden Sie unter Verwenden von Anführungszeichen mit Zeichenfolgen im im AWS CLI AWS Command Line Interface -Benutzerhandbuch.

Für dieses Tutorial empfehlen wir die Verwendung der example values, außer es gibt eine Anmerkung, diese zu ersetzen. Sie können jeden example value ersetzen, wenn Sie die Schritte für einen Produktions-Cluster ausführen. Wir empfehlen, alle Schritte auf demselben Terminal auszuführen. Grund dafür ist, dass Variablen während der Schritte festgelegt und verwendet werden und diese in anderen Terminals nicht vorhanden sind.

Die Befehle in diesem Thema sind unter Verwendung der Konventionen formatiert, die unter Verwenden der AWS CLI Beispiele aufgeführt sind. Wenn Sie Befehle über die Befehlszeile für Ressourcen ausführen, die sich in einer anderen befinden AWS-Region als die im verwendeten AWS CLI Profil AWS-Region definierte Standardeinstellung, müssen Sie --region region-code den Befehlen hinzufügen.

Wenn Sie benutzerdefinierte Netzwerke in Ihrem Produktions-Cluster bereitstellen möchten, fahren Sie mit Schritt 2: Konfigurieren Ihrer VPC fort.

Schritt 1: Erstellen einer Test-VPC und eines Clusters

So erstellen Sie einen Cluster

Mit den folgenden Verfahren können Sie eine Test-VPC und einen Cluster erstellen und benutzerdefinierte Netzwerke für diesen Cluster konfigurieren. Wir empfehlen, den Test-Cluster nicht für Produktions-Workloads zu verwenden, da in diesem Thema verschiedene nicht verwandte Features nicht behandelt werden, die Sie vielleicht in Ihrem Produktions-Cluster verwenden. Weitere Informationen finden Sie unter Erstellen eines Amazon-EKS-Clusters.

  1. Definieren Sie einige Variablen, die in den verbleibenden Schritten verwendet werden sollen.

    export cluster_name=my-custom-networking-cluster
account_id=$(aws sts get-caller-identity --query Account --output text)

  2. Erstellen Sie eine VPC.

    1. Erstellen Sie eine VPC mit einer Amazon-EKS- AWS CloudFormation Vorlage.

      aws cloudformation create-stack --stack-name my-eks-custom-networking-vpc \
  --template-url https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/amazon-eks-vpc-private-subnets.yaml \
  --parameters ParameterKey=VpcBlock,ParameterValue=192.168.0.0/24 \
  ParameterKey=PrivateSubnet01Block,ParameterValue=192.168.0.64/27 \
  ParameterKey=PrivateSubnet02Block,ParameterValue=192.168.0.96/27 \
  ParameterKey=PublicSubnet01Block,ParameterValue=192.168.0.0/27 \
  ParameterKey=PublicSubnet02Block,ParameterValue=192.168.0.32/27

      Die Erstellung des AWS CloudFormation Stacks dauert einige Minuten. Führen Sie den folgenden Befehl aus, um den Status der Bereitstellung des Stacks zu überprüfen.

      aws cloudformation describe-stacks --stack-name my-eks-custom-networking-vpc --query Stacks\[\].StackStatus  --output text

      Fahren Sie erst mit dem nächsten Schritt fort, wenn die Ausgabe des Befehls CREATE_COMPLETE ist.

    2. Definieren Sie Variablen mit den Werten der von der Vorlage erstellten privaten Subnetz-IDs.

      subnet_id_1=$(aws cloudformation describe-stack-resources --stack-name my-eks-custom-networking-vpc \
    --query "StackResources[?LogicalResourceId=='PrivateSubnet01'].PhysicalResourceId" --output text)
subnet_id_2=$(aws cloudformation describe-stack-resources --stack-name my-eks-custom-networking-vpc \
    --query "StackResources[?LogicalResourceId=='PrivateSubnet02'].PhysicalResourceId" --output text)

    3. Definieren Sie Variablen mit den Availability Zones der im vorherigen Schritt abgerufenen Subnetze.

      az_1=$(aws ec2 describe-subnets --subnet-ids $subnet_id_1 --query 'Subnets[*].AvailabilityZone' --output text)
az_2=$(aws ec2 describe-subnets --subnet-ids $subnet_id_2 --query 'Subnets[*].AvailabilityZone' --output text)

  3. Erstellen Sie eine Cluster-IAM-Rolle.

    1. Führen Sie den folgenden Befehl aus, um eine JSON-Datei für eine IAM-Vertrauensrichtlinie zu erstellen. 

      cat >eks-cluster-role-trust-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "eks.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
EOF

    2. Erstellen Sie die Amazon-EKS-Cluster-IAM-Rolle. Falls erforderlich, stellen Sie eks-cluster-role-trust-policy.json den Pfad auf Ihrem Computer voran, in den Sie im vorherigen Schritt die Datei geschrieben haben. Der Befehl verknüpft die im vorherigen Schritt erstellte Vertrauensrichtlinie mit der Rolle. Um eine IAM-Rolle zu erstellen, muss dem IAM-Prinzipal, der die Rolle erstellt, die iam:CreateRole-Aktion (Berechtigung) zugewiesen werden.

      aws iam create-role --role-name myCustomNetworkingAmazonEKSClusterRole --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"

    3. Hängen Sie die von Amazon EKS verwaltete Richtlinie AmazonEKSClusterPolicy an die Rolle an. Um eine IAM-Richtlinie an einen IAM-Prinzipal anzuhängen, muss dem Prinzipal, der die Richtlinie anhängt, eine der folgenden IAM-Aktionen (Berechtigungen) zugewiesen werden: iam:AttachUserPolicy oder iam:AttachRolePolicy.

      aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy --role-name myCustomNetworkingAmazonEKSClusterRole

  4. Erstellen Sie einen Amazon-EKS-Cluster und konfigurieren Sie Ihr Gerät für die Kommunikation mit diesem.

    1. Erstellen Sie einen Cluster.

      aws eks create-cluster --name my-custom-networking-cluster \
   --role-arn arn:aws:iam::$account_id:role/myCustomNetworkingAmazonEKSClusterRole \
   --resources-vpc-config subnetIds=$subnet_id_1","$subnet_id_2
      Anmerkung

      Sie erhalten möglicherweise eine Fehlermeldung, dass eine der Availability Zones in Ihrer Anfrage nicht über genügend Kapazität zum Erstellen eines Amazon-EKS-Clusters verfügt. Wenn dies der Fall ist, enthält die Fehlerausgabe die Availability Zones, die einen neuen Cluster unterstützen können. Versuchen Sie, Ihren Cluster mit mindestens zwei Subnetzen erneut zu erstellen, die sich in den unterstützten Availability Zones für Ihr Konto befinden. Weitere Informationen finden Sie unter Unzureichende Kapazität.

    2. Die Erstellung des Clusters dauert mehrere Minuten. Führen Sie den folgenden Befehl aus, um den Status der Bereitstellung des Clusters zu überprüfen.

      aws eks describe-cluster --name my-custom-networking-cluster --query cluster.status

      Fahren Sie erst mit dem nächsten Schritt fort, wenn die Ausgabe des Befehls "ACTIVE" ist.

    3. Konfigurieren Sie kubectl für die Kommunikation mit Ihrem Cluster.

      aws eks update-kubeconfig --name my-custom-networking-cluster

Schritt 2: Konfigurieren Ihrer VPC

Für dieses Tutorial wird die VPC in Schritt 1: Erstellen einer Test-VPC und eines Clusters erstellt. Passen Sie für einen Produktions-Cluster die Schritte entsprechend Ihrer VPC an, indem Sie alle example values durch eigene Werte ersetzen.

  1. Bestätigen Sie, dass Ihr derzeit installiertes Amazon VPC CNI plugin for Kubernetes die neueste Version ist. Informationen zur Ermittlung der neuesten Version für den Amazon-EKS-Add-On-Typ und zur Aktualisierung Ihrer Version auf diese Version finden Sie unter Aktualisieren eines Add-Ons. Informationen dazu, wie Sie die neueste Version für den selbstverwalteten Add-On-Typ ermitteln und Ihre Version darauf aktualisieren können, finden Sie unter Arbeiten mit dem Amazon VPC CNI plugin for Kubernetes-Amazon-EKS-Add-on.

  2. Rufen Sie die ID Ihrer Cluster-VPC ab und speichern Sie diese zur Verwendung in späteren Schritten in einer Variable. Ersetzen Sie für einen Produktions-Cluster my-custom-networking-cluster durch den Namen Ihres Clusters.

    vpc_id=$(aws eks describe-cluster --name my-custom-networking-cluster --query "cluster.resourcesVpcConfig.vpcId" --output text)

  3. Verknüpfen Sie einen zusätzlichen Classless Inter-Domain Routing (CIDR)-Block mit der VPC Ihres Clusters. Der CIDR-Block kann sich nicht mit vorhandenen zugewiesenen CIDR-Blöcken überschneiden.

    1. Zeigen Sie die aktuellen CIDR-Blöcke an, die Ihrer VPC zugeordnet sind.

      aws ec2 describe-vpcs --vpc-ids $vpc_id \
    --query 'Vpcs[*].CidrBlockAssociationSet[*].{CIDRBlock: CidrBlock, State: CidrBlockState.State}' --out table

      Eine Beispielausgabe sieht wie folgt aus.

      ----------------------------------
|          DescribeVpcs          |
+-----------------+--------------+
|    CIDRBlock    |    State     |
+-----------------+--------------+
|  192.168.0.0/24 |  associated  |
+-----------------+--------------+

    2. Ordnen Sie Ihrer VPC zusätzliche CIDR-Blöcke zu. Weitere Informationen finden Sie unter Zuordnen zusätzlicher IPv4 CIDR-Blöcke zu Ihrer VPC im Amazon-VPC-Benutzerhandbuch.

      aws ec2 associate-vpc-cidr-block --vpc-id $vpc_id --cidr-block 192.168.1.0/24

    3. Bestätigen Sie, dass der neue Block zugeordnet ist.

      aws ec2 describe-vpcs --vpc-ids $vpc_id --query 'Vpcs[*].CidrBlockAssociationSet[*].{CIDRBlock: CidrBlock, State: CidrBlockState.State}' --out table

      Eine Beispielausgabe sieht wie folgt aus.

      ----------------------------------
|          DescribeVpcs          |
+-----------------+--------------+
|    CIDRBlock    |    State     |
+-----------------+--------------+
|  192.168.0.0/24 |  associated  |
|  192.168.1.0/24 |  associated  |
+-----------------+--------------+

    Fahren Sie erst mit dem nächsten Schritt fort, wenn der State Ihrer neuen CIDR-Blöcke associated ist.

  4. Erstellen Sie so viele Subnetze, wie Sie in jeder Availability Zone verwenden möchten, in denen sich Ihre vorhandenen Subnetze befinden. Geben Sie einen CIDR-Block an, der sich innerhalb des CIDR-Blocks befindet, den Sie in einem vorherigen Schritt mit Ihrer VPC verknüpft haben.

    1. Erstellen Sie neue Subnetze. Die Subnetze müssen in einem anderen VPC-CIDR-Block erstellt werden als Ihre vorhandenen Subnetze, jedoch in denselben Availability Zones wie Ihre vorhandenen Subnetze. In diesem Beispiel wird ein Subnetz im neuen CIDR-Block jeder Availability Zone erstellt, in der die aktuellen privaten Subnetze vorhanden sind. Die IDs der erstellten Subnetze werden zur Verwendung in späteren Schritten in Variablen gespeichert. Die Name-Werte entsprechen den Werten, die den Subnetzen zugewiesen wurden, die in einem vorherigen Schritt mit der Amazon-EKS-VPC-Vorlage erstellt wurden. Namen sind nicht erforderlich. Sie können verschiedene Namen verwenden. 

      new_subnet_id_1=$(aws ec2 create-subnet --vpc-id $vpc_id --availability-zone $az_1 --cidr-block 192.168.1.0/27 \
    --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=my-eks-custom-networking-vpc-PrivateSubnet01},{Key=kubernetes.io/role/internal-elb,Value=1}]' \
    --query Subnet.SubnetId --output text)
new_subnet_id_2=$(aws ec2 create-subnet --vpc-id $vpc_id --availability-zone $az_2 --cidr-block 192.168.1.32/27 \
    --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=my-eks-custom-networking-vpc-PrivateSubnet02},{Key=kubernetes.io/role/internal-elb,Value=1}]' \
    --query Subnet.SubnetId --output text)
      Wichtig

      Standardmäßig sind Ihre neuen Subnetze implizit mit der Haupt-Routing-Tabelle Ihrer VPCs verknüpft. Diese Routing-Tabelle ermöglicht die Kommunikation zwischen allen Ressourcen, die in der VPC bereitgestellt werden. Sie erlaubt jedoch keine Kommunikation mit Ressourcen mit IP-Adressen, die sich außerhalb der mit Ihrer VPC verknüpften CIDR-Blöcke befinden. Sie können Ihre eigene Routing-Tabelle Ihren Subnetzen zuordnen, um dieses Verhalten zu ändern. Weitere Informationen finden Sie unter Subnetz-Routing-Tabellen im Amazon-VPC-Benutzerhandbuch.

    2. Zeigen Sie die aktuellen Subnetze in Ihrer VPC an.

      aws ec2 describe-subnets --filters "Name=vpc-id,Values=$vpc_id" \
    --query 'Subnets[*].{SubnetId: SubnetId,AvailabilityZone: AvailabilityZone,CidrBlock: CidrBlock}' \
    --output table

      Eine Beispielausgabe sieht wie folgt aus.

      ----------------------------------------------------------------------
|                           DescribeSubnets                          |
+------------------+--------------------+----------------------------+
| AvailabilityZone |     CidrBlock      |         SubnetId           |
+------------------+--------------------+----------------------------+
|  us-west-2d      |  192.168.0.0/27    |     subnet-example1        |
|  us-west-2a      |  192.168.0.32/27   |     subnet-example2        |
|  us-west-2a      |  192.168.0.64/27   |     subnet-example3        |
|  us-west-2d      |  192.168.0.96/27   |     subnet-example4        |
|  us-west-2a      |  192.168.1.0/27    |     subnet-example5        |
|  us-west-2d      |  192.168.1.32/27   |     subnet-example6        |
+------------------+--------------------+----------------------------+

      Sie können sehen, dass die Subnetze im CIDR-Block 192.168.1.0, den Sie erstellt haben, in denselben Availability Zones liegen wie die Subnetze im CIDR-Block 192.168.0.0.

Schritt 3: Konfigurieren von Kubernetes-Ressourcen

Konfigurieren Sie die Kubernetes-Ressourcen wie folgt

  1. Setzen Sie die AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG-Umgebungsvariable im aws-node DaemonSet auf true.

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

  2. Rufen Sie die ID der Cluster-Sicherheitsgruppe ab und speichern Sie diese in einer Variablen zur Verwendung im nächsten Schritt. Amazon EKS erstellt diese Sicherheitsgruppe automatisch, wenn Sie Ihren Cluster erstellen.

    cluster_security_group_id=$(aws eks describe-cluster --name $cluster_name --query cluster.resourcesVpcConfig.clusterSecurityGroupId --output text)

  3. Erstellen Sie eine benutzerdefinierte ENIConfig-Ressource für jedes Subnetz, in dem Sie Pods bereitstellen möchten.

    1. Erstellen Sie für jede Konfiguration der Netzwerkschnittstelle eine eindeutige Datei.

      Die folgenden Befehle erstellen separate ENIConfig-Dateien für die beiden Subnetze, die in einem vorherigen Schritt erstellt wurden. Der Wert für name muss eindeutig sein. Der Name entspricht der Availability Zone, in der sich das Subnetz befindet. Die Cluster-Sicherheitsgruppe ist dem ENIConfig zugeordnet.

      cat >$az_1.yaml <<EOF
apiVersion: crd.k8s.amazonaws.com/v1alpha1
kind: ENIConfig
metadata: 
  name: $az_1
spec: 
  securityGroups: 
    - $cluster_security_group_id
  subnet: $new_subnet_id_1
EOF

      cat >$az_2.yaml <<EOF
apiVersion: crd.k8s.amazonaws.com/v1alpha1
kind: ENIConfig
metadata: 
  name: $az_2
spec: 
  securityGroups: 
    - $cluster_security_group_id
  subnet: $new_subnet_id_2
EOF

      Für einen Produktions-Cluster können Sie die folgenden Änderungen an den vorherigen Befehlen vornehmen:

      • Ersetzen Sie $cluster_security_group_id mit der ID einer bestehenden Sicherheitsgruppe, die Sie für jeden ENIConfig verwenden möchten.

      • Wir empfehlen, Ihrer ENIConfigs denselben Namen zu geben wie der Availability Zone, in der Sie die ENIConfig verwenden, falls möglich. Unter Umständen müssen Sie für Ihre ENIConfigs andere Namen verwenden als für die Availability Zones. Wenn Sie beispielsweise mehr als zwei Subnetze in derselben Availability Zone haben und beide mit benutzerdefinierten Netzwerken verwenden möchten, benötigen Sie mehrere ENIConfigs für dieselbe Availability Zone. Da jede ENIConfig einen eindeutigen Namen erfordert, können Sie nur einer Ihrer ENIConfigs den Namen der Availability Zone geben.

        Wenn Ihre ENIConfig-Namen nicht alle identisch mit den Availability-Zone-Namen sind, ersetzen Sie $az_1 und $az_2 in den vorherigen Befehlen durch eigene Namen und kommentieren Sie Ihre Knoten mit dem ENIConfig weiter unten in diesem Tutorial.

      Anmerkung

      Wenn Sie keine gültige Sicherheitsgruppe für die Verwendung mit einem Produktions-Cluster angeben und

      • Version 1.8.0 oder höher des Amazon VPC CNI plugin for Kubernetes verwenden, dann werden die Sicherheitsgruppen verwendet, die mit der primären Elastic-Network-Schnittstelle des Knotens verknüpft sind.

      • eine Version des Amazon VPC CNI plugin for Kubernetes vor 1.8.0 verwenden, wird die Standardsicherheitsgruppe für die VPC sekundären Netzwerkschnittstellen zugewiesen.

      Wichtig

      • AWS_VPC_K8S_CNI_EXTERNALSNAT=false ist eine Standardeinstellung in der Konfiguration für das Amazon-VPC-CNI-Plugin für Kubernetes. Wenn Sie die Standardeinstellung verwenden, verwendet Datenverkehr, der für IP-Adressen bestimmt ist, die sich nicht innerhalb eines mit Ihrer VPC verknüpften CIDR-Blöcke befinden, die Sicherheitsgruppen und Subnetze der primären Netzwerkschnittstelle Ihres Knotens. Die in Ihrem ENIConfigs definierten Subnetze und Sicherheitsgruppen, die zum Erstellen sekundärer Netzwerkschnittstellen verwendet werden, werden für diesen Datenverkehr nicht verwendet. Weitere Informationen zu dieser Einstellung finden Sie unter SNAT für Pods.

      • Wenn Sie auch Sicherheitsgruppen für Pods verwenden, wird die in einer SecurityGroupPolicy angegebene Sicherheitsgruppe anstelle der Sicherheitsgruppe verwendet, die im ENIConfigs angegeben ist. Weitere Informationen finden Sie unter Sicherheitsgruppen für Pods.

    2. Wenden Sie alle benutzerdefinierten Ressourcendateien, die Sie zuvor erstellt haben, mit den folgenden Befehlen auf Ihren Cluster an:

      kubectl apply -f $az_1.yaml
kubectl apply -f $az_2.yaml

  4. Bestätigen Sie, dass Ihre ENIConfigs erstellt wurden.

    kubectl get ENIConfigs

    Eine Beispielausgabe sieht wie folgt aus.

    NAME         AGE
us-west-2a   117s
us-west-2d   105s

  5. Wenn Sie benutzerdefinierte Netzwerke in einem Produktions-Cluster aktivieren und Ihren ENIConfigs einen anderen Namen gegeben haben als die Availability Zone, für die Sie diese verwenden, springen Sie zum nächsten Schritt, um Amazon-EC2-Knoten bereitzustellen.

    Aktivieren Sie Kubernetes, um die ENIConfig für eine Availability Zone für alle neuen Amazon-EC2-Knoten zu verwenden, die in Ihrem Cluster erstellt wurden.

    1. Gehen Sie für den Test-Cluster in diesem Tutorial zum nächsten Schritt.

      Prüfen Sie für einen Produktions-Cluster, ob eine annotation mit dem Schlüssel k8s.amazonaws.com/eniConfig für die ENI_CONFIG_ANNOTATION_DEF Umgebungsvariable in der Container-Spezifikation für den aws-node DaemonSet vorhanden ist.

      kubectl describe daemonset aws-node -n kube-system | grep ENI_CONFIG_ANNOTATION_DEF

      Wenn eine Ausgabe zurückgegeben wird, ist die Anmerkung vorhanden. Wenn keine Ausgabe zurückgegeben wird, ist die Variable nicht gesetzt. Für einen Produktions-Cluster können Sie entweder diese Einstellung oder die Einstellung im folgenden Schritt verwenden. Wenn Sie diese Einstellung verwenden, überschreibt sie die Einstellung im folgenden Schritt. In diesem Tutorial wird die Einstellung im nächsten Schritt verwendet.

    2. Aktualisieren Sie Ihren aws-node DaemonSet, um die ENIConfig für eine Availability Zone automatisch für alle neuen Amazon-EC2-Knoten zu verwenden, die in Ihrem Cluster erstellt wurden.

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

Schritt 4: Bereitstellen von Amazon-EC2-Knoten

So stellen Sie Amazon-EC2-Knoten bereit

  1. Erstellen Sie eine Knoten-IAM-Rolle.

    1. Führen Sie den folgenden Befehl aus, um eine JSON-Datei für eine IAM-Vertrauensrichtlinie zu erstellen.

      cat >node-role-trust-relationship.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
EOF

    2. Führen Sie den folgenden Befehl aus, um eine Variable für Ihren Rollennamen festzulegen. Sie können myCustomNetworkingAmazonEKSNodeRole mit einem beliebigen Namen ersetzen, den Sie wählen.

      export node_role_name=myCustomNetworkingAmazonEKSNodeRole

    3. Erstellen Sie die IAM-Rolle und speichern Sie den zurückgegebenen Amazon-Ressourcennamen (ARN) in einer Variablen zur Verwendung in einem späteren Schritt.

      node_role_arn=$(aws iam create-role --role-name $node_role_name --assume-role-policy-document file://"node-role-trust-relationship.json" \
    --query Role.Arn --output text)

    4. Hängen Sie die drei erforderlichen verwalteten IAM-Richtlinien an die IAM-Rolle an.

      aws iam attach-role-policy \
  --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy \
  --role-name $node_role_name
aws iam attach-role-policy \
  --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly \
  --role-name $node_role_name
aws iam attach-role-policy \
    --policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy \
    --role-name $node_role_name
      Wichtig

      Der Einfachheit halber wird in diesem Tutorial die Richtlinie AmazonEKS_CNI_Policy an diese Knoten-IAM-Rolle angehängt. In einem Produktions-Cluster empfehlen wir jedoch, die Richtlinie an eine separate IAM-Rolle anzuhängen, die nur mit dem Amazon VPC CNI plugin for Kubernetes verwendet wird. Weitere Informationen finden Sie unter Konfigurieren der Amazon VPC CNI plugin for Kubernetes zur Verwendung von IAM-Rollen für Servicekonten (IRSA).

  2. Erstellen Sie einen der folgenden Typen von Knotengruppen. Informationen zum Bestimmen des Instance-Typs, den Sie bereitstellen möchten, finden Sie unter Auswählen eines Amazon-EC2-Instance-Typs. Füllen Sie für dieses Tutorial die Option Verwaltet, Ohne Startvorlage oder mit Startvorlage ohne angegebene AMI-ID aus. Wenn Sie die Knotengruppe für Produktions-Workloads verwenden, empfehlen wir, dass Sie sich vor Bereitstellen der Knotengruppe mit allen verwalteten und selbstverwalteten Knotengruppenoptionen vertraut machen.

    • Verwaltet – Stellen Sie Ihre Knotengruppe mit einer der folgenden Optionen bereit:

      • Ohne Startvorlage oder mit Startvorlage ohne angegebene AMI-ID – Führen Sie den folgenden Befehl aus. Verwenden Sie in diesem Tutorial die example values. Ersetzen Sie für eine Produktionsknotengruppe alle example values durch Ihre eigenen Werte. Der Knotengruppenname darf nicht länger als 63 Zeichen sein. Er muss mit einem Buchstaben oder einer Ziffer beginnen, kann danach aber auch Bindestriche und Unterstriche enthalten.

        aws eks create-nodegroup --cluster-name $cluster_name --nodegroup-name my-nodegroup \
    --subnets $subnet_id_1 $subnet_id_2 --instance-types t3.medium --node-role $node_role_arn

      • Mit einer Startvorlage mit einer angegebenen AMI-ID

        1. Bestimmen Sie die von Amazon EKS empfohlenen maximalen Pods für Ihre Knoten. 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 in diesem Thema hinzu. Notieren Sie die Ausgabe zur Verwendung im nächsten Schritt.

        2. 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 in der Startvorlage an. Diese Benutzerdaten übergeben Argumente an die bootstrap.sh-Datei. Weitere Informationen zur Bootstrap-Datei finden Sie unter bootstrap.sh auf GitHub. Sie können 20 entweder durch den Wert aus dem vorherigen Schritt (empfohlen) oder Ihren eigenen Wert ersetzen.

          /etc/eks/bootstrap.sh my-cluster --use-max-pods false --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.

    • Selbstverwaltet

      1. Bestimmen Sie die von Amazon EKS empfohlenen maximalen Pods für Ihre Knoten. 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 in diesem Thema hinzu. Notieren Sie die Ausgabe zur Verwendung im nächsten Schritt.

      2. Stellen Sie die Knotengruppe mithilfe der Anweisungen in Starten selbstverwalteter Amazon Linux-Knoten bereit. Geben Sie den folgenden Text für den BootstrapArguments Parameter an. Sie können 20 entweder durch den Wert aus dem vorherigen Schritt (empfohlen) oder Ihren eigenen Wert ersetzen.

        --use-max-pods false --kubelet-extra-args '--max-pods=20'
    Anmerkung

    Wenn Sie möchten, dass Knoten in einem Produktions-Cluster eine deutlich höhere Anzahl von Pods unterstützen, führen Sie das Skript in Von Amazon EKS empfohlene maximale Pods für jeden Amazon-EC2-Instance-Typ erneut aus. Fügen Sie außerdem die Option --cni-prefix-delegation-enabled zu dem Befehl hinzu. Beispielsweise wird 110 für einen m5.large-Instance-Typ zurückgegeben. Anweisungen, wie Sie diese Funktion aktivieren, finden Sie unter Erhöhen Sie die Anzahl der verfügbaren IP-Adressen für Ihre Amazon-EC2-Knoten. Sie können diese Funktion mit benutzerdefinierten Netzwerken verwenden.

    Die Erstellung der Knotengruppe dauert mehrere Minuten. Sie können den Status der Erstellung einer verwalteten Knotengruppe mit dem folgenden Befehl überprüfen.

    aws eks describe-nodegroup --cluster-name $cluster_name --nodegroup-name my-nodegroup --query nodegroup.status --output text

    Fahren Sie erst mit dem nächsten Schritt fort, wenn die zurückgegebene Ausgabe ACTIVE ist.

  3. Für das Tutorial können Sie diesen Schritt überspringen.

    Wenn Sie Ihre ENIConfigs für einen Produktions-Cluster nicht genauso benannt haben wie die Availability Zone, für die Sie diese verwenden, müssen Sie in Ihren Knoten den Namen der ENIConfig anmerken, die mit dem Knoten verwendet werden soll. Dieser Schritt ist nicht erforderlich, wenn Sie in jeder Availability Zone nur ein Subnetz haben und Ihre ENIConfigs denselben Namen haben wie Ihre Availability Zones. Das liegt daran, dass das Amazon VPC CNI plugin for Kubernetes automatisch die richtige ENIConfig mit dem Knoten verknüpft, wenn Sie dies in einem vorherigen Schritt aktiviert haben.

    1. Rufen Sie die Liste der Knoten in Ihrem Cluster ab.

      kubectl get nodes

      Eine Beispielausgabe sieht wie folgt aus.

      NAME                                          STATUS   ROLES    AGE     VERSION
ip-192-168-0-126.us-west-2.compute.internal   Ready    <none>   8m49s   v1.22.9-eks-810597c
ip-192-168-0-92.us-west-2.compute.internal    Ready    <none>   8m34s   v1.22.9-eks-810597c

    2. Bestimmen Sie, in welcher Availability Zone sich jeder Knoten befindet. Führen Sie den folgenden Befehl für jeden Knoten aus, der im vorherigen Schritt ausgegeben wurde.

      aws ec2 describe-instances --filters Name=network-interface.private-dns-name,Values=ip-192-168-0-126.us-west-2.compute.internal \
--query 'Reservations[].Instances[].{AvailabilityZone: Placement.AvailabilityZone, SubnetId: SubnetId}'

      Eine Beispielausgabe sieht wie folgt aus.

      [
    {
        "AvailabilityZone": "us-west-2d",
        "SubnetId": "subnet-Example5"
    }
]

    3. Kommentieren Sie jeden Knoten mit der ENIConfig, die Sie für die Subnetz-ID und die Availability Zone erstellt haben. Sie können einen Knoten nur mit einer ENIConfig kommentieren, aber es können mehrere Knoten mit derselben ENIConfig kommentiert werden. Ersetzen Sie das example values durch Ihr eigenes.

      kubectl annotate node ip-192-168-0-126.us-west-2.compute.internal k8s.amazonaws.com/eniConfig=EniConfigName1
kubectl annotate node ip-192-168-0-92.us-west-2.compute.internal k8s.amazonaws.com/eniConfig=EniConfigName2

  4. Wenn Sie Knoten in einem Produktions-Cluster hatten, in dem Pods ausgeführt wurden, bevor Sie zur Verwendung des benutzerdefinierten Netzwerkfeatures gewechselt haben, führen Sie die folgenden Schritte aus:

    1. Stellen Sie sicher, dass es verfügbare Knoten gibt, das benutzerdefinierte Netzwerkfeature verwenden.

    2. Sperren und entleeren Sie die Knoten, um die Pods herunterzufahren. Weitere Informationen finden Sie unter Sicheres Entleeren eines Knotens in der Kubernetes-Dokumentation.

    3. Beenden Sie die Knoten. Wenn sich die Knoten in einer vorhandenen verwalteten Knotengruppe befinden, können Sie die Knotengruppe löschen. Kopieren Sie den folgenden Befehl auf Ihr Gerät. Nehmen Sie nach Bedarf die folgenden Änderungen am Befehl vor und führen Sie anschließend den geänderten Befehl aus:

      • Ersetzen Sie my-cluster durch den Namen für Ihren Cluster.

      • Ersetzen Sie my-nodegroup durch den Namen für Ihre Knotengruppe.

      aws eks delete-nodegroup --cluster-name my-cluster --nodegroup-name my-nodegroup

    Nur neue Knoten, die mit der Bezeichnung k8s.amazonaws.com/eniConfig registriert sind, verwenden das neue benutzerdefinierte Netzwerkfeature.

  5. Bestätigen Sie, dass Pods eine IP-Adresse aus einem CIDR-Block zugewiesen wird, der mit einem der in einem vorherigen Schritt erstellten Subnetze verknüpft ist.

    kubectl get pods -A -o wide

    Eine Beispielausgabe sieht wie folgt aus.

    NAMESPACE     NAME                       READY   STATUS    RESTARTS   AGE     IP              NODE                                          NOMINATED NODE   READINESS GATES
kube-system   aws-node-2rkn4             1/1     Running   0          7m19s   192.168.0.92    ip-192-168-0-92.us-west-2.compute.internal    <none>           <none>
kube-system   aws-node-k96wp             1/1     Running   0          7m15s   192.168.0.126   ip-192-168-0-126.us-west-2.compute.internal   <none>           <none>
kube-system   coredns-657694c6f4-smcgr   1/1     Running   0          56m     192.168.1.23    ip-192-168-0-92.us-west-2.compute.internal    <none>           <none>
kube-system   coredns-657694c6f4-stwv9   1/1     Running   0          56m     192.168.1.28    ip-192-168-0-92.us-west-2.compute.internal    <none>           <none>
kube-system   kube-proxy-jgshq           1/1     Running   0          7m19s   192.168.0.92    ip-192-168-0-92.us-west-2.compute.internal    <none>           <none>
kube-system   kube-proxy-wx9vk           1/1     Running   0          7m15s   192.168.0.126   ip-192-168-0-126.us-west-2.compute.internal   <none>           <none>

    Sie sehen, dass den coredns Pods IP-Adressen aus dem CIDR-Block 192.168.1.0 zugewiesen werden, den Sie Ihrer VPC hinzugefügt haben. Ohne benutzerdefiniertes Netzwerk wären diesen Adressen aus dem CIDR-Block 192.168.0.0 zugewiesen worden, da dies der einzige ursprünglich mit der VPC verbundene CIDR-Block war.

    Wenn die spec eines Pod's hostNetwork=true enthalten, wird diesem die primäre IP-Adresse des Knotens zugewiesen. Es wird keine Adresse aus den hinzugefügten Subnetzen zugewiesen. Standardmäßig ist dieser Wert auf false festgelegt. Dieser Wert ist auf true festgelegt für kube-proxy und Amazon VPC CNI plugin for Kubernetes (aws-node) Pods, die auf Ihrem Cluster laufen. Aus diesem Grund sind der kube-proxy und der aws-nodePods des Plugins in der vorherigen Ausgabe nicht 192.168.1.x-Adressen zugewiesen. Weitere Informationen zu einer Pod's hostNetwork Einstellung finden Sie unter PodSpec v1 core in der Kubernetes -API-Referenz.

Schritt 5: Löschen von Tutorial-Ressourcen

Nachdem Sie das Tutorial abgeschlossen haben, empfehlen wir, dass Sie die erstellten Ressourcen löschen. Sie können dann die Schritte anpassen, um benutzerdefinierte Netzwerke für einen Produktions-Cluster zu aktivieren.

Löschen Sie die Tutorial-Ressourcen wie folgt

  1. Wenn die von Ihnen erstellte Knotengruppe nur zum Testen gedacht ist, löschen Sie sie.

    aws eks delete-nodegroup --cluster-name $cluster_name --nodegroup-name my-nodegroup

    Auch wenn die AWS CLI Ausgabe besagt, dass der Cluster gelöscht wurde, ist der Löschvorgang möglicherweise nicht abgeschlossen. Der Löschvorgang dauert einige Minuten. Bestätigen Sie, dass der Vorgang abgeschlossen ist, indem Sie den folgenden Befehl ausführen.

    aws eks describe-nodegroup --cluster-name $cluster_name --nodegroup-name my-nodegroup --query nodegroup.status --output text

    Fahren Sie erst fort, wenn die zurückgegebene Ausgabe der folgenden Ausgabe entspricht.

    An error occurred (ResourceNotFoundException) when calling the DescribeNodegroup operation: No node group found for name: my-nodegroup.

  2. Wenn die von Ihnen erstellte Knotengruppe nur zum Testen gedacht ist, löschen Sie den Knoten IAM-Rolle.

    1. Trennen Sie die Richtlinien von der Rolle.

      aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy

    2. Löschen Sie die Rolle.

      aws iam delete-role --role-name myCustomNetworkingAmazonEKSNodeRole

  3. Löschen Sie den Cluster.

    aws eks delete-cluster --name $cluster_name

    Bestätigen Sie, dass der Cluster gelöscht ist, indem Sie den folgenden Befehl ausführen.

    aws eks describe-cluster --name $cluster_name --query cluster.status --output text

    Wird eine Ausgabe ähnlich der folgenden zurückgegeben, wurde der Cluster erfolgreich gelöscht.

    An error occurred (ResourceNotFoundException) when calling the DescribeCluster operation: No cluster found for name: my-cluster.

  4. Löschen Sie die Cluster-IAM-Rolle.

    1. Trennen Sie die Richtlinien von der Rolle.

      aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSClusterRole --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy

    2. Löschen Sie die Rolle.

      aws iam delete-role --role-name myCustomNetworkingAmazonEKSClusterRole

  5. Löschen Sie die Subnetze, die Sie in einem vorherigen Schritt erstellt haben.

    aws ec2 delete-subnet --subnet-id $new_subnet_id_1
aws ec2 delete-subnet --subnet-id $new_subnet_id_2

  6. Löschen Sie die VPC, die Sie erstellt haben.

    aws cloudformation delete-stack --stack-name my-eks-custom-networking-vpc