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.

Überlegungen für Workloads mit geringer Kapazität oder hoher Kapazität

Der EKS-Automatikmodus verwendet standardmäßig die Präfixdelegierung (Präfixe)/28. Jeder Knoten reserviert 16 Pod-IPs, was für Workloads mit hoher Pod-Dichte, die diese Steckplätze füllen, effizient ist. Für Workloads mit geringer Pod-Dichte (einige Pods pro Knoten, wie sie bei ML- oder GPU-Workloads üblich sind, oder Workloads mit hoher Anti-Affinität), die auf mehr als ein paar hundert Knoten pro Availability Zone abzielen, ist der sekundäre IP-Modus () eine optimiertere Konfiguration. "32" Es weist eine IP pro Pod zu, anstatt 16 pro Knoten zu reservieren, wodurch die effektive Kapazität der Pod-Subnetze erweitert wird. /20

Weitere Informationen finden Sie unter Sekundärer IP-Modus für Pods. Informationen dazu, wie Sie Pods in einem von den Knoten getrennten Subnetz halten (unabhängig vom Zuweisungsmodus), finden Sie unter. Separate Subnetze und Sicherheitsgruppen für Pods

Erstellung einer Knotenklasse

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

1. YAML-Datei (zum Beispiel nodeclass.yaml) mit Ihrer Knotenklassen-Konfiguration erstellen

2. Konfiguration mithilfe von kubectl auf Ihren Cluster anwenden

3. 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"

Dadurch NodeClass erhöht sich 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:

  • Der Drift-Austausch ist bei voller Kapazität blockiert — Der EKS-Automatikmodus startet einen Ersatzknoten, bevor der alte Knoten beendet wird. Wenn ein Spread-PG 7 Instances in einem 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.

• Anheften der 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.

• Hugepages — Informationen zur Konfiguration von Hugepages auf Knoten finden Sie unter. Konfigurieren Sie riesige Seiten auf Knoten

• Kubelet-Einstellungen — Informationen zum Überschreiben von Kubelet-Einstellungen wie Pod-Dichte, Schwellenwerten für Räumungen und Log-Rotation finden Sie unter. Konfigurieren Sie die Kubelet-Einstellungen auf Knoten

• Kernel sysctls — Informationen zur Konfiguration von Kernel-Sysctls auf Knoten finden Sie unter. Konfigurieren Sie Kernel-Sysctls auf Knoten

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:

1. 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.

2. 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.

3. 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 Network Access Control List (ACL) der Pod-Subnetze für die Kommunikation zwischen Knoten- und Pod-Subnetzen richtig 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.

advancedNetworking.ipv4PrefixSizeakzeptiert zwei Werte: Auto (Standard; Präfix-Delegierung; höhere Geschwindigkeit bei der Pod-Erstellung; reserviert mindestens 16 IPs pro Knoten) und "32" (sekundärer IP-Modus; 1 IP pro Pod; fügt AssignPrivateIpAddresses Aufrufe pro Pod hinzu; Pods pro Knoten, begrenzt durch die ENI des Instance-Typs). IP-limit

Im Auto Modus weist der EKS-Automatikmodus jedem Knoten im Voraus ein /28 Präfix (16 IPs) zu und fügt ein weiteres hinzu, /28 wenn die Pod-Nachfrage die Kapazität des aktuellen Blocks überschreitet. 16 ist also ein Minimum pro Knoten und nicht eine Obergrenze.

Verwenden Sie die folgenden Zahlen für die Planung. Die tatsächlichen Cluster variieren. Wenn das Pod-Subnetz fragmentiert ist und kein zusammenhängendes Subnetz frei /28 ist, fällt der Auto Modus auf die Zuweisung pro IP auf diesem Knoten zurück. Per-node Die Anzahl der IP-Adressen liegt dann unter dem unten abgebildeten Muster von 16 pro Präfix.

Beispiel A — 1 Pod auf dem Knoten

• Sekundärer IP-Modus: 1 Pod-IP + 1 Node-IP = 2 IPs werden verwendet.

