**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.
# EKS-Auto-Mode-Einstellungen konfigurieren
In diesem Kapitel wird beschrieben, wie Sie bestimmte Aspekte Ihrer Amazon Elastic Kubernetes Service (EKS)-Auto-Mode-Cluster konfigurieren. Während EKS Auto Mode die meisten Infrastrukturkomponenten automatisch verwaltet, können Sie bestimmte Features an Ihre Workload-Anforderungen anpassen.
Mithilfe der in diesem Thema beschriebenen Konfigurationsoptionen können Sie Netzwerkeinstellungen, Rechenressourcen und Lastausgleichsverhalten ändern und gleichzeitig die Vorteile der automatisierten Infrastrukturverwaltung beibehalten. Bevor Sie Konfigurationsänderungen vornehmen, überprüfen Sie die verfügbaren Optionen in den folgenden Abschnitten, um zu bestimmen, welcher Ansatz Ihren Anforderungen am besten entspricht.
| Welche Features möchten Sie konfigurieren? | Konfigurationsoption |
| --- | --- |
| **Knotenvernetzung und -speicherung** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/settings-auto.html) | [Knotenklasse für Amazon EKS erstellen](create-node-class.md) |
| **Knoten-Rechenressourcen** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/settings-auto.html) | [Einen Knotenpool für EKS Auto Mode erstellen](create-node-pool.md) |
| **Knotenpools mit statischer Kapazität** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/settings-auto.html) | [Statische Kapazitätsknotenpools im automatischen EKS-Modus](auto-static-capacity.md) |
| **Einstellungen für Application Load Balancer** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/settings-auto.html) | [Erstellen Sie einen IngressClass , um einen Application Load Balancer zu konfigurieren](auto-configure-alb.md) |
| **Einstellungen für Network Load Balancer** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/settings-auto.html) | [Verwendung von Service-Annotationen zur Konfiguration von Network Load Balancers](auto-configure-nlb.md) |
| **Einstellungen für Speicherklasse** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/settings-auto.html) | [Erstellen einer Speicherklasse](create-storage-class.md) |
| **ODCR-Nutzung steuern** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/settings-auto.html) | [Steuern Sie die Bereitstellung von Workloads in Kapazitätsreservierungen mit EKS Auto Mode.](auto-odcr.md) |
| **Erweiterte Sicherheit für Knoten** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/settings-auto.html) | [Erweiterte Sicherheitseinstellungen für Knoten konfigurieren](auto-advanced-security.md) |
# 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
1. Konfiguration mithilfe von `kubectl` auf Ihren Cluster anwenden
1. Verweisen Sie in Ihrer Knoten-Pool-Konfiguration auf die Knotenklasse. Weitere Informationen finden Sie unter [Einen Knotenpool für EKS Auto Mode erstellen](create-node-pool.md).
Sie müssen `kubectl` installiert und konfiguriert haben. Weitere Informationen finden Sie unter [Einrichtung zur Verwendung von Amazon EKS](setting-up.md).
### 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](create-node-pool.md).
## 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](access-entries.md)
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 \
--principal-arn \
--type EC2
# Associate the auto node policy
aws eks associate-access-policy \
--cluster-name \
--principal-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:
PrincipalArn:
Type: "EC2"
AccessPolicies:
- AccessScope:
Type: cluster
PolicyArn: arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy
DependsOn: [ ] # previously defined in CloudFormation
```
Informationen zur Bereitstellung von CloudFormation Stacks finden Sie unter [Erste Schritte mit CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/GettingStarted.html)
## 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](access-entries.md).
+ **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](choosing-instance-type.md).
+ **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](auto-learn-iam.md).
+ **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](set-builtin-node-pools.md).
+ ** `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](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#pod-topology-spread-constraints) [Aware Routing](https://kubernetes.io/docs/concepts/services-networking/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](#pod-subnet-selector).
## 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](security-groups-for-pods.md) (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` und`podSecurityGroupSelectorTerms`:
1. Die primäre ENI des Knotens verwendet die Subnetze und Sicherheitsgruppen von `subnetSelectorTerms` und`securityGroupSelectorTerms`. Dieser Schnittstelle ist nur die eigene IP-Adresse des Knotens zugewiesen.
1. 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"` verwendet`advancedNetworking`. IPs
1. 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 (Standard`snatPolicy: 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 festlegen`snatPolicy: 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.
# Einen Knotenpool für EKS Auto Mode erstellen
Amazon-EKS-Knoten-Pools bieten eine flexible Möglichkeit zur Verwaltung von Rechenressourcen in Ihrem Kubernetes-Cluster. Dieses Thema veranschaulicht, wie Sie mit Karpenter, einem Tool zur Bereitstellung von Knoten, das die Cluster-Skalierung und Ressourcenauslastung optimiert, Knoten-Pools erstellen und konfigurieren können. Mit der NodePool-Ressource von Karpenter können Sie spezifische Anforderungen für Ihre Rechenressourcen definieren, darunter Instance-Typen, Availability Zones, Architekturen und Kapazitätstypen.
Die integrierten `system`- und `general-purpose`- Knoten-Pools können nicht geändert werden. Sie können sie lediglich aktivieren oder deaktivieren. Weitere Informationen finden Sie unter [Integriert aktivieren oder deaktivieren NodePools](set-builtin-node-pools.md).
Die NodePool-Spezifikation ermöglicht eine detaillierte Steuerung der Rechenressourcen Ihres EKS-Clusters durch verschiedene unterstützte Labels und Anforderungen. Dazu gehören Optionen zur Festlegung von EC2-Instance-Kategorien, CPU-Konfigurationen, Availability Zones, Architekturen (ARM64/AMD64) und Kapazitätstypen (Spot oder On-Demand). Sie können auch Ressourcenlimits für die CPU- und Speichernutzung festlegen, um sicherzustellen, dass Ihr Cluster innerhalb der erforderlichen Betriebsgrenzen bleibt.
EKS Auto Mode nutzt bekannte Kubernetes-Labels, um konsistente und standardisierte Methoden zur Identifizierung von Knotenmerkmalen bereitzustellen. Diese Labels, wie beispielsweise `topology.kubernetes.io/zone` für Availability Zones und `kubernetes.io/arch` für die CPU-Architektur, entsprechen den gängigen Kubernetes-Konventionen. Darüber hinaus erweitern EKS-spezifische Labels (mit dem Präfix `eks.amazonaws.com/`) diese Funktionalität um AWS-spezifische Attribute wie Instance-Typen, CPU-Hersteller, GPU-Fähigkeiten und Netzwerk-Spezifikationen. Dieses standardisierte Kennzeichnungssystem ermöglicht eine nahtlose Integration in vorhandene Kubernetes-Tools und bietet gleichzeitig eine umfassende AWS-Infrastrukturintegration.
## Einen NodePool erstellen
Führen Sie die folgenden Schritte aus, um einen NodePool für Ihren Amazon-EKS-Cluster zu erstellen
1. Erstellen Sie eine YAML-Datei mit dem Namen `nodepool.yaml` und der erforderlichen NodePool-Konfiguration. Sie können die folgende Beispielkonfiguration verwenden.
1. Wenden Sie den NodePool auf Ihren Cluster an:
```
kubectl apply -f nodepool.yaml
```
1. Überprüfen Sie, ob der NodePool erfolgreich erstellt wurde:
```
kubectl get nodepools
```
1. (Optional) Überwachen Sie den NodePool-Status:
```
kubectl describe nodepool default
```
Stellen Sie sicher, dass Ihr NodePool auf eine gültige NodeClass verweist, die in Ihrem Cluster vorhanden ist. Die NodeClass definiert AWS-spezifische Konfigurationen für Ihre Rechenressourcen. Weitere Informationen finden Sie unter [Knotenklasse für Amazon EKS erstellen](create-node-class.md).
## Beispiel-NodePool
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
billing-team: my-team
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b"]
- key: "kubernetes.io/arch"
operator: In
values: ["arm64", "amd64"]
limits:
cpu: "1000"
memory: 1000Gi
```
## Unterstützte Labels für EKS Auto Mode
EKS Auto Mode unterstützt die folgenden bekannten Labels.
**Anmerkung**
EKS Auto Mode verwendet andere Bezeichnungen als Karpenter. Bezeichnungen, die sich auf von EC2 verwaltete Instances beziehen, beginnen mit `eks.amazonaws.com`.
| Label (Bezeichnung) | Beispiel | Beschreibung |
| --- | --- | --- |
| topology.kubernetes.io/zone | us-east-2a | Region AWS |
| node.kubernetes.io/instance-type | g4dn.8xgroß | AWS-Instance-Typ |
| kubernetes.io/arch | amd64 | Architekturen werden durch [GOARCH-Werte](https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go#L58) auf der Instance definiert. |
| karpenter.sh/capacity-type | spot | Zu den Kapazitätstypen gehören `spot`, `on-demand` |
| eks.amazonaws.com/instance-hypervisor | nitro | Instance-Typen, die einen bestimmten Hypervisor verwenden |
| eks.amazonaws.com/compute-type | auto | Identifiziert von EKS Auto Mode verwaltete Knoten |
| eks.amazonaws.com/instance-encryption-in-transit-supported | true | Instance-Typen, welche die Verschlüsselung während der Übertragung unterstützen (oder nicht) |
| eks.amazonaws.com/instance-category | g | Instance-Typen derselben Kategorie, in der Regel die Zeichenfolge vor der Generierungsnummer |
| eks.amazonaws.com/instance-generation | 4 | Instace-Typ-Generierungsnummer innerhalb einer Instance-Kategorie |
| eks.amazonaws.com/instance-family | g4dn | Instance-Typen mit ähnlichen Eigenschaften, aber unterschiedlichen Ressourcenmengen |
| eks.amazonaws.com/instance-size | 8xlarge | Instance-Typen mit ähnlichen Ressourcenmengen, jedoch unterschiedlichen Eigenschaften |
| eks.amazonaws.com/instance-cpu | 32 | Anzahl der CPUs auf der Instance |
| eks.amazonaws.com/instance-cpu-manufacturer | `aws` | Name des CPU-Herstellers |
| eks.amazonaws.com/instance-memory | 13 1072 | Anzahl der Mebibyte Speicher auf der Instance |
| eks.amazonaws.com/instance-ebs-bandwidth | 9 500 | Anzahl der verfügbaren [maximalen Megabits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html#ebs-optimization-performance) auf der Instance |
| eks.amazonaws.com/instance-network-bandwidth | 13 1072 | Anzahl der verfügbaren [Basis-Megabits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html) auf der Instance |
| eks.amazonaws.com/instance-gpu-name | t4 | Name der GPU auf der Instance, sofern verfügbar |
| eks.amazonaws.com/instance-gpu-manufacturer | nvidia | Name des GPU-Herstellers |
| eks.amazonaws.com/instance-gpu-count | 1 | Anzahl der GPUs auf der Instance |
| eks.amazonaws.com/instance-gpu-memory | 16 384 | Anzahl der Mebibyte Speicher auf der GPU |
| eks.amazonaws.com/instance-local-nvme | 900 | Anzahl der Gibibyte lokalen NVMe-Speichers auf der Instance |
**Anmerkung**
EKS Auto Mode unterstützt nur bestimmte Instances und hat Mindestgrößenanforderungen. Weitere Informationen finden Sie unter [Unterstützte Instance-Referenz für EKS Auto Mode](automode-learn-instances.md#auto-supported-instances).
## Von EKS Auto Mode nicht unterstützte Labels
EKS Auto Mode unterstützt die folgenden Labels nicht.
+ EKS Auto Mode unterstützt Linux nicht
+ `node.kubernetes.io/windows-build`
+ `kubernetes.io/os`
## Integrierte Knoten-Pools deaktivieren
Wenn Sie benutzerdefinierte Knoten-Pools erstellen, können Sie die integrierten Knoten-Pools deaktivieren. Weitere Informationen finden Sie unter [Integriert aktivieren oder deaktivieren NodePools](set-builtin-node-pools.md).
## Cluster ohne integrierte Knoten-Pools
Sie können einen Cluster ohne integrierte Knoten-Pools erstellen. Dies ist nützlich, wenn Ihr Unternehmen benutzerdefinierte Knoten-Pools erstellt hat.
**Anmerkung**
Wenn Sie einen Cluster ohne integrierte Knoten-Pools erstellen, wird die `default` NodeClass nicht automatisch bereitgestellt. Sie müssen eine benutzerdefinierte NodeClass erstellen. Weitere Informationen finden Sie unter [Knotenklasse für Amazon EKS erstellen](create-node-class.md).
**Übersicht:**
1. Erstellen Sie einen EKS-Cluster, bei dem die `nodePools`- und `nodeRoleArn`-Werte leer sind.
+ Beispiel-eksctl `autoModeConfig`:
```
autoModeConfig:
enabled: true
nodePools: []
# Do not set a nodeRoleARN
```
Weitere Informationen finden Sie unter [Erstellung eines EKS-Auto-Mode-Clusters mit der eksctl-Befehlszeilenschnittstelle](automode-get-started-eksctl.md).
1. Benutzerdefinierte Knotenklasse mit einer Knotenrollen-ARN erstellen
+ Weitere Informationen finden Sie unter [Knotenklasse für Amazon EKS erstellen](create-node-class.md).
1. Zugriffseintrag für die benutzerdefinierte Knotenklasse erstellen
+ Weitere Informationen finden Sie unter [Knotenklassen-Zugriffseintrag erstellen](create-node-class.md#auto-node-access-entry).
1. Erstellen Sie einen benutzerdefinierten Knoten-Pool, wie oben beschrieben.
## Unterbrechung
Sie können EKS Auto Mode so konfigurieren, dass Knoten über Ihren NodePool auf verschiedene Arten unterbrochen werden. Sie können `spec.disruption.consolidationPolicy`, `spec.disruption.consolidateAfter` oder `spec.template.spec.expireAfter` verwenden. Sie können die Unterbrechung von EKS Auto Mode auch über den `spec.disruption.budgets` des NodePools begrenzen. Außerdem können Sie die Zeitfenster und die Anzahl der gleichzeitig unterbrochenen Knoten steuern. Anweisungen zur Konfiguration dieses Verhaltens finden Sie unter [Unterbrechung](https://karpenter.sh/docs/concepts/disruption/) in der Karpenter-Dokumentation.
Sie können Unterbrechungen für Knoten-Pools wie folgt konfigurieren:
+ Identifizieren Sie, wann Instances nicht ausreichend ausgelastet sind, und konsolidieren Sie Workloads.
+ Erstellen Sie ein Budget für Knoten-Pool-Unterbrechung, um die Beendigung von Knoten aufgrund von Abweichungen, Leerständen und Konsolidierungen zu begrenzen.
Standardmäßig macht EKS Auto Mode Folgendes:
+ Konsolidiert nicht ausgelastete Instances.
+ Beendet Instances nach 336 Stunden.
+ Legt ein einzelnes Budget für Unterbrechung von 10 % der Knoten fest.
+ Ermöglicht den Austausch von Knoten aufgrund von Abweichungen, wenn eine neue AMI im Automatikmodus veröffentlicht wird. Das kommt etwa einmal pro Woche vor.
## Kündigungsfrist
Wenn ein `terminationGracePeriod` in einem EKS Auto NodePool nicht explizit definiert ist, wendet das System automatisch eine standardmäßige 24-stündige Kündigungsfrist auf den zugehörigen NodeClaim an. Während EKS-Auto-Kunden in ihren benutzerdefinierten NodePool-Konfigurationen keinen Standardwert von `terminationGracePeriod` sehen, beobachten sie diesen Standardwert im NodeClaim. Die Funktionalität bleibt konsistent, unabhängig davon, ob die Karenzzeit explizit im NodePool festgelegt oder im NodeClaim standardmäßig festgelegt ist. Dies gewährleistet ein vorhersehbares Knoten-Beendigungsverhalten im gesamten Cluster.
# Statische Kapazitätsknotenpools im automatischen EKS-Modus
Amazon EKS Auto Mode unterstützt Knotenpools mit statischer Kapazität, die unabhängig vom Pod-Bedarf eine feste Anzahl von Knoten beibehalten. Knotenpools mit statischer Kapazität sind nützlich für Workloads, die vorhersehbare Kapazität, reservierte Instances oder spezifische Compliance-Anforderungen erfordern, bei denen Sie eine konsistente Infrastruktur aufrechterhalten müssen.
Im Gegensatz zu dynamischen Knotenpools, die auf der Grundlage der Pod-Scheduling-Anforderungen skaliert werden, behalten Knotenpools mit statischer Kapazität die Anzahl der von Ihnen konfigurierten Knoten bei.
## Konfigurieren Sie einen Knotenpool mit statischer Kapazität
Um einen Knotenpool mit statischer Kapazität zu erstellen, legen Sie das `replicas` Feld in Ihrer NodePool Spezifikation fest. Das `replicas` Feld definiert die genaue Anzahl von Knoten, die der Knotenpool verwalten wird. Informationen [Beispiele](#static-capacity-examples) zur Konfiguration finden Sie unter`replicas`.
## Überlegungen zum Knotenpool mit statischer Kapazität
Knotenpools mit statischer Kapazität weisen mehrere wichtige Einschränkungen und Verhaltensweisen auf:
**Einschränkungen bei der Konfiguration:**
+ Der **Modus kann nicht gewechselt** werden: Sobald Sie einen Knotenpool eingerichtet `replicas` haben, können Sie ihn nicht mehr entfernen. Der Knotenpool kann nicht zwischen statischem und dynamischem Modus wechseln.
+ **Begrenzte Ressourcenlimits**: Nur das `limits.nodes` Feld wird im Abschnitt „Limits“ unterstützt. CPU- und Speichergrenzwerte gelten nicht.
+ **Kein Gewichtungsfeld**: Das `weight` Feld kann nicht für Knotenpools mit statischer Kapazität festgelegt werden, da die Knotenauswahl nicht auf der Priorität basiert.
**Betriebsverhalten:**
+ **Keine Konsolidierung**: Knoten in statischen Kapazitätspools werden für die Konsolidierung nicht berücksichtigt.
+ **Skalierung von Abläufen**: Skalierungsoperationen umgehen Budgets für Knotenunterbrechungen, werden aber trotzdem eingehalten PodDisruptionBudgets.
+ **Node-Austausch**: Nodes werden aufgrund von Drift (z. B. AMI-Updates) und Ablaufzeiten immer noch auf Grundlage Ihrer Konfiguration ersetzt.
## Best Practices
**Kapazitätsplanung:**
+ Legen Sie einen `limits.nodes` höheren Wert als fest`replicas`, um eine temporäre Skalierung bei Vorgängen zum Austausch von Knoten zu ermöglichen.
+ Berücksichtigen Sie bei der Festlegung von Grenzwerten die maximale Kapazität, die bei Node-Drift- oder AMI-Updates benötigt wird.
**Auswahl der Instanz:**
+ Verwenden Sie bestimmte Instance-Typen, wenn Sie Reserved Instances haben oder bestimmte Hardwareanforderungen haben.
+ Vermeiden Sie zu restriktive Anforderungen, die die Instance-Verfügbarkeit während der Skalierung einschränken könnten.
**Störungsmanagement:**
+ Richten Sie angemessene Budgets für Unterbrechungen ein, um ein Gleichgewicht zwischen Verfügbarkeit und Wartungsbetrieb herzustellen.
+ Berücksichtigen Sie bei der Festlegung von Budgetanteilen die Toleranz Ihrer Anwendung in Bezug auf den Austausch von Knoten.
**Überwachung:**
+ Überwachen Sie das `status.nodes` Feld regelmäßig, um sicherzustellen, dass Ihre gewünschte Kapazität erhalten bleibt.
+ Richten Sie Warnmeldungen ein, wenn die tatsächliche Knotenzahl von den gewünschten Replikaten abweicht.
**Zonenverteilung:**
+ Für eine hohe Verfügbarkeit sollten Sie die statische Kapazität auf mehrere Availability Zones verteilen.
+ Wenn Sie einen Knotenpool mit statischer Kapazität erstellen, der sich über mehrere Availability Zones erstreckt, verteilt EKS Auto Mode die Knoten auf die angegebenen Zonen, aber es kann nicht garantiert werden, dass die Verteilung gleichmäßig ist.
+ Für eine vorhersehbare und gleichmäßige Verteilung über die Availability Zones sollten Sie separate statische Kapazitätsknotenpools erstellen, die jeweils anhand der Anforderung an eine bestimmte Availability Zone gebunden sind. `topology.kubernetes.io/zone`
+ Wenn Sie 12 Knoten benötigen, die gleichmäßig auf drei Zonen verteilt sind, erstellen Sie drei Knotenpools mit jeweils 4 Replikaten anstelle eines Knotenpools mit 12 Replikaten in drei Zonen.
## Skalieren Sie einen Knotenpool mit statischer Kapazität
Sie können die Anzahl der Replikate in einem Knotenpool mit statischer Kapazität mithilfe des `kubectl scale` folgenden Befehls ändern:
```
# Scale down to 5 nodes
kubectl scale nodepool static-nodepool --replicas=5
```
Beim Herunterskalieren beendet der automatische Modus von EKS die Knoten ordnungsgemäß. Dabei werden laufende Pods berücksichtigt PodDisruptionBudgets und können auf die verbleibenden Knoten verschoben werden.
## Überwachen Sie Knotenpools mit statischer Kapazität
Verwenden Sie die folgenden Befehle, um Ihre Knotenpools mit statischer Kapazität zu überwachen:
```
# View node pool status
kubectl get nodepool static-nodepool
# Get detailed information including current node count
kubectl describe nodepool static-nodepool
# Check the current number of nodes
kubectl get nodepool static-nodepool -o jsonpath='{.status.nodes}'
```
Das `status.nodes` Feld zeigt die aktuelle Anzahl der vom Knotenpool verwalteten Knoten, die unter normalen Bedingungen Ihrer gewünschten `replicas` Anzahl entsprechen sollte.
## Fehlerbehebung
**Knoten, die die gewünschten Replikate nicht erreichen:**
+ Prüfen Sie, ob der `limits.nodes` Wert ausreichend ist
+ Stellen Sie sicher, dass Ihre Anforderungen die Instanzauswahl nicht zu stark einschränken
+ Prüfen Sie die AWS Servicekontingente für die Instanztypen und Regionen, die Sie verwenden
**Der Austausch des Knotens dauert zu lange:**
+ Passen Sie die Budgets für Unterbrechungen an, um mehr gleichzeitige Ersatzlieferungen zu ermöglichen
+ Prüfen Sie, ob PodDisruptionBudgets die Kündigung eines Knotens verhindert wird
**Unerwarteter Knotenabbruch:**
+ Überprüfen Sie `expireAfter` die `terminationGracePeriod` Einstellungen
+ Suchen Sie nach manuellen Knotenabbrüchen oder AWS Wartungsereignissen
## Beispiele
### Grundlegender Knotenpool mit statischer Kapazität
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: basic-static
spec:
replicas: 5
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["m"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a"]
limits:
nodes: 8 # Allow scaling up to 8 during operations
```
### Statische Kapazität mit bestimmten Instanztypen
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: reserved-instances
spec:
replicas: 20
template:
metadata:
labels:
instance-type: reserved
cost-center: production
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "node.kubernetes.io/instance-type"
operator: In
values: ["m5.2xlarge"] # Specific instance type
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
limits:
nodes: 25
disruption:
# Conservative disruption for production workloads
budgets:
- nodes: 10%
```
### Knotenpool mit statischer Kapazität aus mehreren Zonen
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: multi-zone-static
spec:
replicas: 12 # Will be distributed across specified zones
template:
metadata:
labels:
availability: high
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["8", "16"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
limits:
nodes: 15
disruption:
budgets:
- nodes: 25%
```
### Statische Kapazität mit Kapazitätsreservierung
Das folgende Beispiel zeigt, wie ein statischer Kapazitätsknotenpool mit einer EC2-Kapazitätsreservierung verwendet wird. Weitere Informationen zur Verwendung von EC2-Kapazitätsreservierungen mit dem automatischen EKS-Modus finden Sie unter. [Steuern Sie die Bereitstellung von Workloads in Kapazitätsreservierungen mit EKS Auto Mode.](auto-odcr.md)
`NodeClass`definieren der `capacityReservationSelectorTerms`
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: capacity-reservation-nodeclass
spec:
role: AmazonEKSNodeRole
securityGroupSelectorTerms:
- id: sg-0123456789abcdef0
subnetSelectorTerms:
- id: subnet-0123456789abcdef0
capacityReservationSelectorTerms:
- id: cr-0123456789abcdef0
```
`NodePool`auf das Obige verweisen `NodeClass` und verwenden`karpenter.sh/capacity-type: reserved`.
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: static-capacity-reservation-nodepool
spec:
replicas: 5
limits:
nodes: 8 # Allow scaling up to 8 during operations
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: capacity-reservation-nodeclass
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ['reserved']
```
# Erstellen Sie einen IngressClass , um einen Application Load Balancer zu konfigurieren
EKS Auto Mode automatisiert Routineaufgaben für den Lastausgleich, einschließlich der Bereitstellung von Cluster-Anwendungen im Internet
AWS schlägt vor, Application Load Balancers (ALB) für den HTTP- und HTTPS-Verkehr zu verwenden. Application Load Balancers können Anfragen basierend auf dem Inhalt der Anfrage weiterleiten. Weitere Informationen über Application Load Balancer finden Sie unter [Was ist elastischer Lastenausgleich?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html).
Der automatische EKS-Modus erstellt und konfiguriert Application Load Balancers (). ALBs Beispielsweise erstellt EKS Auto Mode einen Load Balancer, wenn Sie ein `Ingress`-Kubernetes-Objekt erstellen, und konfiguriert ihn so, dass der Datenverkehr an Ihre Cluster-Workload weitergeleitet wird.
**Übersicht**
1. Erstellen Sie eine Workload, die Sie im Internet verfügbar machen möchten.
1. Erstellen Sie eine `IngressClassParams` Ressource und geben Sie AWS bestimmte Konfigurationswerte an, z. B. das zu verwendende Zertifikat SSL/TLS und VPC-Subnetze.
1. Erstellen Sie eine `IngressClass`-Ressource und legen Sie fest, dass EKS Auto Mode als Controller für die Ressource dienen soll.
1. Erstellen Sie eine `Ingress`-Ressource, die einen HTTP-Pfad und einen Port mit einer Cluster-Workload verknüpft.
EKS Auto Mode erstellt einen Application Load Balancer, der auf die in der `Ingress`-Ressource angegebene Workload verweist und die in der `IngressClassParams`-Ressource angegebene Load-Balancer-Konfiguration verwendet.
## Voraussetzungen
+ EKS Auto Mode in einem Amazon-EKS-Cluster aktiviert
+ Kubectl für die Verbindung mit Ihrem Cluster konfiguriert
+ Sie können `kubectl apply -f ` verwenden um die unten aufgeführten YAML-Beispiel-Konfigurationsdateien in Ihren Cluster anwenden.
**Anmerkung**
EKS Auto Mode erfordert Subnetz-Tags zur Identifizierung öffentlicher und privater Subnetze.
Wenn Sie Ihren Cluster mit `eksctl` erstellt haben, verfügen Sie bereits über diese Tags.
Weitere Informationen erhalten Sie unter [Kennzeichnung von Subnetzen für EKS Auto Mode](tag-subnets-auto.md).
## Schritt 1: Workload erstellen
Erstellen Sie zunächst eine Workload, die Sie im Internet verfügbar machen möchten. Dies kann jede Kubernetes-Ressource sein, die HTTP-Datenverkehr bereitstellt, z. B. eine Bereitstellung oder ein Service.
In diesem Beispiel wird ein einfacher HTTP-Service mit dem Namen `service-2048` verwendet, der auf Port `80` empfangsbereit ist. Erstellen Sie diesen Service und dessen Bereitstellung, indem Sie das folgende Manifest `2048-deployment-service.yaml` anwenden:
```
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 2
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: app-2048
```
Wenden Sie die Konfiguration auf Ihren Cluster an:
```
kubectl apply -f 2048-deployment-service.yaml
```
Die oben aufgeführten Ressourcen werden im Standard-Namespace erstellt. Sie können dies durch Ausführung des folgenden Befehls überprüfen:
```
kubectl get all -n default
```
## Schritt 2: Erstellen IngressClassParams
Erstellen Sie ein `IngressClassParams` Objekt, um AWS spezifische Konfigurationsoptionen für den Application Load Balancer anzugeben. In diesem Beispiel erstellen wir eine `IngressClassParams`-Ressource mit dem Namen `alb` (die Sie im nächsten Schritt verwenden werden), die das Load-Balancer-Schema als `internet-facing` in einer Datei mit dem Namen `alb-ingressclassparams.yaml` festlegt.
```
apiVersion: eks.amazonaws.com/v1
kind: IngressClassParams
metadata:
name: alb
spec:
scheme: internet-facing
```
Wenden Sie die Konfiguration auf Ihren Cluster an:
```
kubectl apply -f alb-ingressclassparams.yaml
```
## Schritt 3: Erstellen IngressClass
Erstellen Sie eine`IngressClass`, die auf die AWS spezifischen Konfigurationswerte verweist, die in der `IngressClassParams` Ressource in einer Datei mit dem Namen festgelegt sind`alb-ingressclass.yaml`. Notieren Sie den Namen des `IngressClass`. In diesem Beispiel haben sowohl `IngressClass` als auch `IngressClassParams` den Namen `alb`.
Verwenden Sie die `is-default-class`-Annotation, um zu steuern, ob `Ingress`-Ressourcen diese Klasse standardmäßig verwenden sollen.
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: alb
annotations:
# Use this annotation to set an IngressClass as Default
# If an Ingress doesn't specify a class, it will use the Default
ingressclass.kubernetes.io/is-default-class: "true"
spec:
# Configures the IngressClass to use EKS Auto Mode
controller: eks.amazonaws.com/alb
parameters:
apiGroup: eks.amazonaws.com
kind: IngressClassParams
# Use the name of the IngressClassParams set in the previous step
name: alb
```
Weitere Informationen zu den Konfigurationsoptionen finden Sie unter [IngressClassParams Referenz](#ingress-reference).
Wenden Sie die Konfiguration auf Ihren Cluster an:
```
kubectl apply -f alb-ingressclass.yaml
```
## Schritt 4: Ingress erstellen
Erstellen Sie eine `Ingress`-Ressource in einer Datei mit dem Namen `alb-ingress.yaml`. Der Zweck dieser Ressource besteht darin, Pfade und Ports dem Application Load Balancer mit Workloads in Ihrem Cluster zuzuordnen. Für dieses Beispiel erstellen wir eine `Ingress`-Ressource mit dem Namen `2048-ingress`, die den Datenverkehr an einen Service mit dem Namen `service-2048` auf Port 80 weiterleitet.
Weitere Informationen zum Konfigurieren dieser Ressource finden Sie unter [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) in der Kubernetes-Dokumentation.
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: 2048-ingress
spec:
# this matches the name of IngressClass.
# this can be omitted if you have a default ingressClass in cluster: the one with ingressclass.kubernetes.io/is-default-class: "true" annotation
ingressClassName: alb
rules:
- http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: service-2048
port:
number: 80
```
Wenden Sie die Konfiguration auf Ihren Cluster an:
```
kubectl apply -f alb-ingress.yaml
```
## Schritt 5: Status überprüfen
Verwenden Sie `kubectl`, um den Status von `Ingress` zu ermitteln. Es kann einige Minuten dauern, bis der Load Balancer verfügbar ist.
Verwenden Sie den Namen der `Ingress`-Ressource, die Sie im vorherigen Schritt festgelegt haben. Beispiel:
```
kubectl get ingress 2048-ingress
```
Sobald die Ressource bereit ist, rufen Sie den Domain-Namen des Load Balancers ab.
```
kubectl get ingress 2048-ingress -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
```
Um den Service in einem Webbrowser anzuzeigen, überprüfen Sie den Port und den Pfad, die in der `Ingress`-Rettungsdatei angegeben sind.
## Schritt 6: Bereinigen
Zur Bereinigung des Load Balancer verwenden Sie den folgenden Befehl:
```
kubectl delete ingress 2048-ingress
kubectl delete ingressclass alb
kubectl delete ingressclassparams alb
```
Der automatische Modus von EKS löscht automatisch den zugehörigen Load Balancer in Ihrem AWS Konto.
## IngressClassParams Referenz
Die folgende Tabelle dient als Kurzübersicht über häufig verwendete Konfigurationsoptionen.
| Feld | Description | Beispielwert |
| --- | --- | --- |
| `scheme` | Legt fest, ob der ALB intern oder mit dem Internet verbunden ist | `internet-facing` |
| `namespaceSelector` | Schränkt ein, welche Namespaces dies verwenden können IngressClass | `environment: prod` |
| `group.name` | Gruppiert mehrere Ingresses, um einen einzigen ALB gemeinsam zu nutzen | `retail-apps` |
| `ipAddressType` | Legt den IP-Adresstyp für den ALB fest | `dualstack` |
| `subnets.ids` | Liste der Subnetze für die ALB-Bereitstellung IDs | `subnet-xxxx, subnet-yyyy` |
| `subnets.tags` | Tag-Filter zur Auswahl von Subnetzen für ALB | `Environment: prod` |
| `certificateARNs` | ARNs der zu verwendenden SSL-Zertifikate | ` arn:aws: acm:region:account:certificate/id` |
| `tags` | Benutzerdefinierte Tags für AWS Ressourcen | `Environment: prod, Team: platform` |
| `loadBalancerAttributes` | Load-Balancer-spezifische Attribute | `idle_timeout.timeout_seconds: 60` |
## Überlegungen
+ Sie können Anmerkungen nicht für eine verwenden, IngressClass um Load Balancer mit dem automatischen EKS-Modus zu konfigurieren. IngressClass Die Konfiguration sollte durch erfolgen. IngressClassParams Sie können jedoch Anmerkungen zu einzelnen Ingress-Ressourcen verwenden, um das Verhalten des Load Balancers zu konfigurieren (z. B. `alb.ingress.kubernetes.io/security-group-prefix-lists` oder). `alb.ingress.kubernetes.io/conditions.*`
+ Im automatischen Modus von EKS können Sie keine [ListenerAttribute](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_ListenerAttribute.html)Einstellungen vornehmen.
+ Sie müssen die Cluster-IAM-Rolle aktualisieren, um die Tag-Weitergabe von Kubernetes an AWS Load Balancer-Ressourcen zu ermöglichen. Weitere Informationen finden Sie unter [Benutzerdefinierte AWS Tags für EKS Auto-Ressourcen](auto-learn-iam.md#tag-prop).
+ Informationen zum Zuordnen von Ressourcen zum automatischen Modus von EKS oder zum selbstverwalteten Load AWS Balancer Controller finden Sie unter. [Migrationsreferenz](migrate-auto.md#migration-reference)
+ Informationen zum Beheben von Problemen mit Load Balancern finden Sie unter [Fehlerbehebung mit EKS Auto Mode](auto-troubleshoot.md).
+ Weitere Überlegungen zur Verwendung der Load-Balancing-Funktion von EKS Auto Mode finden Sie unter [Lastausgleich](auto-networking.md#auto-lb-consider).
Die folgenden Tabellen bieten einen detaillierten Vergleich der Änderungen IngressClassParams, der Ingress-Anmerkungen und der TargetGroupBinding Konfigurationen für den EKS-Automatikmodus. Diese Tabellen zeigen die wichtigsten Unterschiede zwischen der Lastenausgleichsfunktion von EKS Auto Mode und dem Open-Source Load Balancer Controller auf, darunter Änderungen der API-Version, veraltete Features und aktualisierte Parameternamen.
### IngressClassParams
| Vorherige | Neu | Description |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Änderung der API-Version |
| `spec.certificateArn` | `spec.certificateARNs` | Support für mehrere Zertifikate ARNs |
| `spec.subnets.tags` | `spec.subnets.matchTags` | Geändertes Schema für die Subnetz-Zuordnung |
| `spec.listeners.listenerAttributes` | Nicht unterstützt | Wird von EKS Auto Mode noch nicht unterstützt |
### Ingress-Annotationen
| Vorherige | Neu | Description |
| --- | --- | --- |
| `kubernetes.io/ingress.class` | Nicht unterstützt | `spec.ingressClassName` in Eingangsobjekten verwenden |
| `alb.ingress.kubernetes.io/group.name` | Nicht unterstützt | Geben Sie IngressClass nur Gruppen an |
| `alb.ingress.kubernetes.io/waf-acl-id` | Nicht unterstützt | Stattdessen WAF v2 verwenden |
| `alb.ingress.kubernetes.io/web-acl-id` | Nicht unterstützt | Stattdessen WAF v2 verwenden |
| `alb.ingress.kubernetes.io/shield-advanced-protection` | Nicht unterstützt | Shield-Integration deaktiviert |
| `alb.ingress.kubernetes.io/auth-type: oidc` | Nicht unterstützt | OIDC-Authentifizierungstyp wird derzeit nicht unterstützt |
### TargetGroupBinding
| Vorherige | Neu | Description |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Änderung der API-Version |
| `spec.targetType` optional | `spec.targetType` erforderlich | Explizite Angabe des Zieltyps |
| `spec.networking.ingress.from` | Nicht unterstützt | NLB ohne Sicherheitsgruppen wird nicht mehr unterstützt |
Um die benutzerdefinierte TargetGroupBinding Funktion verwenden zu können, müssen Sie die Zielgruppe mit dem eks: eks-cluster-name -Tag und dem Clusternamen taggen, um dem Controller die erforderlichen IAM-Berechtigungen zu gewähren. Beachten Sie, dass der Controller die Zielgruppe löscht, wenn die TargetGroupBinding Ressource oder der Cluster gelöscht wird.
# Verwendung von Service-Annotationen zur Konfiguration von Network Load Balancers
Erfahren Sie, wie Sie Network Load Balancers (NLB) in Amazon EKS mithilfe von Kubernetes-Service-Annotationen konfigurieren. In diesem Thema werden die Anmerkungen erläutert, die vom automatischen Modus von EKS für die Anpassung des NLB-Verhaltens unterstützt werden, einschließlich Internetzugriff, Integritätsprüfungen, SSL/TLS Kündigung und IP-Targeting-Modi.
Wenn Sie einen Kubernetes-Dienst vom Typ `LoadBalancer` im EKS-Automodus erstellen, stellt EKS automatisch einen AWS Network Load Balancer bereit und konfiguriert ihn auf der Grundlage der von Ihnen angegebenen Anmerkungen. Dieser deklarative Ansatz ermöglicht es Ihnen, Load-Balancer-Konfigurationen direkt über Ihre Kubernetes-Manifeste zu verwalten und so die Infrastruktur als Code zu verwalten.
Der automatische Modus von EKS übernimmt standardmäßig die Bereitstellung von Network Load Balancer für alle Dienste dieses Typs LoadBalancer — es ist keine zusätzliche Controller-Installation oder -Konfiguration erforderlich. Die `loadBalancerClass: eks.amazonaws.com/nlb`-Spezifikation wird automatisch als Cluster-Standard festgelegt, wodurch der Bereitstellungsprozess optimiert und gleichzeitig die Kompatibilität mit vorhandenen Kubernetes-Workloads gewährleistet wird.
**Anmerkung**
EKS Auto Mode erfordert Subnetz-Tags zur Identifizierung öffentlicher und privater Subnetze.
Wenn Sie Ihren Cluster mit `eksctl` erstellt haben, verfügen Sie bereits über diese Tags.
Weitere Informationen erhalten Sie unter [Kennzeichnung von Subnetzen für EKS Auto Mode](tag-subnets-auto.md).
## Beispiel-Service
Weitere Informationen zur Kubernetes-`Service`-Ressource finden Sie in [der Kubernetes-Dokumentation](https://kubernetes.io/docs/concepts/services-networking/service/).
Überprüfen Sie die unten stehende `Service`-Beispiel-Ressource:
```
apiVersion: v1
kind: Service
metadata:
name: echoserver
annotations:
# Specify the load balancer scheme as internet-facing to create a public-facing Network Load Balancer (NLB)
service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
spec:
selector:
app: echoserver
ports:
- port: 80
targetPort: 8080
protocol: TCP
type: LoadBalancer
# Specify the new load balancer class for NLB as part of EKS Auto Mode feature
# For clusters with Auto Mode enabled, this field can be omitted as it's the default
loadBalancerClass: eks.amazonaws.com/nlb
```
## Häufig verwendete Annotationen
Die folgende Tabelle listet häufig verwendete Annotationen auf, die von EKS Auto Mode unterstützt werden. Beachten Sie, dass EKS Auto Mode möglicherweise nicht alle Annotationen unterstützt.
**Tipp**
Alle folgenden Annotationen müssen mit `service.beta.kubernetes.io/` vorangestellt werden
| Feld | Description | Beispiel |
| --- | --- | --- |
| `aws-load-balancer-type` | Gibt den Typ des Load Balancers an. Verwenden Sie `external` für neue Bereitstellungen. | `external` |
| `aws-load-balancer-nlb-target-type` | Gibt an, ob der Datenverkehr an Knoteninstanzen oder direkt an den Pod weitergeleitet werden soll. IPs Verwenden Sie `instance` für Standard-Bereitstellungen oder `ip` für die direkte Pod-Weiterleitung. | `instance` |
| `aws-load-balancer-scheme` | Steuert, ob der Load Balancer intern oder mit dem Internet verbunden ist. | `internet-facing` |
| `aws-load-balancer-healthcheck-protocol` | Protokoll für die Zustandsprüfung der Zielgruppe. Gängige Optionen sind `TCP` (Standard) oder `HTTP`. | `HTTP` |
| `aws-load-balancer-healthcheck-path` | Der HTTP-Pfad für Integritätsprüfungen bei Verwendung HTTP/HTTPS des Protokolls. | `/healthz` |
| `aws-load-balancer-healthcheck-port` | Der für Zustandsprüfungen verwendete Port. Dies kann eine bestimmte Portnummer oder `traffic-port` sein. | `traffic-port` |
| `aws-load-balancer-subnets` | Gibt an, in welchen Subnetzen der Load Balancer erstellt werden soll. Kann Subnetz IDs oder Namen verwenden. | `subnet-xxxx, subnet-yyyy` |
| `aws-load-balancer-ssl-cert` | ARN des SSL-Zertifikats von AWS Certificate Manager für HTTPS/TLS. | ` arn:aws: acm:region:account:certificate/cert-id` |
| `aws-load-balancer-ssl-ports` | Legt fest, welche Ports SSL/TLS verwenden sollen. | `443, 8443` |
| `load-balancer-source-ranges` | Für den Zugriff auf den Load Balancer zulässige CIDR-Bereiche. | `10.0.0.0/24, 192.168.1.0/24` |
| `aws-load-balancer-additional-resource-tags` | Zusätzliche AWS Tags, die auf den Load Balancer und verwandte Ressourcen angewendet werden sollen. | `Environment=prod,Team=platform` |
| `aws-load-balancer-ip-address-type` | Gibt an, ob der Load Balancer Dual-Stack (IPv4 \$1) verwendet IPv4 . IPv6 | `ipv4` oder `dualstack` |
## Überlegungen
+ Sie müssen die Cluster-IAM-Rolle aktualisieren, um die Tag-Weitergabe von Kubernetes an AWS Load Balancer-Ressourcen zu ermöglichen. Weitere Informationen finden Sie unter [Benutzerdefinierte AWS Tags für EKS Auto-Ressourcen](auto-learn-iam.md#tag-prop).
+ Informationen zum Zuordnen von Ressourcen zum automatischen Modus von EKS oder zum selbstverwalteten Load AWS Balancer Controller finden Sie unter. [Migrationsreferenz](migrate-auto.md#migration-reference)
+ Informationen zum Beheben von Problemen mit Load Balancern finden Sie unter [Fehlerbehebung mit EKS Auto Mode](auto-troubleshoot.md).
+ Weitere Überlegungen zur Verwendung der Load-Balancing-Funktion von EKS Auto Mode finden Sie unter [Lastausgleich](auto-networking.md#auto-lb-consider).
Bei der Migration zu EKS Auto Mode für Load Balancing sind mehrere Änderungen an Service-Annotationen und Ressourcen-Konfigurationen erforderlich. Die folgenden Tabellen zeigen die wichtigsten Unterschiede zwischen der bisherigen und der neuen Implementierung, einschließlich nicht unterstützter Optionen und empfohlener Alternativen.
### Service-Annotationen
| Vorherige | Neu | Description |
| --- | --- | --- |
| `service.beta.kubernetes.io/load-balancer-source-ranges` | Nicht unterstützt | `spec.loadBalancerSourceRanges` für Service verwenden |
| `service.beta.kubernetes.io/aws-load-balancer-type` | Nicht unterstützt | `spec.loadBalancerClass` für Service verwenden |
| `service.beta.kubernetes.io/aws-load-balancer-internal` | Nicht unterstützt | Verwenden von `service.beta.kubernetes.io/aws-load-balancer-scheme` |
| `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol` | Nicht unterstützt | Stattdessen `service.beta.kubernetes.io/aws-load-balancer-target-group-attributes` verwenden |
| Verschiedene Attribute des Load Balancers | Nicht unterstützt | Verwenden von `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled` | Nicht unterstützt | Stattdessen `service.beta.kubernetes.io/aws-load-balancer-attributes` verwenden |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` | Nicht unterstützt | Stattdessen `service.beta.kubernetes.io/aws-load-balancer-attributes` verwenden |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix` | Nicht unterstützt | Stattdessen `service.beta.kubernetes.io/aws-load-balancer-attributes` verwenden |
| `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled` | Nicht unterstützt | Stattdessen `service.beta.kubernetes.io/aws-load-balancer-attributes` verwenden |
Um von veralteten Annotation zu Load-Balancer-Attributen zu migrieren, konsolidieren Sie diese Einstellungen in der `service.beta.kubernetes.io/aws-load-balancer-attributes`-Annotation. Diese Annotation akzeptiert eine durch Kommas getrennte Liste von Schlüssel-Wert-Paaren für verschiedene Load-Balancer-Attribute. Verwenden Sie beispielsweise das folgende Format, um die Zugriffsprotokollierung und den zonenübergreifenden Lastenausgleich zu spezifizieren:
```
service.beta.kubernetes.io/aws-load-balancer-attributes: access_logs.s3.enabled=true,access_logs.s3.bucket=my-bucket,access_logs.s3.prefix=my-prefix,load_balancing.cross_zone.enabled=true
```
Dieses konsolidierte Format bietet eine konsistentere und flexiblere Möglichkeit zur Konfiguration von Load Balancer-Attributen und reduziert gleichzeitig die Anzahl der erforderlichen einzelnen Annotationen. Überprüfen Sie Ihre vorhandenen Service-Konfigurationen und aktualisieren Sie sie, um dieses konsolidierte Format zu verwenden.
### TargetGroupBinding
| Vorherige | Neu | Description |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Änderung der API-Version |
| `spec.targetType` optional | `spec.targetType` erforderlich | Explizite Angabe des Zieltyps |
| `spec.networking.ingress.from` | Nicht unterstützt | NLB ohne Sicherheitsgruppen wird nicht mehr unterstützt |
Hinweis: Um die benutzerdefinierte TargetGroupBinding Funktion verwenden zu können, müssen Sie die Zielgruppe mit dem Tag mit `eks:eks-cluster-name` dem Clusternamen kennzeichnen, um dem Controller die erforderlichen IAM-Berechtigungen zu gewähren. Beachten Sie, dass der Controller die Zielgruppe löscht, wenn die TargetGroupBinding Ressource oder der Cluster gelöscht wird.
# Erstellen einer Speicherklasse
Eine `StorageClass` im Amazon EKS Auto Mode definiert, wie Amazon-EBS-Volumes automatisch bereitgestellt werden, wenn Anwendungen persistenten Speicher anfordern. Auf dieser Seite wird erläutert, wie Sie eine `StorageClass` erstellen und konfigurieren, das mit dem Amazon EKS Auto Mode zusammenarbeitet, um EBS-Volumes bereitzustellen.
Durch die Konfiguration einer `StorageClass` können Sie Standardeinstellungen für Ihre EBS-Volumes festlegen, darunter Volume-Typ, Verschlüsselung, IOPS und andere Speicherparameter. Sie können den auch so konfigurieren`StorageClass`, dass AWS KMS-Schlüssel für die Verschlüsselungsverwaltung verwendet werden.
EKS Auto Mode erstellt keine `StorageClass` für Sie. Sie müssen eine `StorageClass`-Referenzierung `ebs.csi.eks.amazonaws.com` erstellen, um die Speicherfunktion von EKS Auto Mode zu nutzen.
Erstellen Sie zunächst eine Datei mit dem Namen `storage-class.yaml`:
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
allowedTopologies:
- matchLabelExpressions:
- key: eks.amazonaws.com/compute-type
values:
- auto
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
Wenden Sie anschließend die Speicherklasse auf Ihren Cluster an.
```
kubectl apply -f storage-class.yaml
```
**Zentrale Komponenten:**
+ `provisioner: ebs.csi.eks.amazonaws.com` – Verwendet EKS Auto Mode
+ `allowedTopologies` – Durch die Angabe von `matchLabelExpressions` für die Übereinstimmung mit `eks.amazonaws.com/compute-type:auto` wird sichergestellt, dass Ihre Pods, die ein Volume benötigen, das automatisch im Automatikmodus bereitgestellt wird, nicht auf Nicht-Automatik-Knoten geplant werden.
+ `volumeBindingMode: WaitForFirstConsumer` – Verzögert die Volume-Erstellung, bis ein Pod sie benötigt
+ `type: gp3` – Gibt den EBS-Volume-Typ an
+ `encrypted: "true"` – EBS verschlüsselt alle Volumes, die mit `StorageClass` erstellt wurden. EBS verwendet den `aws/ebs`-Standard-Schlüssel-Alias. Weitere Informationen finden Sie unter [So funktioniert die Amazon-EBS-Verschlüsselung](https://docs.aws.amazon.com/ebs/latest/userguide/how-ebs-encryption-works.html) im Amazon-EBS-Benutzerhandbuch. Dieser Wert ist optional, wird jedoch empfohlen.
+ `storageclass.kubernetes.io/is-default-class: "true"` – Kubernetes verwendet standardmäßig diese Speicherklasse, sofern Sie nicht für einen persistenten Volume-Anspruch eine andere Volume-Klasse angeben. Dieser Wert ist optional. Seien Sie beim Festlegen dieses Werts vorsichtig, wenn Sie von einem anderen Speicher-Controller migrieren.
## Selbstverwalteter KMS-Schlüssel zur Verschlüsselung von EBS-Volumes verwenden
Um einen selbstverwalteten KMS-Schlüssel zur Verschlüsselung von EBS-Volumes zu verwenden, die durch EKS Auto Mode automatisiert werden, müssen Sie folgende Schritte ausführen:
1. Erstellen Sie einen selbstverwalteten KMS-Schlüssel.
+ Weitere Informationen finden Sie unter [Erstellen eines symmetrischen KMS-Verschlüsselungsschlüssels](https://docs.aws.amazon.com/kms/latest/developerguide/create-symmetric-cmk.html) oder [So verwendet Amazon Elastic Block Store (Amazon EBS) KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services-ebs.html) im KMS-Benutzerhandbuch.
1. Erstellen Sie eine neue Richtlinie, die den Zugriff auf den KMS-Schlüssel zulässt.
+ Verwenden Sie die unten aufgeführte Beispiel-IAM-Richtlinie, um die Richtlinie zu erstellen. Geben Sie die ARN des neuen selbstverwalteten KMS-Schlüssels ein. Weitere Informationen finden Sie im AWS IAM-Benutzerhandbuch unter [Rollen erstellen und Richtlinien anhängen (Konsole)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html).
1. Fügen Sie die Richtlinie der EKS- Cluster-Rolle an.
+ Verwenden Sie die AWS Konsole, um den ARN der EKS-Clusterrolle zu finden. Die Rollen-Informationen sind im Abschnitt **Übersicht** einsehbar. Weitere Informationen finden Sie unter [Amazon-EKS-Cluster-IAM-Rolle](cluster-iam-role.md).
1. Aktualisieren Sie `StorageClass`, um auf die KMS-Schlüssel-ID im `parameters.kmsKeyId`-Feld zu verweisen.
### Beispiel für eine selbstverwaltete KMS-IAM-Richtlinie
Aktualisieren Sie die folgenden Werte in der unten aufgeführten Richtlinie:
+ ``— Ihre AWS Konto-ID, z. B. `111122223333`
+ ``— Die AWS Region Ihres Clusters, wie `us-west-2`
```
{
"Version":"2012-10-17",
"Id": "key-auto-policy-3",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow access through EBS for all principals in the account that are authorized to use EBS",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:CallerAccount": "123456789012",
"kms:ViaService": "ec2.us-east-1.amazonaws.com"
}
}
}
]
}
```
### Beispiel für ein selbstverwaltetes KMS `StorageClass`
```
parameters:
type: gp3
encrypted: "true"
kmsKeyId:
```
## `StorageClass`-Parameter-Referenz
Allgemeine Informationen zu den `StorageClass`-Kubernetes-Ressourcen finden Sie unter [Speicherklassen](https://kubernetes.io/docs/concepts/storage/storage-classes/) in der Kubernetes-Dokumentation
THe `parameters`Der Abschnitt der `StorageClass` Ressource ist spezifisch für AWS. Verwenden Sie die folgende Tabelle, um die verfügbaren Optionen zu überprüfen.
| Parameters | Werte | Standard | Description |
| --- | --- | --- | --- |
| „csi.storage.k8s.io/fstype“ | xfs, ext2, ext3, ext4 | ext4 | Dateisystemtyp, der während der Volume-Erstellung formatiert wird. Bei diesem Parameter wird zwischen Groß- und Kleinschreibung unterschieden\$1 |
| „type“ | io1, io2, gp2, gp3, sc1, st1, standard, sbp1, sbg1 | gp3 | EBS-Volume-Typ. |
| „iopsPerGB“ | | | E/A-Vorgänge pro Sekunde pro GiB. Kann für IO1 IO2, und GP3 Volumen angegeben werden. |
| „Automatisch zulassen IOPSPerGBIncrease“ | true, false | false | Wenn `"true"` der CSI-Treiber die IOPS für ein Volume erhöht, wenn `iopsPerGB * ` es zu niedrig ist, um in den von unterstützten IOPS-Bereich zu passen. AWS Dadurch ist die dynamische Bereitstellung immer erfolgreich, selbst wenn der Benutzer eine zu geringe PVC-Kapazität oder einen zu geringen `iopsPerGB`-Wert angibt. Andererseits können zusätzliche Kosten entstehen, da solche Volumes höhere IOPS aufweisen als in `iopsPerGB` angefordert. |
| „iops“ | | | E/A-Vorgänge pro Sekunde. Kann für IO1, IO2 und GP3 Volumes angegeben werden. |
| „throughput“ | | 125 | Durchsatz in MiB/s. Nur wirksam, wenn der Datenträgertyp gp3 angegeben ist. |
| „verschlüsselt“ | true, false | false | Ob das Volume verschlüsselt werden soll oder nicht. Gültige Werte sind „wahr“ oder „falsch“. |
| „blockExpress“ | true, false | false | Ermöglicht die Erstellung von io2-Block-Express-Volumes. |
| "kmsKeyId" | | | Die vollständige ARN des Schlüssels, der bei der Verschlüsselung des Volumes verwendet werden soll. Wenn nicht angegeben, AWS wird der Standard-KMS-Schlüssel für die Region verwendet, in der sich das Volume befindet. Wenn dieser nicht geändert wird, handelt es sich um einen automatisch generierten Schlüssel mit dem Namen `/aws/ebs`. |
| „blockSize“ | | | Die Blockgröße, die beim Formatieren des zugrunde liegenden Dateisystems verwendet werden soll. Wird nur auf Linux-Knoten und mit fstype `ext2`, `ext3`, `ext4` oder `xfs` unterstützt. |
| „inodeSize“ | | | Die Inode-Größe, die beim Formatieren des zugrunde liegenden Dateisystems verwendet werden soll. Wird nur auf Linux-Knoten und mit fstype `ext2`, `ext3`, `ext4` oder `xfs` unterstützt. |
| "bytesPerInode" | | | Die `bytes-per-inode`, die beim Formatieren des zugrunde liegenden Dateisystems verwendet werden sollen. Wird nur auf Linux-Knoten und mit fstype `ext2`, `ext3`, `ext4` unterstützt. |
| "numberOfInodes" | | | Die `number-of-inodes`, die beim Formatieren des zugrunde liegenden Dateisystems verwendet werden sollen. Wird nur auf Linux-Knoten und mit fstype `ext2`, `ext3`, `ext4` unterstützt. |
| „ext4BigAlloc“ | true, false | false | Ändert das `ext4`-Dateisystem, um die gruppierte Block-Zuweisung zu verwenden, indem die `bigalloc`-Formatierungsoption aktiviert wird. Warnung: `bigalloc` wird möglicherweise nicht vollständig vom Linux-Kernel Ihres Knotens unterstützt. |
| „ClusterSizeext4“ | | | Die Cluster-Größe, die beim Formatieren eines `ext4`-Dateisystems verwendet werden soll, wenn das `bigalloc`-Feature aktiviert ist. Hinweis: Der Parameter `ext4BigAlloc` muss auf „wahr“ gesetzt sein. |
Weitere Informationen finden Sie unter dem [AWS EBS-CSI-Treiber unter](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/parameters.md). GitHub
## Überlegungen
**Anmerkung**
Sie können Workloads, die vom EKS-Automatikmodus abhängen, nur auf StorageClasses EKS-Automodus-Knoten bereitstellen. Wenn Sie über einen Cluster mit kombinierten Knotentypen verfügen, müssen Sie Ihre Workloads so konfigurieren, dass sie ausschließlich in EKS-Auto-Mode-Knoten ausgeführt werden. Weitere Informationen finden Sie unter [Überprüfen, ob eine Workload in Knoten von EKS Auto Mode bereitgestellt wird](associate-workload.md).
Die Blockspeicherfunktion des EKS Auto Mode unterscheidet sich vom EBS-CSI-Treiber.
+ Statische Bereitstellung
+ Wenn Sie extern erstellte EBS-Volumes mit dem automatischen EKS-Modus verwenden möchten, müssen Sie manuell ein AWS Tag mit dem Schlüssel `eks:eks-cluster-name` und dem Wert des Clusternamens hinzufügen.
+ Knoten-Startup-Taint
+ Es ist nicht möglich, das Node-Startup-Taint-Feature zu verwenden, um die Pod-Planung zu verhindern, bevor die Speicherkapazität bereit ist.
+ Benutzerdefinierte Tags auf dynamisch bereitgestellten Volumes
+ Sie können das CLI-Flag „extra-tag“ nicht verwenden, um benutzerdefinierte Tags für dynamisch bereitgestellte EBS-Volumes zu konfigurieren.
+ Sie können `StorageClass`-Kennzeichnung verwenden, um benutzerdefinierte Tags hinzuzufügen. Der automatische EKS-Modus fügt den zugehörigen Ressourcen Tags hinzu. AWS Sie müssen die Cluster-IAM-Rolle für benutzerdefinierte Tags aktualisieren. Weitere Informationen finden Sie unter [Benutzerdefinierte AWS Tags für EKS Auto-Ressourcen](auto-learn-iam.md#tag-prop).
+ Detaillierte EBS-Leistungsmetriken
+ Sie können nicht auf Prometheus-Metriken für die detaillierte EBS-Leistung zugreifen
## Add-On „CSI-Snapshot Controller“ installieren
EKS Auto Mode ist mit dem Amazon-EKS-Add-On „CSI Snapshot Controller“ kompatibel.
AWS schlägt vor, dass Sie dieses Add-on so konfigurieren, dass es auf dem integrierten `system` Knotenpool ausgeführt wird.
Weitere Informationen finden Sie unter:
+ [Kritische Add-Ons in dedizierten Instances ausführen](critical-workload.md)
+ [Integriert aktivieren oder deaktivieren NodePools](set-builtin-node-pools.md)
+ [Snapshot-Funktion für CSI-Volumes aktivieren](csi-snapshot-controller.md)
### So installieren Sie den Snapshot-Controller im System-Knoten-Pool
1. Öffnen Sie Ihren EKS-Cluster in der AWS Konsole
1. Wählen Sie auf der Registerkarte **Add-Ons** die Option **Weitere Add-Ons abrufen**
1. Wählen Sie den **CSI Snapshot Controller** und dann **Weiter**
1. Wählen Sie auf der Seite **Einstellungen für ausgewählte Add-Ons konfigurieren** die Option **Optionale Konfigurationseinstellungen** aus, um das **Add-On-Konfigurationsschema** anzuzeigen.
1. Fügen Sie das folgende YAML ein, um den Snapshot-Controller dem `system`-Knoten-Pool zuzuordnen. Der Snapshot-Controller enthält eine Toleranz für den `CriticalAddonsOnly`-Taint.
```
{
"nodeSelector": {
"karpenter.sh/nodepool": "system"
}
}
```
1. Klicken Sie auf **Weiter**
1. Überprüfen Sie die Add-On-Konfiguration und wählen Sie dann **Erstellen** aus
# EKS Auto Mode deaktivieren
Sie können EKS Auto Mode in einem vorhandenen EKS-Cluster deaktivieren. Hierbei handelt es sich um einen destruktiven Vorgang.
+ EKS beendet alle vom EKS Auto Mode betriebenen EC2 Instanzen.
+ EKS wird alle von EKS Auto Mode betriebenen Load Balancer löschen.
+ EKS löscht **keine** EBS-Volumes, die von EKS Auto Mode bereitgestellt werden.
EKS Auto Mode wurde entwickelt, um die von ihm erstellten Ressourcen vollständig zu verwalten. Manuelle Eingriffe können dazu führen, dass EKS Auto Mode diese Ressourcen bei seiner Deaktivierung nicht vollständig bereinigt. Wenn Sie beispielsweise auf eine verwaltete Sicherheitsgruppe aus externen Sicherheitsgruppenregeln verwiesen haben und vergessen, diesen Verweis zu entfernen, bevor Sie EKS Auto Mode für einen Cluster deaktivieren, wird die verwaltete Sicherheitsgruppe verloren gehen (nicht gelöscht). Die folgenden Schritte beschreiben, wie Sie eine verloren gegangene Sicherheitsgruppe entfernen, falls dies passieren sollte.
## Deaktivieren Sie den EKS-Automatikmodus (AWS Konsole)
1. Öffnen Sie Ihre Cluster-Übersichtsseite in der AWS-Managementkonsole.
1. Wählen Sie unter **EKS Auto Mode** die Option **Verwalten** aus.
1. Schalten Sie **EKS Auto Mode** auf `off` um.
Wenn eine verwaltete Sicherheitsgruppe am Ende dieses Vorgangs nicht gelöscht wird, können Sie sie mithilfe der Beschreibungen unter [Sicherheitsgruppe löschen](https://docs.aws.amazon.com/vpc/latest/userguide/deleting-security-groups.html) manuell löschen.
## Deaktivieren Sie den EKS-Automatikmodus (AWS CLI)
Verwenden Sie den folgenden Befehl, um EKS Auto Mode in einem vorhandenen Cluster zu deaktivieren.
Sie müssen die `aws`-CLI installiert haben und mit ausreichenden Berechtigungen angemeldet sein, um EKS-Cluster zu verwalten. Weitere Informationen finden Sie unter [Einrichtung zur Verwendung von Amazon EKS](setting-up.md).
**Anmerkung**
Die Funktionen für Rechenleistung, Blockspeicher und Lastenausgleich müssen alle in derselben Anfrage aktiviert oder deaktiviert werden.
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=false \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": false}}' \
--storage-config '{"blockStorage":{"enabled": false}}'
```
Sie können wie folgt überprüfen, ob eine verloren gegangene Sicherheitsgruppe in EKS Auto Mode nach der Deaktivierung von EKS Auto Mode gelöscht werden konnte:
```
aws ec2 describe-security-groups \
--filters Name=tag:eks:eks-cluster-name,Values= Name=tag-key,Values=ingress.eks.amazonaws.com/resource,service.eks.amazonaws.com/resource --query "SecurityGroups[*].[GroupName]"
```
So löschen Sie die Sicherheitsgruppe:
```
aws ec2 delete-security-group --group-name=
```
# Aktualisierung der Kubernetes-Version eines Clusters in EKS Auto Mode
In diesem Thema wird erläutert, wie Sie die Kubernetes-Version Ihres Clusters im Automatikmodus aktualisieren können. Der Automatikmodus vereinfacht den Prozess der Versionsaktualisierung, indem er die Koordination der Aktualisierungen der Steuerebene mit dem Austausch von Knoten übernimmt. Gleichzeitig wird die Verfügbarkeit der Workload durch Budgets für Pod-Unterbrechung gewährleistet.
Bei der Aktualisierung eines Clusters im Automatikmodus werden viele Komponenten, die bisher manuell aktualisiert werden mussten, nun als Teil des Services verwaltet. Wenn Sie mit den automatisierten Aspekten des Aktualisierungsprozesses und Ihren Aufgaben vertraut sind, können Sie einen nahtlosen Versionswechsel für Ihren Cluster sicherstellen.
## Weitere Informationen zu Aktualisierungen mit EKS Auto Mode
Nachdem Sie ein Upgrade der Steuerebene initiiert haben, aktualisiert EKS Auto Mode die Knoten in Ihrem Cluster. Wenn Knoten ablaufen, ersetzt EKS Auto Mode diese durch neue Knoten. Die neuen Knoten verfügen über die entsprechende neue Kubernetes-Version. EKS Auto Mode berücksichtigt beim Upgrade von Knoten die Budgets für Pod-Unterbrechung.
Darüber hinaus müssen Sie folgende Komponenten nicht mehr aktualisieren:
+ Amazon VPC CNI
+ AWS-Lastenverteilungs-Controller
+ CoreDNS
+ `kube-proxy`
+ Karpenter
+ AWS-EBS-CSI-Treiber
EKS Auto Mode ersetzt diese Komponenten durch Servicefunktionen.
Sie sind weiterhin für die Aktualisierung verantwortlich:
+ Apps und Workloads, die in Ihrem Cluster bereitgestellt werden
+ Selbstverwaltete Add-Ons und Controller
+ Amazon-EKS-Add-Ons
+ Erfahren Sie, wie Sie [Aktualisierung eines Amazon-EKS-Add-Ons](updating-an-add-on.md)
Erfahren Sie mehr über [Bewährte Methoden für Cluster-Upgrades](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html)
## Cluster-Aktualisierung starten
Informationen zum Starten einer Cluster-Aktualisierung finden Sie unter [Aktualisierung des vorhandenen Clusters auf die neue Kubernetes-Version](update-cluster.md).
# Integriert aktivieren oder deaktivieren NodePools
Der EKS-Automatikmodus verfügt über zwei integrierte Funktionen NodePools. Sie können diese NodePools über die AWS Konsole, CLI oder API aktivieren oder deaktivieren.
## Integrierte NodePool Referenz
+ `system`
+ Das NodePool hat einen `CriticalAddonsOnly` Makel. Viele EKS-Add-Ons, wie beispielsweise CoreDNS, tolerieren diesen Taint. Verwenden Sie diesen System-KnotenPool, um Cluster-kritische Anwendungen zu trennen.
+ Unterstützt sowohl `amd64`- als auch `arm64`-Architekturen.
+ `general-purpose`
+ Dies NodePool bietet Unterstützung für das Starten von Knoten für allgemeine Workloads in Ihrem Cluster.
+ Verwendet nur `amd64`-Architektur.
Beide sind integriert NodePools:
+ Verwenden Sie das Standard-EKS NodeClass
+ Verwenden Sie nur EC2 On-Demand-Kapazität
+ Verwenden Sie die EC2 Instanzfamilien C, M und R
+ EC2 Instances der Generation 5 oder neuer erforderlich
**Anmerkung**
Die Aktivierung von mindestens einer integrierten NodePool Komponente ist erforderlich, damit EKS den „Standard“ bereitstellen kann NodeClass. Wenn Sie alle integrierten Funktionen deaktivieren NodePools, müssen Sie eine benutzerdefinierte Version erstellen NodeClass und eine konfigurieren NodePool , um sie zu verwenden. Weitere Informationen zu finden NodeClasses Sie unter[Knotenklasse für Amazon EKS erstellen](create-node-class.md).
## Verfahren
### Voraussetzungen
+ Die neueste Version der AWS Befehlszeilenschnittstelle (AWS CLI) ist auf Ihrem Gerät installiert und konfiguriert. Um Ihre aktuelle Version zu überprüfen, verwenden Sie `aws --version`. Informationen zur Installation der neuesten Version finden Sie unter [Installation](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) und [Schnellkonfiguration](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config) mit aws configure im Benutzerhandbuch für die AWS Befehlszeilenschnittstelle.
+ Melden Sie sich mit ausreichenden IAM-Berechtigungen bei der CLI an, um AWS Ressourcen wie IAM-Richtlinien, IAM-Rollen und EKS-Cluster zu erstellen.
### Mit AWS CLI aktivieren
Verwenden Sie den folgenden Befehl, um beide integrierten Funktionen zu aktivieren NodePools:
```
aws eks update-cluster-config \
--name \
--compute-config '{
"nodeRoleArn": "",
"nodePools": ["general-purpose", "system"],
"enabled": true
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}
}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
Sie können den Befehl ändern, um den selektiv zu aktivieren. NodePools
### Mit AWS CLI deaktivieren
Verwenden Sie den folgenden Befehl, um beide integrierten Funktionen zu deaktivieren NodePools:
```
aws eks update-cluster-config \
--name \
--compute-config '{
"enabled": true,
"nodePools": []
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
# Überprüfen, ob eine Workload in Knoten von EKS Auto Mode bereitgestellt wird
Bei der Ausführung von Workloads in einem EKS-Cluster mit EKS Auto Mode kann es erforderlich sein, zu steuern, ob bestimmte Workloads in Knoten von EKS Auto Mode oder anderen Rechentypen ausgeführt werden. In diesem Thema wird beschrieben, wie Sie mithilfe von Knoten-Selektoren und Affinitätsregeln sicherstellen können, dass Ihre Workloads in der vorgesehenen Recheninfrastruktur geplant werden.
Die Beispiele in diesem Thema veranschaulichen, wie Sie mithilfe des `eks.amazonaws.com/compute-type`-Labels die Bereitstellung von Workloads auf Knoten in EKS Auto Mode entweder erfordern oder verhindern können. Dies ist besonders nützlich für Cluster im gemischten Modus, in denen sowohl EKS Auto Mode als auch andere Rechentypen ausgeführt werden, beispielsweise selbstverwaltete Karpenter-Bereitsteller oder EKS-verwaltete Knotengruppen.
Knoten von EKS Auto Mode haben den Wert des Labels von `eks.amazonaws.com/compute-type` auf `auto` festgelegt. Mit diesem Label können Sie steuern, ob eine Workload in Knoten bereitgestellt wird, die von EKS Auto Mode verwaltet werden.
## Voraussetzung: Eine Workload muss in Knoten von EKS Auto Mode bereitgestellt sein
**Anmerkung**
Dieser `nodeSelector`-Wert ist für EKS Auto Mode nicht erforderlich. Dieser `nodeSelector`-Wert ist nur relevant, wenn Sie einen Cluster im gemischten Modus ausführen, dessen Knotentypen nicht von EKS Auto Mode verwaltet werden. Beispielsweise können Sie in Ihrem Cluster über EKS-verwaltete Knotengruppen statische Rechenkapazität bereitstellen und über dynamische Rechenkapazität verfügen, die von EKS Auto Mode verwaltet wird.
Sie können diesen `nodeSelector` zu Bereitstellungen oder anderen Workloads hinzufügen, um zu verlangen, dass Kubernetes sie in Knoten von EKS Auto Mode plant.
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
## Voraussetzung: Ein Workload wird nicht in Knoten von EKS Auto Mode bereitgestellt
Sie können diesen `nodeAffinity` zu Bereitstellungen oder anderen Workloads hinzufügen, um zu verlangen, dass Kubernetes sie **nicht** in Knoten von EKS Auto Mode plant.
```
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- auto
```
# Kritische Add-Ons in dedizierten Instances ausführen
In diesem Thema erfahren Sie, wie Sie eine Workload mit einer `CriticalAddonsOnly`-Toleranz bereitstellen, sodass der EKS Auto Mode sie im `system`-Knoten-Pool plant.
Der integrierte `system`-Knoten-Pool des EKS Auto Mode ist für die Ausführung wichtiger Add-Ons in dedizierten Instances konzipiert. Diese Segmentierung stellt sicher, dass wichtige Komponenten über dedizierte Ressourcen verfügen und von allgemeinen Workloads isoliert sind, was die allgemeine Cluster-Stabilität und -Leistung verbessert.
Dieser Leitfaden zeigt, wie Add-Ons mithilfe von `CriticalAddonsOnly`-Toleranz und geeigneten Knotenselektoren im `system`-Knoten-Pool bereitgestellt werden können. Mit diesen Schritten können Sie sicherstellen, dass Ihre kritischen Anwendungen auf den dedizierten `system`-Knoten geplant werden, wobei Sie die Vorteile der Isolierung und Ressourcenzuweisung nutzen, welche die spezielle Knoten-Poolstruktur des EKS Auto Mode bietet.
EKS Auto Mode verfügt über zwei integrierte Knoten-Pools: `general-purpose` und `system`. Weitere Informationen finden Sie unter [Integriert aktivieren oder deaktivieren NodePools](set-builtin-node-pools.md).
Der Zweck des `system`-Knoten-Pools besteht darin, kritische Add-Ons auf verschiedene Knoten zu verteilen. Von dem `system`-Knoten-Pool bereitgestellte Knoten verfügen über einen `CriticalAddonsOnly`-Kubernetes-Taint. Kubernetes plant Pods nur dann auf diesen Knoten ein, wenn sie über eine entsprechende Toleranz verfügen. Weitere Informationen finden Sie unter [Taints und Toleranzen](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) in der Kubernetes-Dokumentation.
## Voraussetzungen
+ Cluster von EKS Auto Mode mit aktiviertem integrierten `system`-Knoten-Pool. Weitere Informationen finden Sie unter [Integriert aktivieren oder deaktivieren NodePools](set-builtin-node-pools.md).
+ `kubectl` installiert und konfiguriert. Weitere Informationen finden Sie unter [Einrichtung zur Verwendung von Amazon EKS](setting-up.md).
## Verfahren
Sehen Sie sich das YAML-Beispiel unten an. Beachten Sie die folgenden Konfigurationen:
+ `nodeSelector` – Dies ordnet die Workload dem integrierten `system`-Knoten-Pool zu. Dieser Knoten-Pool muss über die AWS-API aktiviert werden. Weitere Informationen finden Sie unter [Integriert aktivieren oder deaktivieren NodePools](set-builtin-node-pools.md).
+ `tolerations` – Diese Toleranz überwindet den `CriticalAddonsOnly`-Taint von Knoten im `system`-Knoten-Pool.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample-app
spec:
replicas: 3
selector:
matchLabels:
app: sample-app
template:
metadata:
labels:
app: sample-app
spec:
nodeSelector:
karpenter.sh/nodepool: system
tolerations:
- key: "CriticalAddonsOnly"
operator: "Exists"
containers:
- name: app
image: nginx:latest
resources:
requests:
cpu: "500m"
memory: "512Mi"
```
Zur Aktualisierung einer Workload für die Ausführung im `system`-Knoten-Pool sind folgende Schritte erforderlich:
1. Aktualisieren Sie die vorhandene Workload, um die folgenden oben beschriebenen Konfigurationen hinzuzufügen:
+ `nodeSelector`
+ `tolerations`
1. Die aktualisierte Workload mit `kubectl apply` in Ihrem Cluster bereitstellen
Nach der Aktualisierung der Workload wird diese in dedizierten Knoten ausgeführt.
# Verwendung von Netzwerkrichtlinien mit EKS Auto Mode
## -Übersicht
Da Kunden ihre Anwendungsumgebungen mithilfe von EKS skalieren, wird die Isolierung des Netzwerkverkehrs immer wichtiger, um unbefugten Zugriff auf Ressourcen innerhalb und außerhalb des Clusters zu verhindern. Dies ist besonders wichtig in einer Umgebung mit mehreren Mandanten, in der mehrere voneinander unabhängige Workloads nebeneinander im Cluster ausgeführt werden. Mit Kubernetes-Netzwerkrichtlinien können Sie die Netzwerksicherheit für Ihre Kubernetes-Workloads und deren Integrationen mit clusterexternen Endpunkten verbessern. Der automatische Modus von EKS unterstützt verschiedene Arten von Netzwerkrichtlinien.
### Isolierung der Schichten 3 und 4
Standard-Kubernetes-Netzwerkrichtlinien arbeiten auf den Ebenen 3 und 4 des OSI-Netzwerkmodells und ermöglichen es Ihnen, den Verkehrsfluss auf IP-Adresse- oder Portebene innerhalb Ihres Amazon EKS-Clusters zu steuern.
#### Anwendungsfälle
+ Segmentieren Sie den Netzwerkverkehr zwischen Workloads, um sicherzustellen, dass nur verwandte Anwendungen miteinander kommunizieren können.
+ Isolieren Sie Mandanten auf Namespace-Ebene mithilfe von Richtlinien, um die Netzwerktrennung durchzusetzen.
### DNS-basierte Durchsetzung
Kunden stellen in der Regel Workloads in EKS bereit, die Teil einer breiteren verteilten Umgebung sind, von denen einige mit Systemen und Diensten außerhalb des Clusters kommunizieren müssen (Northbound-Verkehr). Diese Systeme und Dienste können sich in der AWS Cloud oder ganz außerhalb befinden AWS . Mit DNS-basierten Richtlinien (Domain Name System) können Sie Ihre Sicherheitslage verbessern, indem Sie einen stabileren und vorhersehbareren Ansatz verfolgen, um unbefugten Zugriff von Pods auf clusterexterne Ressourcen oder Endpunkte zu verhindern. Durch diesen Mechanismus ist es nicht mehr erforderlich, bestimmte IP-Adressen manuell zu verfolgen und aufzulisten. Durch die Sicherung von Ressourcen mit einem DNS-basierten Ansatz haben Sie auch mehr Flexibilität bei der Aktualisierung der externen Infrastruktur, ohne dass Sie Ihre Sicherheitslage lockern oder die Netzwerkrichtlinien ändern müssen, wenn sich Änderungen an vorgelagerten Servern und Hosts ergeben. Sie können ausgehenden Datenverkehr zu externen Endpunkten entweder mithilfe eines vollqualifizierten Domänennamens (FQDN) oder eines passenden Musters für einen DNS-Domainnamen filtern. Dies bietet Ihnen die zusätzliche Flexibilität, den Zugriff auf mehrere Subdomänen zu erweitern, die einem bestimmten externen Cluster-Endpunkt zugeordnet sind.
#### Anwendungsfälle
+ Verwenden Sie standardmäßig einen DNS-basierten Ansatz zur Filterung des Zugriffs von einer Kubernetes-Umgebung auf clusterexterne Endpunkte.
+ Sicherer Zugriff auf Dienste in einer Umgebung mit mehreren Mandanten. AWS
+ Verwalten Sie den Netzwerkzugriff von Pods bis hin zu lokalen Workloads in Ihren Hybrid-Cloud-Umgebungen.
### Administratorregeln (oder Clusterregeln)
In einigen Fällen, z. B. bei Mehrmandanten-Szenarien, müssen Kunden möglicherweise einen Netzwerksicherheitsstandard durchsetzen, der für den gesamten Cluster gilt. Anstatt wiederholt eine eigene Richtlinie für jeden Namespace zu definieren und zu verwalten, können Sie eine einzige Richtlinie verwenden, um die Netzwerkzugriffskontrollen für verschiedene Workloads im Cluster unabhängig von ihrem Namespace zentral zu verwalten. Mit diesen Richtlinientypen können Sie den Umfang der Durchsetzung Ihrer Netzwerkfilterregeln, die auf Ebene 3, Schicht 4 und bei der Verwendung von DNS-Regeln angewendet werden, erweitern.
#### Anwendungsfälle
+ Verwalten Sie die Netzwerkzugriffskontrollen für alle (oder eine Teilmenge von) Workloads in Ihrem EKS-Cluster zentral.
+ Definieren Sie einen standardmäßigen Netzwerksicherheitsstatus für den gesamten Cluster.
+ Erweitern Sie die organisatorischen Sicherheitsstandards auf betrieblich effizientere Weise auf den gesamten Clusterbereich.
## Erste Schritte
### Voraussetzungen
+ Ein Amazon-EKS-Cluster mit aktiviertem EKS Auto Mode
+ Kubectl für die Verbindung mit Ihrem Cluster konfiguriert
### Schritt 1: Netzwerkrichtlinien-Controller aktivieren
Um Netzwerkrichtlinien mit dem automatischen EKS-Modus verwenden zu können, müssen Sie zunächst den Network Policy Controller aktivieren, indem Sie a ConfigMap auf Ihren Cluster anwenden.
1. Erstellen Sie eine Datei mit dem Namen `enable-network-policy.yaml` und dem folgenden Inhalt:
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-network-policy-controller: "true"
```
1. Wenden Sie das ConfigMap auf Ihren Cluster an:
```
kubectl apply -f enable-network-policy.yaml
```
### Schritt 2: Netzwerkrichtlinien erstellen und testen
Ihr EKS-Auto-Mode-Cluster ist nun für den Support von Kubernetes-Netzwerkrichtlinien konfiguriert. Sie können dies mit [Stars-Demo der Netzwerkrichtlinie für Amazon EKS](network-policy-stars-demo.md) testen.
### Schritt 3: Passen Sie die Konfiguration des Network Policy Agents in der Knotenklasse an (optional)
Sie können optional eine neue Knotenklasse erstellen, um das Standardverhalten des Network Policy Agent auf den Knoten zu ändern oder die Protokollierung von Netzwerkrichtlinienereignissen zu aktivieren. Führen Sie dazu die folgenden Schritte aus:
1. Erstellen oder bearbeiten Sie eine Knotenklassen-YAML-Datei (z. B. `nodeclass-network-policy.yaml`) mit dem folgenden Inhalt:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: network-policy-config
spec:
# Optional: Changes default network policy behavior
networkPolicy: DefaultAllow
# Optional: Enables logging for network policy events
networkPolicyEventLogs: Enabled
# Include other Node Class configurations as needed
```
1. Wenden Sie die Knotenklassen-Konfiguration auf Ihren Cluster an:
```
kubectl apply -f nodeclass-network-policy.yaml
```
1. Überprüfen Sie, ob die Knotenklasse erstellt wurde:
```
kubectl get nodeclass network-policy-config
```
1. Aktualisieren Sie Ihren Knoten-Pool, um diese Knotenklasse zu verwenden. Weitere Informationen finden Sie unter [Einen Knotenpool für EKS Auto Mode erstellen](create-node-pool.md).
## Funktionsweise
### DNS-basierte Netzwerkrichtlinie
![\[Veranschaulichung des Workflows, wenn eine DNS-basierte Richtlinie in EKS Auto angewendet wird\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/apply-dns-policy-1.png)
![\[Abbildung des Workflows, wenn eine DNS-basierte Richtlinie in EKS Auto angewendet wird\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/apply-dns-policy-2.png)
1. Das Plattformteam wendet eine DNS-basierte Richtlinie auf den EKS-Cluster an.
1. Der Network Policy Controller ist dafür verantwortlich, die Erstellung von Richtlinien innerhalb des Clusters zu überwachen und anschließend die Richtlinienendpunkte abzustimmen. In diesem Anwendungsfall weist der Netzwerkrichtlinien-Controller den Node-Agent an, DNS-Anfragen auf der Grundlage der Domänen zu filtern, die in der erstellten Richtlinie zugelassen sind. Domänennamen werden mithilfe des FQDN oder eines Domainnamens, der einem in der Kubernetes-Ressourcenkonfiguration definierten Muster entspricht, auf die Zulassungsliste gesetzt.
1. Workload A versucht, die IP für einen clusterexternen Endpunkt aufzulösen. Die DNS-Anfrage durchläuft zunächst einen Proxy, der solche Anfragen anhand der Zulassungsliste filtert, die in der Netzwerkrichtlinie angewendet wurde.
1. Sobald die DNS-Anfrage die Zulassungsliste des DNS-Filters durchlaufen hat, wird sie an CoreDNS weitergeleitet.
1. CoreDNS wiederum sendet die Anfrage an den externen DNS-Resolver (Amazon Route 53 Resolver), um die Liste der IP-Adressen hinter dem Domainnamen abzurufen.
1. Die IPs mit TTL aufgelösten Daten werden in der Antwort auf die DNS-Anfrage zurückgegeben. Diese IPs werden dann in eine eBPF-Map geschrieben, die im nächsten Schritt für die Durchsetzung der IP-Schicht verwendet wird.
1. Die an die Pod-Veth-Schnittstelle angeschlossenen eBPF-Sonden filtern dann den ausgehenden Datenverkehr von Workload A zum clusterexternen Endpunkt auf der Grundlage der geltenden Regeln. Dadurch wird sichergestellt, dass Pods nur clusterexternen Datenverkehr an die aufgelisteten Domänen senden können. IPs Ihre Gültigkeit IPs basiert auf der TTL, die vom externen DNS-Resolver (Amazon Route 53 Resolver) abgerufen wurde.
#### Verwendung der Anwendungsnetzwerkrichtlinie
Die `ApplicationNetworkPolicy` kombiniert die Funktionen von Standard-Kubernetes-Netzwerkrichtlinien mit DNS-basierter Filterung auf Namespace-Ebene unter Verwendung einer einzigen Custom Resource Definition (CRD). Daher `ApplicationNetworkPolicy` kann der verwendet werden für:
1. Definition von Einschränkungen auf den Ebenen 3 und 4 des Netzwerkstapels mithilfe von IP-Blöcken und Portnummern.
1. Definition von Regeln, die auf Schicht 7 des Netzwerkstapels angewendet werden, und ermöglichen es Ihnen, den Datenverkehr anhand dieser Kriterien zu filtern FQDNs.
**Wichtig**
DNS-basierte Regeln, die mithilfe von definiert wurden, `ApplicationNetworkPolicy` gelten nur für Workloads, die in EC2-Instances ausgeführt werden, die im EKS Auto Mode gestartet wurden. `ApplicationNetworkPolicy`unterstützt alle Felder des Standard-Kubernetes mit einem zusätzlichen `NetworkPolicy` FQDN-Filter für Ausgangsregeln.
**Warnung**
Verwenden Sie nicht denselben Namen für ein `ApplicationNetworkPolicy` und a `NetworkPolicy` innerhalb desselben Namespace. Wenn die Namen kollidieren, spiegeln die resultierenden `PolicyEndpoints` Objekte möglicherweise keine der beiden Richtlinien korrekt wider. Beide Ressourcen werden ohne Fehler akzeptiert, sodass dieses Problem nur schwer zu diagnostizieren ist.
Um einen Namenskonflikt zu lösen, benennen Sie entweder die `ApplicationNetworkPolicy` oder die um, `NetworkPolicy` sodass sie innerhalb des Namespaces eindeutig sind, und überprüfen Sie dann, ob die entsprechenden `PolicyEndpoints` Objekte korrekt aktualisiert wurden.
#### Beispiel
Sie haben einen Workload in Ihrem EKS-Auto-Mode-Cluster, der mit einer lokalen Anwendung kommunizieren muss, die sich hinter einem Load Balancer mit einem DNS-Namen befindet. Sie könnten dies mithilfe der folgenden Netzwerkrichtlinie erreichen:
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
name: my-onprem-app-egress
namespace: galaxy
spec:
podSelector:
matchLabels:
role: backend
policyTypes:
- Egress
egress:
- to:
- domainNames:
- "myapp.mydomain.com"
ports:
- protocol: TCP
port: 8080
```
Auf Kubernetes-Netzwerkebene würde dies den Ausgang von allen Pods im „Galaxy“ -Namespace ermöglichen, die mit gekennzeichnet sind, `role: backend` um eine Verbindung zum Domainnamen **myapp.mydomain.com** am TCP-Port 8080 herzustellen. Darüber hinaus müssten Sie die Netzwerkkonnektivität für den ausgehenden Datenverkehr von Ihrer VPC zu Ihrem Unternehmensrechenzentrum einrichten.
![\[Abbildung der Arbeitslast in EKS Automatische Kommunikation mit Anwendungen vor Ort\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/eks-auto-to-on-prem.png)
### Netzwerkrichtlinie für Administratoren (oder Cluster)
![\[Abbildung der Bewertungsreihenfolge für Netzwerkrichtlinien in EKS\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/evaluation-order.png)
#### Verwendung der Cluster-Netzwerkrichtlinie
Bei Verwendung von werden die Richtlinien der Admin-Ebene zuerst bewertet und können nicht außer Kraft gesetzt werden. `ClusterNetworkPolicy` Wenn die Richtlinien auf Admin-Ebene evaluiert wurden, werden die angewendeten Netzwerksegmentierungsregeln anhand der standardmäßigen Namespace-Richtlinien ausgeführt. Dies kann entweder mit oder erreicht werden. `ApplicationNetworkPolicy` `NetworkPolicy` Schließlich werden die Baseline-Tier-Regeln, die die Standard-Netzwerkeinschränkungen für Cluster-Workloads definieren, durchgesetzt. Diese Regeln der Baseline-Stufe **können** bei Bedarf durch die Richtlinien für den Namespace-Bereich außer Kraft gesetzt werden.
#### Beispiel
Sie haben eine Anwendung in Ihrem Cluster, die Sie von anderen Mandanten-Workloads isolieren möchten. Sie können den Clusterverkehr von anderen Namespaces explizit blockieren, um den Netzwerkzugriff auf den sensiblen Workload-Namespace zu verhindern.
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: protect-sensitive-workload
spec:
tier: Admin
priority: 10
subject:
namespaces:
matchLabels:
kubernetes.io/metadata.name: earth
ingress:
- action: Deny
from:
- namespaces:
matchLabels: {} # Match all namespaces.
name: select-all-deny-all
```
## Überlegungen
### Verstehen Sie die Reihenfolge der Richtlinienevaluierung
Die in EKS unterstützten Funktionen für Netzwerkrichtlinien werden in einer bestimmten Reihenfolge bewertet, um ein vorhersehbares und sicheres Datenverkehrsmanagement zu gewährleisten. Daher ist es wichtig, den Bewertungsablauf zu verstehen, um eine effektive Netzwerksicherheit für Ihre Umgebung zu entwickeln.
1. **Richtlinien auf Admin-Ebene (zuerst bewertet)**: ClusterNetworkPolicies Die gesamte Admin-Ebene wird vor allen anderen Richtlinien bewertet. Innerhalb der Admin-Ebene werden Richtlinien in der Reihenfolge ihrer Priorität verarbeitet (Nummer mit der niedrigsten Priorität zuerst). Der Aktionstyp bestimmt, was als Nächstes passiert.
+ **Aktion ablehnen (höchste Priorität)**: Wenn eine Admin-Richtlinie mit der Aktion „Ablehnen“ dem Verkehr entspricht, wird dieser Verkehr sofort blockiert, unabhängig von anderen Richtlinien. Es werden keine weiteren ClusterNetworkPolicy NetworkPolicy OD-Regeln verarbeitet. Dadurch wird sichergestellt, dass unternehmensweite Sicherheitskontrollen nicht durch Richtlinien auf Namespace-Ebene außer Kraft gesetzt werden können.
+ **Aktion zulassen**: Nach der Auswertung der Ablehnungsregeln werden Administratorrichtlinien mit Zulassen-Aktionen in der Reihenfolge ihrer Priorität verarbeitet (die niedrigste Priorität zuerst). Wenn eine Aktion „Zulassen“ zutrifft, wird der Datenverkehr akzeptiert und es findet keine weitere Richtlinienbewertung statt. Diese Richtlinien können auf der Grundlage von Label-Selektoren Zugriff auf mehrere Namespaces gewähren und ermöglichen so eine zentrale Kontrolle darüber, welche Workloads auf bestimmte Ressourcen zugreifen können.
+ **Aktion weiterleiten**: Bei der Weiterleitung von Aktionen in den Richtlinien der Admin-Ebene wird die Entscheidungsfindung an untergeordnete Ebenen delegiert. Wenn der Traffic mit einer Pass-Regel übereinstimmt, werden bei der Evaluierung alle verbleibenden Regeln auf Admin-Ebene für diesen Traffic übersprungen und direkt zur NetworkPolicy Stufe weitergeleitet. Auf diese Weise können Administratoren die Kontrolle über bestimmte Datenverkehrsmuster explizit an Anwendungsteams delegieren. Sie können beispielsweise Pass-Regeln verwenden, um die Verwaltung des Datenverkehrs innerhalb des Namespaces an Namespace-Administratoren zu delegieren und gleichzeitig strenge Kontrollen des externen Zugriffs aufrechtzuerhalten.
1. **Netzwerkrichtlinienebene**: Wenn keine Richtlinie auf Admin-Ebene mit „Verweigern“ oder „Zulassen“ übereinstimmt oder wenn eine Pass-Aktion gefunden wurde, werden als Nächstes Ressourcen mit ApplicationNetworkPolicy Namespace-Bereich und herkömmliche Ressourcen bewertet. NetworkPolicy Diese Richtlinien ermöglichen eine detaillierte Steuerung innerhalb der einzelnen Namespaces und werden von Anwendungsteams verwaltet. Namespace-bezogene Richtlinien können nur restriktiver sein als Admin-Richtlinien. Sie können die Ablehnungsentscheidung einer Admin-Richtlinie nicht außer Kraft setzen, aber sie können den Datenverkehr weiter einschränken, der durch Admin-Richtlinien zugelassen oder weitergeleitet wurde.
1. **Administratorrichtlinien der Baseline-Stufe**: Wenn keine Admin- oder Namespace-bezogenen Richtlinien dem Traffic entsprechen, wird die Baseline-Stufe bewertet. ClusterNetworkPolicies Diese bieten standardmäßige Sicherheitsvorkehrungen, die durch Richtlinien im Namespace-Bereich außer Kraft gesetzt werden können. So können Administratoren unternehmensweite Standardeinstellungen festlegen und den Teams gleichzeitig die Flexibilität geben, sie nach Bedarf anzupassen. Basisrichtlinien werden in der Reihenfolge ihrer Priorität bewertet (niedrigste Priorität zuerst).
1. **Standardverweigerung (wenn keine Richtlinien zutreffen)**: Dieses deny-by-default Verhalten stellt sicher, dass nur explizit zugelassene Verbindungen zugelassen werden, wodurch ein hohes Maß an Sicherheit gewährleistet wird.
### Anwendung des Prinzips der geringsten Rechte
+ **Beginnen Sie mit restriktiven Richtlinien und fügen Sie nach Bedarf schrittweise Berechtigungen hinzu**. Implementieren Sie zunächst deny-by-default Richtlinien auf Clusterebene und fügen Sie dann schrittweise Zulassungsregeln hinzu, wenn Sie legitime Konnektivitätsanforderungen überprüfen. Dieser Ansatz zwingt die Teams, jede externe Verbindung ausdrücklich zu begründen, wodurch eine sicherere und überprüfbarere Umgebung geschaffen wird.
+ **Regelmäßige Überprüfung und Entfernung ungenutzter Richtlinienregeln** — Netzwerkrichtlinien können sich im Laufe der Zeit ansammeln, wenn sich Anwendungen weiterentwickeln, sodass veraltete Regeln zurückbleiben, die Ihre Angriffsfläche unnötig erweitern. Führen Sie einen regelmäßigen Überprüfungsprozess durch, um nicht mehr benötigte Richtlinienregeln zu identifizieren und zu entfernen. So stellen Sie sicher, dass Ihre Sicherheitsvorkehrungen weiterhin streng und durchführbar sind.
+ **Verwenden Sie nach Möglichkeit spezifische Domainnamen statt allgemeiner Muster.** Platzhaltermuster wie z. B. `*.amazonaws.com` bieten zwar Komfort, gewähren aber auch Zugriff auf eine breite Palette von Diensten. Geben Sie, wann immer möglich, genaue Domainnamen an, z. B. `s3.us-west-2.amazonaws.com` um den Zugriff nur auf die spezifischen Dienste zu beschränken, die Ihre Anwendungen benötigen, wodurch das Risiko einer seitlichen Verlagerung verringert wird, wenn eine Arbeitslast beeinträchtigt wird.
### Verwendung von DNS-basierten Richtlinien in EKS
+ DNS-basierte Regeln, die mithilfe von definiert wurden, `ApplicationNetworkPolicy` gelten nur für Workloads, die in EC2-Instances ausgeführt werden, die im automatischen EKS-Modus gestartet wurden. Wenn Sie einen Cluster im gemischten Modus ausführen (der sowohl aus EKS Auto- als auch aus Nicht-EKS Auto-Worker-Knoten besteht), sind Ihre DNS-basierten Regeln nur in den EKS-Workerknoten im automatischen Modus (EC2-verwaltete Instances) wirksam.
### Validierung Ihrer DNS-Richtlinien
+ **Verwenden Sie zum Testen Staging-Cluster, die die Topologie des Produktionsnetzwerks widerspiegeln**. Ihre Staging-Umgebung sollte die Netzwerkarchitektur, die externen Abhängigkeiten und die Konnektivitätsmuster der Produktion replizieren, um genaue Richtlinientests zu gewährleisten. Dazu gehören passende VPC-Konfigurationen, DNS-Auflösungsverhalten und Zugriff auf dieselben externen Dienste, die Ihre Produktions-Workloads benötigen.
+ **Implementieren Sie automatisierte Tests für kritische Netzwerkpfade** — Erstellen Sie automatisierte Tests, die die Konnektivität zu wichtigen externen Diensten als Teil Ihrer CI/CD Pipeline validieren. Mit diesen Tests sollte überprüft werden, ob legitimer Datenverkehr zulässig ist, während nicht autorisierte Verbindungen blockiert werden. Auf diese Weise wird kontinuierlich überprüft, ob Ihre Netzwerkrichtlinien bei der Weiterentwicklung Ihrer Infrastruktur den richtigen Sicherheitsstatus beibehalten.
+ **Überwachen Sie das Anwendungsverhalten nach Richtlinienänderungen** — Nach der Implementierung neuer oder geänderter Netzwerkrichtlinien in der Produktion sollten Sie die Anwendungsprotokolle, Fehlerraten und Leistungskennzahlen genau überwachen, um Verbindungsprobleme schnell zu identifizieren. Richten Sie klare Rollback-Verfahren ein, damit Sie Richtlinienänderungen schnell rückgängig machen können, falls sie zu unerwartetem Anwendungsverhalten oder Betriebsunterbrechungen führen.
### Interaktion mit der Amazon Route 53 DNS-Firewall
Die Admin- und Netzwerkrichtlinien von EKS werden zunächst auf Pod-Ebene bewertet, wenn der Datenverkehr initiiert wird. Wenn eine EKS-Netzwerkrichtlinie den Ausgang zu einer bestimmten Domäne zulässt, führt der Pod dann eine DNS-Abfrage durch, die den Route 53 53-Resolver erreicht. Zu diesem Zeitpunkt werden die DNS-Firewallregeln für Route 53 ausgewertet. Wenn die DNS-Firewall die Domänenabfrage blockiert, schlägt die DNS-Auflösung fehl und die Verbindung kann nicht hergestellt werden, obwohl die EKS-Netzwerkrichtlinie dies zulässt. Dadurch entstehen ergänzende Sicherheitsebenen: Die DNS-basierten Netzwerkrichtlinien von EKS bieten Ausgangskontrolle auf Pod-Ebene für anwendungsspezifische Zugriffsanforderungen und mehrinstanzenfähige Sicherheitsgrenzen, während die DNS-Firewall VPC-weiten Schutz vor bekannten bösartigen Domänen bietet und unternehmensweite Blocklisten durchsetzt.
# Kennzeichnung von Subnetzen für EKS Auto Mode
Wenn Sie die Lastausgleichsfunktion von EKS Auto Mode verwenden, müssen Sie Ihren VPC-Subnetzen AWS Tags hinzufügen.
## Hintergrund
Diese Tags kennzeichnen Subnetze als mit dem Cluster verbunden und, noch wichtiger, sie geben an, ob es sich um ein öffentliches oder privates Subnetz handelt.
Öffentliche Subnetze verfügen über einen direkten Internetzugang über ein Internet-Gateway. Sie werden für Ressourcen verwendet, die öffentlich zugänglich sein müssen, wie beispielsweise Load Balancer.
Private Subnetze verfügen über keinen direkten Internetzugang und verwenden NAT-Gateways für ausgehenden Datenverkehr. Sie werden für interne Ressourcen wie EKS-Knoten verwendet, die keine öffentlichen Ressourcen benötigen. IPs
Weitere Informationen zu NAT-Gateways und Internet-Gateways finden Sie unter [Verbinden Ihrer VPC mit anderen Netzwerken](https://docs.aws.amazon.com/vpc/latest/userguide/extend-intro.html) im Benutzerhandbuch zu Amazon Virtual Private Cloud (VPC).
## Anforderung
Derzeit müssen Subnetze, die für den Lastausgleich im EKS Auto Mode verwendet werden, über eines der folgenden Tags verfügen.
### Öffentliche Subnetze
Öffentliche Subnetze werden für Load Balancer mit Internetverbindung verwendet. Diese Subnetze müssen die folgenden Tags aufweisen:
| Key (Schlüssel) | Value (Wert) |
| --- | --- |
| `kubernetes.io/role/elb` | `1` oder `` |
### Private Subnetze
Private Subnetze werden für interne Load Balancer verwendet. Diese Subnetze müssen die folgenden Tags aufweisen:
| Key (Schlüssel) | Value (Wert) |
| --- | --- |
| `kubernetes.io/role/internal-elb` | `1` oder `` |
## Verfahren
Ermitteln Sie zunächst, welche Subnetze öffentlich sind (mit Internetzugang) und welche privat sind (mit NAT-Gateway). Sie benötigen Berechtigungen, um VPC-Ressourcen zu ändern.
### AWS-Managementkonsole
1. Öffnen Sie die Amazon VPC-Konsole und navigieren Sie zu **Subnetze**.
1. Wählen Sie das Subnetz aus, das Sie kennzeichnen möchten.
1. Wählen Sie die Registerkarte „**Tags**“ und dann „**Tag hinzufügen**“.
1. Das entsprechende Tag hinzufügen:
+ Für öffentliche Subnetze: Schlüssel = `kubernetes.io/role/elb`
+ Für private Subnetze: Schlüssel = `kubernetes.io/role/internal-elb`
1. Legen Sie **Wert** auf fest `1` oder lassen Sie das Feld leer.
1. Speichern Sie und wiederholen Sie den Vorgang für die verbleibenden Subnetze.
### AWS CLI
Für öffentliche Subnetze:
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/elb,Value=1
```
Für private Subnetze:
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/internal-elb,Value=1
```
Ersetzen Sie `subnet-ID` durch Ihre tatsächliche Subnetz-ID.
# CIS-Compliance-Berichte aus Kubernetes-Knoten mithilfe von kubectl debug generieren
In diesem Thema wird beschrieben, wie Sie mithilfe des `kubectl debug`-Befehls CIS-Konformitätsberichte (Center for Internet Security) für Amazon-EKS-Knoten generieren können. Mit diesem Befehl können Sie vorübergehend einen Debugging-Container in einem Kubernetes-Knoten erstellen und CIS-Konformitätsprüfungen mit dem `apiclient`-Tool durchführen. Das `apiclient`-Tool ist Teil von Bottlerocket OS, dem Betriebssystem, das von Knoten in EKS Auto Mode verwendet wird.
## Voraussetzungen
Stellen Sie vor Beginn sicher, dass Sie über Folgendes verfügen:
+ Zugriff auf einen Amazon-EKS-Cluster mit konfiguriertem `kubectl` (Version muss mindestens v1.32.0 sein. `kubectl version` eingeben, um dies zu überprüfen).
+ Die entsprechenden IAM-Berechtigungen zum Debuggen von Knoten.
+ Ein gültiges Profil, das Debugging-Vorgänge zulässt (z. B. `sysadmin`).
Weitere Informationen zur Verwendung von Debugging-Profilen mit `kubectl` finden Sie unter [Debugging eines Pods oder Knotens bei Anwendung eines Profils](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#debugging-profiles) in der Kubernetes-Dokumentation.
## Verfahren
1. Ermitteln Sie die AWS Instanz-ID des Knotens, auf dem Sie den Bericht ausführen möchten. Verwenden Sie den folgenden Befehl, um die Knoten im Cluster aufzulisten. Die Instance-ID befindet sich in der Spalte „Name“ und beginnt mit `i-`:
```
kubectl get nodes
```
```
NAME STATUS ROLES AGE VERSION
i-0ea0ba0f8ef9ad609 Ready 62s v1.30.10-eks-1a9dacd
```
1. Führen Sie den folgenden Befehl aus und ersetzen Sie `` durch die Instance-ID des Knotens, den Sie abfragen möchten:
```
kubectl debug node/ -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023 -- bash -c "yum install -q -y util-linux-core; nsenter -t 1 -m apiclient report cis --level 1 --format text"
```
Zu den Komponenten dieses Befehls gehören:
+ `kubectl debug node/` – Erstellt eine Debugging-Sitzung in der angegebenen EC2-Instance-ID.
+ `-it` – Weist ein TTY (Kommandozeilen-Shell) zu und hält die Standardeingabe für die interaktive Nutzung geöffnet.
+ `--profile=sysadmin` – Verwendet das angegebene `kubectl`-Profil mit den entsprechenden Berechtigungen.
+ `--image=public.ecr.aws/amazonlinux/amazonlinux:2023` – Verwendet `amazonlinux:2023` als Container-Image zum Debuggen.
+ `bash -c "…"` – Führt die folgenden Befehle in einer Bash-Shell aus:
+ `yum install -q -y util-linux-core` – Installiert das erforderliche Service-Programmpaket im Hintergrund.
+ `nsenter -t 1 -m` – Führt `nsenter` aus, um in den Namespace des Host-Prozesses (PID 1) zu gelangen.
+ `apiclient report cis --level 1 --format text` – Führt den CIS-Konformitätsbericht auf Ebene 1 mit Textausgabe aus.
1. Überprüfen Sie die Textausgabe des Berichts.
## Auswertung der Ausgabe
Der Befehl generiert einen textbasierten Bericht, der den Konformitätsstatus verschiedener CIS-Steuerungen anzeigt. Die Ausgabe enthält:
+ Individuelle CIS-Steuerung IDs
+ Beschreibung jeder Steuerung
+ Status „Bestanden“, „Nicht bestanden“ oder „Übersprungen“ für jede Prüfung
+ Details, die etwaige Compliance-Probleme erklären
Nachfolgend finden Sie ein Beispiel für die Ausgabe des Berichts, der in einer Bottlerocket-Instance ausgeführt wurde:
```
Benchmark name: CIS Bottlerocket Benchmark
Version: v1.0.0
Reference: https://www.cisecurity.org/benchmark/bottlerocket
Benchmark level: 1
Start time: 2025-04-11T01:40:39.055623436Z
[SKIP] 1.2.1 Ensure software update repositories are configured (Manual)
[PASS] 1.3.1 Ensure dm-verity is configured (Automatic)[PASS] 1.4.1 Ensure setuid programs do not create core dumps (Automatic)
[PASS] 1.4.2 Ensure address space layout randomization (ASLR) is enabled (Automatic)
[PASS] 1.4.3 Ensure unprivileged eBPF is disabled (Automatic)
[PASS] 1.5.1 Ensure SELinux is configured (Automatic)
[SKIP] 1.6 Ensure updates, patches, and additional security software are installed (Manual)
[PASS] 2.1.1.1 Ensure chrony is configured (Automatic)
[PASS] 3.2.5 Ensure broadcast ICMP requests are ignored (Automatic)
[PASS] 3.2.6 Ensure bogus ICMP responses are ignored (Automatic)
[PASS] 3.2.7 Ensure TCP SYN Cookies is enabled (Automatic)
[SKIP] 3.4.1.3 Ensure IPv4 outbound and established connections are configured (Manual)
[SKIP] 3.4.2.3 Ensure IPv6 outbound and established connections are configured (Manual)
[PASS] 4.1.1.1 Ensure journald is configured to write logs to persistent disk (Automatic)
[PASS] 4.1.2 Ensure permissions on journal files are configured (Automatic)
Passed: 11
Failed: 0
Skipped: 4
Total checks: 15
```
Informationen zum Benchmark finden Sie unter [Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) vom Center for Internet Security (CIS).
## Zugehörige Ressourcen
+ [Bottlerocket CIS Benchmark](https://bottlerocket.dev/en/os/1.34.x/api/reporting/cis/) in der Bottlerocket-OS-Dokumentation.
+ [Debugging von ausgeführten Pods](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/) in der Kubernetes-Dokumentation.
+ [Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) vom Center for Internet Security (CIS)
# EBS-Volume-Verschlüsselung mit vom Kunden verwalteten KMS-Schlüsseln für EKS Auto Mode aktivieren
Sie können das flüchtige Root-Volume für Instances in EKS Auto Mode mit einem vom Kunden verwalteten KMS-Schlüssel verschlüsseln.
Amazon EKS Auto Mode verwendet serviceverknüpfte Rollen, um Berechtigungen an andere AWS Services zu delegieren, wenn verschlüsselte EBS-Volumes für Ihre Kubernetes-Cluster verwaltet werden. In diesem Thema wird beschrieben, wie Sie die Schlüsselrichtlinie einrichten, die Sie benötigen, wenn Sie einen vom Kunden verwalteten Schlüssel für die Amazon-EBS-Verschlüsselung mit EKS Auto Mode angeben.
Überlegungen:
+ Der automatische Modus von EKS benötigt keine zusätzliche Autorisierung, um den AWS verwalteten Standardschlüssel zum Schutz der verschlüsselten Volumes in Ihrem Konto zu verwenden.
+ In diesem Thema wird das Verschlüsseln kurzlebiger Volumes, also der Root-Volumes für Instances, behandelt. EC2 Weitere Informationen zur Verschlüsselung von für Workloads verwendeten Daten-Volumes finden Sie unter [Erstellen einer Speicherklasse](create-storage-class.md).
## -Übersicht
Die folgenden AWS KMS-Schlüssel können für die Amazon EBS-Root-Volume-Verschlüsselung verwendet werden, wenn EKS Auto Mode Instances startet:
+ ** AWS -verwalteter Schlüssel** – Ein Verschlüsselungsschlüssel in Ihrem Konto, den Amazon EBS erstellt, besitzt und verwaltet. Dies ist der Standardverschlüsselungsschlüssel für ein neues Konto.
+ **Kundenverwalteter Schlüssel** – Ein benutzerdefinierter Verschlüsselungsschlüssel, den Sie erstellen, besitzen und verwalten.
**Anmerkung**
Der Schlüssel muss symmetrisch sein. Amazon EBS unterstützt keine asymmetrischen vom Kunden verwalteten Schlüssel.
## Schritt 1: Schlüsselrichtlinie konfigurieren
Ihre KMS-Schlüssel müssen über eine Schlüsselrichtlinie verfügen, die es EKS Auto Mode ermöglicht, Instances mit Amazon-EBS-Volumes zu starten, die mit einem vom Kunden verwalteten Schlüssel verschlüsselt sind.
Konfigurieren Sie Ihre Schlüsselrichtlinie mit der folgenden Struktur:
**Anmerkung**
Diese Richtlinie umfasst nur Berechtigungen für EKS Auto Mode. Die Schlüsselrichtlinie benötigt möglicherweise zusätzliche Berechtigungen, wenn andere Identitäten den Schlüssel verwenden oder Berechtigungen verwalten müssen.
```
{
"Version":"2012-10-17",
"Id": "MyKeyPolicy",
"Statement": [
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
]
}
```
Stellen Sie sicher, dass Sie es `` durch Ihre tatsächliche AWS Konto-ID ersetzen.
Beim Konfigurieren der Schlüsselrichtlinie:
+ Die `ClusterServiceRole` muss über die erforderlichen IAM-Berechtigungen verfügen, um den KMS-Schlüssel für Verschlüsselungsvorgänge zu verwenden
+ Die `kms:GrantIsForAWSResource` Bedingung stellt sicher, dass Zuschüsse nur für AWS Dienstleistungen gewährt werden können
## Schritt 2: Konfigurieren Sie NodeClass mit Ihrem vom Kunden verwalteten Schlüssel
Nachdem Sie die Schlüsselrichtlinie konfiguriert haben, verweisen Sie in Ihrer NodeClass EKS-Konfiguration für den automatischen Modus auf den KMS-Schlüssel:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Insert existing configuration
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
# KMS key for encryption
kmsKeyID: "arn:aws: kms:::key/"
```
Ersetzen Sie die Platzhalterwerte durch Ihre tatsächlichen Werte:
+ ``mit Ihrer AWS Region
+ ``mit deiner AWS Konto-ID
+ `` mit Ihrer KMS-Schlüssel-ID
Sie können den KMS-Schlüssel in einem der folgenden Formate angeben:
+ KMS-Schlüssel-ID: `1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ KMS-Schlüssel-ARN: ` arn:aws: kms:us-west-2:111122223333:key/1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ Schlüssel-Alias-Name: `alias/eks-auto-mode-key`
+ Schlüssel-Alias-ARN: ` arn:aws: kms:us-west-2:111122223333:alias/eks-auto-mode-key`
Wenden Sie die NodeClass Konfiguration mit kubectl an:
```
kubectl apply -f nodeclass.yaml
```
## Verwandte Ressourcen
+ [Knotenklasse für Amazon EKS erstellen](create-node-class.md)
+ Weitere Informationen finden Sie im AWS Key Management Service Developer Guide
+ [Berechtigungen für AWS Dienste in wichtigen Richtlinien](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-services.html)
+ [Schlüsselrichtlinie ändern](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html)
+ [Zuschüsse in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)
# Organisationssteuerung für EKS Auto Mode aktualisieren
Einige Organisationssteuerungen können die korrekte Funktion von EKS Auto Mode beeinträchtigen. In diesem Fall müssen Sie diese Steuerungen aktualisieren, damit EKS Auto Mode über die erforderlichen Berechtigungen verfügt, um EC2-Instances in Ihrem Namen zu verwalten.
EKS Auto Mode verwendet eine Servicerolle zum Starten der EC2-Instances, welche die Knoten von EKS Auto Mode unterstützen. Eine Servicerolle ist eine [IAM-Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html), die in Ihrem Konto erstellt wird und die ein Service übernimmt, um in Ihrem Namen Aktionen auszuführen. [Dienststeuerungsrichtlinien](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCPs) gelten immer für Aktionen, die mit Servicerollen ausgeführt werden. Dadurch kann ein SCP die Vorgänge im Automatikmodus unterbinden. Am häufigsten kommt es vor, wenn ein SCP verwendet wird, um die Amazon Machine Images (AMIs) einzuschränken, die gestartet werden können. Damit der EKS-Automodus funktioniert, ändern Sie den SCP so, dass der Start AMIs von EKS-Automodus-Konten aus möglich ist.
Sie können auch die AMIs Funktion [EC2 Allowed](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-allowed-amis.html) verwenden, um die Sichtbarkeit von AMIs in anderen Konten einzuschränken. Wenn Sie dieses Feature verwenden, müssen Sie die Image-Kriterien erweitern, um auch die AMI-Konten in EKS Auto Mode in den relevanten Regionen einzubeziehen.
## Beispiel SCP, um alle AMIs außer dem EKS-Automatikmodus zu blockieren AMIs
Die nachfolgende SCP verhindert den Aufruf von `ec2:RunInstances`, es sei denn, die AMI gehört zum AMI-Konto in EKS Auto Mode für us-west-2 oder us-east-1.
**Anmerkung**
Es ist wichtig, den Kontextschlüssel `ec2:Owner` **nicht** zu verwenden. Amazon ist Eigentümer der AMI-Konten in EKS Auto Mode, und der Wert für diesen Schlüssel ist stets `amazon`. Die Konstruktion eines SCP, das den Start ermöglicht, AMIs wenn der `ec2:Owner` IS `amazon` das Starten aller Amazon-eigenen AMI ermöglicht, nicht nur der AMIs für den EKS-Automatikmodus. \$1
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAMI",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:*:ec2:*::image/ami-*",
"Condition": {
"StringNotEquals": {
"aws:ResourceAccount": [
"767397842682",
"992382739861"
]
}
}
}
]
}
```
## AMI-Konten in EKS Auto Mode
AWS Konten, die je nach Region variieren, hosten EKS Auto Mode public AMIs.
| | |
| --- |--- |
| AWS Region | Account |
| af-south-1 | 471112993317 |
| ap-east-1 | 590183728416 |
| ap-east-2 | 381492200852 |
| ap-northeast-1 | 851725346105 |
| ap-northeast-2 | 992382805010 |
| ap-northeast-3 | 891377407544 |
| ap-south-1 | 975049899075 |
| ap-south-2 | 590183737426 |
| ap-southeast-1 | 339712723301 |
| ap-southeast-2 | 058264376476 |
| ap-southeast-3 | 471112941769 |
| ap-southeast-4 | 590183863144 |
| ap-southeast-5 | 654654202513 |
| ap-southeast-6 | 905418310314 |
| ap-southeast-7 | 533267217478 |
| ca-central-1 | 992382439851 |
| ca-west-1 | 767397959864 |
| eu-central-1 | 891376953411 |
| eu-central-2 | 381492036002 |
| eu-north-1 | 339712696471 |
| eu-south-1 | 975049955519 |
| eu-south-2 | 471112620929 |
| eu-west-1 | 381492008532 |
| eu-west-2 | 590184142468 |
| eu-west-3 | 891376969258 |
| il-central-1 | 590183797093 |
| me-central-1 | 637423494195 |
| me-south-1 | 905418070398 |
| mx-central-1 | 211125506622 |
| sa-east-1 | 339712709251 |
| us-east-1 | 992382739861 |
| us-east-2 | 975050179949 |
| us-west-1 | 975050035094 |
| us-west-2 | 767397842682 |
| us-gov-east-1 | 446077414359 |
| us-gov-west-1 | 446098668741 |
## Öffentliche IP-Adresse zuweisen
Wenn `ec2:RunInstances` aufgerufen wird, wird das `AssociatePublicIpAddress`-Feld für einen Instance-Start automatisch durch den Typ des Subnetzes bestimmt, in dem die Instance gestartet wird. Ein SCP kann verwendet werden, um sicherzustellen, dass dieser Wert unabhängig vom Typ des Subnetzes, in dem der Start erfolgt, explizit auf „false“ gesetzt wird. In diesem Fall `spec.advancedNetworking.associatePublicIPAddress` kann das NodeClass Feld auch auf false gesetzt werden, um die Anforderungen des SCP zu erfüllen.
```
{
"Sid": "DenyPublicEC2IPAddesses",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:network-interface/*",
"Condition": {
"BoolIfExists": {
"ec2:AssociatePublicIpAddress": "true"
}
}
}
```
# Steuern Sie die Bereitstellung von Workloads in Kapazitätsreservierungen mit EKS Auto Mode.
Sie können die Bereitstellung von Workloads in [Kapazitätsreservierungen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html) steuern. EKS Auto Mode unterstützt EC2-On-Demand-Kapazitätsreservierungen (ODCRs) und EC2-Kapazitätsblöcke für ML.
**Tipp**
Standardmäßig kann der automatische EKS-Modus ODCRs durch Open-Matching in Open gestartet werden, priorisiert sie jedoch nicht. Instances, die durch Open-Matching gestartet werden, sind gekennzeichnet`karpenter.sh/capacity-type: on-demand`, nicht. `reserved` Um der ODCR-Nutzung Priorität einzuräumen und Instanzen beschriften zu lassen`karpenter.sh/capacity-type: reserved`, konfigurieren Sie dies `capacityReservationSelectorTerms` in der Definition. NodeClass Kapazitätsblöcke für ML sind immer erforderlich `capacityReservationSelectorTerms` und werden nicht automatisch verwendet.
## EC2-Kapazitätsreservierungen auf Abruf () ODCRs
EC2-Kapazitätsreservierungen ermöglichen Ihnen das Reservieren von Datenverarbeitungskapazität für Ihre Amazon-EC2-Instances in einer bestimmten Availability Zone für eine beliebige Dauer. Bei Verwendung von EKS Auto Mode möchten Sie möglicherweise steuern, ob Ihre Kubernetes-Workloads in diesen reservierten Instances bereitgestellt werden, um die Auslastung der im Voraus erworbenen Kapazität zu maximieren oder um sicherzustellen, dass wichtige Workloads Zugriff auf garantierte Ressourcen haben.
Standardmäßig wird der EKS-Automatikmodus automatisch geöffnet ODCRs. Durch die Konfiguration `capacityReservationSelectorTerms` auf a können Sie NodeClass jedoch explizit steuern, welche ODCRs Workloads verwendet werden. Knoten, die mithilfe von configured bereitgestellt wurden, haben ODCRs Vorrang vor On-Demand-Nodes `karpenter.sh/capacity-type: reserved` und Spot-Nodes und haben auch weiterhin Priorität. Sobald diese Funktion aktiviert ist, verwendet der automatische EKS-Modus nicht mehr automatisch die Option „Öffnen“ ODCRs. Sie müssen explizit durch ein ausgewählt werden NodeClass, sodass Sie die Kapazitätsreservierungsnutzung in Ihrem gesamten Cluster genau steuern können.
**Warnung**
Wenn Sie NodeClass in `capacityReservationSelectorTerms` einem Cluster eine Konfiguration vornehmen, verwendet EKS Auto Mode nicht mehr automatisch open ODCRs für *alle* NodeClass im Cluster.
### Beispiel NodeClass
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
spec:
# Optional: Selects upon on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
app: "my-app"
# Optional owning account ID filter
owner: "012345678901"
```
Dieses Beispiel NodeClass zeigt zwei Ansätze für die Auswahl ODCRs. Die erste Methode verweist direkt über die ID (`cr-56fac701cc1951b03`) auf einen bestimmten ODCR. Die zweite Methode verwendet eine Tag-basierte Auswahl, ODCRs wobei das Targeting anhand des Tags `Name: "targeted-odcr"` erfolgt. Sie können optional auch nach dem AWS Konto filtern, dem die Reservierung gehört. Dies ist besonders nützlich in kontoübergreifenden Szenarien oder bei der Arbeit mit Reservierungen für gemeinsame Kapazitäten.
## EC2-Kapazitätsblöcke für ML
Kapazitätsblöcke für ML reservieren GPU-basierte beschleunigte Rechen-Instances für einen zukünftigen Zeitpunkt, um Ihre kurzfristigen Machine-Learning-Workloads (ML) zu unterstützen. Instances, die innerhalb eines Kapazitätsblocks ausgeführt werden, werden in Amazon EC2 automatisch nahe beieinander platziert UltraClusters, um blockierungsfreie Netzwerke im Petabit-Bereich mit niedriger Latenz zu gewährleisten.
Weitere Informationen zu den unterstützten Plattformen und Instance-Typen finden Sie unter [Kapazitätsblöcke für ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) im EC2-Benutzerhandbuch.
Sie können einen automatischen EKS-Modus erstellen NodeClass , der einen Kapazitätsblock für ML verwendet, ähnlich einem ODCR (weiter oben beschrieben).
Die folgenden Beispieldefinitionen erstellen drei Ressourcen:
1. A NodeClass , das auf Ihre Kapazitätsblock-Reservierung verweist
1. Eine NodePool , die den NodeClass und verwendet, verleiht ihm einen Makel
1. Eine Pod-Spezifikation, die den Taint toleriert und GPU-Ressourcen anfordert
### Beispiel NodeClass
Dies NodeClass verweist anhand seiner Reservierungs-ID auf einen bestimmten Kapazitätsblock für ML. Sie können diese ID über die EC2-Konsole abrufen.
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
# Specify your Capacity Block reservation ID
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
```
Weitere Informationen finden Sie unter [Knotenklasse für Amazon EKS erstellen](create-node-class.md).
### Beispiel NodePool
Dies NodePool verweist auf die `gpu` NodeClass und spezifiziert eine wichtige Konfiguration:
+ Er nutzt **auschliesslich** reservierte Kapazität, indem er `karpenter.sh/capacity-type: reserved` festlegt
+ Es werden bestimmte GPU-Instance-Familien angefordert, die für ML-Workloads geeignet sind
+ Es wird ein `nvidia.com/gpu` Taint angewendet, um sicherzustellen, dass nur GPU-Workloads auf diesen Knoten geplant werden
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: gpu
requirements:
- key: eks.amazonaws.com/instance-family
operator: In
values:
- g6
- p4d
- p4de
- p5
- p5e
- p5en
- p6
- p6-b200
- key: karpenter.sh/capacity-type
operator: In
values:
- reserved
# Enable other capacity types
# - on-demand
# - spot
taints:
- effect: NoSchedule
key: nvidia.com/gpu
```
Weitere Informationen finden Sie unter [Einen Knotenpool für EKS Auto Mode erstellen](create-node-pool.md).
### Beispiel Pod
Dieses Beispiel-Pod veranschaulicht, wie Sie eine Workload für die Ausführung in Ihren Kapazitätsblock-Knoten konfigurieren:
+ Es verwendet einen **NodeSelector**, um auf bestimmte GPU-Typen abzuzielen (in diesem Fall H200) GPUs
+ Es beinhaltet eine **Toleranz für den Makel, der durch** den `nvidia.com/gpu` NodePool
+ Es fordert **explizit GPU-Ressourcen** unter Verwendung des `nvidia.com/gpu`-Ressourcentyps an
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
# Select specific GPU type - uncomment as needed
# eks.amazonaws.com/instance-gpu-name: l4
# eks.amazonaws.com/instance-gpu-name: a100
eks.amazonaws.com/instance-gpu-name: h200
# eks.amazonaws.com/instance-gpu-name: b200
eks.amazonaws.com/compute-type: auto
restartPolicy: OnFailure
containers:
- name: nvidia-smi
image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
args:
- "nvidia-smi"
resources:
requests:
# Uncomment if needed
# memory: "30Gi"
# cpu: "3500m"
nvidia.com/gpu: 1
limits:
# Uncomment if needed
# memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
Weitere Informationen finden Sie unter [Dry run](https://kubernetes.io/docs/concepts/workloads/pods/) in der Kubernetes-Dokumentation.
### Verwandte Ressourcen
+ [Kapazitätsblöcke für ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) im Benutzerhandbuch für Amazon-EC2
+ [Kapazitätsblöcke suchen und erwerben](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-purchase.html) im Benutzerhandbuch für Amazon-EC2
+ [Rechenressourcen für AI/ML Workloads auf Amazon EKS verwalten](https://docs.aws.amazon.com/eks/latest/userguide/ml-compute-management.html)
+ [GPU-Ressourcenoptimierung und Kostenmanagement](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html#_gpu_resource_optimization_and_cost_management) im EKS-Leitfaden für bewährte Verfahren
# Stellen Sie EKS-Automodus-Knoten in Local Zones bereit
Der automatische Modus von EKS bietet eine vereinfachte Clusterverwaltung mit automatischer Knotenbereitstellung. AWS Local Zones erweitern die AWS Infrastruktur auf geografische Standorte, die näher an Ihren Endbenutzern liegen, und reduzieren so die Latenz für latenzempfindliche Anwendungen. Dieses Handbuch führt Sie durch den Prozess der Bereitstellung von EKS-Automodus-Knoten in AWS Local Zones, sodass Sie containerisierte Anwendungen mit geringerer Latenz für Benutzer in bestimmten geografischen Gebieten ausführen können.
In diesem Leitfaden wird auch gezeigt, wie Sie mithilfe von Kubernetes-Taints and Tolerations sicherstellen können, dass nur bestimmte Workloads auf Ihren Local-Zone-Knoten ausgeführt werden. So können Sie die Kosten kontrollieren und die Ressourcennutzung optimieren.
## Voraussetzungen
Bevor Sie mit der Bereitstellung von EKS-Automodus-Knoten in Local Zones beginnen, stellen Sie sicher, dass die folgenden Voraussetzungen erfüllt sind:
+ [Ein vorhandener EKS-Auto-Mode-Cluster](create-auto.md)
+ [Sie haben sich in Ihrem Konto für die lokale Zone angemeldet AWS](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-find-local-zone)
## Schritt 1: Subnetz für die lokale Zone erstellen
Der erste Schritt bei der Bereitstellung von EKS-Automodus-Knoten in einer lokalen Zone besteht darin, ein Subnetz in dieser lokalen Zone zu erstellen. Dieses Subnetz stellt die Netzwerkinfrastruktur für Ihre Knoten bereit und ermöglicht ihnen, mit dem Rest Ihrer VPC zu kommunizieren. Folgen Sie den Anweisungen zum [Erstellen eines Subnetzes für eine lokale Zone](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-create-local-zone-subnet) (im Benutzerhandbuch für AWS Local Zones), um ein Subnetz in der von Ihnen ausgewählten lokalen Zone zu erstellen.
**Tipp**
Notieren Sie sich den Namen Ihres lokalen Zonen-Subnetzes.
## Schritt 2: Erstellen Sie das NodeClass Subnetz für die lokale Zone
Nachdem Sie Ihr Subnetz für die lokale Zone erstellt haben, müssen Sie ein Subnetz definieren, NodeClass das auf dieses Subnetz verweist. Das NodeClass ist eine benutzerdefinierte Kubernetes-Ressource, die die Infrastrukturattribute für Ihre Knoten spezifiziert, einschließlich der zu verwendenden Subnetze, Sicherheitsgruppen und Speicherkonfigurationen. Im folgenden Beispiel erstellen wir eine NodeClass sogenannte „lokale Zone“, die anhand ihres Namens auf ein Subnetz der lokalen Zone abzielt. Sie können auch die Subnetz-ID verwenden. Sie müssen diese Konfiguration an Ihr lokales Zonen-Subnetz anpassen.
Weitere Informationen finden Sie unter [Knotenklasse für Amazon EKS erstellen](create-node-class.md).
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: local-zone
spec:
subnetSelectorTerms:
- id:
```
## Schritt 3: Create NodePool with NodeClass und Taint
Nachdem Sie es NodeClass konfiguriert haben, müssen Sie jetzt eine erstellen NodePool , die dies NodeClass verwendet. A NodePool definiert die Recheneigenschaften Ihrer Knoten, einschließlich der Instanztypen. Der NodePool verwendet das NodeClass als Referenz, um zu bestimmen, wo Instances gestartet werden sollen.
Im folgenden Beispiel erstellen wir eine, NodePool die auf unsere „lokale Zone“ verweist. NodeClass Außerdem fügen wir den Knoten einen Tain hinzu, um sicherzustellen, dass nur Pods mit einer entsprechenden Toleranz auf diesen Local-Zone-Knoten geplant werden können. Dies ist besonders wichtig für Knoten in der lokalen Zone, die in der Regel höhere Kosten verursachen und nur von Workloads verwendet werden sollten, die speziell von der reduzierten Latenz profitieren.
Weitere Informationen finden Sie unter [Einen Knotenpool für EKS Auto Mode erstellen](create-node-pool.md).
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
node-type: local-zone
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: local-zone
taints:
- key: "aws.amazon.com/local-zone"
value: "true"
effect: NoSchedule
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
```
Der Nachteil von Schlüssel `aws.amazon.com/local-zone` und Effekt `NoSchedule` stellt sicher, dass Pods ohne entsprechende Toleranzen nicht auf diesen Knoten eingeplant werden. Dadurch wird verhindert, dass reguläre Workloads versehentlich in der lokalen Zone ausgeführt werden, was zu unerwarteten Kosten führen könnte.
## Schritt 4: Stellen Sie Workloads mit Toleranz und Knotenaffinität bereit
Für eine optimale Kontrolle der Workload-Platzierung auf Knoten in der lokalen Zone sollten Sie beide taints/tolerations und die Knotenaffinität zusammen verwenden. Dieser kombinierte Ansatz bietet die folgenden Vorteile:
1. **Kostenkontrolle**: Dieser Fehler stellt sicher, dass nur Pods mit ausdrücklichen Toleranzen potenziell teure Local-Zone-Ressourcen nutzen können.
1. **Garantierte Platzierung**: Durch die Knotenaffinität wird sichergestellt, dass Ihre latenzempfindlichen Anwendungen ausschließlich in der lokalen Zone und nicht auf regulären Clusterknoten ausgeführt werden.
Hier ist ein Beispiel für eine Bereitstellung, die speziell für die Ausführung auf Knoten der lokalen Zone konfiguriert wurde:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: low-latency-app
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: low-latency-app
template:
metadata:
labels:
app: low-latency-app
spec:
tolerations:
- key: "aws.amazon.com/local-zone"
operator: "Equal"
value: "true"
effect: "NoSchedule"
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: "node-type"
operator: "In"
values: ["local-zone"]
containers:
- name: application
image: my-low-latency-app:latest
resources:
limits:
cpu: "1"
memory: "1Gi"
requests:
cpu: "500m"
memory: "512Mi"
```
Diese Bereitstellung hat zwei wichtige Planungskonfigurationen:
1. Diese **Toleranz** ermöglicht es, die Pods auf Knoten mit dem `aws.amazon.com/local-zone` Makel zu planen.
1. Die Anforderung an die **Knotenaffinität** stellt sicher, dass diese Pods nur auf Knoten mit dem Label ausgeführt werden. `node-type: local-zone`
Zusammen stellen sie sicher, dass Ihre latenzempfindliche Anwendung nur auf Knoten der lokalen Zone ausgeführt wird und reguläre Anwendungen die Ressourcen der lokalen Zone nicht verbrauchen, sofern sie nicht ausdrücklich dafür konfiguriert wurden.
## Schritt 5: Überprüfen Sie mit der Konsole AWS
Nachdem Sie Ihre NodeClass NodePool, und Bereitstellungen eingerichtet haben, sollten Sie überprüfen, ob die Knoten wie erwartet in Ihrer lokalen Zone bereitgestellt werden und ob Ihre Workloads auf ihnen ausgeführt werden. Sie können die AWS Managementkonsole verwenden, um zu überprüfen, ob EC2 Instances im richtigen Subnetz der lokalen Zone gestartet werden.
Darüber hinaus können Sie anhand `kubectl get nodes -o wide` der Kubernetes-Knotenliste überprüfen, ob die Knoten Ihrem Cluster mit den richtigen Labels und Taints beitreten:
```
kubectl get nodes -o wide
kubectl describe node | grep -A 5 Taints
```
Sie können auch überprüfen, ob Ihre Workload-Pods auf den Knoten der lokalen Zone geplant sind:
```
kubectl get pods -o wide
```
Durch diesen Ansatz wird sichergestellt, dass auf diesen Knoten nur Workloads geplant werden, die den Taint Local Zone speziell tolerieren. Auf diese Weise können Sie die Kosten kontrollieren und die Ressourcen Ihrer lokalen Zone so effizient wie möglich nutzen.
# Erweiterte Sicherheitseinstellungen für Knoten konfigurieren
In diesem Thema wird beschrieben, wie Sie mithilfe der `advancedSecurity` Spezifikation in Ihrer Node Class erweiterte Sicherheitseinstellungen für Amazon EKS Auto Mode-Knoten konfigurieren.
## Voraussetzungen
Stellen Sie vor Beginn sicher, dass Sie über Folgendes verfügen:
+ Ein Cluster in Amazon EKS Auto Mode. Weitere Informationen finden Sie unter [Einen Cluster mit Amazon EKS Auto Mode erstellen](create-auto.md).
+ `kubectl` installiert und konfiguriert. Weitere Informationen finden Sie unter [Einrichtung zur Verwendung von Amazon EKS](setting-up.md).
+ Verständnis der Node Class-Konfiguration. Weitere Informationen finden Sie unter [Knotenklasse für Amazon EKS erstellen](create-node-class.md).
## Konfigurieren Sie erweiterte Sicherheitseinstellungen
Um erweiterte Sicherheitseinstellungen für Ihre Knoten zu konfigurieren, legen Sie die `advancedSecurity` Felder in Ihrer Node Class-Spezifikation fest:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: security-hardened
spec:
role: MyNodeRole
subnetSelectorTerms:
- tags:
Name: "private-subnet"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
advancedSecurity:
# Enable FIPS-compliant AMIs (US regions only)
fips: true
# Configure kernel lockdown mode
kernelLockdown: "integrity"
```
Wenden Sie diese Konfiguration an:
```
kubectl apply -f nodeclass.yaml
```
Verweisen Sie in Ihrer Node-Pool-Konfiguration auf diese Node-Klasse. Weitere Informationen finden Sie unter [Einen Knotenpool für EKS Auto Mode erstellen](create-node-pool.md).
## Beschreibungen der Felder
+ `fips`(boolean, optional): Wenn auf gesetzt`true`, werden Knoten mithilfe von FIPS AMIs 140-2-validierten kryptografischen Modulen bereitgestellt. Mit dieser Einstellung wird FIPS-konform ausgewählt. Kunden sind für die Verwaltung ihrer Compliance-Anforderungen AMIs verantwortlich. [Weitere Informationen finden Sie unter FIPS-Konformität.AWS](https://aws.amazon.com/compliance/fips/) Standard: `false`.
+ `kernelLockdown`(Zeichenfolge, optional): Steuert den Modus des Kernel-Lockdown-Sicherheitsmoduls. Zulässige Werte:
+ `integrity`: Blockiert Methoden zum Überschreiben des Kernelspeichers oder zum Ändern des Kernelcodes. Verhindert das Laden von Kernelmodulen ohne Vorzeichen.
+ `none`: Deaktiviert den Kernel-Lockdown-Schutz.
Weitere Informationen finden Sie in der [Dokumentation zum Lockdown des Linux-Kernels](https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html).
## Überlegungen
+ FIPS-konform AMIs sind in den Regionen AWS USA Ost/West, AWS GovCloud (USA) und AWS Kanada (Zentral/West) verfügbar. [Weitere Informationen finden Sie unter FIPS-Konformität.AWS](https://aws.amazon.com/compliance/fips/)
+ Stellen Sie bei der Verwendung sicher`kernelLockdown: "integrity"`, dass Ihre Workloads nicht das Laden von unsignierten Kernelmodulen oder das Ändern des Kernelspeichers erfordern.
## Zugehörige Ressourcen
+ [Knotenklasse für Amazon EKS erstellen](create-node-class.md)- Vollständiger Leitfaden zur Konfiguration von Node Class
+ [Einen Knotenpool für EKS Auto Mode erstellen](create-node-pool.md)- Konfiguration des Knotenpools