Knotenklasse für Amazon EKS erstellen - Amazon EKS
Erstellung einer KnotenklasseKnotenklassen-Zugriffseintrag erstellenKnotenklassen-SpezifikationÜberlegungenSeparate Subnetze und Sicherheitsgruppen für PodsSekundärer IP-Modus für PodsDeaktiviert den IPv4 Ausgang von IPv6 Pods in Clustern. IPv6

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.

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.

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:

  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 Einen Knotenpool für EKS Auto Mode erstellen.

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 Einen Knotenpool für EKS Auto Mode erstellen.

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 Ihrem Knotenrollen-ARN. 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

  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: 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 unterschiedlichen Availability Zones (AZs) befinden, können Sie Kubernetes-Funktionen wie Spread-Beschränkungen für die Pod-Topologie und Topology Aware Routing verwenden, um Pods und Traffic auf 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.

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:

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

  2. Der automatische EKS-Modus erstellt ENIs in den übereinstimmenden Subnetzen ein sekundäres podSubnetSelectorTerms Element, wobei die Sicherheitsgruppen von podSecurityGroupSelectorTerms angehängt werden. Pod-IP-Adressen werden diesen sekundären Adressen standardmäßig ENIs mit /28-Präfixen zugewiesen. Wenn kein zusammenhängender Präfixblock verfügbar ist, wird automatisch auf sekundäre Adressen IPs (/32) zurückgegriffen. Wenn auf in gesetzt ipv4PrefixSize ist, werden nur sekundäre Geräte "32" verwendetadvancedNetworking. IPs

  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 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 (node-to-node Kommunikation) 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äre Gruppe angehängt ENIs 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.

  • NodeClassGranularität auf -Ebene: Die Pod-Sicherheitsgruppen gelten für alle Pods, die auf Knoten geplant sind, die die verwenden. NodeClass 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 für mehrere erstellt haben. AZs 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 behält nur eine sekundäre IP als Minimalwert bei. IPTarget

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: Die durch das Präfix verursachte 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, IPs wenn mehr Pods erstellt werden.

Deaktiviert den IPv4 Ausgang von IPv6 Pods in Clustern. IPv6

Das enableV4Egress Feld ist true standardmäßig. Bei IPv6 Clustern im automatischen Modus kann die Funktion deaktiviert werden, sodass im automatischen Modus keine reine IPv4 Ausgangsschnittstelle für Pods erstellt wird. IPv6 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 Ausgehender Datenverkehr ist standardmäßig zulässig.

  • Netzwerkrichtlinie verwenden: Derzeit unterstützt die EKS-Netzwerkrichtlinie keinen Dual-Stack-Modus. Durch die Deaktivierung enableV4Egress kann verhindert werden, dass der Pod-Verkehr unerwartet übergeht. IPv4

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 Datenverkehr zu. IPv4 Diese Einstellung enableV4Egress: false blockiert IPv4 ausgehenden Datenverkehr und sorgt so für mehr Sicherheit, insbesondere bei Verwendung mit Netzwerkrichtlinien.