Erstellung einer Knotenklasse Knotenklassen-Zugriffseintrag erstellen Knotenklassen-Spezifikation Überlegungen Separate Subnetze und Sicherheitsgruppen für Pods Sekundärer IP-Modus für Pods Deaktivieren Sie den IPv4-Ausgang von IPv6-Pods in IPv6-Clustern.Konfiguration der statischen Netzwerkschnittstelle

Unterstützung für die Verbesserung dieser Seite beitragen

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.

Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link Diese Seite bearbeiten unter, der sich im rechten Bereich jeder Seite befindet.

Knotenklasse für Amazon EKS erstellen

Amazon-EKS-Knotenklassen sind Vorlagen, die eine differenzierte Steuerung der Konfiguration Ihrer im EKS Auto Mode verwalteten Knoten ermöglichen. Eine Knotenklasse definiert Einstellungen auf Infrastrukturebene, die für Knotengruppen in Ihrem EKS-Cluster gelten, einschließlich Netzwerkkonfiguration, Speichereinstellungen und Ressourcen-Kennzeichnung. In diesem Thema wird erläutert, wie Sie eine Knotenklasse erstellen und konfigurieren, um Ihre spezifischen Betriebsanforderungen zu erfüllen.

Wenn Sie die Bereitstellung und Konfiguration von EC2-Instances in EKS Auto Mode über die Standardeinstellungen hinaus anpassen müssen, erhalten Sie durch die Erstellung einer Knotenklasse präzise Kontrolle über wichtige Infrastruktur-Parameter. Beispielsweise können Sie zur Erhöhung der Sicherheit die Platzierung in einem privaten Subnetz festlegen, für leistungssensitive Workloads flüchtigen Instance-Speicher konfigurieren oder zur Kostenverteilung benutzerdefinierte Tags zuweisen.

Erstellung einer Knotenklasse

Um eine NodeClass zu erstellen, gehen Sie wie folgt vor:

YAML-Datei (zum Beispiel nodeclass.yaml) mit Ihrer Knotenklassen-Konfiguration erstellen
Konfiguration mithilfe von kubectl auf Ihren Cluster anwenden
Verweisen Sie in Ihrer Knoten-Pool-Konfiguration auf die Knotenklasse. Weitere Informationen finden Sie unter Erstellen eines Knotenpools für EKS Auto Mode.

Sie müssen kubectl installiert und konfiguriert haben. Weitere Informationen finden Sie unter Einrichtung zur Verwendung von Amazon EKS.

Beispiel für eine grundlegende Knotenklasse

Hier ist ein Beispiel für eine Knotenklasse:


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: private-compute
spec:
  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"
        kubernetes.io/role/internal-elb: "1"
  securityGroupSelectorTerms:
    - tags:
        Name: "eks-cluster-sg"
  ephemeralStorage:
    size: "160Gi"

Dies NodeClass erhöht die Menge an temporärem Speicher auf dem Knoten.

Wenden Sie diese Konfiguration wie folgt an


kubectl apply -f nodeclass.yaml

Verweisen Sie anschließend in Ihrer Knoten-Pool-Konfiguration auf die Knotenklasse. Weitere Informationen finden Sie unter Erstellen eines Knotenpools für EKS Auto Mode.

Knotenklassen-Zugriffseintrag erstellen

Wenn Sie eine benutzerdefinierte Knotenklasse erstellen, müssen Sie einen EKS-Zugriffseintrag erstellen, damit die Knoten dem Cluster beitreten können. EKS erstellt automatisch Zugriffseinträge, wenn Sie die integrierte Knotenklasse und Knoten-Pools verwenden.

Informationen zur Funktionsweise von Zugriffseinträgen finden Sie unter IAM-Benutzern mit EKS-Zugriffseinträgen Zugriff auf Kubernetes gewähren

Beim Erstellen von Zugriffseinträgen für EKS-Auto-Mode-Knotenklassen müssen Sie den EC2-Zugriffseintragstyp verwenden.

Zugriffseintrag mit der CLI erstellen

Um einen Zugriffseintrag für EC2-Knoten zu erstellen und die EKS-Auto-Node-Richtlinie zuzuordnen:

