

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

# Knoten mit optimiertem Amazon Linux erstellen AMIs
<a name="eks-optimized-ami"></a>

Amazon Elastic Kubernetes Service (Amazon EKS) bietet spezielle Amazon Machine Images (AMIs), die für die Ausführung von Kubernetes-Worker-Knoten optimiert sind. Diese EKS-optimierten Amazon Linux (AL) AMIs sind mit wichtigen Komponenten wie dem AWS IAM Authenticator und vorkonfiguriert`kubelet`, um eine nahtlose Integration und Sicherheit innerhalb Ihrer `containerd` Cluster zu gewährleisten. In diesem Handbuch werden die verfügbaren AMI-Versionen beschrieben und spezielle Optionen für beschleunigtes Rechnen und ARM-basierte Architekturen beschrieben.

## Überlegungen
<a name="ami-considerations"></a>
+ Sie können Sicherheits- oder Datenschutzereignisse für [Amazon Linux im Amazon-Linux-Sicherheitscenter](https://alas.aws.amazon.com/) verfolgen, indem Sie die Registerkarte für die gewünschte Version auswählen. Sie können auch den entsprechenden RSS-Feed abonnieren. Sicherheits- oder Datenschutzereignisse enthalten eine Übersicht über das Problem, welche Pakete betroffen sind und wie Sie Ihre Instances aktualisieren, um das Problem zu beheben.
+ Bevor Sie ein beschleunigtes AMI oder ein ARM-AMI bereitstellen, lesen Sie die Informationen in [Amazon EKS-optimiertem beschleunigtem Amazon Linux AMIs](#gpu-ami) und. [Amazon EKS-optimierter Arm Amazon Linux AMIs](#arm-ami)
+  EC2 `P2`Amazon-Instances werden auf Amazon EKS nicht unterstützt, da sie `NVIDIA` Treiberversion 470 oder früher benötigen.
+ Alle neu erstellten verwalteten Knotengruppen in Clustern der Version `1.30` oder neuer verwenden automatisch standardmäßig AL2 023 als Knotenbetriebssystem.

## Amazon EKS-optimiertes beschleunigtes Amazon Linux AMIs
<a name="gpu-ami"></a>

Amazon EKS-optimiertes beschleunigtes Amazon Linux (AL) AMIs baut auf dem standardmäßigen EKS-optimierten Amazon Linux auf. AMIs Sie sind so konfiguriert, dass sie als optionale Images für Amazon-EKS-Knoten dienen, um GPU-, [Inferentia](https://aws.amazon.com/machine-learning/inferentia/)- und [Trainium](https://aws.amazon.com/machine-learning/trainium/)-basierte Workloads zu unterstützen.

Weitere Informationen finden Sie unter [Verwenden Sie EKS-optimierte beschleunigte AMIs GPU-Instanzen](ml-eks-optimized-ami.md).

## Amazon EKS-optimierter Arm Amazon Linux AMIs
<a name="arm-ami"></a>

Arm-Instances führen zu deutlichen Kosteneinsparungen für skalierbare und Arm-basierte Anwendungen wie Webserver, Container-Microservices, Zwischenspeicherflotten und verteilte Datenspeicher. Beachten Sie beim Hinzufügen von Arm-Knoten zu Ihrem Cluster die folgenden Überlegungen.
+ Wenn Ihr Cluster vor dem 17. August 2020 bereitgestellt wurde, müssen Sie ein einmaliges Upgrade kritischer Cluster-Add-on-Manifeste durchführen. Dies ist so, dass Kubernetes für jede Hardwarearchitektur, die in Ihrem Cluster verwendet wird, das richtige Image abrufen kann. Weitere Informationen zum Aktualisieren von Cluster-Add-ons finden Sie unter [Schritt 1: Upgrade vorbereiten](update-cluster.md#update-existing-cluster). Wenn Sie Ihren Cluster am oder nach dem 17. August 2020 bereitgestellt haben, sind Ihr CoreDNS-, `kube-proxy`- und Amazon VPC-CNI-Plug-in für Kubernetes-Add-Ons bereits Multi-Architektur-fähig.
+ Anwendungen, die auf Arm-Knoten bereitgestellt werden, müssen für Arm kompiliert werden.
+ Wenn Sie DaemonSets diese in einem vorhandenen Cluster bereitgestellt haben oder sie in einem neuen Cluster bereitstellen möchten, in dem Sie auch ARM-Knoten bereitstellen möchten, stellen Sie sicher, dass Sie auf allen Hardwarearchitekturen in Ihrem Cluster ausgeführt werden DaemonSet können.
+ Sie können Arm-Knotengruppen und x86-Knotengruppen im selben Cluster ausführen. In diesem Fall sollten Sie Container-Images mit mehreren Architekturen in einem Container-Repository wie Amazon Elastic Container Registry bereitstellen und dann Knoten-Selektoren zu Ihren Manifesten hinzufügen, damit Kubernetes weiß, auf welcher Hardwarearchitektur ein Pod bereitgestellt werden kann. Weitere Informationen finden Sie unter [Übertragen eines Multi-Architektur-Images](https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-multi-architecture-image.html) im *Amazon-ECR-Benutzerhandbuch* und im Blogbeitrag [Einführung in Multi-Architektur-Container-Images für Amazon ECR](https://aws.amazon.com/blogs/containers/introducing-multi-architecture-container-images-for-amazon-ecr).

## Weitere Informationen
<a name="linux-more-information"></a>

Weitere Informationen zur Verwendung von Amazon EKS-optimiertem Amazon Linux AMIs finden Sie in den folgenden Abschnitten:
+ Informationen zur Verwendung von Amazon Linux mit verwalteten Knotengruppen finden Sie unter [Vereinfachung des Knotenlebenszyklus mit verwalteten Knotengruppen](managed-node-groups.md).
+ Informationen zum Starten selbstverwalteter Amazon-Linux-Knoten finden Sie unter [Rufen Sie das empfohlene Amazon Linux AMI ab IDs](retrieve-ami-id.md).
+ Versionsinformationen finden Sie unter [Abrufen der Versionsinformationen zu Amazon-Linux-AMI](eks-linux-ami-versions.md).
+ Informationen zum Abrufen der neuesten Version IDs des für Amazon EKS optimierten Amazon Linux AMIs finden Sie unter. [Rufen Sie das empfohlene Amazon Linux AMI ab IDs](retrieve-ami-id.md)
+ Informationen zu Open-Source-Skripten, die zur Erstellung der Amazon EKS-optimierten AMIs Version verwendet werden, finden Sie unter. [Erstellen Sie ein benutzerdefiniertes EKS-optimiertes Amazon Linux-AMI](eks-ami-build-scripts.md)

# Upgrade von Amazon Linux 2 zu Amazon Linux 2023
<a name="al2023"></a>

**Warnung**  
Amazon EKS hat die Veröffentlichung von EKS-optimiertem Amazon Linux 2 (AL2) AMIs am 26. November 2025 eingestellt. AL2023 und Bottlerocket auf Basis von Amazon EKS sind AMIs für alle unterstützten Kubernetes-Versionen einschließlich 1.33 und höher verfügbar.

AL2023 ist ein Linux-basiertes Betriebssystem, das entwickelt wurde, um eine sichere, stabile und leistungsstarke Umgebung für Ihre Cloud-Anwendungen bereitzustellen. Es handelt sich um die nächste Generation von Amazon Linux von Amazon Web Services und ist für alle unterstützten Amazon-EKS-Versionen verfügbar.

AL2023 bietet mehrere Verbesserungen gegenüber AL2. Einen vollständigen Vergleich finden Sie unter [ AL2 Comparing and Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html) im *Amazon Linux 2023-Benutzerhandbuch*. Es wurden mehrere Pakete hinzugefügt, aktualisiert und entfernt AL2. Es wird dringend empfohlen, Ihre Anwendungen AL2023 vor dem Upgrade mit zu testen. Eine Liste aller Paketänderungen in AL2023 finden Sie unter [Paketänderungen in Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/release-notes/compare-packages.html) in den *Versionshinweisen zu Amazon Linux 2023*.

Zusätzlich zu diesen Änderungen sollten Sie Folgendes beachten:
+ AL2023 führt einen neuen Knoteninitialisierungsprozess ein`nodeadm`, der ein YAML-Konfigurationsschema verwendet. Wenn Sie selbstverwaltete Knotengruppen oder eine AMI mit einer Startvorlage verwenden, müssen Sie nun beim Erstellen einer neuen Knotengruppe explizit zusätzliche Cluster-Metadaten angeben. Ein [Beispiel](https://awslabs.github.io/amazon-eks-ami/nodeadm/) für die mindestens erforderlichen Parameter ist wie folgt, wobei jetzt `apiServerEndpoint`, `certificateAuthority` und Service-`cidr` erforderlich sind:

  ```
  ---
  apiVersion: node.eks.aws/v1alpha1
  kind: NodeConfig
  spec:
    cluster:
      name: my-cluster
      apiServerEndpoint: https://example.com
      certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
      cidr: 10.100.0.0/16
  ```

   AL2In wurden die Metadaten dieser Parameter aus dem Amazon `DescribeCluster` EKS-API-Aufruf ermittelt. Mit hat sich dieses Verhalten geändert AL2023, da durch den zusätzlichen API-Aufruf die Gefahr einer Drosselung bei der Skalierung großer Knoten besteht. Diese Änderung betrifft Sie nicht, wenn Sie verwaltete Knotengruppen ohne Startvorlage verwenden oder wenn Sie Karpenter verwenden. Weitere Informationen zu `certificateAuthority` und Service `cidr` finden Sie unter [https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html) in der *API-Referenz von Amazon EKS*.
+ Denn ändert `nodeadm` auch das Format AL2023, in dem Parameter `kubelet` für jeden verwendeten Knoten angewendet werden. [https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec) In AL2, das wurde mit dem `--kubelet-extra-args` Parameter gemacht. Dies wird häufig verwendet, um Knoten mit Beschriftungen und Taints zu versehen. Ein Beispiel unten zeigt die Anwendung von `maxPods` und `--node-labels` auf den Knoten.

  ```
  ---
  apiVersion: node.eks.aws/v1alpha1
  kind: NodeConfig
  spec:
    cluster:
      name: test-cluster
      apiServerEndpoint: https://example.com
      certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
      cidr: 10.100.0.0/16
    kubelet:
      config:
        maxPods: 110
      flags:
        - --node-labels=karpenter.sh/capacity-type=on-demand,karpenter.sh/nodepool=test
  ```
+ Amazon VPC CNI-Version `1.16.2` oder höher ist erforderlich für. AL2023
+ AL2023 erfordert `IMDSv2` standardmäßig. `IMDSv2`hat mehrere Vorteile, die zur Verbesserung der Sicherheitslage beitragen. Das Programm verwendet eine sitzungsorientierte Authentifizierungsmethode, welche die Erstellung eines geheimen Tokens in einer einfachen HTTP-PUT-Anfrage zum Starten der Sitzung erfordert. Die Gültigkeitsdauer eines Sitzungs-Tokens kann zwischen 1 Sekunde und 6 Stunden variieren. Weitere Informationen zum Übergang von `IMDSv1` zu `IMDSv2` finden Sie unter [Umstellung auf Instance Metadata Service Version 2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html) und [Nutzen Sie alle Vorteile IMDSv2 und deaktivieren Sie Ihre IMDSv1 gesamte AWS Infrastruktur](https://aws.amazon.com/blogs/security/get-the-full-benefits-of-imdsv2-and-disable-imdsv1-across-your-aws-infrastructure). Wenn Sie `IMDSv1` verwenden möchten, können Sie dies dennoch tun, indem Sie die Einstellungen mithilfe der Starteigenschaften der Instance-Metadatenoption manuell überschreiben.
**Anmerkung**  
`IMDSv2`Bei kann AL2023 die Standard-Hop-Anzahl für verwaltete Knotengruppen variieren:  
Wenn keine Startvorlage verwendet wird, ist der Standardwert auf `1` eingestellt. Dies bedeutet, dass Container über IMDS keinen Zugriff auf die Anmeldeinformationen des Knotens haben. Wenn Sie Container-Zugriff auf die Anmeldeinformationen des Knotens benötigen, können Sie dies weiterhin mithilfe einer [benutzerdefinierten Amazon-EC2-Startvorlage](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-launchtemplate-metadataoptions.html) tun.
Wenn Sie in einer Startvorlage ein benutzerdefiniertes AMI verwenden, wird das Standard-`HttpPutResponseHopLimit` auf `2` gesetzt. Sie können `HttpPutResponseHopLimit` in der Startvorlage manuell überschreiben.
Alternativ können Sie anstelle von `IMDSv2` [Amazon EKS Pod Identity](pod-identities.md) verwenden, um Anmeldeinformationen bereitzustellen.
+ AL2023 bietet die nächste Generation einheitlicher Kontrollgruppenhierarchien (`cgroupv2`). `cgroupv2`wird verwendet, um eine Container-Laufzeit zu implementieren, und von`systemd`. Es enthält zwar AL2023 immer noch Code, mit dem das System zum Laufen gebracht werden kann`cgroupv1`, ist aber keine empfohlene oder unterstützte Konfiguration. Diese Konfiguration wird in einer zukünftigen Hauptversion von Amazon Linux vollständig entfernt.
+  `eksctl`Für `eksctl` die Unterstützung ist eine Version `0.176.0` oder höher erforderlich AL2023.

Für bereits bestehende verwaltete Knotengruppen können Sie entweder ein direktes Upgrade oder ein blue/green Upgrade durchführen, je nachdem, wie Sie eine Startvorlage verwenden:
+ Wenn Sie ein benutzerdefiniertes AMI mit einer verwalteten Knotengruppe verwenden, können Sie ein direktes Upgrade durchführen, indem Sie die AMI-ID in der Startvorlage austauschen. Sie sollten sicherstellen, dass Ihre Anwendungen und alle Benutzerdaten an AL2023 First übertragen werden, bevor Sie diese Upgrade-Strategie durchführen.
+ Wenn Sie verwaltete Knotengruppen entweder mit der Standardstartvorlage oder mit einer benutzerdefinierten Startvorlage verwenden, die die AMI-ID nicht angibt, müssen Sie das Upgrade mithilfe einer blue/green Strategie durchführen. Ein blue/green Upgrade ist in der Regel komplexer und beinhaltet die Erstellung einer völlig neuen Knotengruppe, die Sie AL2023 als AMI-Typ angeben würden. Die neue Knotengruppe muss anschließend sorgfältig konfiguriert werden, um sicherzustellen, dass alle benutzerdefinierten Daten aus der AL2 Knotengruppe mit dem neuen Betriebssystem kompatibel sind. Sobald die neue Knotengruppe mit Ihren Anwendungen getestet und validiert wurde, können Pods von der alten Knotengruppe auf die neue Knotengruppe migriert werden. Nach Abschluss der Migration können Sie die alte Knotengruppe löschen.

Wenn Sie Karpenter verwenden und verwenden möchten AL2023, müssen Sie das `EC2NodeClass` `amiFamily` Feld mit ändern. AL2023 Drift ist standardmäßig in Karpenter aktiviert. Dies bedeutet, dass Karpenter nach einer Änderung des `amiFamily`-Feldes Ihre Worker-Knoten automatisch auf die neueste AMI aktualisiert, sobald diese verfügbar ist.

## Zusätzliche Informationen zu nodeadm
<a name="_additional_information_about_nodeadm"></a>

Wenn Sie ein EKS-optimiertes Amazon Linux 2023 AMI verwenden oder ein benutzerdefiniertes EKS Amazon Linux 2023 AMI mithilfe der im offiziellen amazon-eks-ami GitHub Repository bereitgestellten Packer-Skripts erstellen, sollten Sie es vermeiden, nodeadm init explizit in EC2-Benutzerdaten oder als Teil Ihres benutzerdefinierten AMI auszuführen.

Wenn Sie NodeConfig in Ihren Benutzerdaten Dynamik erzeugen möchten, können Sie diese Konfiguration in eine Drop-In-Yaml- oder JSON-Datei schreiben. `/etc/eks/nodeadm.d` Diese Konfigurationsdateien werden zusammengeführt und auf Ihren Knoten angewendet, wenn nodeadm init später im Startvorgang automatisch gestartet wird. Beispiel:

```
cat > /etc/eks/nodeadm.d/additional-node-labels.yaml << EOF
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  kubelet:
    flags:
      - --node-labels=foo=bar
EOF
```

Das EKS-optimierte Amazon Linux 2023 führt nodeadm init AMIs automatisch in zwei Phasen über separate Systemd-Dienste aus: nodeadm-config wird vor der Ausführung der Benutzerdaten ausgeführt, während nodeadm-run danach ausgeführt wird. Der Dienst nodeadm-config richtet Basiskonfigurationen für containerd und kubelet ein, bevor Benutzerdaten ausgeführt werden. Der Dienst nodeadm-run führt ausgewählte System-Daemons aus und schließt alle endgültigen Konfigurationen nach der Ausführung der Benutzerdaten ab. Wenn der Befehl nodeadm init ein weiteres Mal über Benutzerdaten oder ein benutzerdefiniertes AMI ausgeführt wird, kann er Annahmen über die Reihenfolge der Ausführung widerlegen, was zu unerwarteten Ergebnissen, einschließlich einer Fehlkonfiguration, führen kann. ENIs

# Abrufen der Versionsinformationen zu Amazon-Linux-AMI
<a name="eks-linux-ami-versions"></a>

Für Amazon EKS optimierte Amazon-Linux-AMIs werden anhand der Kubernetes-Version und des Veröffentlichungsdatums des AMI in folgendem Format versioniert:

```
k8s_major_version.k8s_minor_version.k8s_patch_version-release_date
```

Jede AMI-Version enthält verschiedene Versionen von [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/), dem Linux-Kernel und [containerd](https://containerd.io/). Die beschleunigten AMIs umfassen auch verschiedene Versionen des NVIDIA-Treibers. Diese Informationen finden Sie im [Änderungsprotokoll](https://github.com/awslabs/amazon-eks-ami/blob/main/CHANGELOG.md) in GitHub.

# Rufen Sie das empfohlene Amazon Linux AMI ab IDs
<a name="retrieve-ami-id"></a>

Beim Bereitstellen von Knoten können Sie eine ID für ein vorkonfiguriertes, für Amazon EKS optimiertes Amazon Machine Image (AMI) angeben. Um eine AMI-ID abzurufen, die Ihrer gewünschten Konfiguration entspricht, fragen Sie die AWS Systems Manager Parameter Store-API ab. Durch die Verwendung dieser API entfällt die Notwendigkeit, manuell nach Amazon EKS-optimiertem AMI zu suchen IDs. Weitere Informationen finden Sie unter [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html). Das von Ihnen verwendete [IAM-Prinzipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) muss über die `ssm:GetParameter`-IAM-Berechtigung zum Abrufen der Amazon EKS-optimierten AMI-Metadaten verfügen.

Sie können die Image-ID des aktuellen empfohlenen für Amazon EKS optimierten Amazon-Linux-AMI mit dem folgenden Befehl abrufen, der den Unterparameter `image_id` verwendet. Nehmen Sie nach Bedarf die folgenden Änderungen am Befehl vor und führen Sie anschließend den geänderten Befehl aus:
+ Ersetzen Sie `<kubernetes-version>` durch eine von [Amazon EKS unterstützte Version](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
+ *ami-type*Ersetzen Sie es durch eine der folgenden Optionen. Informationen zu den Typen von EC2 Amazon-Instances finden Sie unter [ EC2 Amazon-Instance-Typen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html).
  + Wird *amazon-linux-2023/x86\$164/standard* für Amazon Linux 2023 (AL2023) `x86` -basierte Instances verwendet.
  + Wird *amazon-linux-2023/arm64/standard* für AL2 023 ARM-Instances verwendet, z. B. [AWS Graviton-basierte](https://aws.amazon.com/ec2/graviton/) Instances.
  + Wird *amazon-linux-2023/x86\$164/nvidia* für die neuesten genehmigten AL2 023 `x86` NVIDIA-basierten Instanzen verwendet.
  + Wird *amazon-linux-2023/arm64/nvidia* für die neuesten genehmigten AL2 023 `arm64` NVIDIA-basierten Instanzen verwendet.
  + Wird *amazon-linux-2023/x86\$164/neuron* für die neuesten AL2 023 [AWS Neuron-Instanzen](https://aws.amazon.com/machine-learning/neuron/) verwendet.
+ `<region-code>`Ersetzen Sie durch eine von [Amazon EKS unterstützte AWS Region](https://docs.aws.amazon.com/general/latest/gr/eks.html), für die Sie die AMI-ID benötigen.

```
aws ssm get-parameter --name /aws/service/eks/optimized-ami/<kubernetes-version>/<ami-type>/recommended/image_id \
    --region <region-code> --query "Parameter.Value" --output text
```

Hier ist ein Beispielbefehl, nachdem Platzhalter ersetzt wurden.

```
aws ssm get-parameter --name /aws/service/eks/optimized-ami/1.31/amazon-linux-2023/x86_64/standard/recommended/image_id \
    --region us-west-2 --query "Parameter.Value" --output text
```

Eine Beispielausgabe sieht wie folgt aus.

```
ami-1234567890abcdef0
```

# Erstellen Sie ein benutzerdefiniertes EKS-optimiertes Amazon Linux-AMI
<a name="eks-ami-build-scripts"></a>

**Warnung**  
Amazon EKS hat die Veröffentlichung von EKS-optimiertem Amazon Linux 2 (AL2) AMIs am 26. November 2025 eingestellt. AL2023 und Bottlerocket auf Basis von Amazon EKS sind AMIs für alle unterstützten Kubernetes-Versionen einschließlich 1.33 und höher verfügbar.

Amazon EKS bietet Open-Source-Build-Skripte im [Amazon EKS AMI Build Specification-Repository](https://github.com/awslabs/amazon-eks-ami), mit denen Sie die Konfigurationen für `kubelet` die Laufzeit und den AWS IAM Authenticator für Kubernetes anzeigen und Ihr eigenes AL-basiertes AMI von Grund auf neu erstellen können.

Dieses Repository enthält das spezielle [Bootstrap-Skript für AL2 und das [Nodeadm-Tool](https://awslabs.github.io/amazon-eks-ami/nodeadm/) für 023](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh), das beim Booten ausgeführt wird. AL2 Diese Skripte konfigurieren die Zertifikatsdaten Ihrer Instance, den Endpunkt der Steuerebene, den Cluster-Namen und weitere Elemente. Die Skripts gelten als Informationsquelle für Amazon EKS-optimierte AMI-Builds, sodass Sie dem GitHub Repository folgen können, um Änderungen an unseren zu überwachen. AMIs

Bei der Erstellung benutzerdefinierter Systeme AMIs mit EKS-Optimized AMIs als Basis wird die Ausführung eines Betriebssystem-Upgrades nicht empfohlen oder unterstützt (z. `dnf upgrade`) oder eines der Kubernetes- oder GPU-Pakete aktualisieren, die im EKS-optimierten Paket enthalten sind AMIs, da dadurch die Komponentenkompatibilität beeinträchtigt werden kann. Wenn Sie das Betriebssystem oder die Pakete, die in EKS-Optimized enthalten sind, aktualisieren, wird empfohlen AMIs, vor der Bereitstellung in der Produktion gründliche Tests in einer Entwicklungs- oder Staging-Umgebung durchzuführen.

Bei der Erstellung benutzerdefinierter GPU-Instanzen empfiehlt es sich, AMIs AMIs für jeden Instance-Typ, jede Generation und Familie, die Sie ausführen möchten, separate benutzerdefinierte Instances zu erstellen. Die für EKS optimierten beschleunigten AMIs Systeme installieren Treiber und Pakete selektiv zur Laufzeit, basierend auf der Generation und Familie des zugrunde liegenden Instance-Typs. Weitere Informationen finden Sie in den EKS AMI-Skripts für [Installation](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2023/provisioners/install-nvidia-driver.sh) und [Laufzeit](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2023/runtime/gpu/nvidia-kmod-load.sh).

## Voraussetzungen
<a name="_prerequisites"></a>
+  [Installieren Sie die AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) 
+  [Installieren Sie HashiCorp Packer v1.9.4\$1](https://developer.hashicorp.com/packer/downloads) 
+  [Installation von GNU Make](https://www.gnu.org/software/make/) 

## Quickstart
<a name="_quickstart"></a>

Dieser Schnellstart zeigt Ihnen die Befehle zum Erstellen eines benutzerdefinierten AMI in Ihrem AWS Konto. Weitere Informationen zu den verfügbaren Konfigurationen zur Anpassung Ihrer AMI finden Sie unter den Vorlagenvariablen auf der Seite [Amazon Linux 2023](https://awslabs.github.io/amazon-eks-ami/usage/al2023/).

### Voraussetzungen
<a name="_prerequisites_2"></a>

Installieren Sie das erforderliche [Amazon-Plugin](https://developer.hashicorp.com/packer/integrations/hashicorp/amazon). Beispiel:

```
packer plugins install github.com/hashicorp/amazon
```

### Schritt 1. Einrichtung Ihrer Umgebung
<a name="_step_1_setup_your_environment"></a>

Klonen oder forken Sie das offizielle Amazon-EKS-AMI-Repository. Beispiel:

```
git clone https://github.com/awslabs/amazon-eks-ami.git
cd amazon-eks-ami
```

Überprüfen Sie, ob Packer installiert ist:

```
packer --version
```

### Schritt 2. So erstellen Sie ein benutzerdefiniertes -AMI
<a name="_step_2_create_a_custom_ami"></a>

Im Folgenden finden Sie Beispielbefehle für verschiedene benutzerdefinierte AMIs Befehle.

 **Grundlegendes AL2 NVIDIA-AMI:** 

```
make k8s=1.31 os_distro=al2 \
  enable_accelerator=nvidia \
  nvidia_driver_major_version=560 \
  enable_efa=true
```

 **Grundlegendes NVIDIA AL2 023 AMI:** 

```
make k8s=1.31 os_distro=al2023 \
  enable_accelerator=nvidia \
  nvidia_driver_major_version=560 \
  enable_efa=true
```

 **STIG-konformes Neuron 023 AMI AL2:** 

```
make k8s=1.31 os_distro=al2023 \
  enable_accelerator=neuron \
  enable_fips=true \
  source_ami_id=ami-0abcd1234efgh5678 \
  kms_key_id=alias/aws-stig
```

Nachdem Sie diese Befehle ausgeführt haben, geht Packer wie folgt vor: \$1 Startet eine temporäre EC2 Amazon-Instance. \$1 Installieren Sie Kubernetes-Komponenten, -Treiber und -Konfigurationen. \$1 Erstellen Sie das AMI in Ihrem AWS Konto.

Die erwartete Ausgabe sollte in etwa wie folgt aussehen:

```
==> Wait completed after 8 minutes 42 seconds

==> Builds finished. The artifacts of successful builds are:
--> amazon-ebs: AMIs were created:
us-west-2: ami-0e139a4b1a7a9a3e9

--> amazon-ebs: AMIs were created:
us-west-2: ami-0e139a4b1a7a9a3e9

--> amazon-ebs: AMIs were created:
us-west-2: ami-0e139a4b1a7a9a3e9
```

### Schritt 3. Standardwerte anzeigen
<a name="_step_3_view_default_values"></a>

Um Standardwerte und zusätzliche Optionen anzuzeigen, führen Sie den folgenden Befehl aus:

```
make help
```