• Präfixmodus: 1 Knoten-IP + 16 IPs ab dem ersten /28 Präfix (davon 1 wird vom Pod verwendet, 15 werden für zukünftige Pods gespeichert) = 17 zugewiesene IPs, 2 werden verwendet.

Beispiel B — 18 Pods auf dem Knoten

• Sekundärer IP-Modus: 18 Pod-IPs + 1 Node-IP = 19 IPs werden verwendet.

• Präfixmodus: 1 Knoten-IP + 2 × /28 Präfixe (32 IPs insgesamt, erste /28 voll bei 16 Pods, zweite für /28 Pods 17-18, 14 für zukünftige Pods) = 33 zugewiesene IPs, 19 werden verwendet.

Um für eine Arbeitslast mit wenigen Pods in den sekundären IP-Modus (1 IP pro Pod, keine Präfixreservierung) zu wechseln, erstellen Sie ein benutzerdefiniertes NodeClass mit advancedNetworking.ipv4PrefixSize: "32" und zeigen Sie ein benutzerdefiniertes Feld darauf. NodePool Die integrierten Pools general-purpose und die system Node-Pools verwenden automatisch bereitgestellte default NodeClass. Für das Außerkraftsetzen ist ein benutzerdefinierter Pool mit einem benutzerdefinierten NodeClass Pool ipv4PrefixSize erforderlich. NodePool

Anwendungsfälle

• Bessere Nutzung der Subnetz-IP-Adressen

• Keine Präfixfragmentierung

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 angehängt 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

Konfigurieren Sie riesige Seiten auf Knoten

Mit dem advancedCompute.hugepages Feld können Sie Hugepages auf Knoten in der konfigurieren. NodeClass Hugepages verbessern die Speicherzugriffsleistung für latenzempfindliche Workloads wie Hochleistungsrechnen (HPC), Datenbanken und netzwerkintensive Anwendungen. Sie können zwei unabhängige Hugepages-Konfigurationen getrennt oder zusammen verwenden:

• Statische Hugepages — Verwenden Sie das pages Feld, um jedem Knoten eine feste Anzahl von 1Gi Hugepages 2Mi oder eine Mischung aus beiden Größen vorab zuzuweisen. Statische Hugepages sind eine planbare Node-Ressource. Um sie zu nutzen, konfiguriere deine Pods so, dass sie explizit Hugepage-Ressourcen wie oder anfordern. hugepages-2Mi hugepages-1Gi Weitere Informationen finden Sie unter Manage HugePages in der Kubernetes-Dokumentation.

• Transparent Hugepages (THP) — Verwenden Sie das transparent Feld, um die THP-Richtlinie des Kernels zu konfigurieren. THP ist eher eine kernelweite Richtlinie als eine zuweisbare Ressource. Es hat keinen Einfluss auf die Planung oder die Knotenkapazität und Pods fordern es nicht an. Weitere Informationen finden Sie unter Transparent Hugepage Support in der Linux-Kernel-Dokumentation.

Beispielkonfiguration

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

  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"

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

  advancedCompute:
    hugepages:
      # Static hugepage reservations: up to one entry for each size
      pages:
        - size: "2Mi"
          count: 512
        - size: "1Gi"
          count: 2
      # Transparent hugepages (THP) kernel policy
      transparent:
        enabled: always  # or madvise, never
        defrag: defer    # or always, defer+madvise, madvise, never

Transparente Hugepage-Einstellungen

Beide transparent Einstellungen sind optional. Wenn Sie eine Einstellung weglassen, verwendet der Knoten die Kernel-Standardeinstellung (madvise).

• enabled— Wird enabled zur Steuerung der THP-Zuweisungsrichtlinie verwendet. Stellen Sie diese Option ein, always um THP systemweit anzuwenden. Stellen Sie diese Option auf einmadvise, um THP nur auf Speicherbereiche anzuwenden, die sich mit anmelden. madvise(MADV_HUGEPAGE) Stellen Sie es auf ein, never um THP zu deaktivieren.