Aktualisieren Sie die folgenden CLI-Befehle mit Ihrem Cluster-Namen und der Knotenrollen-ARN. Die Knotenrollen-ARN ist in der Knotenklasse YAML angegeben.


# Create the access entry for EC2 nodes
aws eks create-access-entry \
  --cluster-name <cluster-name> \
  --principal-arn <node-role-arn> \
  --type EC2

# Associate the auto node policy
aws eks associate-access-policy \
  --cluster-name <cluster-name> \
  --principal-arn <node-role-arn> \
  --policy-arn arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy \
  --access-scope type=cluster

Erstellen Sie einen Zugangseintrag mit CloudFormation

Um einen Zugriffseintrag für EC2-Knoten zu erstellen und die EKS-Auto-Node-Richtlinie zuzuordnen:

Aktualisieren Sie Folgendes CloudFormation mit Ihrem Clusternamen und dem ARN der Knotenrolle. Die Knotenrollen-ARN ist in der Knotenklasse YAML angegeben.


EKSAutoNodeRoleAccessEntry:
  Type: AWS::EKS::AccessEntry
  Properties:
    ClusterName: <cluster-name>
    PrincipalArn: <node-role-arn>
    Type: "EC2"
    AccessPolicies:
      - AccessScope:
          Type: cluster
        PolicyArn: arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy
  DependsOn: [ <cluster-name> ] # previously defined in CloudFormation

Informationen zur Bereitstellung von CloudFormation Stacks finden Sie unter Erste Schritte mit CloudFormation

Knotenklassen-Spezifikation


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: my-node-class
spec:
  # Required fields

  # role and instanceProfile are mutually exclusive fields.
  role: MyNodeRole  # IAM role for EC2 instances
  # instanceProfile: eks-MyNodeInstanceProfile  # IAM instance-profile for EC2 instances

  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"
        kubernetes.io/role/internal-elb: "1"
    # Alternative using direct subnet ID
    # - id: "subnet-0123456789abcdef0"

  securityGroupSelectorTerms:
    - tags:
        Name: "eks-cluster-sg"
    # Alternative approaches:
    # - id: "sg-0123456789abcdef0"
    # - name: "eks-cluster-security-group"

  # Optional: Pod subnet selector for advanced networking
  podSubnetSelectorTerms:
    - tags:
        Name: "pod-subnet"
        kubernetes.io/role/pod: "1"
    # Alternative using direct subnet ID
    # - id: "subnet-0987654321fedcba0"
  # must include Pod security group selector also
  podSecurityGroupSelectorTerms:
    - tags:
        Name: "eks-pod-sg"
    # Alternative using direct security group ID
    # - id: "sg-0123456789abcdef0"

  # Optional: Selects on-demand capacity reservations and capacity blocks
  # for EKS Auto Mode to prioritize.
  capacityReservationSelectorTerms:
    - id: cr-56fac701cc1951b03
    # Alternative Approaches
    - tags:
        Name: "targeted-odcr"
      # Optional owning account ID filter
      owner: "012345678901"

  # Optional fields
  snatPolicy: Random  # or Disabled

  networkPolicy: DefaultAllow  # or DefaultDeny
  networkPolicyEventLogs: Disabled  # or Enabled

  ephemeralStorage:
    size: "80Gi"    # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
    iops: 3000      # Range: 3000-16000
    throughput: 125 # Range: 125-1000
    # Optional KMS key for encryption
    kmsKeyID: "arn:aws: kms:region:account:key/key-id"
    # Accepted formats:
    # KMS Key ID
    # KMS Key ARN
    # Key Alias Name
    # Key Alias ARN

  advancedNetworking:
    # Optional: Controls whether public IP addresses are assigned to instances that are launched with the nodeclass.
    # If not set, defaults to the MapPublicIpOnLaunch setting on the subnet.
    associatePublicIPAddress: false

    # Optional: Forward proxy, commonly requires certificateBundles as well
    # for EC2, see https://repost.aws/knowledge-center/eks-http-proxy-containerd-automation
    httpsProxy: http://192.0.2.4:3128 #commonly port 3128 (Squid) or 8080 (NGINX) #Max 255 characters
    #httpsProxy: http://[2001:db8::4]:3128 # IPv6 address with port, use []
    noProxy: #Max 50 entries
        - localhost #Max 255 characters each
        - 127.0.0.1
        #- ::1 # IPv6 localhost
        #- 0:0:0:0:0:0:0:1 # IPv6 localhost
        - 169.254.169.254 # EC2 Instance Metadata Service
        #- [fd00:ec2::254] # IPv6 EC2 Instance Metadata Service
        # Domains to exclude, put all VPC endpoints here
        - .internal
        - .eks.amazonaws.com
    # ipv4PrefixSize is default to Auto which is prefix and fallback to secondary IP. "32" is the secondary IP mode.
    ipv4PrefixSize: Auto # or "32"

    # enableV4Egress is default to true. Setting it to false when using network policy or blocking IPv4 traffic in IPv6 clusters
    enableV4Egress: false

    # Optional: Static network interface configuration for EFA workloads
    networkInterfaces:
      # The primary ENI (networkCardIndex 0, deviceIndex 0) must use interfaceType: interface
      # secondaryIPv4Count and secondaryIPv4PrefixCount are only supported on networkCardIndex 0
    - deviceIndex: 0
      interfaceType: interface
      networkCardIndex: 0
      secondaryIPv4Count: 10
    - deviceIndex: 1
      interfaceType: interface
      networkCardIndex: 0
      secondaryIPv4PrefixCount: 2 # Only one of secondaryIPv4Count or secondaryIPv4PrefixCount per ENI
    - deviceIndex: 0
      interfaceType: efa-only
      networkCardIndex: 1

  advancedSecurity:
    # Optional, US regions only: Specifying `fips: true` will cause nodes in the nodeclass to run FIPS compatible AMIs.
    fips: false

  # Optional: Custom certificate bundles.
  certificateBundles:
    - name: "custom-cert"
      data: "base64-encoded-cert-data"

  # Optional: EC2 Placement Group
  placementGroupSelector:
    name: "targeted-pg"
    # Alternative use direct placement group ID
    # id: "pg-02465754522cda020"

  # Optional: Additional EC2 tags (with restrictions)
  tags:
    Environment: "production"
    Team: "platform"
    # Note: Cannot use restricted tags like:
    # - kubernetes.io/cluster/*
    # - karpenter.sh/provisioner-name
    # - karpenter.sh/nodepool
    # - karpenter.sh/nodeclaim
    # - karpenter.sh/managed-by
    # - eks.amazonaws.com/nodeclass

