**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.
# Vorbereitung des Betriebssystems für Hybridknoten
Bottlerocket, Amazon Linux 2023 (AL2023), Ubuntu und RHEL werden fortlaufend für die Verwendung als Knotenbetriebssystem für Hybridknoten validiert. Bottlerocket wird nur AWS in VMware vSphere-Umgebungen unterstützt. AL2023 ist nicht durch AWS Supportpläne abgedeckt, wenn sie außerhalb von Amazon EC2 ausgeführt werden. AL2023 kann nur in lokalen virtualisierten Umgebungen verwendet werden. Weitere Informationen finden Sie im [Amazon Linux 2023 User Guide](https://docs.aws.amazon.com/linux/al2023/ug/outside-ec2.html). AWS unterstützt die Integration von Hybridknoten mit Ubuntu- und RHEL-Betriebssystemen, bietet jedoch keine Unterstützung für das Betriebssystem selbst.
Sie sind für die Bereitstellung und Verwaltung des Betriebssystems verantwortlich. Wenn Sie Hybridknoten zum ersten Mal testen, ist es am einfachsten, die CLI für Amazon EKS Hybrid Nodes (`nodeadm`) auf einem bereits bereitgestellten Host auszuführen. Für Produktions-Bereitstellungen empfehlen wir, `nodeadm` in Ihre Betriebssystem-Images aufzunehmen und es so zu konfigurieren, dass es als systemd-Service ausgeführt wird, um Hosts beim Host-Startup automatisch mit Amazon-EKS-Clustern zu verbinden. Wenn Sie Bottlerocket als Knotenbetriebssystem auf vSphere verwenden, müssen Sie `nodeadm` nicht verwenden, da Bottlerocket bereits die für Hybridknoten erforderlichen Abhängigkeiten enthält und beim Host-Startup automatisch eine Verbindung mit dem von Ihnen konfigurierten Cluster herstellt.
## Versionskompatibilität
Die nachfolgende Tabelle enthält die Betriebssystemversionen, die kompatibel und für die Verwendung als Knoten-Betriebssystem für Hybridknoten validiert sind. Wenn Sie andere Betriebssystemvarianten oder Versionen verwenden, die nicht in dieser Tabelle enthalten sind, wird die Kompatibilität von Hybridknoten mit Ihrer Betriebssystemvariante oder -version nicht vom AWS Support abgedeckt. Hybridknoten sind unabhängig von der zugrunde liegenden Infrastruktur und unterstützen x86- und ARM-Architekturen.
| Betriebssystem | Versionen |
| --- | --- |
| Amazon Linux | Amazon Linux 2023 (AL2023) |
| Flaschenrakete | v1.37.0 und höhere VMware Varianten, auf denen Kubernetes v1.28 und höher ausgeführt wird |
| Ubuntu | Ubuntu 20.04, Ubuntu 22.04, Ubuntu 24.04 |
| Red Hat Enterprise Linux | RHEL 8, RHEL 9 |
## Überlegungen zum Betriebssystem
### General
+ Die Amazon EKS Hybrid Nodes CLI (`nodeadm`) kann verwendet werden, um die Installation und Konfiguration der Hybridknoten-Komponenten und -Abhängigkeiten zu vereinfachen. Sie können den `nodeadm install`-Prozess während der Erstellung Ihrer Betriebssystem-Image-Pipelines oder zur Laufzeit auf jedem On-Premises-Host ausführen. Weitere Informationen zu den von `nodeadm` installierten Komponenten finden Sie unter [`nodeadm`-Referenz für Hybridknoten](hybrid-nodes-nodeadm.md).
+ Wenn Sie in Ihrer On-Premises-Umgebung einen Proxy für den Internetzugang verwenden, sind zusätzliche Betriebssystemkonfigurationen für die Installations- und Aktualisierungsprozesse erforderlich, um Ihren Paket-Manager für die Verwendung des Proxys zu konfigurieren. Detaillierte Anweisungen finden Sie unter [Konfiguration des Proxys für Hybridknoten](hybrid-nodes-proxy.md).
### Bottlerocket
+ Die Schritte und Tools zum Verbinden eines Bottlerocket-Knotens unterscheiden sich von den Schritten für andere Betriebssysteme und werden separat in [Hybridknoten mit Bottlerocket verbinden](hybrid-nodes-bottlerocket.md) behandelt, anstatt in den Schritten in [Hybridknoten verbinden](hybrid-nodes-join.md).
+ Die Schritte für Bottlerocket verwenden nicht das CLI-Tool für Hybridknoten, `nodeadm`.
+ Nur VMware Varianten von Bottlerocket Version v1.37.0 und höher werden von EKS Hybrid Nodes unterstützt. VMware Varianten von Bottlerocket sind für die Kubernetes-Versionen v1.28 und höher verfügbar. [Andere Bottlerocket-Varianten](https://bottlerocket.dev/en/os/1.36.x/concepts/variants) werden als Betriebssystem für Hybridknoten nicht unterstützt. HINWEIS: VMware Varianten von Bottlerocket sind nur für die x86\_64-Architektur verfügbar.
### Containerd
+ Containerd ist die Standard-Container-Laufzeit von Kubernetes und eine Abhängigkeit für Hybridknoten sowie alle Amazon-EKS-Knoten-Rechentypen. Die CLI für Amazon EKS Hybrid Nodes (`nodeadm`) versucht während des `nodeadm install`-Vorgangs, containerd zu installieren. Sie können die containerd-Installation zur `nodeadm install`-Laufzeit mit der Befehlszeilenoption `--containerd-source` konfigurieren. Gültige Optionen sind `none`, `distro` und `docker`. Wenn Sie RHEL verwenden, ist `distro` keine gültige Option und Sie können `nodeadm` entweder so konfigurieren, dass die containerd-Entwicklung aus den Docker-Repos installiert wird. Sie können containerd auch manuell installieren. Wenn Sie AL2 023 oder Ubuntu verwenden, wird containerd `nodeadm` standardmäßig aus der Betriebssystemdistribution installiert. Wenn Sie nicht möchten, dass nodeadm containerd installiert, verwenden Sie die `--containerd-source none`-Option.
### Ubuntu
+ [Wenn Sie Ubuntu 24.04 verwenden, müssen Sie möglicherweise Ihre Version von containerd aktualisieren oder Ihre AppArmor Konfiguration ändern, um einen Fix zu implementieren, mit dem Pods ordnungsgemäß beendet werden können, siehe Ubuntu \#2065423.](https://bugs.launchpad.net/ubuntu/+source/containerd-app/\+bug/2065423) Ein Neustart ist erforderlich, um die Änderungen am Profil zu übernehmen. AppArmor Die neueste Version von Ubuntu 24.04 enthält in ihrem Paket-Manager eine aktualisierte containerd-Version mit der Korrektur (Containerd-Version 1.7.19\+).
### ARM
+ Wenn Sie ARM-Hardware verwenden, ist ein ARMv8 2.2-kompatibler Prozessor mit der Cryptography Extension (ARMv8.2\+Crypto) erforderlich, um Version 1.31 und höher des EKS-Kube-Proxy-Add-Ons auszuführen. Alle Raspberry-Pi-Systeme vor dem Raspberry Pi 5 sowie Cortex-A72-basierte Prozessoren erfüllen diese Anforderung nicht. Als vorübergehende Lösung können Sie die Version 1.30 des EKS-kube-proxy-Add-Ons weiterhin verwenden, bis der erweiterte Support im Juli 2026 endet (siehe [Kubernetes-Versions-Kalender](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)), oder ein benutzerdefiniertes kube-proxy-Image aus dem Upstream verwenden.
+ Die folgende Fehlermeldung im kube-proxy-Protokoll weist auf diese Inkompatibilität hin:
```
Fatal glibc error: This version of Amazon Linux requires a newer ARM64 processor compliant with at least ARM architecture 8.2-a with Cryptographic extensions. On EC2 this is Graviton 2 or later.
```
## Erstellung von Betriebssystem-Images
Amazon EKS bietet [Beispielvorlagen für Packer](https://github.com/aws/eks-hybrid/tree/main/example/packer), mit denen Sie Betriebssystem-Images erstellen können, die `nodeadm` enthalten, und diese so konfigurieren können, dass sie beim Startup des Hosts ausgeführt werden. Dieser Prozess wird empfohlen, um zu vermeiden, dass die Abhängigkeiten der Hybridknoten einzeln auf jedem Host abgerufen werden müssen, und um den Bootstrap-Prozess der Hybridknoten zu automatisieren. Sie können die Beispielvorlagen für Packer mit einem ISO-Image von Ubuntu 22.04, Ubuntu 24.04, RHEL 8 oder RHEL 9 verwenden und Images in den folgenden Formaten ausgeben: OVA, Qcow2 oder raw.
### Voraussetzungen
Bevor Sie die Beispielvorlagen für Packer verwenden können, müssen Sie die folgenden Komponenten auf dem Computer installieren, auf dem Sie Packer ausführen.
+ Packer-Version 1.11.0 oder höher. Anweisungen zur Installation von Packer finden Sie unter [Installation von Packer](https://developer.hashicorp.com/packer/tutorials/docker-get-started/get-started-install-cli) in der Packer-Dokumentation.
+ Beim Erstellen das OVAs VMware vSphere-Plug-in 1.4.0 oder höher
+ Bei Erstellung von `Qcow2`- oder RAW-Images: QEMU-Plugin Version 1.x.
### Festlegen von Umgebungsvariablen
Legen Sie vor Ausführung der Packer-Entwicklung die folgenden Umgebungsvariablen auf dem Computer fest, von dem aus Sie Packer ausführen.
**General**
Die folgenden Umgebungsvariablen müssen für die Erstellung von Images mit allen Betriebssystemen und Ausgabeformaten festgelegt werden.
| Umgebungsvariable | Typ | Description |
| --- | --- | --- |
| PKR\_SSH\_PASSWORD | Zeichenfolge | Packer verwendet die Variablen `ssh_username` und `ssh_password`, um bei der Bereitstellung per SSH auf den erstellten Rechner zuzugreifen. Dies muss mit den Passwörtern übereinstimmen, die zur Erstellung des ersten Benutzers in den Kickstart- oder Benutzerdatendateien des jeweiligen Betriebssystems verwendet wurden. Der Standardwert ist je nach Betriebssystem „builder“ oder „ubuntu“. Achten Sie bei der Festlegung Ihres Passworts darauf, es in der entsprechenden `ks.cfg`- oder `user-data`-Datei entsprechend anzupassen. |
| ISO\_URL | Zeichenfolge | URL der zu verwendenden ISO. Dies kann ein Weblink zum Herunterladen von einem Server oder ein absoluter Pfad zu einer lokalen Datei sein |
| ISO\_CHECKSUM | Zeichenfolge | Zugehörige Prüfsumme für die bereitgestellte ISO-Datei. |
| CREDENTIAL\_PROVIDER | Zeichenfolge | Anmeldeinformationsanbieter für Hybridknoten. Gültige Werte sind `ssm` (Standard) für SSM-Hybridaktivierungen und für `iam` IAM Roles Anywhere. |
| K8S\_VERSION | Zeichenfolge | Kubernetes-Version für Hybridknoten (z. B. `1.31`). Informationen zu den unterstützten Kubernetes-Versionen finden Sie unter [Unterstützte Amazon-EKS-Versionen](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html). |
| NODEADM\_ARCH | Zeichenfolge | Architektur für `nodeadm install`: Wählen Sie `amd` oder `arm`. |
**RHEL**
Wenn Sie RHEL verwenden, müssen die folgenden Umgebungsvariablen festgelegt werden.
| Umgebungsvariable | Typ | Description |
| --- | --- | --- |
| RH\_USERNAME | Zeichenfolge | Benutzername des RHEL-Abonnement-Managers |
| RH\_PASSWORD | Zeichenfolge | Kennwort für den RHEL-Abonnement-Manager |
| RHEL\_VERSION | Zeichenfolge | Verwendete Rhel-ISO-Version. Gültige Werte sind `8` oder `9`. |
**Ubuntu **
Es sind keine Ubuntu-spezifischen Umgebungsvariablen erforderlich.
**vSphere**
Wenn Sie eine VMware vSphere-OVA erstellen, müssen die folgenden Umgebungsvariablen festgelegt werden.
| Umgebungsvariable | Typ | Description |
| --- | --- | --- |
| VSPHERE\_SERVER | Zeichenfolge | vSphere-Server-Adresse |
| VSPHERE\_USER | Zeichenfolge | vSphere-Benutzername |
| VSPHERE\_PASSWORD | Zeichenfolge | vSphere-Kennwort |
| VSPHERE\_DATACENTER | Zeichenfolge | Name des vSphere-Rechenzentrums |
| VSPHERE\_CLUSTER | Zeichenfolge | vSphere-Cluster-Name |
| VSPHERE\_DATASTORE | Zeichenfolge | Name des vSphere-Datenspeichers |
| VSPHERE\_NETWORK | Zeichenfolge | vSphere-Netzwerkname |
| VSPHERE\_OUTPUT\_FOLDER | Zeichenfolge | vSphere-Ausgabeordner für die Vorlagen |
**QEMU**
| Umgebungsvariable | Typ | Description |
| --- | --- | --- |
| PACKER\_OUTPUT\_FORMAT | Zeichenfolge | Ausgabeformat für QEMU-Entwickler. Gültige Werte sind `qcow2` und `raw`. |
**Vorlage validieren**
Bevor Sie Ihre Entwicklung ausführen, überprüfen Sie Ihre Vorlage mit dem folgenden Befehl, nachdem Sie Ihre Umgebungsvariablen festgelegt haben. Ersetzen Sie `template.pkr.hcl`, falls Sie einen anderen Namen für Ihre Vorlage verwenden.
```
packer validate template.pkr.hcl
```
### Entwicklungs-Images
Erstellen Sie Ihre Images mit den folgenden Befehlen und verwenden Sie das `-only`-Flag, um das Ziel und das Betriebssystem für Ihre Images anzugeben. Ersetzen Sie `template.pkr.hcl`, falls Sie einen anderen Namen für Ihre Vorlage verwenden.
**vSphere OVAs**
**Anmerkung**
Wenn Sie RHEL mit vSphere verwenden, müssen Sie die Kickstart-Dateien in ein OEMDRV-Image konvertieren und es als ISO zum Booten übergeben. Weitere Informationen finden Sie in der [Packer-Readme-Datei](https://github.com/aws/eks-hybrid/tree/main/example/packer#utilizing-rhel-with-vsphere) im EKS Hybrid Nodes Repository. GitHub
**Ubuntu 22.04 OVA**
```
packer build -only=general-build.vsphere-iso.ubuntu22 template.pkr.hcl
```
**Ubuntu 24.04 OVA**
```
packer build -only=general-build.vsphere-iso.ubuntu24 template.pkr.hcl
```
**RHEL 8 OVA**
```
packer build -only=general-build.vsphere-iso.rhel8 template.pkr.hcl
```
**RHEL 9 OVA**
```
packer build -only=general-build.vsphere-iso.rhel9 template.pkr.hcl
```
**QEMU**
**Anmerkung**
Wenn Sie ein Image für eine bestimmte Host-CPU erstellen, die nicht mit Ihrem Builder-Host übereinstimmt, suchen Sie in der [QEMU](https://www.qemu.org/docs/master/system/qemu-cpu-models.html)-Dokumentation nach dem Namen, der Ihrer Host-CPU entspricht, und verwenden Sie das `-cpu`-Flag mit dem Namen der Host-CPU, wenn Sie die folgenden Befehle ausführen.
**Ubuntu 22.04 Qcow2 / Raw**
```
packer build -only=general-build.qemu.ubuntu22 template.pkr.hcl
```
**Ubuntu 24.04 Qcow2 / Raw**
```
packer build -only=general-build.qemu.ubuntu24 template.pkr.hcl
```
**RHEL 8 Qcow2 / Raw**
```
packer build -only=general-build.qemu.rhel8 template.pkr.hcl
```
**RHEL 9 Qcow2 / Raw**
```
packer build -only=general-build.qemu.rhel9 template.pkr.hcl
```
### nodeadm-Konfiguration über Benutzerdaten übergeben
Sie können die Konfiguration für `nodeadm` in Ihren Benutzerdaten über cloud-init übergeben, um Hybridknoten zu konfigurieren und beim Startup des Hosts automatisch mit Ihrem EKS-Cluster zu verbinden. Im Folgenden finden Sie ein Beispiel dafür, wie Sie dies erreichen können, wenn Sie VMware vSphere als Infrastruktur für Ihre Hybridknoten verwenden.
1. Installieren Sie die `govc` CLI gemäß den Anweisungen in der [Govc-Readme-Datei unter](https://github.com/vmware/govmomi/blob/main/govc/README.md). GitHub
1. Nachdem Sie die Packer-Entwicklung im vorherigen Abschnitt ausgeführt und Ihre Vorlage bereitgestellt haben, können Sie Ihre Vorlage klonen, um mithilfe der folgenden Schritte mehrere verschiedene Knoten zu erstellen. Sie müssen die Vorlage für jede neue VM klonen, die Sie für Hybridknoten erstellen. Ersetzen Sie die Variablen im folgenden Befehl durch die Werte für Ihre Umgebung. Der `VM_NAME` im folgenden Befehl enthaltene Befehl wird als Ihr verwendet`NODE_NAME`, wenn Sie die Namen für Sie VMs über Ihre Datei eingeben. `metadata.yaml`
```
govc vm.clone -vm "/PATH/TO/TEMPLATE" -ds="YOUR_DATASTORE" \
-on=false -template=false -folder=/FOLDER/TO/SAVE/VM "VM_NAME"
```
1. Nachdem Sie die Vorlage für jedes Ihrer neuen geklont haben VMs, erstellen Sie ein `userdata.yaml` und `metadata.yaml` für Ihre. VMs Sie VMs können dasselbe teilen `userdata.yaml` `metadata.yaml` und Sie werden diese in den folgenden Schritten für jede VM einzeln ausfüllen. Die `nodeadm`-Konfiguration wird im `write_files`-Abschnitt Ihres `userdata.yaml` erstellt und definiert. Im folgenden Beispiel werden AWS SSM-Hybrid-Aktivierungen als lokaler Anbieter von Anmeldeinformationen für Hybridknoten verwendet. Weitere Informationen zur `nodeadm`-Konfiguration finden Sie unter [`nodeadm`-Referenz für Hybridknoten](hybrid-nodes-nodeadm.md).
**userdata.yaml:**
```
#cloud-config
users:
- name: # username for login. Use 'builder' for RHEL or 'ubuntu' for Ubuntu.
passwd: # password to login. Default is 'builder' for RHEL.
groups: [adm, cdrom, dip, plugdev, lxd, sudo]
lock-passwd: false
sudo: ALL=(ALL) NOPASSWD:ALL
shell: /bin/bash
write_files:
- path: /usr/local/bin/nodeConfig.yaml
permissions: '0644'
content: |
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: # Cluster Name
region: # AWS region
hybrid:
ssm:
activationCode: # Your ssm activation code
activationId: # Your ssm activation id
runcmd:
- /usr/local/bin/nodeadm init -c file:///usr/local/bin/nodeConfig.yaml >> /var/log/nodeadm-init.log 2>&1
```
**metadata.yaml:**
Erstellen Sie einen `metadata.yaml` für Ihre Umgebung. Behalten Sie das Variablenformat `"$NODE_NAME"` in der Datei bei, da dieses in einem nachfolgenden Schritt mit Werten gefüllt wird.
```
instance-id: "$NODE_NAME"
local-hostname: "$NODE_NAME"
network:
version: 2
ethernets:
nics:
match:
name: ens*
dhcp4: yes
```
1. Fügen Sie die `userdata.yaml`- und `metadata.yaml`-Dateien als `gzip+base64`-Zeichenfolgen mit den folgenden Befehlen hinzu. Die folgenden Befehle sollten für jeden Befehl ausgeführt werden, den VMs Sie erstellen. Ersetzen Sie `VM_NAME` durch den Namen der VM, die Sie aktualisieren.
```
export NODE_NAME="VM_NAME"
export USER_DATA=$(gzip -c9 metadata.yaml.tmp
export METADATA=$(gzip -c9