• defrag— Wird verwendetdefrag, um zu steuern, wie aggressiv der Kernel den Speicher komprimiert, um eine THP-Zuweisung zu erfüllen. Gültige Werte sind always, defer, defer+madvise, madvise und never.

Um THP zu deaktivieren, z. B. für Datenbank-Workloads, bei denen empfohlen wird, es auszuschalten, setzen Sie. enabled: never Wenn ja enablednever, lassen Sie den Wert defrag leer oder setzen Sie ihn aufnever; bei der NodeClass Validierung wird jede andere Kombination abgelehnt.

Überlegungen zu riesigen Seiten

Beachten Sie Folgendes, wenn Sie Hugepages auf einem konfigurieren: NodeClass

• Statische Hugepage-Größen — Verwenden Sie das pages Feld, um bis zu einem Eintrag für jede Hugepage-Größe (und) anzugeben. 2Mi 1Gi Sie können beide Größen auf denselben Knoten reservieren.

• Speicherreservierung — Statische Hugepages werden auf den Gesamtspeicher der Instanz angerechnet. Amazon EKS kennzeichnet Instance-Typen als inkompatibel, NodeClass wenn die kombinierte Hugepages-Reservierung für alle Seitengrößen 80% des Gesamtspeichers überschreiten würde.

• Gegenseitiger Ausschluss durch EFA — Elastic Fabric Adapter (EFA) und statische Hugepages können nicht nebeneinander existieren. NodeClass Wenn Sie interfaceType: efa-only zusammen mit festlegen, schlägt die Validierung fehl. pages NodeClass Amazon EKS stellt keine Pods bereit, die vpc.amazonaws.com/efa von einem NodeClass mit statischen Hugepages angefordert werden. Verwenden Sie eine separate NodeClass für EFA-Workloads. Transparente Hugepages stehen nicht in Konflikt mit EFA; Sie können die Konfiguration transparent auf einer NodeClass Seite vornehmen, die EFA-Schnittstellen verwendet.

Konfigurieren Sie die Kubelet-Einstellungen auf Knoten

Verwenden Sie das advancedCompute.kubelet Feld, um die Kubelet-Einstellungen auf Knoten in der zu überschreiben. NodeClass Mit diesen Überschreibungen können Sie die Pod-Dichte, das Löschen von Ressourcen, die Rotation von Container-Protokollen und das Verhalten bei unzureichendem Arbeitsspeicher (OOM) optimieren. Amazon EKS wendet Standard-Kubelet-Einstellungen auf Knoten im Auto-Modus an. Konfigurieren Sie dieses Feld daher nur, wenn Ihre Workloads ein anderes Verhalten erfordern. Weitere Informationen zu den zugrunde liegenden Einstellungen finden Sie unter Kubelet-Konfiguration in der Kubernetes-Dokumentation.

Die folgenden Kubelet-Einstellungen sind verfügbar:

• maxPods: Die maximale Anzahl von Pods, die auf einem Knoten ausgeführt werden können.

• podPidsLimit: Die maximale Anzahl von Prozess-IDs (PIDs) pro Pod.

• idsPerPod: Die Anzahl der UIDs und GIDs, die das Kubelet dem Benutzernamespace jedes Pods zuweist.

• singleProcessOOMKill: Ob das Kubelet-OOM Prozesse in einem Container einzeln statt als Gruppe beendet.

• eviction: Harte und weiche Grenzwerte für die Entfernung von Signalen, die den Ressourcenverbrauch beeinflussen.

• logging: Größe und Anzahl der Dateien im Container-Protokoll.

• allowedUnsafeSysctls: Eine Liste unsicherer Sysctls oder Namespace-Muster, die auf dem Knoten enden und die Pods*, die auf dem Knoten geplant sind, festlegen dürfen.