Überlegungen

Wenn Sie überprüfen möchten, über wie viel lokalen Speicherplatz eine Instance verfügt, können Sie den Knoten beschreiben, um die flüchtige Speicher-Ressource anzuzeigen.
Volumenverschlüsselung — EKS verwendet den konfigurierten benutzerdefinierten KMS-Schlüssel, um das schreibgeschützte Root-Volume der Instance und des Datenvolumes zu verschlüsseln. read/write
IAM-Rolle des Knotens ersetzen – Wenn Sie die einer NodeClass zugeordneten IAM-Rolle ändern, müssen Sie einen neuen Zugriffseintrag erstellen. EKS erstellt während der Cluster-Erstellung automatisch einen Zugriffseintrag für die IAM-Rolle des Knotens. Die IAM-Rolle des Knotens erfordert die AmazonEKSAutoNodePolicy-EKS-Zugriffsrichtlinie. Weitere Informationen finden Sie unter IAM-Benutzern mit EKS-Zugriffseinträgen Zugriff auf Kubernetes gewähren.
Maximale Pod-Dichte – EKS begrenzt die maximale Anzahl von Pods auf einem Knoten auf 110. Diese Begrenzung wird nach der vorhandenen Berechnung der maximalen Pods angewendet. Weitere Informationen finden Sie unter Auswahl eines optimalen Amazon-EC2-Knoten-Instance-Typs.
Tags – Wenn Sie Tags von Kubernetes auf EC2 übertragen möchten, müssen Sie zusätzliche IAM-Berechtigungen konfigurieren. Weitere Informationen finden Sie unter Weitere Informationen zu Identität und Zugriff in EKS Auto Mode.
Standard-Knotenklasse – Benennen Sie Ihre benutzerdefinierte Knotenklasse default nicht. Dies liegt daran, dass EKS Auto Mode eine NodeClass mit dem Namen default enthält, die automatisch bereitgestellt wird, wenn Sie mindestens ein integriertes NodePool aktivieren. Informationen zur Aktivierung des integrierten NodePools finden Sie unter Aktivieren oder deaktivieren Built-in NodePools.
subnetSelectorTerms-Verhalten bei mehreren Subnetzen – Wenn mehrere Subnetze vorhanden sind, die den subnetSelectorTerms-Bedingungen entsprechen oder die Sie anhand der ID angeben, erstellt der EKS Auto Mode Knoten, die über die Subnetze verteilt sind.
- Wenn sich die Subnetze in verschiedenen Availability Zones (AZs) befinden, können Sie Kubernetes-Features wie Pod-Topologie-Verteilungsbeschränkungen und Topologiebasiertes Routing verwenden, um Pods und Datenverkehr über die Zonen zu verteilen.
- Wenn es in derselben AZ mehrere Subnetze gibt, die mit subnetSelectorTerms übereinstimmen, erstellt EKS Auto Mode Pods auf jedem Knoten, die über die Subnetze in dieser AZ verteilt sind. EKS Auto Mode erstellt sekundäre Netzwerkschnittstellen auf jedem Knoten in den anderen Subnetzen derselben AZ. Die Auswahl erfolgt anhand der Anzahl der verfügbaren IP-Adressen in jedem Subnetz, um die Subnetze effizienter zu nutzen. Sie können jedoch nicht festlegen, welches Subnetz EKS Auto Mode für jeden Pod verwendet. Wenn Sie möchten, dass Pods in bestimmten Subnetzen ausgeführt werden, verwenden Sie stattdessen Separate Subnetze und Sicherheitsgruppen für Pods.
Einschränkungen bei der Placement-Gruppenstrategie — Für jede Placement-Gruppenstrategie (Cluster, Partition, Spread) gelten spezifische Einschränkungen in Bezug auf Instance-Typen, AZs und Kapazität. Einzelheiten finden Sie unter Strategien für Platzierungsgruppen im Amazon EC2-Benutzerhandbuch.
Spread-Placement-Gruppe — Limit von 7 Instances — Eine Spread-Placement-Gruppe auf Rackebene ermöglicht maximal 7 laufende Instances pro Availability Zone und Gruppe. Dadurch entstehen die folgenden Randfälle:
- Drift-Austausch bei voller Kapazität blockiert — Der EKS-Automatikmodus startet einen Ersatzknoten, bevor der alte Knoten beendet wird. Wenn ein Spread-PG 7 Instances in einer AZ hat, schlägt der Ersatzstart fehl und der Drift-Knoten läuft weiter, bis ein Slot frei wird.
- Alle AZs sind voll ausgelastet — Wenn jede AZ im Spread-PG ihr Limit von 7 Instanzen erreicht hat, können keine Ersetzungen geplant werden. Drift-Knoten oder Knoten, die für eine Konsolidierung in Frage kommen, laufen unbegrenzt weiter.
- Kein Fallback außerhalb der Placement-Gruppe — EKS Auto Mode versucht nicht, Ersatz-Instances außerhalb der Placement-Gruppe zu starten.
- Problemumgehung — Verwenden Sie eine WhenEmpty Konsolidierungsrichtlinie ()consolidationPolicy: WhenEmpty. Knoten werden erst gelöscht, wenn alle Pods ohne Daemonset leer sind. Dadurch wird ein PG-Slot frei, ohne dass zuerst ein neuer gestartet werden muss. Beachten Sie, dass Drift unabhängig von der Konsolidierungsrichtlinie immer „Ersetzen und dann Löschen“ verwendet, sodass Drift bei voller Kapazität blockiert bleibt.
Cluster-Platzierungsgruppe — Sobald die erste Instance in einer Cluster-Platzierungsgruppe gestartet wird, wird das PG an diese AZ angeheftet. Wenn Sie mehrere AZs NodePool zulassen, kann es bei parallelen Starts beim ersten Scale-Up zu einem Wettlauf kommen: Eine ist erfolgreich und fixiert die AZ, die anderen schlagen aufgrund von Kapazitätsfehlern fehl. Passen Sie die AZ NodePool an Ihre Anforderungen an, um vorübergehende Ausfälle zu vermeiden.
Partitionsplatzierungsgruppe — Partitionsplatzierungsgruppen werden ohne zusätzliche Einschränkungen unterstützt, die über die standardmäßigen EC2-Grenzwerte hinausgehen.
Durch die Konsolidierung können Pods aus einer Platzierungsgruppe verschoben werden — Wenn für einen Pod keine Einschränkungen hinsichtlich der Platzierungsgruppenplanung gelten (z. B. ein nodeSelector Oneks.amazonaws.com/placement-group-id), kann er durch die Konsolidierung auf einen Knoten außerhalb des PG verschoben werden. Anwendungen, die eine Mitgliedschaft in einer Platzierungsgruppe erfordern, sollten dies durch Einschränkungen auf Pod-Ebene zum Ausdruck bringen.
Nicht vorhandene oder gelöschte Platzierungsgruppe — Wenn a NodeClass auf eine Platzierungsgruppe verweist, die nicht existiert oder gelöscht wurde, werden keine Instanzen gestartet. Das Format der Platzierungsgruppen-ID wird bei der Zulassung überprüft, die Existenz wird jedoch erst beim Start überprüft. Wenn eine Placement-Gruppe gelöscht wird, während Knoten in Betrieb sind, werden vorhandene Knoten als Drift markiert und laufen auf unbestimmte Zeit weiter, da Drift-Replacement-Starts ebenfalls blockiert sind.

