Wie verwende ich mehrere CIDR-Bereiche mit Amazon EKS?

Kurzbeschreibung

Gehe wie folgt vor, um mehrere CIDR-Bereiche in Amazon EKS zu verwenden:

1. Füge weitere CIDR-Bereiche hinzu, um dein Virtual Private Cloud (VPC)-Netzwerk zu erweitern.
2. Erstelle Subnetze mit einem neuen CIDR-Bereich.
3. Ordne dein neues Subnetz einer Routing-Tabelle zu.
4. Konfiguriere das Amazon Virtual Private Cloud (Amazon VPC) Container Network Interface (CNI)-Plugin für die Verwendung eines neuen CIDR-Bereichs.

Hinweis: Es hat sich bewährt, CIDRs (/16) aus dem Carrier-Grade-NAT (CGN)-Bereich wie 100.64.0.0/10 oder 198.19.0.0/16 zu verwenden. Du kannst einen gültigen VPC-Bereich als sekundären CIDR-Bereich in benutzerdefinierten Netzwerken verwenden. Es ist jedoch weniger wahrscheinlich, dass diese Bereiche in einem Unternehmensumfeld verwendet werden. Weitere Informationen zu benutzerdefinierten Netzwerkanforderungen findest du unter Überlegungen.

Lösung

Hinweis: Wenn du beim Ausführen von AWS Command Line Interface (AWS CLI)-Befehlen Fehlermeldungen erhältst, findest du weitere Informationen dazu unter Problembehandlung bei der AWS CLI. Stelle außerdem sicher, dass du die neueste Version von AWS CLI verwendest.

Voraussetzungen: Du musst über die folgenden Konfigurationen verfügen:

• Ein laufender Amazon-EKS-Cluster
• AWS Identity and Access Management (IAM)-Berechtigungen zur Verwaltung einer Amazon VPC
• Ein kubectl mit Berechtigungen zum Erstellen benutzerdefinierter Ressourcen und zum Bearbeiten des DaemonSet
• Eine installierte Version von jq auf deinem System
  Hinweis: Informationen zum Herunterladen und Installieren von jq findest du unter jq herunterladen auf der jq-Website.
• Ein Unix-basiertes System mit einer Bash-Shell
• Eine konfigurierte VPC

Füge weitere CIDR-Bereiche hinzu, um dein VPC-Netzwerk zu erweitern

Führe die folgenden Schritte aus:

1. Um die ID deiner Cluster-VPC abzurufen und in einer Variablen zu speichern, führe den folgenden describe-cluster-AWS-CLI-Befehl aus:

   VPC_ID=$(aws eks describe-cluster --name CLUSTER_NAME --region REGION_CODE --query "cluster.resourcesVpcConfig.vpcId" --output text)

   Hinweis: Ersetze CLUSTER_NAME durch den Namen deines Clusters und REGION_CODE durch die AWS-Region, in der du den Cluster bereitgestellt hast.
2. Um der VPC einen weiteren CIDR-Block mit dem Bereich 100.64.0.0/16 zuzuordnen, führe den folgenden associate-vpc-cidr-block-Befehl aus:

   aws ec2 associate-vpc-cidr-block --vpc-id $VPC_ID --cidr-block 100.64.0.0/16

Erstellen von Subnetzen mit einem neuen CIDR-Bereich

Führe die folgenden Schritte aus:

1. Führe den folgenden describe-availability-zones-Befehl aus, um alle Availability Zones in deiner Region aufzulisten:

   aws ec2 describe-availability-zones --region REGION_CODE --query 'AvailabilityZones[*].ZoneName'

   Hinweis: Ersetze REGION_CODE durch die Region, in der du deine Ressourcen bereitgestellt hast.