Beispielkonfiguration

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

  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"

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

  advancedCompute:
    kubelet:
      # Range: 1-110
      maxPods: 60
      # -1 disables the limit, or specify 100 or greater
      podPidsLimit: 4096
      # Multiple of 65536, range: 65536-4294967295. Requires
      # advancedCompute.kernel.sysctl.user.max_user_namespaces > 0.
      idsPerPod: 65536
      singleProcessOOMKill: false
      eviction:
        # Valid signals: memory.available, nodefs.available, nodefs.inodesFree,
        # imagefs.available, imagefs.inodesFree, pid.available
        hard:
          memory.available: "100Mi"
          nodefs.available: "10%"
        soft:
          memory.available: "500Mi"
          nodefs.available: "15%"
        # Required when soft thresholds are set
        softGracePeriod:
          memory.available: "1m30s"
          nodefs.available: "2m"
        # 0 uses each Pod's terminationGracePeriodSeconds
        maxPodGracePeriod: 60
      logging:
        containerLogMaxSize: "10Mi"
        # Minimum: 2
        containerLogMaxFiles: 5
      # Up to 64 entries. Allowed patterns: kernel.shm*, kernel.msg*,
      # kernel.sem, fs.mqueue.*, net.*
      allowedUnsafeSysctls:
        - "net.core.somaxconn"
        - "kernel.shm*"

Überlegungen zu den Kubelet-Einstellungen

Beachten Sie Folgendes, wenn Sie die Kubelet-Einstellungen auf einem konfigurieren: NodeClass

• Node-Ersatz: Wenn Sie die Kubelet-Einstellungen für einen vorhandenen Knoten ändern, werden die Knoten, die ihn verwenden, als „Drift“ NodeClass markiert. Amazon EKS ersetzt diese Knoten durch neue Knoten, die die aktualisierte Konfiguration verwenden. Amazon EKS wendet keine Kubelet-Einstellungen auf laufende Knoten an.

• maxPodsKlemmen: Der von Ihnen festgelegte Wert ist eine Obergrenze, keine Garantie. Zur Laufzeit wendet Amazon EKS den niedrigsten von drei Werten an. Dies sind Ihr maxPods Wert, die für den Instance-Typ verfügbaren IP-Adressen und das Auto-Modus-Limit von 110 Pods pro Knoten. Weitere Informationen finden Sie unter Auswahl eines optimalen Amazon-EC2-Knoten-Instance-Typs.

• podPidsLimitWerte: Geben Sie -1 an, ob das Limit deaktiviert werden soll, oder geben Sie einen Wert von 100 oder höher an. NodeClassBei der Validierung werden Werte zwischen 0 und 99 zurückgewiesen.

• idsPerPodAnforderungen: Der Wert muss ein Vielfaches von 65536 zwischen 65536 und 4294967295 sein. Die Einstellung idsPerPod muss advancedCompute.kernel.sysctl.user.max_user_namespaces auf einen positiven Wert für dasselbe NodeClass Objekt festgelegt werden. Bei der NodeClass Zulassung werden Konfigurationen abgelehnt, die festgelegt wurden, idsPerPod ohne dass ebenfalls ein Wert über user.max_user_namespaces 0 dem Wert festgelegt wurde. Mehr über user.max_user_namespaces erfahren Sie unter Unterstützte Sysctls.

• Weiche Schwellenwerte für das gleiche Signal: Ein weicher Schwellenwert muss weniger aggressiv sein als der harte Schwellenwert für dasselbe Signal, d. h., er wird früher ausgelöst. Wenn Sie weiche Schwellenwerte festlegen, müssen Sie diese auch für jedes Signal festlegensoftGracePeriod. Ein weicher Schwellenwert und ein fester Schwellenwert können unterschiedliche Einheiten verwenden, z. B. einen Prozentsatz und eine absolute Menge. In diesem Fall löst Amazon EKS beide Werte für jeden Instance-Typ auf. Amazon EKS markiert dann Instance-Typen, die gegen den Vergleich verstoßen, als inkompatibel mit demNodeClass.

• singleProcessOOMKillVersionsanforderung: Für diese Einstellung ist Kubernetes Version 1.32 oder höher erforderlich. In früheren Versionen gibt Amazon EKS ein Warnereignis aus NodeClass und die Einstellung hat keine Auswirkung.

