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.

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 auf, 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 flüchtigem 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 für die 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 zum Bereitstellen 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

  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 Instanz und das Datenvolumen 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 Integriert aktivieren oder deaktivieren 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 der Platzierungsgruppenstrategie — Jede Platzierungsgruppenstrategie (Cluster, Partition, Spread) hat spezifische Einschränkungen in Bezug auf Instance-Typen, AZs und Kapazität. Einzelheiten finden Sie unter Placement-Gruppenstrategien im Amazon EC2 EC2-Benutzerhandbuch.
Spread Placement-Gruppe — Limit von 7 Instanzen — Eine Spread Placement-Gruppe auf Rack-Ebene erlaubt maximal 7 laufende Instances pro Availability Zone pro Gruppe. Dadurch entstehen die folgenden Grenzfälle:
- Der Drift-Ersatz ist ausgelastet — der EKS-Automatikmodus startet einen Ersatzknoten, bevor der alte beendet wird. Wenn ein verteiltes PG über 7 Instances in einer AZ verfügt, schlägt der Ersatzstart fehl und der Drift-Node läuft weiter, bis ein Slot frei wird.
- Alle AZs sind voll ausgelastet — Wenn jede AZ in der Spread-PG ihr Limit von 7 Instanzen erreicht hat, können keine Ersatzinstanzen geplant werden. Knoten, die nicht mehr zur Verfügung stehen oder für eine Konsolidierung in Frage kommen, bleiben auf unbestimmte Zeit in Betrieb.
- Kein Fallback außerhalb der Platzierungsgruppe — Der automatische EKS-Modus versucht nicht, Ersatz-Instances außerhalb der Platzierungsgruppe zu starten.
- Problemumgehung — Verwenden Sie die WhenEmpty Konsolidierungsrichtlinie ()consolidationPolicy: WhenEmpty. Knoten werden erst gelöscht, wenn alle Pods, die nicht auf Daemon gesetzt sind, abgeladen sind, wodurch ein PG-Steckplatz frei wird, ohne dass zuerst ein Ersatzstart erforderlich ist. 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-Placement-Gruppe AZ-Pinning — Sobald die erste Instance in einer Cluster-Placement-Gruppe gestartet wird, wird das PG an diese AZ angeheftet. Wenn Sie mehrere AZs zulassen, NodePool können parallel Starts bei der anfänglichen Skalierung rasend schnell voranschreiten: Einer ist erfolgreich und bindet die AZ, der Rest schlägt mit 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 entfernt werden. Wenn für einen Pod keine Einschränkungen bei der Planung von Platzierungsgruppen gelten (z. B. eineks.amazonaws.com/placement-group-id), wird er durch die Konsolidierung möglicherweise nodeSelector auf einen Knoten außerhalb des PGs verschoben. Anwendungen, für die eine Mitgliedschaft in einer Platzierungsgruppe erforderlich ist, sollten dies durch Einschränkungen auf Pod-Ebene zum Ausdruck bringen.
Nicht existierende oder gelöschte Platzierungsgruppe — Wenn eine NodeClass auf eine Platzierungsgruppe verweist, die nicht existiert oder gelöscht wurde, werden keine Instances gestartet. Das Format der Placement-Gruppen-ID wird bei der Zulassung überprüft, das Vorhandensein wird jedoch erst beim Start überprüft. Wenn eine Platzierungsgruppe gelöscht wird, während Knoten ausgeführt werden, werden bestehende Knoten als Drift markiert und bleiben auf unbestimmte Zeit aktiv, da auch Drift-Replacement-Starts blockiert werden.

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 Funktion Security Groups for Pods (SGPP), die mit der AWS VPC CNI für Datenverarbeitung im automatischen Modus ohne EKS verwendet wird. SGPP wird im automatischen EKS-Modus nicht unterstützt. Verwenden Sie stattdessen podSecurityGroupSelectorTerms in, NodeClass um separate Sicherheitsgruppen auf den Pod-Verkehr anzuwenden. Die Sicherheitsgruppen gelten auf der NodeClass Ebene, d. h. alle Pods auf Knoten, die diese verwenden, NodeClass teilen sich dieselben Pod-Sicherheitsgruppen.

Funktionsweise

Wenn Sie konfigurieren podSubnetSelectorTerms undpodSecurityGroupSelectorTerms:

Die primäre ENI des Knotens verwendet die Subnetze und Sicherheitsgruppen von subnetSelectorTerms undsecurityGroupSelectorTerms. Dieser Schnittstelle ist nur die eigene IP-Adresse des Knotens zugewiesen.
Der automatische Modus von EKS erstellt sekundäre ENIs in den entsprechenden SubnetzenpodSubnetSelectorTerms, wobei die Sicherheitsgruppen aus podSecurityGroupSelectorTerms den zugehörigen Subnetzen hinzugefügt werden. Pod-IP-Adressen werden von diesen sekundären ENIs standardmäßig mit /28-Präfixen zugewiesen. Wenn kein zusammenhängender Präfixblock verfügbar ist, wird automatisch auf sekundäre IP-Adressen (/32) zurückgegriffen. 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 in der snatPolicy ändern. NodeClass

Anwendungsfälle

Verwenden Sie podSubnetSelectorTerms und podSecurityGroupSelectorTerms wann Sie müssen:

Wenden Sie verschiedene Sicherheitsgruppen an, um den Verkehr 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 zu separaten Pod-Subnetzen und Sicherheitsgruppen

Geltungsbereich der Sicherheitsgruppe: Die Sicherheitsgruppen von podSecurityGroupSelectorTerms sind an die sekundären ENIs angehängt und gelten für den Pod-Verkehr innerhalb der VPC. Wenn SNAT aktiviert ist (StandardsnatPolicy: 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 diese Einstellung festlegensnatPolicy: 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 NodeClass verwenden. Um unterschiedliche Sicherheitsgruppen auf unterschiedliche Workloads anzuwenden, erstellen Sie separate NodePool Ressourcen NodeClass und verwenden Sie Taints, Toleranzen oder Node-Selectoren, um Workloads auf 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.
Geringere Anzahl an Pods: Die Geschwindigkeit der Pod-Erstellung ist kein großes Problem.
Keine Präfixfragmentierung: 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

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

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

Das enableV4Egress Feld ist standardmäßig. true Bei IPv6-Clustern im automatischen Modus kann die Funktion deaktiviert werden, sodass im automatischen Modus keine IPv4-Schnittstelle für IPv6-Pods erstellt wird, die nur für ausgehenden Datenverkehr bestimmt sind. 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: IPv4-Ausgangsverkehr ist standardmäßig zulässig.
Netzwerkrichtlinie verwenden: Derzeit unterstützt die EKS-Netzwerkrichtlinie keinen Dual-Stack. Durch die Deaktivierung enableV4Egress kann verhindert werden, dass der Pod-Verkehr unerwartet über IPv4 abfließt.

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 lassen standardmäßig IPv4-Verkehr zu. Diese Einstellung enableV4Egress: false blockiert den ausgehenden IPv4-Verkehr und bietet so eine erhöhte Sicherheit, insbesondere bei Verwendung mit Netzwerkrichtlinien.

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