2. Erstelle die Subnetze, die du verwenden möchtest, in jeder Availability Zone, in der sich deine bestehenden Subnetze befinden. Um neue Subnetze unter der VPC mit dem neuen CIDR-Bereich zu erstellen, führe die folgenden create-subnet-Befehle aus.

   CUST_SNET1=$(aws ec2 create-subnet --cidr-block 100.64.0.0/19 --vpc-id $VPC_ID --availability-zone AZ1 | jq -r .Subnet.SubnetId)
   CUST_SNET2=$(aws ec2 create-subnet --cidr-block 100.64.32.0/19 --vpc-id $VPC_ID --availability-zone AZ2 | jq -r .Subnet.SubnetId)
   CUST_SNET3=$(aws ec2 create-subnet --cidr-block 100.64.64.0/19 --vpc-id $VPC_ID --availability-zone AZ3 | jq -r .Subnet.SubnetId)

   **Hinweis:**Ersetze AZ1, AZ2 und AZ3 durch deine vorhandenen Subnetz-Availability Zones.
3. (Optional) Um ein Schlüssel-Wert-Paar festzulegen, um deinen Subnetzen ein Namens-Tag hinzuzufügen, führe den folgenden create-tags-Befehl aus:

   aws ec2 create-tags --resources $CUST_SNET1 --tags Key=KEY,Value=VALUE
   aws ec2 create-tags --resources $CUST_SNET2 --tags Key=KEY,Value=VALUE
   aws ec2 create-tags --resources $CUST_SNET3 --tags Key=KEY,Value=VALUE

   Hinweis: Ersetze KEY durch den Tag-Schlüssel und VALUE durch den Tag-Wert.

Zuordnen deines neuen Subnetz zu einer Routing-Tabelle

Standardmäßig ordnet Amazon VPC deine neuen Subnetze der Haupt-Routing-Tabelle deiner VPC zu. Diese Routing-Tabelle ermöglicht nur die Kommunikation zwischen den Ressourcen, die in der VPC bereitgestellt werden. Um die Kommunikation mit IP-Adressen zu ermöglichen, die sich außerhalb der CIDR-Blöcke der VPC befinden, musst du deine eigene Routing-Tabelle für deine Subnetze erstellen.

Amazon-VPC-CNI-Plugin für die Verwendung des neuen CIDR-Bereichs konfigurieren

Führe die folgenden Schritte aus:

1. Stelle sicher, dass du die richtige Plugin-Version für deine Kubernetes-Version ausführst. Führe den folgenden Befehl aus, um die Version zu überprüfen:

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

   Wenn du nicht über die richtige Plugin-Version verfügst, aktualisiere das Amazon VPC CNI.

2. Führe den folgenden Befehl aus, um die benutzerdefinierte Netzwerkkonfiguration für das Amazon VPC CNI-Plugin zu aktivieren:

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

3. Führe den folgenden Befehl aus, um das Label ENIConfig zur Identifizierung deiner Worker-Knoten hinzuzufügen:

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

4. Führe die folgenden Befehle aus, um benutzerdefinierte Ressourcen vom Typ ENIConfig für alle Subnetze und Availability Zones zu erstellen:

   cat <<EOF  | kubectl apply -f -apiVersion: crd.k8s.amazonaws.com/v1alpha1
   kind: ENIConfig
   metadata:
    name: $AZ1
   spec:
     securityGroups:
       - cluster_security_group_id
     subnet: $CUST_SNET1
   EOF
   
   cat <<EOF | kubectl apply -f -
   apiVersion: crd.k8s.amazonaws.com/v1alpha1
   kind: ENIConfig
   metadata:
    name: $AZ2
   spec:
     securityGroups:
       - cluster_security_group_id
     subnet: $CUST_SNET2
   EOF
   
   cat <<EOF | kubectl apply -f -
   apiVersion: crd.k8s.amazonaws.com/v1alpha1
   kind: ENIConfig
   metadata:
    name: $AZ3
   spec:
     securityGroups:
       - cluster_security_group_id
     subnet: $CUST_SNET3
   EOF

   Hinweis: Ersetze cluster_security_group_id durch die ID der vorhandenen Sicherheitsgruppe, die du für jede ENIConfig-Ressource verwenden möchtest. Die ENIConfig-Ressourcennamen entsprechen denen der Availability Zone, in der du die neuen Subnetze erstellt hast.

