**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. # Ausführung von On-Premises-Workloads in Hybridknoten In einem EKS-Cluster mit aktivierten EKS-Hybridknoten können Sie On-Premises- und Edge-Anwendungen auf Ihrer eigenen Infrastruktur mit denselben Amazon-EKS-Clustern, Features und Tools ausführen, die Sie in der AWS Cloud verwenden. Die folgenden Abschnitte enthalten schrittweise Anleitungen zur Verwendung von Hybridknoten. **Topics** + [Hybridknoten verbinden](hybrid-nodes-join.md) + [Hybridknoten mit Bottlerocket verbinden](hybrid-nodes-bottlerocket.md) + [Hybridknoten aktualisieren](hybrid-nodes-upgrade.md) + [Hybridknoten patchen](hybrid-nodes-security.md) + [Hybridknoten löschen](hybrid-nodes-remove.md) # Hybridknoten verbinden **Anmerkung** Die folgenden Schritte gelten für Hybridknoten mit kompatiblen Betriebssystemen außer Bottlerocket. Anweisungen zum Verbinden eines Hybridknotens mit Bottlerocket finden Sie unter [Hybridknoten mit Bottlerocket verbinden](hybrid-nodes-bottlerocket.md). In diesem Thema wird beschrieben, wie Hybridknoten mit einem Amazon-EKS-Cluster verbunden werden. Nachdem Ihre Hybridknoten dem Cluster beigetreten sind, werden sie in der Amazon-EKS-Konsole und in Kubernetes-kompatiblen Tools wie kubectl mit dem Status „Nicht bereit“ angezeigt. Nachdem Sie die Schritte auf dieser Seite abgeschlossen haben, fahren Sie mit [CNI für Hybridknoten konfigurieren](hybrid-nodes-cni.md) fort, um Ihre Hybridknoten für die Ausführung von Anwendungen vorzubereiten. ## Voraussetzungen Bevor Sie Hybridknoten mit Ihrem Amazon-EKS-Cluster verbinden, stellen Sie sicher, dass Sie die erforderlichen Schritte abgeschlossen haben. + Sie verfügen über eine Netzwerkverbindung von Ihrer On-Premises-Umgebung zu der AWS-Region, in der Ihr Amazon-EKS-Cluster gehostet wird. Weitere Informationen finden Sie unter [Vorbereitung der Vernetzung für Hybridknoten](hybrid-nodes-networking.md). + Sie verfügen über ein kompatibles Betriebssystem für Hybridknoten, das auf Ihren On-Premises-Hosts installiert ist. Weitere Informationen finden Sie unter [Vorbereitung des Betriebssystems für Hybridknoten](hybrid-nodes-os.md). + Sie haben Ihre IAM-Rolle für Hybridknoten erstellt und Ihren On-Premises-Anmeldeinformationsanbieter (AWS-Systems-Manager-Hybridaktivierungen oder AWS IAM Roles Anywhere) eingerichtet. Weitere Informationen finden Sie unter [Vorbereitung der Anmeldeinformationen für Hybridknoten](hybrid-nodes-creds.md). + Sie haben Ihren für Hybridknoten aktivierten Amazon-EKS-Cluster erstellt. Weitere Informationen finden Sie unter [Einen Amazon-EKS-Cluster mit Hybridknoten erstellen](hybrid-nodes-cluster-create.md). + Sie haben Ihre Hybridknoten-IAM-Rolle den Berechtigungen der rollenbasierten Zugriffssteuerung (RBAC) von Kubernetes zugeordnet. Weitere Informationen finden Sie unter [Vorbereitung des Cluster-Zugriffs für Hybridknoten](hybrid-nodes-cluster-prep.md). ## Schritt 1: Hybridknoten-CLI (`nodeadm`) auf jedem On-Premises-Host installieren Wenn Sie die Amazon-EKS-Hybrid-Nodes-CLI (`nodeadm`) in Ihre vorgefertigten Betriebssystem-Images integrieren, können Sie diesen Schritt überspringen. Weitere Informationen zur Hybridknotenversion von `nodeadm` finden Sie unter [`nodeadm`-Referenz für Hybridknoten](hybrid-nodes-nodeadm.md). Die Hybridknoten-Version von `nodeadm` wird in Amazon S3 gehostet und von Amazon CloudFront bereitgestellt. Um die Installation auf jedem On-Premises-Host `nodeadm` durchzuführen, können Sie den folgenden Befehl von Ihren On-Premises-Hosts aus ausführen. **Für x86\$164 hosts:** ``` curl -OL 'https://hybrid-assets.eks.amazonaws.com/releases/latest/bin/linux/amd64/nodeadm' ``` **Für ARM-Hosts** ``` curl -OL 'https://hybrid-assets.eks.amazonaws.com/releases/latest/bin/linux/arm64/nodeadm' ``` Fügen Sie der heruntergeladenen Binärdatei auf jedem Host die Berechtigung zum Ausführen von Dateien hinzu. ``` chmod +x nodeadm ``` ## Schritt 2: Die Abhängigkeiten der Hybridknoten mit `nodeadm` installieren Wenn Sie die Abhängigkeiten der Hybridknoten in vorgefertigten Betriebssystem-Images installieren, können Sie diesen Schritt überspringen. Mit dem `nodeadm install`-Befehl können Sie alle für Hybridknoten erforderlichen Abhängigkeiten installieren. Die Abhängigkeiten der Hybridknoten beinhalten Containerd, kubelet, kubectl und AWS-SSM- oder AWS-IAM-Roles-Anywhere-Komponenten. Weitere Informationen zu den von [`nodeadm`-Referenz für Hybridknoten](hybrid-nodes-nodeadm.md) installierten Komponenten und Dateispeicherorten finden Sie unter `nodeadm install`. Weitere Informationen zu den Domains, die in Ihrer On-Premises-Firewall für den `nodeadm install`-Prozess zugelassen werden müssen, finden Sie unter [Vorbereitung der Vernetzung für Hybridknoten](hybrid-nodes-networking.md) für Hybridknoten. Führen Sie den folgenden Befehl aus, um die Abhängigkeiten der Hybridknoten auf Ihrem On-Premises-Host zu installieren. Der nachfolgende Befehl muss von einem Benutzer ausgeführt werden, der über sudo-/root-Zugriff auf Ihren Host verfügt. **Wichtig** Die Hybridknoten-CLI (`nodeadm`) muss mit einem Benutzer ausgeführt werden, der über sudo/root-Zugriff auf Ihren Host verfügt. + Ersetzen Sie `K8S_VERSION` durch die Kubernetes-Nebenversion Ihres Amazon-EKS-Clusters, z. B. `1.31`. Eine Liste der unterstützten Kubernetes-Versionen finden Sie unter [Unterstützte Versionen von Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html). + Ersetzen Sie `CREDS_PROVIDER` durch den von Ihnen verwendeten On-Premises-Anmeldeinformationsanbieter. Gültige Werte sind `ssm` für AWS SSM und `iam-ra` für AWS IAM Roles Anywhere. ``` nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER ``` ## Schritt 3: Hybridknoten mit Ihrem Cluster verbinden Bevor Sie Ihre Hybridknoten mit Ihrem Cluster verbinden, stellen Sie sicher, dass Sie in Ihrer On-Premises-Firewall und in der Sicherheitsgruppe für Ihren Cluster den erforderlichen Zugriff für die Kommunikation zwischen der Amazon-EKS-Steuerebene und dem Hybridknoten zugelassen haben. Die meisten Probleme in diesem Schritt stehen im Zusammenhang mit der Firewall-Konfiguration, der Konfiguration der Sicherheitsgruppe oder der Konfiguration der IAM-Rolle für Hybridknoten. **Wichtig** Die Hybridknoten-CLI (`nodeadm`) muss mit einem Benutzer ausgeführt werden, der über sudo/root-Zugriff auf Ihren Host verfügt. 1. Erstellen Sie auf jedem Host eine `nodeConfig.yaml`-Datei mit den Werten für Ihre Bereitstellung. Eine vollständige Beschreibung der verfügbaren Konfigurationseinstellungen finden Sie unter [`nodeadm`-Referenz für Hybridknoten](hybrid-nodes-nodeadm.md). Wenn Ihre IAM-Rolle für Hybridknoten über keine Berechtigung für die `eks:DescribeCluster`-Aktion verfügt, müssen Sie Ihren Kubernetes-API-Endpunkt, Ihr Cluster-CA-Bundle und Ihre Kubernetes-Service-IPv4-CIDR im Cluster-Abschnitt Ihres `nodeConfig.yaml` übergeben. 1. Verwenden Sie das nachfolgende `nodeConfig.yaml`-Beispiel, wenn Sie AWS-SSM-Hybridaktivierungen für Ihren On-Premises-Anmeldeinformationsanbieter verwenden. 1. Ersetzen Sie `CLUSTER_NAME` mit dem Namen Ihres Clusters. 1. Ersetzen Sie `AWS_REGION` mit der AWS-Region, in der Ihr Cluster gehostet wird. Beispiel, `us-west-2`. 1. Ersetzen Sie `ACTIVATION_CODE` durch den Aktivierungscode, den Sie beim Erstellen Ihrer AWS-SSM-Hybridaktivierung erhalten haben. Weitere Informationen finden Sie unter [Vorbereitung der Anmeldeinformationen für Hybridknoten](hybrid-nodes-creds.md). 1. Ersetzen Sie `ACTIVATION_ID` durch die Aktivierungs-ID, die Sie beim Erstellen Ihrer AWS-SSM-Hybridaktivierung erhalten haben. Sie können diese Informationen von der AWS-Systems-Manager-Konsole oder über den `aws ssm describe-activations`-Befehl der AWS-CLI abrufen. ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: CLUSTER_NAME region: AWS_REGION hybrid: ssm: activationCode: ACTIVATION_CODE activationId: ACTIVATION_ID ``` 1. Verwenden Sie das nachfolgende `nodeConfig.yaml`-Beispiel, wenn Sie AWS IAM Roles Anywhere für Ihren On-Premises-Anmeldeinformationsanbieter verwenden. 1. Ersetzen Sie `CLUSTER_NAME` mit dem Namen Ihres Clusters. 1. Ersetzen Sie `AWS_REGION` mit der AWS-Region, in der Ihr Cluster gehostet wird. Beispiel, `us-west-2`. 1. Ersetzen Sie `NODE_NAME` durch den Namen Ihres Knotens. Der Knotenname muss mit dem CN des Zertifikats auf dem Host übereinstimmen, wenn Sie die Vertrauensrichtlinie Ihrer IAM-Rolle für Hybridknoten mit der `"sts:RoleSessionName": "${aws:PrincipalTag/x509Subject/CN}"`-Ressourcenbedingung konfiguriert haben. Der von Ihnen verwendete `nodeName` darf nicht länger als 64 Zeichen sein. 1. Ersetzen Sie `TRUST_ANCHOR_ARN` durch die ARN des Trust Anchors, den Sie in den Schritten zum Vorbereiten der Anmeldeinformationen für Hybridknoten konfiguriert haben. 1. Ersetzen Sie `PROFILE_ARN` durch die ARN des Trust Anchors, den Sie in den Schritten für [Vorbereitung der Anmeldeinformationen für Hybridknoten](hybrid-nodes-creds.md) konfiguriert haben. 1. Ersetzen Sie `ROLE_ARN` durch die ARN Ihrer IAM-Rolle für Hybridknoten. 1. Ersetzen Sie `CERTIFICATE_PATH` durch den Pfad auf Ihrer Festplatte zu Ihrem Knotenzertifikat. Wenn Sie keinen Pfad angeben, wird standardmäßig `/etc/iam/pki/server.pem` verwendet. 1. Ersetzen Sie `KEY_PATH` durch den Pfad auf Ihrer Festplatte zu Ihrem privaten Zertifikatsschlüssel. Wenn Sie keinen Pfad angeben, wird standardmäßig `/etc/iam/pki/server.key` verwendet. ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: CLUSTER_NAME region: AWS_REGION hybrid: iamRolesAnywhere: nodeName: NODE_NAME trustAnchorArn: TRUST_ANCHOR_ARN profileArn: PROFILE_ARN roleArn: ROLE_ARN certificatePath: CERTIFICATE_PATH privateKeyPath: KEY_PATH ``` 1. Führen Sie den `nodeadm init`-Befehl mit Ihrem `nodeConfig.yaml` aus, um Ihre Hybridknoten mit Ihrem Amazon-EKS-Cluster zu verbinden. ``` nodeadm init -c file://nodeConfig.yaml ``` Wenn der obige Befehl erfolgreich abgeschlossen wurde, ist Ihr Hybridknoten Ihrem Amazon-EKS-Cluster beigetreten. Sie können dies in der Amazon-EKS-Konsole überprüfen, indem Sie zur Registerkarte „Datenverarbeitung“ für Ihren Cluster navigieren ([stellen Sie sicher, dass der IAM-Prinzipal über Anzeigeberechtigungen verfügt](view-kubernetes-resources.md#view-kubernetes-resources-permissions)) oder mit `kubectl get nodes`. **Wichtig** Ihre Knoten haben den Status `Not Ready`, was zu erwarten ist und darauf zurückzuführen ist, dass auf Ihren Hybridknoten kein CNI ausgeführt wird. Wenn Ihre Knoten nicht dem Cluster beigetreten sind, sehen Sie unter [Fehlerbehebung bei Hybridknoten](hybrid-nodes-troubleshooting.md) nach. ## Schritt 4: CNI für Hybridknoten konfigurieren Um Ihre Hybridknoten für die Ausführung von Anwendungen vorzubereiten, führen Sie die Schritte in [CNI für Hybridknoten konfigurieren](hybrid-nodes-cni.md) aus. # Hybridknoten mit Bottlerocket verbinden In diesem Thema wird beschrieben, wie Sie Hybridknoten, auf denen Bottlerocket ausgeführt wird, mit einem Amazon-EKS-Cluster verbinden. [Bottlerocket](https://aws.amazon.com/bottlerocket/) ist eine Open-Source-Linux-Distribution, die von gesponsert und unterstützt wird. AWS Bottlerocket wurde speziell für das Hosting von Container-Workloads entwickelt. Mit Bottlerocket können Sie die Verfügbarkeit von containerisierten Bereitstellungen verbessern und die Betriebskosten senken, indem Sie Aktualisierungen Ihrer Container-Infrastruktur automatisieren. Bottlerocket enthält ausschließlich die für den Betrieb von Containern erforderliche Software. Dies führt zu einer verbesserten Ressourcennutzung, einer Reduzierung von Sicherheitsrisiken und einem geringeren Verwaltungsaufwand. 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. Die Betriebssystem-Images für diese Varianten beinhalten Kubelet, Containerd aws-iam-authenticator und andere Softwarevoraussetzungen für EKS-Hybridknoten. Sie können diese Komponenten mithilfe einer Bottlerocket-[Einstellungsdatei](https://github.com/bottlerocket-os/bottlerocket#settings) konfigurieren, die Base64-codierte Benutzerdaten für die Bottlerocket-Bootstrap- und Admin-Container enthält. Durch die Konfiguration dieser Einstellungen kann Bottlerocket Ihren Anmeldeinformationsanbieter für Hybridknoten verwenden, um Hybridknoten gegenüber Ihrem Cluster zu authentifizieren. Nachdem Ihre Hybridknoten dem Cluster beigetreten sind, werden sie mit Status `Not Ready` in der Amazon-EKS-Konsole und in Kubernetes-kompatiblen Tools wie `kubectl` angezeigt. Nachdem Sie die Schritte auf dieser Seite abgeschlossen haben, fahren Sie mit [CNI für Hybridknoten konfigurieren](hybrid-nodes-cni.md) fort, um Ihre Hybridknoten für die Ausführung von Anwendungen vorzubereiten. ## Voraussetzungen Bevor Sie Hybridknoten mit Ihrem Amazon-EKS-Cluster verbinden, stellen Sie sicher, dass Sie die erforderlichen Schritte abgeschlossen haben. + Sie haben Netzwerkkonnektivität von Ihrer lokalen Umgebung zur AWS Region, in der Ihr Amazon EKS-Cluster gehostet wird. Weitere Informationen finden Sie unter [Vorbereitung der Vernetzung für Hybridknoten](hybrid-nodes-networking.md). + Sie haben Ihre IAM-Rolle Hybrid Nodes erstellt und Ihren lokalen Anbieter für Anmeldeinformationen eingerichtet (AWS Systems Manager Manager-Hybridaktivierungen oder AWS IAM Roles Anywhere). Weitere Informationen finden Sie unter [Vorbereitung der Anmeldeinformationen für Hybridknoten](hybrid-nodes-creds.md). + Sie haben Ihren für Hybridknoten aktivierten Amazon-EKS-Cluster erstellt. Weitere Informationen finden Sie unter [Einen Amazon-EKS-Cluster mit Hybridknoten erstellen](hybrid-nodes-cluster-create.md). + Sie haben Ihre Hybridknoten-IAM-Rolle den Berechtigungen der rollenbasierten Zugriffssteuerung (RBAC) von Kubernetes zugeordnet. Weitere Informationen finden Sie unter [Vorbereitung des Cluster-Zugriffs für Hybridknoten](hybrid-nodes-cluster-prep.md). ## Schritt 1: TOML-Datei für die Bottlerocket-Einstellungen erstellen Um Bottlerocket für Hybridknoten zu konfigurieren, ist es erforderlich, eine `settings.toml`-Datei mit der notwendigen Konfiguration zu erstellen. Der Inhalt der TOML-Datei unterscheidet sich je nach verwendetem Anmeldeinformationsanbieter (SSM oder IAM Roles Anywhere). Diese Datei wird bei der Bereitstellung der Bottlerocket-Instance als Benutzerdaten übermittelt. **Anmerkung** Die unten angegebenen TOML-Dateien stellen nur die Mindesteinstellungen dar, die für die Initialisierung einer VMWare Bottlerocket-Maschine als Knoten in einem EKS-Cluster erforderlich sind. Bottlerocket bietet eine Vielzahl von Einstellungen für verschiedene Anwendungsfälle. Weitere Konfigurationsoptionen, die über die Initialisierung des Hybridknotens hinausgehen, finden Sie in der [Bottlerocket-Dokumentation](https://bottlerocket.dev/en) eine umfassende Liste aller dokumentierten Einstellungen für die von Ihnen verwendete Bottlerocket-Version ([hier](https://bottlerocket.dev/en/os/1.51.x/api/settings-index) sind beispielsweise alle für Bottlerocket 1.51.x verfügbaren Einstellungen). ### SSM Wenn Sie AWS Systems Manager als Ihren Anmeldeinformationsanbieter verwenden, erstellen Sie eine `settings.toml` Datei mit dem folgenden Inhalt: ``` [settings.kubernetes] cluster-name = "" api-server = "" cluster-certificate = "" hostname-override = "" provider-id = "eks-hybrid://///" authentication-mode = "aws" cloud-provider = "" server-tls-bootstrap = true [settings.network] hostname = "" [settings.aws] region = "" [settings.kubernetes.credential-providers.ecr-credential-provider] enabled = true cache-duration = "12h" image-patterns = [ "*.dkr.ecr.*.amazonaws.com", "*.dkr.ecr.*.amazonaws.com.rproxy.govskope.ca.cn", "*.dkr.ecr.*.amazonaws.eu", "*.dkr.ecr-fips.*.amazonaws.com", "*.dkr.ecr-fips.*.amazonaws.eu", "public.ecr.aws" ] [settings.kubernetes.node-labels] "eks.amazonaws.com/compute-type" = "hybrid" "eks.amazonaws.com/hybrid-credential-provider" = "ssm" [settings.host-containers.admin] enabled = true user-data = "" [settings.bootstrap-containers.eks-hybrid-setup] mode = "always" user-data = "" [settings.host-containers.control] enabled = true ``` Ersetzen Sie die Platzhalter durch die folgenden Werte: + ``: Der Name Ihres Amazon-EKS-Clusters. + ``: Der API-Server-Endpunkt Ihres Clusters. + ``: Das base64-codierte CA-Paket Ihres Clusters. + ``: Die AWS Region, in der Ihr Cluster gehostet wird, zum Beispiel „us-east-1". + ``: Der Host-Name der Bottlerocket-Instance, der auch als Knotenname konfiguriert wird. Dies kann ein beliebiger eindeutiger Wert Ihrer Wahl sein, muss jedoch den [Benennungskonventionen für Kubernetes-Objekte](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names) entsprechen. Außerdem darf der von Ihnen verwendete Hostname nicht länger als 64 Zeichen sein. HINWEIS: Bei Verwendung des SSM-Anbieters werden dieser Host-Name und der Knotenname nach der Registrierung der Instance bei SSM durch die ID der verwalteten Instance (z. B. `mi-*`-ID) ersetzt. + ``: Der Base64-codierte Inhalt der Bottlerocket-Admin-Container-Konfiguration. Durch Aktivieren des Admin-Containers können Sie zur Systemerkundung und zum Debuggen per SSH eine Verbindung zu Ihrer Bottlerocket-Instance herstellen. Obwohl dies keine erforderliche Einstellung ist, empfehlen wir, sie zur einfacheren Fehlerbehebung zu aktivieren. Weitere Informationen zur Authentifizierung mit dem Admin-Container finden Sie in der [Dokumentation zum Bottlerocket-Admin-Container](https://github.com/bottlerocket-os/bottlerocket-admin-container#authenticating-with-the-admin-container). Der Admin-Container akzeptiert SSH-Benutzer- und Schlüsseleingaben im JSON-Format, zum Beispiel: ``` { "user": "", "ssh": { "authorized-keys": [ "" ] } } ``` + ``: Der Base64-codierte Inhalt der Bottlerocket-Bootstrap-Container-Konfiguration. Weitere Informationen zur Konfiguration finden Sie in der [Dokumentation zum Bottlerocket-Bootstrap-Container](https://github.com/bottlerocket-os/bottlerocket-bootstrap-container). Der Bootstrap-Container ist dafür verantwortlich, die Instance als AWS SSM-verwaltete Instance zu registrieren und ihr als Kubernetes-Knoten in Ihrem Amazon EKS-Cluster beizutreten. Die an den Bootstrap-Container übergebenen Benutzerdaten haben die Form eines Befehlsaufrufs, der den zuvor erstellten SSM-Hybrid-Aktivierungscode und die ID als Eingabe akzeptiert: ``` eks-hybrid-ssm-setup --activation-id= --activation-code= --region= ``` ### IAM Roles Anywhere Wenn Sie AWS IAM Roles Anywhere als Ihren Anbieter für Anmeldeinformationen verwenden, erstellen Sie eine `settings.toml` Datei mit dem folgenden Inhalt: ``` [settings.kubernetes] cluster-name = "" api-server = "" cluster-certificate = "" hostname-override = "" provider-id = "eks-hybrid://///" authentication-mode = "aws" cloud-provider = "" server-tls-bootstrap = true [settings.network] hostname = "" [settings.aws] region = "" config = "" [settings.kubernetes.credential-providers.ecr-credential-provider] enabled = true cache-duration = "12h" image-patterns = [ "*.dkr.ecr.*.amazonaws.com", "*.dkr.ecr.*.amazonaws.com.rproxy.govskope.ca.cn", "*.dkr.ecr.*.amazonaws.eu", "*.dkr.ecr-fips.*.amazonaws.com", "*.dkr.ecr-fips.*.amazonaws.eu", "public.ecr.aws" ] [settings.kubernetes.node-labels] "eks.amazonaws.com/compute-type" = "hybrid" "eks.amazonaws.com/hybrid-credential-provider" = "iam-ra" [settings.host-containers.admin] enabled = true user-data = "" [settings.bootstrap-containers.eks-hybrid-setup] mode = "always" user-data = "" ``` Ersetzen Sie die Platzhalter durch die folgenden Werte: + ``: Der Name Ihres Amazon-EKS-Clusters. + ``: Der API-Server-Endpunkt Ihres Clusters. + ``: Das base64-codierte CA-Paket Ihres Clusters. + ``: Die AWS Region, in der Ihr Cluster gehostet wird, z. B. „us-east-1" + ``: Der Host-Name der Bottlerocket-Instance, der auch als Knotenname konfiguriert wird. Dies kann ein beliebiger eindeutiger Wert Ihrer Wahl sein, muss jedoch den [Benennungskonventionen für Kubernetes-Objekte](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names) entsprechen. Außerdem darf der von Ihnen verwendete Hostname nicht länger als 64 Zeichen sein. HINWEIS: Bei Verwendung des IAM-RA-Anbieters muss der Knotenname mit dem CN des Zertifikats auf dem Host übereinstimmen, wenn Sie die Vertrauensrichtlinie Ihrer IAM-Rolle für Hybridknoten mit der `"sts:RoleSessionName": "${aws:PrincipalTag/x509Subject/CN}"`-Ressourcenbedingung konfiguriert haben. + ``: Der Base64-kodierte Inhalt Ihrer Konfigurationsdatei. AWS Der Inhalt der Datei sollte wie folgt aussehen: ``` [default] credential_process = aws_signing_helper credential-process --certificate /root/.aws/node.crt --private-key /root/.aws/node.key --profile-arn --role-arn --trust-anchor-arn --role-session-name ``` + ``: Der Base64-codierte Inhalt der Bottlerocket-Admin-Container-Konfiguration. Durch Aktivieren des Admin-Containers können Sie zur Systemerkundung und zum Debuggen per SSH eine Verbindung zu Ihrer Bottlerocket-Instance herstellen. Obwohl dies keine erforderliche Einstellung ist, empfehlen wir, sie zur einfacheren Fehlerbehebung zu aktivieren. Weitere Informationen zur Authentifizierung mit dem Admin-Container finden Sie in der [Dokumentation zum Bottlerocket-Admin-Container](https://github.com/bottlerocket-os/bottlerocket-admin-container#authenticating-with-the-admin-container). Der Admin-Container akzeptiert SSH-Benutzer- und Schlüsseleingaben im JSON-Format, zum Beispiel: ``` { "user": "", "ssh": { "authorized-keys": [ "" ] } } ``` + ``: Der Base64-codierte Inhalt der Bottlerocket-Bootstrap-Container-Konfiguration. Weitere Informationen zur Konfiguration finden Sie in der [Dokumentation zum Bottlerocket-Bootstrap-Container](https://github.com/bottlerocket-os/bottlerocket-bootstrap-container). Der Bootstrap-Container ist für die Erstellung der IAM Roles Anywhere-Host-Zertifikats- und Zertifikat-Privatschlüsseldateien auf der Instance verantwortlich. Diese werden dann von `aws_signing_helper` verwendet, um temporäre Anmeldeinformationen für die Authentifizierung bei Ihrem Amazon-EKS-Cluster zu erhalten. Die an den Bootstrap-Container übergebenen Benutzerdaten haben die Form eines Befehlsaufrufs, der als Eingabe den Inhalt des zuvor erstellten Zertifikats und des privaten Schlüssels akzeptiert: ``` eks-hybrid-iam-ra-setup --certificate= --key= ``` ## Schritt 2: Bottlerocket vSphere VM mit Benutzerdaten bereitstellen Nachdem Sie die TOML-Datei erstellt haben, übergeben Sie sie während der Erstellung der vSphere-VM als Benutzerdaten. Beachten Sie, dass die Benutzerdaten konfiguriert werden müssen, bevor die VM zum ersten Mal gestartet wird. Daher müssen Sie diese bei der Erstellung der Instance angeben. Wenn Sie die VM im Voraus erstellen möchten, muss sie sich im Status „poweredOff“ befinden, bis Sie die Benutzerdaten dafür konfiguriert haben. Beispiel bei Verwendung der `govc`-CLI: ### Erstellen einer VM zum ersten Mal ``` govc vm.create \ -on=true \ -c=2 \ -m=4096 \ -net.adapter= \ -net= \ -e guestinfo.userdata.encoding="base64" \ -e guestinfo.userdata="$(base64 -w0 settings.toml)" \ -template= \ ``` ### Aktualisieren der Benutzerdaten für eine vorhandene VM ``` govc vm.create \ -on=false \ -c=2 \ -m=4096 \ -net.adapter= \ -net= \ -template= \ govc vm.change -vm \ -e guestinfo.userdata="$(base64 -w0 settings.toml)" \ -e guestinfo.userdata.encoding="base64" govc vm.power -on ``` In den oben genannten Abschnitten gibt die `-e guestinfo.userdata.encoding="base64"`-Option an, dass die Benutzerdaten base64-codiert sind. Die `-e guestinfo.userdata`-Option übergibt den base64-codierten Inhalt der `settings.toml`-Datei als Benutzerdaten an die Bottlerocket-Instance. Ersetzen Sie die Platzhalter durch Ihre spezifischen Werte, wie beispielsweise die Bottlerocket-OVA-Vorlage und die Netzwerkdetails. ## Schritt 3: Verbindung des Hybridknotens überprüfen Nach dem Start der Bottlerocket-Instance wird versucht, eine Verbindung zu Ihrem Amazon-EKS-Cluster herzustellen. Sie können die Verbindung in der Amazon-EKS-Konsole überprüfen, indem Sie zur Registerkarte „Rechnen“ für Ihren Cluster navigieren oder den folgenden Befehl ausführen: ``` kubectl get nodes ``` **Wichtig** Ihre Knoten haben den Status `Not Ready`, was zu erwarten ist und darauf zurückzuführen ist, dass auf Ihren Hybridknoten kein CNI ausgeführt wird. Wenn Ihre Knoten nicht dem Cluster beigetreten sind, sehen Sie unter [Fehlerbehebung bei Hybridknoten](hybrid-nodes-troubleshooting.md) nach. ## Schritt 4: CNI für Hybridknoten konfigurieren Um Ihre Hybridknoten für die Ausführung von Anwendungen vorzubereiten, führen Sie die Schritte in [CNI für Hybridknoten konfigurieren](hybrid-nodes-cni.md) aus. # Aktualisierung von Hybridknoten für Ihren Cluster Die Anleitung zum Upgrade von Hybridknoten ähnelt der für selbstverwaltete Amazon-EKS-Knoten, die in Amazon EC2 ausgeführt werden. Wir empfehlen Ihnen, neue Hybridknoten auf Ihrer Kubernetes-Zielversion zu erstellen, Ihre vorhandenen Anwendungen ordnungsgemäß auf die Hybridknoten der neuen Kubernetes-Version zu migrieren und die Hybridknoten der alten Kubernetes-Version aus Ihrem Cluster zu entfernen. Lesen Sie unbedingt die [Bewährten Methoden für Amazon-EKS-Upgrades](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html), bevor Sie ein Upgrade starten. Amazon EKS Hybrid Nodes verfügen über dieselbe [Kubernetes-Versionsunterstützung](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) für Amazon-EKS-Cluster mit Cloud-Knoten, einschließlich Standard- und erweiterten Support. Amazon EKS Hybrid Nodes befolgen dieselbe [Versionsabweichungsrichtlinie](https://kubernetes.io/releases/version-skew-policy/#supported-version-skew) für Knoten wie vorgeschaltete Kubernetes. Amazon EKS Hybrid Nodes dürfen keine neuere Version als die Amazon-EKS-Steuerebene aufweisen und Hybridknoten dürfen bis zu drei Kubernetes-Nebenversionen älter sein als die Nebenversion der Amazon-EKS-Steuerebene. Wenn Sie keine freien Kapazitäten haben, um neue Hybridknoten auf Ihrer Zielversion von Kubernetes für eine Cutover-Migrations-Upgrade-Strategie zu erstellen, können Sie alternativ die CLI (`nodeadm`) für Amazon EKS Hybrid Nodes verwenden, um die Kubernetes-Version Ihrer Hybridknoten vor Ort zu aktualisieren. **Wichtig** Wenn Sie Ihre Hybridknoten vor Ort mit `nodeadm` aktualisieren, kommt es während des Vorgangs zu Ausfallzeiten für den Knoten, bei denen die ältere Version der Kubernetes-Komponenten heruntergefahren und die Komponenten der neuen Kubernetes-Version installiert und gestartet werden. ## Voraussetzungen Stellen Sie vor dem Upgrade sicher, dass Sie die folgenden Voraussetzungen erfüllt haben. + Die Ziel-Kubernetes-Version für Ihr Hybridknoten-Upgrade muss gleich oder niedriger als die Version der Amazon-EKS-Steuerebene sein. + Wenn Sie eine Cutover-Migrations-Upgrade-Strategie verfolgen, müssen die neuen Hybridknoten, die Sie auf Ihrer Ziel-Kubernetes-Version installieren, die [Voraussetzungen für die Einrichtung von Hybridknoten](hybrid-nodes-prereqs.md)-Anforderungen erfüllen. Dies umfasst IP-Adressen innerhalb des Fern-Knoten-Netzwerk-CIDR, das Sie bei der Erstellung des Amazon-EKS-Clusters angegeben haben. + Sowohl für die Cutover-Migration als auch für direkte Upgrades müssen die Hybridknoten Zugriff auf die [erforderlichen Domains](hybrid-nodes-networking.md#hybrid-nodes-networking-on-prem) haben, um die neuen Versionen der Abhängigkeiten der Hybridknoten abzurufen. + Sie müssen kubectl auf Ihrem lokalen Rechner oder Ihrer Instance installiert haben, die Sie für die Interaktion mit Ihrem API-Endpunkt für Amazon EKS Kubernetes verwenden. + Die Version Ihres CNI muss die Kubernetes-Version unterstützen, auf die Sie aktualisieren. Ist dies nicht der Fall, aktualisieren Sie Ihre CNI-Version, bevor Sie Ihre Hybridknoten aktualisieren. Weitere Informationen finden Sie unter [CNI für Hybridknoten konfigurieren](hybrid-nodes-cni.md). ## Cutover-Migration (Blau-Grün)-Upgrades *Cutover-Migrations-Upgrades* beziehen sich auf den Prozess der Erstellung neuer Hybridknoten auf neuen Hosts mit Ihrer Ziel-Kubernetes-Version, der ordnungsgemäßen Migration Ihrer vorhandenen Anwendungen auf die neuen Hybridknoten auf Ihrer Ziel-Kubernetes-Version und der Entfernung der Hybridknoten auf der alten Kubernetes-Version aus Ihrem Cluster. Diese Strategie wird auch als Blau-Grün-Migration bezeichnet. 1. Verbinden Sie Ihre neuen Hosts als Hybridknoten, indem Sie die Schritte [Hybridknoten verbinden](hybrid-nodes-join.md) befolgen. Verwenden Sie beim Ausführen des `nodeadm install`-Befehls Ihre Ziel-Kubernetes-Version. 1. Aktivieren Sie die Kommunikation zwischen den neuen Hybridknoten auf der Kubernetes-Zielversion und Ihren Hybridknoten auf der alten Kubernetes-Version. Diese Konfiguration ermöglicht die Kommunikation zwischen Pods, während Sie Ihre Workload auf die Hybridknoten der Kubernetes-Zielversion migrieren. 1. Bestätigen Sie, dass Ihre Hybridknoten auf Ihrer Ziel-Kubernetes-Version Ihrem Cluster erfolgreich beigetreten sind und den Status „Bereit“ aufweisen. 1. Verwenden Sie den folgenden Befehl, um jeden der Knoten, die Sie entfernen möchten, als nicht planbar zu markieren. Dadurch wird verhindert, dass auf den zu ersetzenden Knoten neue Pods geplant oder neu geplant werden. Weitere Informationen finden Sie unter [kubectl cordon](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_cordon/) in der Kubernetes-Dokumentation. Ersetzen Sie `NODE_NAME` durch den Namen der Hybridknoten in der alten Kubernetes-Version. ``` kubectl cordon NODE_NAME ``` Mit dem folgenden Code-Ausschnitt können Sie alle Knoten einer bestimmten Kubernetes-Version (in diesem Fall `1.28`) identifizieren und abgrenzen. ``` K8S_VERSION=1.28 for node in $(kubectl get nodes -o json | jq --arg K8S_VERSION "$K8S_VERSION" -r '.items[] | select(.status.nodeInfo.kubeletVersion | match("\($K8S_VERSION)")).metadata.name') do echo "Cordoning $node" kubectl cordon $node done ``` 1. Wenn Ihre aktuelle Bereitstellung weniger als zwei CoreDNS-Replikate in Ihren Hybridknoten ausführt, skalieren die Bereitstellung auf mindestens zwei Replikate. Wir empfehlen, dass Sie aus Gründen der Ausfallsicherheit im Normalbetrieb mindestens zwei CoreDNS-Replikate in Hybridknoten ausführen. ``` kubectl scale deployments/coredns --replicas=2 -n kube-system ``` 1. Leeren Sie jeden Hybridknoten auf der alten Kubernetes-Version, den Sie aus Ihrem Cluster entfernen möchten, mit dem folgenden Befehl. Weitere Informationen zum Entleeren von Knoten finden Sie unter [Sicheres Entleeren eines Knotens](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) in der Kubernetes-Dokumentation. Ersetzen Sie `NODE_NAME` durch den Namen der Hybridknoten in der alten Kubernetes-Version. ``` kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data ``` Mit dem folgenden Code-Ausschnitt können Sie alle Knoten einer bestimmten Kubernetes-Version (in diesem Fall `1.28`) identifizieren und entleeren. ``` K8S_VERSION=1.28 for node in $(kubectl get nodes -o json | jq --arg K8S_VERSION "$K8S_VERSION" -r '.items[] | select(.status.nodeInfo.kubeletVersion | match("\($K8S_VERSION)")).metadata.name') do echo "Draining $node" kubectl drain $node --ignore-daemonsets --delete-emptydir-data done ``` 1. Sie können `nodeadm` verwenden, um die Artefakte der Hybridknoten zu stoppen und vom Host zu entfernen. Sie müssen `nodeadm` mit einem Benutzer ausführen, der über Root-/Sudo-Berechtigungen verfügt. Standardmäßig wird `nodeadm uninstall` nicht fortgesetzt, wenn auf dem Knoten noch Pods vorhanden sind. Weitere Informationen finden Sie unter [`nodeadm`-Referenz für Hybridknoten](hybrid-nodes-nodeadm.md). ``` nodeadm uninstall ``` 1. Nachdem die Artefakte der Hybridknoten angehalten und deinstalliert wurden, entfernen Sie die Knoten-Ressource aus Ihrem Cluster. ``` kubectl delete node node-name ``` Mit dem folgenden Code-Ausschnitt können Sie alle Knoten einer bestimmten Kubernetes-Version (in diesem Fall `1.28`) identifizieren und löschen. ``` K8S_VERSION=1.28 for node in $(kubectl get nodes -o json | jq --arg K8S_VERSION "$K8S_VERSION" -r '.items[] | select(.status.nodeInfo.kubeletVersion | match("\($K8S_VERSION)")).metadata.name') do echo "Deleting $node" kubectl delete node $node done ``` 1. Abhängig von Ihrer CNI-Wahl können nach der Ausführung der obigen Schritte Artefakte auf Ihren Hybridknoten verbleiben. Weitere Informationen finden Sie unter [CNI für Hybridknoten konfigurieren](hybrid-nodes-cni.md). ## Direkte Upgrades Der direkte Upgrade-Prozess bezieht sich auf die Verwendung von `nodeadm upgrade` zum Upgrade der Kubernetes-Version für Hybridknoten ohne Verwendung neuer physischer oder virtueller Hosts und einer Cutover-Migrationsstrategie. Der `nodeadm upgrade`-Prozess beendet die vorhandenen älteren Kubernetes-Komponenten, die auf dem Hybridknoten ausgeführt werden, deinstalliert die vorhandenen älteren Kubernetes-Komponenten, installiert die neuen Ziel-Kubernetes-Komponenten und startet die neuen Ziel-Kubernetes-Komponenten. Es wird dringend empfohlen, jeweils nur einen Knoten zu aktualisieren, um die Auswirkungen auf Anwendungen, die auf den Hybridknoten ausgeführt werden, zu minimieren. Die Dauer dieses Vorgangs hängt von Ihrer Netzwerkbandbreite und Latenz ab. 1. Verwenden Sie den folgenden Befehl, um den Knoten, den Sie aktualisieren, als nicht planbar zu markieren. Dadurch wird sichergestellt, dass auf dem Knoten, den Sie aktualisieren, keine neuen Pods geplant oder neu geplant werden. Weitere Informationen finden Sie unter [kubectl cordon](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_cordon/) in der Kubernetes-Dokumentation. `NODE_NAME` durch den Namen des Hybridknotens, den Sie aktualisieren, ersetzen ``` kubectl cordon NODE_NAME ``` 1. Entleeren Sie den Knoten, den Sie aktualisieren, mit dem folgenden Befehl. Weitere Informationen zum Entleeren von Knoten finden Sie unter [Sicheres Entleeren eines Knotens](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) in der Kubernetes-Dokumentation. Ersetzen Sie `NODE_NAME` durch den Namen des Hybridknotens, den Sie aktualisieren. ``` kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data ``` 1. Führen Sie `nodeadm upgrade` auf dem Hybridknoten aus, den Sie aktualisieren. Sie müssen `nodeadm` mit einem Benutzer ausführen, der über Root-/Sudo-Berechtigungen verfügt. Der Name des Knotens bleibt während des Upgrades für die Anmeldeinformationsanbieter AWS SSM und AWS IAM Roles Anywhere erhalten. Sie können die Anmeldeinformationsanbieter während des Upgrades nicht ändern. Konfigurationswerte für `nodeConfig.yaml` finden Sie unter [`nodeadm`-Referenz für Hybridknoten](hybrid-nodes-nodeadm.md). Ersetzen Sie `K8S_VERSION` durch die Ziel-Version von Kubernetes, auf die Sie aktualisieren möchten. ``` nodeadm upgrade K8S_VERSION -c file://nodeConfig.yaml ``` 1. Um die Planung von Pods auf dem Knoten nach dem Upgrade zuzulassen, geben Sie Folgendes ein. Ersetzen Sie `NODE_NAME` durch den Namen des Knotens. ``` kubectl uncordon NODE_NAME ``` 1. Überwachen Sie den Status Ihrer Hybridknoten und warten Sie, bis Ihre Knoten heruntergefahren sind und mit dem Status „Bereit“ auf der neuen Kubernetes-Version neu gestartet wurden. ``` kubectl get nodes -o wide -w ``` # Patch-Sicherheitsaktualisierungen für Hybridknoten In diesem Thema wird das Verfahren zum direkten Patchen von Sicherheitsupdates für bestimmte Pakete und Abhängigkeiten beschrieben, die auf Ihren Hybridknoten ausgeführt werden. Als bewährte Methode empfehlen wir Ihnen, Ihre Hybridknoten regelmäßig zu aktualisieren, um CVEs und Sicherheits-Patches zu erhalten. Schritte zum Upgrade der Kubernetes-Version finden Sie unter [Aktualisierung von Hybridknoten für Ihren Cluster](hybrid-nodes-upgrade.md). Ein Beispiel für Software, die möglicherweise Sicherheits-Patches benötigt, ist `containerd`. ## `Containerd` `containerd` ist die Standard-Kubernetes-Container-Laufzeitumgebung und Kernabhängigkeit für EKS-Hybridknoten, die zur Verwaltung des Container-Lebenszyklus verwendet wird, einschließlich des Abrufens von Images und der Verwaltung der Container-Ausführung. Auf einem Hybridknoten können Sie `containerd` über die [nodeadm CLI](https://docs.aws.amazon.com/eks/latest/userguide/hybrid-nodes-nodeadm.html) oder manuell installieren. Abhängig vom Betriebssystem Ihres Knotens installiert `nodeadm` `containerd` aus dem vom Betriebssystem bereitgestellten Paket oder dem Docker-Paket. Wenn eine CVE in `containerd` veröffentlicht wurde, stehen Ihnen die folgenden Optionen zur Verfügung, um auf Ihren Hybridknoten ein Upgrade auf die gepatchte Version von `containerd` durchzuführen. ## Schritt 1: Überprüfen, ob der Patch in den Paket-Managern veröffentlicht wurde Sie können überprüfen, ob der `containerd`-CVE-Patch für den jeweiligen Betriebssystem-Paket-Manager veröffentlicht wurde, indem Sie die entsprechenden Sicherheitsberichte lesene: + [Amazon Linux 2023](https://alas.aws.amazon.com/alas2023.html) + [RHEL](https://access.redhat.com/security/security-updates/security-advisories) + [Ubuntu 20.04](https://ubuntu.com/security/notices?order=newest&release=focal) + [Ubuntu 22.04](https://ubuntu.com/security/notices?order=newest&release=jammy) + [Ubuntu 24.04](https://ubuntu.com/security/notices?order=newest&release=noble) Wenn Sie das Docker-Repository als Quelle von `containerd` verwenden, können Sie die [Docker-Sicherheitsankündigungen](https://docs.docker.com/security/security-announcements/) überprüfen, um die Verfügbarkeit der gepatchten Version im Docker-Repository zu ermitteln. ## Schritt 2: Methode zur Installation des Patches auswählen Es gibt drei Methoden, um Sicherheitsupgrades direkt auf Knoten zu patchen und zu installieren. Welche Methode Sie verwenden können, hängt davon ab, ob der Patch vom Betriebssystem im Paket-Manager verfügbar ist oder nicht: 1. Installieren Sie Patches mit `nodeadm upgrade`, die in Paket-Managern veröffentlicht wurden, siehe [Schritt 2 a](#hybrid-nodes-security-nodeadm). 1. Installieren Sie Patches direkt mit den Paket-Managern, siehe [Schritt 2 b](#hybrid-nodes-security-package). 1. Installieren Sie benutzerdefinierte Patches, die nicht in Paket-Managern veröffentlicht wurden. Beachten Sie, dass für benutzerdefinierte Patches für `containerd`, [Schritt 2 c](#hybrid-nodes-security-manual), besondere Überlegungen angestellt werden müssen. ## Schritt 2 a: Patchen mit `nodeadm upgrade` Nachdem Sie bestätigt haben, dass der `containerd`-CVE-Patch im Betriebssystem oder in den Docker-Repos (entweder Apt oder RPM) veröffentlicht wurde, können Sie mit dem `nodeadm upgrade`-Befehl auf die neueste Version von `containerd` aktualisieren. Da es sich hierbei nicht um ein Upgrade der Kubernetes-Version handelt, müssen Sie Ihre aktuelle Kubernetes-Version an den `nodeadm`-Upgrade-Befehl übergeben. ``` nodeadm upgrade K8S_VERSION --config-source file:///root/nodeConfig.yaml ``` ## Schritt 2 b: Patchen mit Paket-Managern des Betriebssystems Alternativ können Sie auch über den jeweiligen Paket-Manager aktualisieren und damit das `containerd`-Paket wie folgt aktualisieren. **Amazon Linux 2023** ``` sudo yum update -y sudo yum install -y containerd ``` **RHEL** ``` sudo yum install -y yum-utils sudo yum-config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo sudo yum update -y sudo yum install -y containerd ``` **Ubuntu ** ``` sudo mkdir -p /etc/apt/keyrings sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt update -y sudo apt install -y --only-upgrade containerd.io ``` ## Schritt 2 c: `Containerd`-CVE-Patch nicht in Paket-Managern veröffentlicht Wenn die gepatchte `containerd`-Version nur über andere Kanäle als den Paket-Manager verfügbar ist, beispielsweise in GitHub-Veröffentlichungen, können Sie `containerd` von der offiziellen GitHub-Website installieren. 1. Wenn der Rechner bereits als Hybridknoten dem Cluster beigetreten ist, müssen Sie den `nodeadm uninstall`-Befehl ausführen. 1. Installieren Sie die offiziellen `containerd`-Binärdateien. Befolgen Sie die [offiziellen Installationsschritte](https://github.com/containerd/containerd/blob/main/docs/getting-started.md#option-1-from-the-official-binaries) auf GitHub. 1. Führen Sie den `nodeadm install`-Befehl mit dem `--containerd-source`-Argument `none` aus, wodurch die `containerd`-Installation über `nodeadm` übersprungen wird. Sie können den Wert `none` in der `containerd`-Quelle für jedes Betriebssystem verwenden, auf dem der Knoten ausgeführt wird. ``` nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER --containerd-source none ``` # Hybridknoten entfernen In diesem Thema wird beschrieben, wie Sie Hybridknoten aus Ihrem Amazon-EKS-Cluster löschen. Sie müssen Ihre Hybridknoten mit einem Kubernetes-kompatiblen Tool Ihrer Wahl, wie beispielsweise [kubectl](https://kubernetes.io/docs/reference/kubectl/), löschen. Die Gebühren für Hybridknoten werden eingestellt, sobald das Knotenobjekt aus dem Amazon-EKS-Cluster entfernt wird. Weitere Informationen zu den Preisen für Hybridknoten finden Sie unter [Amazon EKS – Preise](https://aws.amazon.com/eks/pricing/). **Wichtig** Das Entfernen von Knoten führt zu einer Unterbrechung der auf dem Knoten ausgeführten Workloads. Bevor Sie Hybridknoten löschen, empfehlen wir Ihnen, zunächst den Knoten zu entleeren, um Pods auf einen anderen aktiven Knoten zu verschieben. Weitere Informationen zum Entleeren von Knoten finden Sie unter [Sicheres Entleeren eines Knotens](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) in der Kubernetes-Dokumentation. Führen Sie die folgenden kubectl-Schritte von Ihrem lokalen Computer oder Ihrer Instance aus, die Sie für die Interaktion mit dem Kubernetes-API-Endpunkt des Amazon-EKS-Clusters verwenden. Wenn Sie eine bestimmte `kubeconfig`-Datei verwenden, verwenden Sie das `--kubeconfig`-Flag. ## Schritt 1: Knoten auflisten ``` kubectl get nodes ``` ## Schritt 2: Knoten entleeren Weitere Informationen zu diesem `kubectl drain`-Befehl finden Sie unter [kubectl drain](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_drain/) in der Kubernetes-Dokumentation. ``` kubectl drain --ignore-daemonsets ``` ## Schritt 3: Hybridknoten-Artefakte beenden und deinstallieren Sie können die CLI von Amazon EKS Hybrid Nodes (`nodeadm`) verwenden, um die Hybridknoten-Artefakte auf dem Host zu beenden und zu entfernen. Sie müssen `nodeadm` mit einem Benutzer ausführen, der über Root-/Sudo-Berechtigungen verfügt. Standardmäßig wird `nodeadm uninstall` nicht fortgesetzt, wenn auf dem Knoten noch Pods vorhanden sind. Wenn Sie AWS Systems Manager (SSM) als Anmeldeinformationsanbieter verwenden, wird der Host mit diesem `nodeadm uninstall`-Befehl als von AWS SSM verwaltete Instance deregistriert. Weitere Informationen finden Sie unter [`nodeadm`-Referenz für Hybridknoten](hybrid-nodes-nodeadm.md). ``` nodeadm uninstall ``` ## Schritt 4: Knoten aus dem Cluster entfernen Nachdem die Artefakte der Hybridknoten angehalten und deinstalliert wurden, entfernen Sie die Knoten-Ressource aus Ihrem Cluster. ``` kubectl delete node ``` ## Schritt 5: Auf verbleibende Artefakte überprüfen Abhängig von Ihrer CNI-Wahl können nach der Ausführung der obigen Schritte Artefakte auf Ihren Hybridknoten verbleiben. Weitere Informationen finden Sie unter [CNI für Hybridknoten konfigurieren](hybrid-nodes-cni.md).