Separate Subnetze und Sicherheitsgruppen für Pods

Die podSecurityGroupSelectorTerms Felder podSubnetSelectorTerms und ermöglichen erweiterte Netzwerkkonfigurationen, da Pods andere Subnetze und Sicherheitsgruppen als ihre Knoten verwenden können. Beide Felder müssen zusammen angegeben werden. Diese Trennung bietet eine verbesserte Kontrolle über das Routing des Netzwerkverkehrs und die Sicherheitsrichtlinien.

Anmerkung

Diese Funktion unterscheidet sich von der SGPP-Funktion (Security Groups for Pods), die mit dem VPC-CNI für Berechnungen im automatischen Modus verwendet wird, die nicht von EKS stammen. SGPP wird im EKS-Automatikmodus nicht unterstützt. Verwenden Sie stattdessen podSecurityGroupSelectorTerms in, NodeClass um separate Sicherheitsgruppen auf den Pod-Verkehr anzuwenden. Die Sicherheitsgruppen gelten auf der NodeClass Ebene, was bedeutet, dass alle Pods auf Knoten, die sie verwenden, NodeClass dieselben Pod-Sicherheitsgruppen verwenden.

Funktionsweise

Wenn Sie konfigurieren podSubnetSelectorTerms undpodSecurityGroupSelectorTerms:

Die primäre ENI des Knotens verwendet die Subnetze und Sicherheitsgruppen von subnetSelectorTerms undsecurityGroupSelectorTerms. Nur die eigene IP-Adresse des Knotens wird dieser Schnittstelle zugewiesen.
Der EKS-Automatikmodus erstellt sekundäre ENIs in den passenden SubnetzenpodSubnetSelectorTerms, wobei die Sicherheitsgruppen angehängt sind. podSecurityGroupSelectorTerms Pod-IP-Adressen werden von diesen sekundären ENIs standardmäßig mit /28-Präfixen zugewiesen, wobei automatisch auf sekundäre IPs (/32) zurückgegriffen wird, wenn kein zusammenhängender Präfixblock verfügbar ist. Wenn auf in gesetzt ipv4PrefixSize ist, werden nur sekundäre IPs "32" verwendetadvancedNetworking.
Die unter angegebenen Sicherheitsgruppen podSecurityGroupSelectorTerms gelten für den Pod-Verkehr innerhalb der VPC. Für Datenverkehr außerhalb der VPC verwenden Pods die primäre ENI des Knotens (und seine Sicherheitsgruppen), da die Source Network Address Translation (SNAT) die Pod-IP in die Knoten-IP übersetzt. Sie können dieses Verhalten mit dem Feld im snatPolicy ändern. NodeClass