• allowedUnsafeSysctlsEinschränkungen: Sie können bis zu 64 Einträge angeben, und jeder Eintrag muss einem der zulässigen Muster entsprechen: kernel.shm*kernel.msg*, kernel.semfs.mqueue. , odernet.. Wenn Sie ein unsicheres Sysctl auf dem Knoten zulassen, können Pods es nur anfordern. Jeder Pod muss das Sysctl trotzdem in seinem Verzeichnis auflisten. securityContext.sysctls Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Verwenden von Sysctls in einem Kubernetes-Cluster.

Konfigurieren Sie Kernel-Sysctls auf Knoten

Verwenden Sie das advancedCompute.kernel.sysctl Feld, um das Linux-Kernel-Sysctls auf Knoten in der einzustellen. NodeClass Sysctls optimieren das Verhalten des Laufzeitkernels für Workloads, die höhere Netzwerklimits, andere Speicherverwaltungsrichtlinien oder bestimmte TCP-Einstellungen benötigen. Die Eigenschaftsnamen in dem sysctl Feld stimmen exakt mit dem zugrunde liegenden Sysctl-Namen des Kernels überein (z. B. und). vm.swappiness net.core.somaxconn Amazon EKS wendet Sysctl-Werte beim Node-Start an. Wenn Sie einen Sysctl-Wert auf einem vorhandenen ändern, beginnt Amazon EKS NodeClass, Knoten zu ersetzen, damit die neuen Werte wirksam werden.

Beispielkonfiguration

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

  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"

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

  advancedCompute:
    kernel:
      sysctl:
        vm.swappiness: 30
        net.core.somaxconn: 4096
        net.ipv4.tcp_congestion_control: "cubic"
        vm.dirty_background_ratio: 10
        vm.dirty_ratio: 20

Unterstützte Sysctls

Amazon EKS unterstützt nur die Sysctls in der folgenden Tabelle. Jedes numerische Sysctl erzwingt das angezeigte Minimum und Maximum, und NodeClass Admission lehnt Werte ab, die außerhalb dieses Bereichs liegen. Die Zeichenfolge sysctls akzeptiert nur die aufgelisteten Werte.

