Versionskompatibilität Überlegungen zum Betriebssystem Erstellung von Betriebssystem-Images

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.

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

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 behandelt, anstatt in den Schritten in Hybridknoten verbinden.
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 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. 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), 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, 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 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.
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 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-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.

Installieren Sie die govc CLI gemäß den Anweisungen in der Govc-Readme-Datei unter. GitHub
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 verwendetNODE_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"
```

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.

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

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 <userdata.yaml | base64)

govc vm.change -dc="YOUR_DATASTORE" -vm "$NODE_NAME" -e guestinfo.userdata="${USER_DATA}"
govc vm.change -dc="YOUR_DATASTORE" -vm "$NODE_NAME" -e guestinfo.userdata.encoding=gzip+base64

envsubst '$NODE_NAME' < metadata.yaml > metadata.yaml.tmp
export METADATA=$(gzip -c9 <metadata.yaml.tmp | base64)

govc vm.change -dc="YOUR_DATASTORE" -vm "$NODE_NAME" -e guestinfo.metadata="${METADATA}"
govc vm.change -dc="YOUR_DATASTORE" -vm "$NODE_NAME" -e guestinfo.metadata.encoding=gzip+base64

Schalten Sie Ihren neuen ein VMs, der automatisch eine Verbindung zu dem von Ihnen konfigurierten EKS-Cluster herstellen sollte.
```
govc vm.power -on "${NODE_NAME}"
```

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Netzwerk vorbereiten

Anmeldeinformationen vorbereiten