Anwendungsfälle

Verwenden Sie podSubnetSelectorTerms und podSecurityGroupSelectorTerms wann Sie müssen:

Wenden Sie verschiedene Sicherheitsgruppen an, um den Datenverkehr für Knoten und Pods getrennt zu steuern.
Trennen Sie den Infrastrukturverkehr (Kommunikation von Knoten zu Knoten) vom Anwendungsverkehr (Pod-to-Pod Kommunikation).
Wenden Sie auf Knoten-Subnetze andere Netzwerkkonfigurationen an als auf Pod-Subnetze.
Konfigurieren Sie Reverse-Proxys oder Netzwerkfilter speziell für den Knoten-Datenverkehr, ohne den Pod-Datenverkehr zu beeinträchtigen. Verwenden Sie advancedNetworking und certificateBundles, um Ihren Reverse-Proxy und alle selbstsignierten oder privaten Zertifikate für den Proxy zu definieren.

Beispielkonfiguration


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: advanced-networking
spec:
  role: MyNodeRole

  # Subnets and security groups for EC2 instances (nodes)
  subnetSelectorTerms:
    - tags:
        Name: "node-subnet"
        kubernetes.io/role/internal-elb: "1"

  securityGroupSelectorTerms:
    - tags:
        Name: "eks-cluster-sg"

  # Separate subnets and security groups for Pods
  podSubnetSelectorTerms:
    - tags:
        Name: "pod-subnet"
        kubernetes.io/role/pod: "1"

  podSecurityGroupSelectorTerms:
  - tags:
      Name: "eks-pod-sg"

Überlegungen zur Verwendung separater Pod-Subnetze und Sicherheitsgruppen

Geltungsbereich der Sicherheitsgruppe: Die Sicherheitsgruppen von podSecurityGroupSelectorTerms sind den sekundären ENIs zugeordnet und gelten für den Pod-Verkehr innerhalb der VPC. Wenn SNAT aktiviert ist (StandardeinstellungsnatPolicy: Random), wird der Datenverkehr, der die VPC verlässt, in die primäre ENI-IP-Adresse des Knotens übersetzt, sodass die Sicherheitsgruppen des Knotens stattdessen für diesen Datenverkehr securityGroupSelectorTerms gelten. Wenn Sie dies einrichtensnatPolicy: Disabled, verwenden Pods ihre eigenen IP-Adressen für den gesamten Datenverkehr, und Sie müssen sicherstellen, dass Routing- und Sicherheitsgruppen entsprechend konfiguriert sind.
NodeClass-level Granularität: Die Pod-Sicherheitsgruppen gelten für alle Pods, die auf Knoten geplant sind, die die verwenden. NodeClass Um verschiedene Sicherheitsgruppen auf verschiedene Workloads anzuwenden, erstellen Sie separate NodePool AD-Ressourcen NodeClass und verwenden Sie Taints, Toleranzen oder Knoten-Selektoren, um Workloads für die entsprechenden Knoten zu planen.
Reduzierte Pod-Dichte: Auf jedem Knoten können weniger Pods ausgeführt werden, da die primäre Netzwerkschnittstelle des Knotens für die Knoten-IP reserviert ist und nicht für Pods verwendet werden kann.
Einschränkungen bei der Subnetzauswahl: Der Standard subnetSelectorTerms und die securityGroupSelectorTerms Konfigurationen gelten nicht für die Auswahl des Pod-Subnetzes oder der Sicherheitsgruppe.
Netzwerk-Planung: Stellen Sie sicher, dass in den Knoten- und Pod-Subnetzen ausreichend IP-Adressraum vorhanden ist, um Ihre Workload-Anforderungen zu erfüllen.
Routing-Konfiguration: Stellen Sie sicher, dass die Routing-Tabelle und die Netzwerkzugriffssteuerungsliste (ACL) der Pod-Subnetze ordnungsgemäß für die Kommunikation zwischen Knoten- und Pod-Subnetzen konfiguriert sind.
Availability Zones: Stellen Sie sicher, dass Sie Pod-Subnetze über mehrere AZs hinweg erstellt haben. Wenn Sie ein bestimmtes Pod-Subnetz verwenden, muss es sich in derselben AZ wie das Knotensubnetz AZ befinden.