5. Wenn du eine selbstverwaltete Knotengruppe verwendest, starte selbstverwaltete Worker-Knoten, damit das Plugin ihnen IP-Adressen zuweisen kann. Verwende für Subnetze die ursprünglichen Subnetze, die du bei der Erstellung des Clusters ausgewählt hast, anstelle der neuen Subnetze, die du in den ENIConfig-Ressourcen verwendet hast. Du kannst auch eine verwaltete Knotengruppe mit einer Startvorlage verwenden, um Knoten zu starten. In beiden Fällen musst du den richtigen max-pods-Wert für Ihren Instance-Typ identifizieren. Dies liegt daran, dass benutzerdefinierte Netzwerke in Amazon EKS nicht die primäre Netzwerkschnittstelle für die Pod-Platzierung verwenden. Stelle sicher, dass du den Parameter --cni-custom-networking-enabled hinzufügst, wenn du das Skript max-pods-calculator.sh ausführst.
   Führe dann den folgenden Befehl aus, um den max-pods-Wert für deine selbstverwalteten Knoten anzugeben:

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

   Hinweis: Ersetze 20 durch den von dir berechneten max-pods-Wert.
   Füge für eine verwaltete Knotengruppe das folgende Skript zu den Benutzerdaten hinzu:

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

   Hinweis: Ersetzen my-cluster-name durch deinen Cluster-Namen und 20 durch den von dir berechneten max-pods-Wert. Gib in deiner Startvorlage eine Amazon EKS-optimierte Amazon Machine Image (AMI)-ID oder ein benutzerdefiniertes AMI an, das auf dem Amazon EKS-optimierten AMI basiert. Amazon Linux 2023 (AL2023)-AMIs verwenden den nodeadm-Prozess. Informationen darüber, wie sich dadurch die Konfiguration der Benutzerdaten ändert, findest du unter Upgrade von Amazon Linux 2 auf Amazon Linux 2023.
   Wenn du eine verwaltete Knotengruppe ohne Startvorlage oder angegebene AMI-ID verwendest, berechnet die verwaltete Knotengruppe automatisch den max-pods-Wert.

6. Wenn die neuen Knoten bereit sind, entleere die vorherigen Knoten, um die Pods ordnungsgemäß herunterzufahren. Weitere Informationen findest du auf der Kubernetes-Website unter Sicheres Leeren eines Knotens. Wenn sich die Knoten in einer vorhandenen verwalteten Knotengruppe befinden, führe den folgenden Befehl aus, um die Knotengruppe zu löschen:

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

   Hinweis: Ersetze CLUSTER_NAME durch den Cluster-Namen und my-nodegroup durch den Knotengruppennamen.

7. Führe den folgenden Befehl aus, um eine neue Bereitstellung zum Testen der Konfiguration zu starten:

   kubectl create deployment nginx-test --image=nginx --replicas=10   
   kubectl get pods -o wide --selector=app=nginx-test

   Hinweis: Der vorangehende Befehl fügt 10 neue Pods hinzu und plant sie für den neuen CIDR-Bereich auf neuen Worker-Knoten ein.

Wichtig: Es kann bis zu 5 Stunden dauern, bis ein Cluster einen neuen CIDR-Block, den du einer VPC zuordnest, erkannt und zugelassen hat. Während dieser Zeit kann die Amazon EKS-Steuerungsebene nicht mit den Pods kommunizieren, die du in den neuen Subnetzen startest. Wenn api-server Pods mit einem Webhook, dem Befehl kubectl logs oder dem Befehl kubectl exec kontaktiert, wird möglicherweise die folgende Fehlermeldung angezeigt:

"failed calling webhook "linkerd-proxy-injector.linkerd.io": failed to call webhook: Post "https://linkerd-proxy-injector.linkerd.svc:443/?timeout=10s": Address is not allowed"