Sysctl	Description	Zulässige Werte
fs.aio-max-nr	Die maximale Anzahl asynchroner I/O Anfragen.	65536–4194304
fs.inotify.max_user_instances	Die maximale Anzahl von Inotify-Instanzen pro echter Benutzer-ID.	8192–1048576
fs.inotify.max_user_watches	Die maximale Anzahl von Inotify-Uhren pro echter Benutzer-ID.	8192–1048576
fs.nr_open	Die maximale Anzahl von Datei-Handles, die ein Prozess zuweisen kann.	1048576–2147483584
kernel.perf_event_paranoid	Steuert den unberechtigten Zugriff auf Leistungsereignissysteme.	-1–2
net.core.netdev_max_backlog	Die maximale Anzahl von Paketen, die pro CPU auf der INPUT-Seite in die Warteschlange gestellt werden.	1000–3240000
net.core.rmem_max	Die maximale Größe des Empfangs-Socket-Puffers in Byte.	212992–134217728
net.core.somaxconn	Der Maximalwert für das Backlog-Argument im Listen-Systemaufruf.	4096–3240000
net.core.wmem_max	Die maximale Größe des Sende-Socket-Puffers in Byte.	212992–134217728
net.ipv4.neigh.default.gc_thresh1	Mindestanzahl der ARP-cache Einträge, bevor die Garbage Collection ausgeführt werden kann.	0–262144
net.ipv4.neigh.default.gc_thresh2	Weiche maximale Anzahl von ARP-cache Einträgen.	512–524288
net.ipv4.neigh.default.gc_thresh3	Harte maximale Anzahl von ARP-cache Einträgen.	1024–1048576
net.ipv4.tcp_congestion_control	Der TCP-Algorithmus zur Überlastungskontrolle für neue Verbindungen.	cubic, reno
net.ipv4.tcp_fin_timeout	Die Zeitdauer in Sekunden, für die eine verwaiste Verbindung im Status FIN_WAIT_2 verbleibt, bevor sie am lokalen Ende abgebrochen wird.	5–120
net.ipv4.tcp_keepalive_time	Wie oft (in Sekunden) versendet TCP Keepalive-Nachrichten, wenn Keepalive aktiviert ist.	30–432000
net.ipv4.tcp_max_syn_backlog	Die maximale Anzahl ausstehender SYN-Anfragen, die zulässig sind. Anfragen, die diesen Wert überschreiten, werden vom Kernel verworfen.	128–3240000
net.ipv4.tcp_tw_reuse	Aktiviert die Wiederverwendung von TIME-WAIT Sockets für neue Verbindungen, wenn dies aus Protokollsicht sicher ist. 0deaktiviert, aktiviert global, 1 2 aktiviert nur Loopback.	0–2
user.max_user_namespaces	Die maximale Anzahl von Benutzernamespaces, die von einem Benutzer erstellt werden können. Der Wert von deaktiviert Benutzernamespaces. 0	0–2147483647
vm.dirty_background_ratio	Prozentsatz des verfügbaren Speichers, bei dem Kernel-Flusher-Threads beginnen, fehlerhafte Seiten zurück auf die Festplatte zu schreiben.	1–20
vm.dirty_expire_centisecs	Hundertstelsekunden, bevor eine fehlerhafte Seite zurückgeschrieben werden kann.	0–6000
vm.dirty_ratio	Prozentsatz des verfügbaren Speichers, bei dem Schreibprogramme gezwungen sind, Schreibvorgänge zu blockieren.	5–40
vm.dirty_writeback_centisecs	Hundertstelsekunden zwischen Aufrufen von Flusher-Threads.	0–1000
vm.max_map_count	Die maximale Anzahl von Speicherabbildungsbereichen, die ein einzelner Prozess haben kann.	65530–2147483647
vm.swappiness	Relative I/O-Kosten des Swappings im Vergleich zum Dateisystem-Paging.	0–200
vm.watermark_scale_factor	Verhältnis von Wasserzeichen zur Speicherrückgewinnung in Bruchteilen von 10.000.	10–3000

Überlegungen zu Sysctls

Beachten Sie Folgendes, wenn Sie Kernel-Sysctls auf einem konfigurieren: NodeClass

• Unterstützte Sysctls — Nur die unter aufgeführten Sysctls werden unterstützt. Unterstützte Sysctls Für jedes Feld gelten dokumentierte Mindest- und Höchstwerte, und Werte, die außerhalb dieses Bereichs liegen, werden von der NodeClass Zulassung zurückgewiesen.

• Wird beim Booten angewendet — Sysctls werden beim Booten des Knotens auf Bottlerockets geschrieben. [settings.kernel.sysctl] Die Laufzeit ändert sich, um bestehende Knoten als „Drift“ zu spec.advancedCompute.kernel.sysctl kennzeichnen. Die neuen Werte werden nur auf Ersatzknoten wirksam.

• vm.dirty_background_ratiound vm.dirty_ratio — Diese beiden Felder müssen beide gesetzt oder beide weggelassen werden und vm.dirty_background_ratio müssen unbedingt kleiner als vm.dirty_ratio sein. NodeClass Die Zulassung lehnt Konfigurationen ab, die gegen eine der Regeln verstoßen.

• net.ipv4.neigh.default.gc_thresh1gc_thresh2, und gc_thresh3 — Die drei ARP-cache Schwellenwerte müssen alle zusammen festgelegt oder weggelassen werden, und ihre Werte müssen den Anforderungen entsprechen. gc_thresh1 < gc_thresh2 < gc_thresh3 NodeClass Die Zulassung lehnt Konfigurationen ab, die gegen eine der Regeln verstoßen.

• net.ipv4.tcp_congestion_control— Nur cubic und reno werden akzeptiert.