Sekundärer IP-Modus für Pods

Das ipv4PrefixSize Feld ermöglicht erweiterte Netzwerkkonfigurationen, indem Knoten nur sekundäre IP-Adressen zugewiesen werden. Diese Funktion weist Knoten keine Präfixe (/28) zu und verwaltet nur eine sekundäre IP als MinimalIPTarget.

Anwendungsfälle

Verwenden Sie ipv4PrefixSize, wenn Sie Folgendes benötigen:

Reduzierte IP-Auslastung: In jedem Knoten wird nur eine IP-Adresse aufgewärmt.
Niedrigere Pod-Abwanderungsrate: Die Geschwindigkeit der Pod-Erstellung ist kein großes Problem.
Keine Fragmentierung von Präfixen: Prefix-caused Fragmentierung ist ein großes Problem oder verhindert die Verwendung des automatischen Modus.

Beispielkonfiguration


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: advanced-networking
spec:
  role: MyNodeRole

  advancedNetworking:
    ipv4PrefixSize: "32"

Überlegungen zum sekundären IP-Modus

Reduzierte Geschwindigkeit bei der Pod-Erstellung: Da nur eine sekundäre IP aufgewärmt wird, benötigt der IPAM-Dienst mehr Zeit für die Bereitstellung von IP-Adressen, wenn mehr Pods erstellt werden.

Deaktivieren Sie den IPv4-Ausgang von IPv6-Pods in IPv6-Clustern.

Das enableV4Egress Feld ist standardmäßig. true Für IPv6-Cluster im automatischen Modus kann die Funktion deaktiviert werden, sodass der automatische Modus keine IPv4-Schnittstelle für IPv6-Pods erstellt, die nur für ausgehenden Verkehr bestimmt ist. Dies ist wichtig, da die IPv4-Ausgangsschnittstelle nicht der Durchsetzung von Netzwerkrichtlinien unterliegt. Netzwerkrichtlinien werden nur auf der primären Schnittstelle des Pods (eth0) durchgesetzt.

Anwendungsfälle

Verwenden Sie enableV4Egress, wenn Sie Folgendes benötigen:

IPv6-Cluster verwenden: Ausgehender IPv4-Verkehr ist standardmäßig zulässig.
Netzwerkrichtlinie verwenden: Derzeit unterstützt die EKS-Netzwerkrichtlinie Dual-Stack nicht. Durch die Deaktivierung enableV4Egress kann verhindert werden, dass der Pod-Verkehr unerwartet über IPv4 abgeht.

Beispielkonfiguration


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: advanced-networking
spec:
  role: MyNodeRole

  advancedNetworking:
    enableV4Egress: false

Überlegungen zur Deaktivierung von EnableV4Egress

Netzwerkrichtlinie im IPv6-Cluster: IPv6-Cluster ermöglichen standardmäßig IPv4-Verkehr. Die Einstellung enableV4Egress: false blockiert den ausgehenden IPv4-Verkehr und sorgt so für erhöhte Sicherheit, insbesondere bei Verwendung mit Netzwerkrichtlinien.

Konfiguration der statischen Netzwerkschnittstelle

Das networkInterfaces Feld unter advancedNetworking ermöglicht es Ihnen, die Netzwerkschnittstellen, die beim Start an Instances angehängt sind, statisch zu definieren. Dies wird hauptsächlich verwendet, um Elastic Fabric Adapter (EFA) -Geräte für eine leistungsstarke Kommunikation zwischen Knoten bei verteilten Trainings- und Inferenz-Workloads zu konfigurieren. Diese Funktion kann mit Node-Pools mit statischer Kapazität kombiniert werden, um vorgewärmte Knoten aufrechtzuerhalten. EFA-ready Weitere Informationen zur EFA-Geräteverwaltung in EKS finden Sie unter. EFA-Geräte auf Amazon EKS verwalten Die empfohlene EFA-Konfiguration für bestimmte Instance-Typen finden Sie unter Maximieren der Netzwerkbandbreite für EFA-enabled Instance-Typen im Amazon EC2-Benutzerhandbuch.

