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

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 ausschließlich von AWS in VMware-vSphere-Umgebungen unterstützt. AL2023 ist nicht durch AWS-Support-Pläne abgedeckt, wenn es außerhalb von Amazon EC2 ausgeführt wird AL2023 kann nur in virtualisierten Umgebungen On-Premises verwendet werden. Weitere Informationen finden Sie im Benutzerhandbuch zu Amazon Linux 2023. AWS unterstützt die Integration von Hybridknoten mit den Betriebssystemen Ubuntu und RHEL, 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 aufgeführt sind, wird die Kompatibilität von Hybridknoten mit Ihrer Betriebssystemvariante oder -version nicht durch den 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)
Bottlerocket	v1.37.0 und höher VMware-Varianten mit Kubernetes v1.28 und höher
Ubuntu	Ubuntu 20.04, Ubuntu 22.04, Ubuntu 24.04
Red Hat Enterprise Linux	RHEL 8, RHEL 9

Überlegungen zum Betriebssystem

Allgemeines

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 mit EKS-Hybridknoten unterstützt. VMware-Varianten von Bottlerocket sind für Kubernetes-Versionen ab v1.28 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. Bei Verwendung von AL2023 oder Ubuntu installiert nodeadm standardmäßig Containerd aus der Betriebssystem-Verteilung. 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 containerd-Version aktualisieren oder Ihre AppArmor-Konfiguration ändern, um eine Korrektur zu übernehmen, der die ordnungsgemäße Beendigung von Pods ermöglicht, siehe Ubuntu #2065423. Ein Neustart ist erforderlich, um die Änderungen am AppArmor-Profil zu übernehmen. 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-kompatibler Prozessor mit Kryptographie-Erweiterung (ARMv8.2+crypto) erforderlich, um die Version 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.
Bei Erstellung von OVAs VMware vSphere-Plugin 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.

Allgemeines

Die folgenden Umgebungsvariablen müssen für die Erstellung von Images mit allen Betriebssystemen und Ausgabeformaten festgelegt werden.

Umgebungsvariable	Typ	Beschreibung
PKR_SSH_PASSWORD	String	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	String	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	String	Zugehörige Prüfsumme für die bereitgestellte ISO-Datei.
CREDENTIAL_PROVIDER	String	Anmeldeinformationsanbieter für Hybridknoten. Gültige Werte sind `ssm` (Standard) für SSM-Hybridaktivierungen und für `iam` IAM Roles Anywhere.
K8S_VERSION	String	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	String	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	Beschreibung
RH_USERNAME	String	Benutzername des RHEL-Abonnement-Managers
RH_PASSWORD	String	Kennwort für den RHEL-Abonnement-Manager
RHEL_VERSION	String	Verwendete Rhel-ISO-Version. Gültige Werte sind `8` oder `9`.

Ubuntu

Es sind keine Ubuntu-spezifischen Umgebungsvariablen erforderlich.

vSphere

Beim Erstellen einer VMware vSphere OVA müssen die folgenden Umgebungsvariablen festgelegt werden.

Umgebungsvariable	Typ	Beschreibung
VSPHERE_SERVER	String	vSphere-Server-Adresse
VSPHERE_USER	String	vSphere-Benutzername
VSPHERE_PASSWORD	String	vSphere-Kennwort
VSPHERE_DATACENTER	String	Name des vSphere-Rechenzentrums
VSPHERE_CLUSTER	String	vSphere-Cluster-Name
VSPHERE_DATASTORE	String	Name des vSphere-Datenspeichers
VSPHERE_NETWORK	String	vSphere-Netzwerkname
VSPHERE_OUTPUT_FOLDER	String	vSphere-Ausgabeordner für die Vorlagen

QEMU

Umgebungsvariable	Typ	Beschreibung
PACKER_OUTPUT_FORMAT	String	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 im GitHub-Repository zu EKS-Hybridknoten.

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. Nachfolgend 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 auf 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 wird als Ihr NODE_NAME verwendet, wenn Sie die Namen für Ihre VMs über Ihre metadata.yaml-Datei einfügen.
```
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 jede Ihrer neuen VMs geklont haben, erstellen Sie ein userdata.yaml und ein metadata.yaml für Ihre VMs. Ihre VMs können denselben userdata.yaml und metadata.yaml gemeinsam nutzen. Sie füllen diese in den folgenden Schritten für jede VM einzeln aus. Die nodeadm-Konfiguration wird im write_files-Abschnitt Ihres userdata.yaml erstellt und definiert. Das folgende Beispiel verwendet AWS-SSM-Hybridaktivierungen als lokalen Anmeldeinformationsanbieter für Hybridknoten. 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 jede der von Ihnen erstellten VMs ausgeführt werden. 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

Starten Sie Ihre neuen VMs, die sich automatisch mit dem von Ihnen konfigurierten EKS-Cluster verbinden sollten.
```
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