Funktionsweise

Jeder Eintrag in networkInterfaces definiert eine Netzwerkschnittstelle, die beim Start an die Instance angeschlossen wird. Jeder Eintrag spezifiziert a networkCardIndex (die Netzwerkkarte, wobei sich die primäre Karte 0 befindet), a deviceIndex (die Geräteposition auf dieser Karte) und an interfaceType (interfacefür IP-based Standarddatenverkehr oder efa-only für EFA-Schnittstellen, die für RDMA-Verkehr ohne IP-Adressen vorgesehen sind). Das primäre ENI (networkCardIndex: 0,deviceIndex: 0) muss verwendet werden, um die interfaceType: interface IP-based Knotenkommunikation zu unterstützen. Die efa-only Schnittstellen unterstützen nur EFA-Gerätefunktionen für RDMA und können nicht mit IP-Adressen konfiguriert werden.

Sie können Schnittstellen auf der primären Netzwerkkarte (networkCardIndex: 0) IP-Kapazität zuweisen, indem Sie secondaryIPv4Count (jede Einheit bietet eine IP-Adresse) oder secondaryIPv4PrefixCount (jede Einheit bietet ein /28-Präfix mit 16 IP-Adressen) verwenden. Pro Schnittstelle kann nur eine davon verwendet werden, und sie werden nur von unterstützt. networkCardIndex: 0 Sie können nicht auf efa-only Schnittstellen verwendet werden.

Wichtig

Wenn networkInterfaces konfiguriert, fügt der EKS-Automodus nach dem Start der Instance keine zusätzlichen IPs, Präfixe oder ENIs hinzu. Nur die beim Start konfigurierten Schnittstellen und IP-Adressen sind für Pods verfügbar. Sie müssen Ihre Pod-Dichte auf der Grundlage der Anzahl der konfigurierten IPs planen.

Überlegungen

IPv6 wird bei statisch definierten Netzwerkschnittstellen nicht unterstützt. associatePublicIPAddressist nicht kompatibel, wenn mehr als eine Netzwerkschnittstelle definiert ist. Daher können Knoten, die mehrere Schnittstellen verwenden, keine öffentlichen IP-Adressen haben (weder in rein öffentlichen Clustern noch in gemischten Clustern). public/private

Wenn Sie statische Netzwerkschnittstellen verwenden podSubnetSelectorTerms und podSecurityGroupSelectorTerms verwenden, konfigurieren Sie die primäre ENI mit 0 sekundären IPs. Die primäre ENI verwendet das Knotensubnetz und die Sicherheitsgruppen, während der Pod-Verkehr die Pod-Subnetzkonfiguration auf sekundären ENIs verwendet.

Beispiel: EFA-only Schnittstellen für das GPU-Training

Das folgende Beispiel zeigt eine mit EFA-only Schnittstellen für eine GPU-Instanz NodeClass konfigurierte Instanz, die im verteilten Training verwendet wird. Die primäre Schnittstelle hat ein /28-Präfix (16 Pod-IPs) und 4 zusätzliche EFA-only Schnittstellen bieten RDMA-Konnektivität. Diese Konfiguration kann mit einem Knotenpool mit statischer Kapazität kombiniert werden, um vorgewärmte Knoten aufrechtzuerhalten. EFA-ready


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: efa-training
spec:
  role: MyNodeRole
  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"
  securityGroupSelectorTerms:
    - tags:
        Name: "efa-security-group"
  placementGroupSelector:
    name: "ml-training-pg"
  advancedNetworking:
    networkInterfaces:
    - deviceIndex: 0
      interfaceType: interface
      networkCardIndex: 0
      secondaryIPv4PrefixCount: 1
    - deviceIndex: 1
      interfaceType: efa-only
      networkCardIndex: 0
    - deviceIndex: 0
      interfaceType: efa-only
      networkCardIndex: 1
    - deviceIndex: 0
      interfaceType: efa-only
      networkCardIndex: 2
    - deviceIndex: 0
      interfaceType: efa-only
      networkCardIndex: 3

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Konfiguration

Knoten-Pool erstellen