**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.
# `nodeadm`-Referenz für Hybridknoten
Die Amazon EKS Hybrid Nodes CLI (`nodeadm`) vereinfacht die Installation, Konfiguration, Registrierung und Deinstallation der Hybridknoten-Komponenten. Sie können `nodeadm` in Ihre Betriebssystem-Images einbinden, um das Bootstrapping von Hybridknoten zu automatisieren. Weitere Informationen finden Sie unter [Vorbereitung des Betriebssystems für Hybridknoten](hybrid-nodes-os.md).
Die `nodeadm`-Version für Hybridknoten unterscheidet sich von der `nodeadm`-Version, die zum Bootstrapping von Amazon-EC2-Instances als Knoten in Amazon-EKS-Clustern verwendet wird. Befolgen Sie die Dokumentation und Referenzen für die entsprechende `nodeadm`-Version. Diese Dokumentationsseite bezieht sich auf die `nodeadm`-Version für Hybridknoten.
Der Quellcode für die Hybridknoten `nodeadm` ist im https://github.com/aws/ GitHub eks-hybrid-Repository veröffentlicht.
**Wichtig**
Sie müssen `nodeadm` mit einem Benutzer arbeiten, der über Rechte verfügt root/sudo .
## Herunterladen von `nodeadm`
Die Hybridknoten-Version von `nodeadm` wird in Amazon S3 gehostet, das von Amazon CloudFront bereitgestellt wird. 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
```
## `nodeadm install`
Der `nodeadm install`-Befehl wird verwendet, um die Artefakte und Abhängigkeiten zu installieren, die zum Ausführen und Verbinden von Hybridknoten mit einem Amazon-EKS-Cluster erforderlich sind. Der `nodeadm install`-Befehl kann einzeln auf jedem Hybridknoten oder während Image-Entwicklungs-Pipelines ausgeführt werden, um die Abhängigkeiten der Hybridknoten in Betriebssystem-Images vorzuinstallieren.
**Usage**
```
nodeadm install [KUBERNETES_VERSION] [flags]
```
**Positionelle Argumente**
(Erforderlich) `KUBERNETES_VERSION` Die zu installierende Haupt- und Nebenversion von EKS Kubernetes, zum Beispiel `1.32`
**Flags**
| Name | Erforderlich | Description |
| --- | --- | --- |
| `-p`, `--credential-provider` | TRUE | Zu installierender Anmeldeinformationsanbieter. Unterstützte Werte sind `iam-ra` und `ssm`. Weitere Informationen finden Sie unter [Vorbereitung der Anmeldeinformationen für Hybridknoten](hybrid-nodes-creds.md). |
| `-s`, `--containerd-source` | FALSE | Quelle für `containerd`. `nodeadm` unterstützt die Installation von `containerd` aus der Betriebssystemverteilung, Docker-Pakete und das Überspringen der `containerd`-Installation. **Werte** `distro`- Dies ist der Standardwert. `nodeadm`installiert das neueste vom Node-Betriebssystem verteilte `containerd` Paket, das mit der EKS Kubernetes-Version kompatibel ist. `distro`ist kein unterstützter Wert für Red Hat Enterprise Linux (RHEL) -Betriebssysteme. `docker`- installiert `nodeadm` das neueste von Docker erstellte und vertriebene `containerd` Paket, das mit der EKS Kubernetes-Version kompatibel ist. `docker`ist kein unterstützter Wert für Amazon Linux 2023. `none` – `nodeadm` installiert das `containerd`-Paket nicht. Sie müssen `containerd` manuell installieren, bevor Sie `nodeadm init` ausführen. |
| `-r`, `--region` | FALSE | Gibt die AWS Region für das Herunterladen von Artefakten wie dem SSM-Agenten an. Standardeinstellung: `us-west-2`. |
| `-t`, `--timeout` | FALSE | Maximale Dauer des Installationsbefehls. Die Eingabe erfolgt im Zeitdauerformat. Zum Beispiel `1h23m`. Die Standard-Zeitüberschreitung für den Download beim Installationsbefehl beträgt 20 Minuten. |
| `-h`, `--help` | FALSE | Zeigt eine Hilfemeldung mit verfügbaren Flag-, Unterbefehls- und Positionswertparametern an. |
**Beispiele**
Installieren Sie die Kubernetes-Version `1.32` mit AWS Systems Manager (SSM) als Anmeldeinformationsanbieter
```
nodeadm install 1.32 --credential-provider ssm
```
Installieren Sie die Kubernetes-Version `1.32` mit AWS Systems Manager (SSM) als Anmeldeinformationsanbieter und Docker als Container-Quelle mit einem Download-Timeout von 20 Minuten.
```
nodeadm install 1.32 --credential-provider ssm --containerd-source docker --timeout 20m
```
Installieren Sie die Kubernetes-Version mit IAM Roles Anywhere als Anmeldeinformationsanbieter `1.32` AWS
```
nodeadm install 1.32 --credential-provider iam-ra
```
## `nodeadm config check`
Der `nodeadm config check`-Befehl überprüft die angegebene Knotenkonfiguration auf Fehler. Mit diesem Befehl kann die Richtigkeit einer Hybridknoten-Konfigurationsdatei überprüft und validiert werden.
**Usage**
```
nodeadm config check [flags]
```
**Flags**
| Name | Erforderlich | Description |
| --- | --- | --- |
| `-c`, `--config-source` | TRUE | Quelle der nodeadm-Konfiguration. Bei Hybridknoten sollte die Eingabe einer URI mit Dateischema folgen. |
| `-h`, `--help` | FALSE | Zeigt eine Hilfemeldung mit verfügbaren Flag-, Unterbefehls- und Positionswertparametern an. |
**Beispiele**
```
nodeadm config check -c file://nodeConfig.yaml
```
## `nodeadm init`
Der `nodeadm init`-Befehl startet und verbindet den Hybridknoten mit dem konfigurierten Amazon-EKS-Cluster. Einzelheiten zur Konfiguration der `nodeConfig.yaml`-Datei finden Sie unter [Knotenkonfiguration für SSM-Hybridaktivierungen](#hybrid-nodes-node-config-ssm) oder [Knotenkonfiguration für IAM Roles Anywhere](#hybrid-nodes-node-config-iamra).
**Usage**
```
nodeadm init [flags]
```
**Flags**
| Name | Erforderlich | Description |
| --- | --- | --- |
| `-c`, `--config-source` | TRUE | Quelle der `nodeadm`-Konfiguration. Bei Hybridknoten sollte die Eingabe einer URI mit Dateischema folgen. |
| `-s`, `--skip` | FALSE | Zu überspringende Phasen von `init`. Es wird nicht empfohlen, eine der Phasen zu überspringen, es sei denn, dies trägt zur Behebung eines Problems bei. **Werte** `install-validation` überspringt die Überprüfung, ob der vorherige Installationsbefehl erfolgreich ausgeführt wurde. `cni-validation` überspringt die Überprüfung, ob die VXLAN-Ports von Cilium oder Calico CNI geöffnet sind, wenn die Firewall auf dem Knoten aktiviert ist. `node-ip-validation` überspringt die Überprüfung, ob die Knoten-IP innerhalb eines CIDR in den Netzwerken der Fern-Knoten liegt. |
| `-h`, `--help` | FALSE | Zeigt eine Hilfemeldung mit verfügbaren Flag-, Unterbefehls- und Positionswertparametern an. |
**Beispiele**
```
nodeadm init -c file://nodeConfig.yaml
```
## `nodeadm upgrade`
Der `nodeadm upgrade`-Befehl aktualisiert alle installierten Artefakte auf die neueste Version und führt einen Bootstrapping des Knotens durch, um die aktualisierten Artefakte zu konfigurieren und dem EKS-Cluster in AWS beizutreten. Ein Upgrade ist ein Befehl zur Unterbrechung der auf dem Knoten ausgeführten Workloads. Verschieben Sie Ihre Workloads vor dem Upgrade auf einen anderen Knoten.
**Usage**
```
nodeadm upgrade [KUBERNETES_VERSION] [flags]
```
**Positionelle Argumente**
(Erforderlich) `KUBERNETES_VERSION` Die zu installierende Haupt- und Nebenversion von EKS Kubernetes, zum Beispiel `1.32`
**Flags**
| Name | Erforderlich | Description |
| --- | --- | --- |
| `-c`, `--config-source` | TRUE | Quelle der `nodeadm`-Konfiguration. Bei Hybridknoten sollte die Eingabe einer URI mit Dateischema folgen. |
| `-t`, `--timeout` | FALSE | Zeitüberschreitung beim Herunterladen von Artefakten. Die Eingabe erfolgt im Zeitdauerformat. Beispielsweise 1 Stunde und 23 Minuten Die Standard-Zeitüberschreitung für den Download des Upgrade-Befehls beträgt 10 Minuten. |
| `-s`, `--skip` | FALSE | Zu überspringende Phasen des Upgrades. Es wird nicht empfohlen, eine der Phasen zu überspringen, es sei denn, dies trägt zur Behebung eines Problems bei **Werte** `pod-validation` überspringt die Überprüfung, ob alle Pods auf dem Knoten ausgeführt werden, mit Ausnahme von Daemon-Sets und statischen Pods. `node-validation` überspringt die Überprüfung, ob der Knoten abgesperrt wurde. `init-validation` überspringt die Überprüfung, ob der Knoten erfolgreich initialisiert wurde, bevor das Upgrade ausgeführt wird. `containerd-major-version-upgrade`verhindert Container-Hauptversions-Upgrades während des Knoten-Upgrades. |
| `-h`, `--help` | FALSE | Zeigt eine Hilfemeldung mit verfügbaren Flag-, Unterbefehls- und Positionswertparametern an. |
**Beispiele**
```
nodeadm upgrade 1.32 -c file://nodeConfig.yaml
```
```
nodeadm upgrade 1.32 -c file://nodeConfig.yaml --timeout 20m
```
## `nodeadm uninstall`
Der `nodeadm uninstall`-Befehl stoppt und entfernt die während `nodeadm install` installierten Artefakte `nodeadm`, einschließlich kubelet und containerd. Beachten Sie, dass der Deinstallations-Befehl Ihre Hybridknoten nicht aus Ihrem Cluster entfernt oder löscht. Sie müssen die Entleerungs- und Löschvorgänge separat ausführen. Weitere Informationen finden Sie unter [Hybridknoten entfernen](hybrid-nodes-remove.md). Standardmäßig wird `nodeadm uninstall` nicht fortgesetzt, wenn auf dem Knoten noch Pods vorhanden sind. Ebenso entfernt `nodeadm uninstall` keine CNI-Abhängigkeiten oder Abhängigkeiten anderer Kubernetes-Add-Ons, die Sie in Ihrem Cluster ausführen. Informationen zum vollständigen Entfernen der CNI-Installation von Ihrem Host finden Sie in den Anweisungen unter [CNI für Hybridknoten konfigurieren](hybrid-nodes-cni.md). Wenn Sie AWS SSM-Hybrid-Aktivierungen als Anbieter für lokale Anmeldeinformationen verwenden, werden Ihre Hosts mit dem `nodeadm uninstall` Befehl als SSM-verwaltete Instanzen deregistriert. AWS
**Usage**
```
nodeadm uninstall [flags]
```
**Flags**
| Name | Erforderlich | Description |
| --- | --- | --- |
| `-s`, `--skip` | FALSE | Zu überspringende Phasen der Deinstallation. Es wird nicht empfohlen, eine der Phasen zu überspringen, es sei denn, dies trägt zur Behebung eines Problems bei. **Werte** `pod-validation` überspringt die Überprüfung, ob alle Pods auf dem Knoten ausgeführt werden, mit Ausnahme von Daemon-Sets und statischen Pods. `node-validation` überspringt die Überprüfung, ob der Knoten abgesperrt wurde. `init-validation` überspringt die Überprüfung, ob der Knoten erfolgreich initialisiert wurde, bevor die Deinstallation ausgeführt wird. |
| `-h`, `--help` | FALSE | Zeigt eine Hilfemeldung mit verfügbaren Flag-, Unterbefehls- und Positionswertparametern an. |
| `-f`, `--force` | FALSE | Erzwingen Sie das Löschen zusätzlicher Verzeichnisse, die möglicherweise verbleibende Dateien von Kubernetes- und CNI-Komponenten enthalten. **WARNUNG** Dadurch werden alle Inhalte in den Standardverzeichnissen von Kubernetes und CNI (`/var/lib/cni`, `/etc/cni/net.d` usw.) gelöscht. Verwenden Sie dieses Flag nicht, wenn Sie Ihre eigenen Daten an diesen Speicherorten speichern. Ab nodeadm `v1.0.9` löscht der `./nodeadm uninstall --skip node-validation,pod-validation --force`-Befehl das `/var/lib/kubelet`-Verzeichnis nicht mehr. Dies liegt daran, dass es Pod-Volumes und Volume- Unterpfad-Verzeichnisse enthalten kann, die manchmal das eingebundene Knoten-Dateisystem enthalten. **Tipps zur sicheren Handhabung** - Das Löschen von eingebundenen Pfaden kann zum versehentlichen Löschen des tatsächlich eingebundenen Dateisystems des Knotens führen. Bevor Sie das `/var/lib/kubelet`-Verzeichnis manuell löschen, überprüfen Sie sorgfältig alle aktiven Einbindungen und binden Sie alle Volumes sicher aus, um Datenverlust zu vermeiden. |
**Beispiele**
```
nodeadm uninstall
```
```
nodeadm uninstall --skip node-validation,pod-validation
```
## `nodeadm debug`
Der `nodeadm debug`-Befehl kann zur Fehlerbehebung bei fehlerhaften oder falsch konfigurierten Hybridknoten verwendet werden. Es bestätigt, dass die folgenden Anforderungen erfüllt sind.
+ Der Knoten hat Netzwerkzugriff auf die zum Abrufen der Anmeldeinformationen erforderlichen AWS APIs
+ Der Knoten ist in der Lage, AWS Anmeldeinformationen für die konfigurierte IAM-Rolle für Hybridknoten abzurufen.
+ Der Knoten verfügt über Netzwerkzugriff auf den EKS-Kubernetes-API-Endpunkt und die Gültigkeit des EKS-Kubernetes-API-Endpunktzertifikats,
+ Der Knoten kann sich beim EKS-Cluster authentifizieren, seine Identität im Cluster ist gültig und der Knoten hat Zugriff auf den EKS-Cluster über die für den EKS-Cluster konfigurierte VPC.
Wenn Fehler gefunden werden, werden in der Ausgabe des Befehls Schritte zur Fehlerbehebung vorgeschlagen. Bestimmte Validierungsschritte zeigen untergeordnete Prozesse an. Wenn diese fehlschlagen, wird die Ausgabe in einem stderr-Abschnitt unter dem Validierungsfehler angezeigt.
**Usage**
```
nodeadm debug [flags]
```
**Flags**
| Name | Erforderlich | Description |
| --- | --- | --- |
| `-c`, `--config-source` | TRUE | Quelle der `nodeadm`-Konfiguration. Bei Hybridknoten sollte die Eingabe einer URI mit Dateischema folgen. |
| `--no-color` | FALSE | Deaktiviert die Farbausgabe. Nützlich für die Automatisierung. |
| `-h`, `--help` | FALSE | Zeigt eine Hilfemeldung mit verfügbaren Flag-, Unterbefehls- und Positionswertparametern an. |
**Beispiele**
```
nodeadm debug -c file://nodeConfig.yaml
```
## Speicherorte für Nodeadm-Dateien
### nodeadm-Installation
Bei der Ausführung von `nodeadm install` werden die folgenden Dateien und Dateispeicherorte konfiguriert.
| Artefakt | Pfad |
| --- | --- |
| CLI für IAM Roles Anywhere | /\$1signing\$1helper usr/local/bin/aws |
| Kubelet-Binärdateien | /usr/bin/kubelet |
| Kubectl-Binärdatei | usr/local/bin/kubectl |
| ECR-Anmeldeinformationsanbieter | /etc/eks/image-credential-provider/ecr-Anmeldeinformationsanbieter |
| AWS IAM-Authentifikator | /-iam-Authentifikator usr/local/bin/aws |
| CLI für SSM-Einrichtung | /opt/ssm/ssm-setup-cli |
| SSM-Agent | Auf Ubuntu -/-ssm-agent snap/amazon-ssm-agent/current/amazon Auf RHEL & -/-ssm-agent AL2023 usr/bin/amazon |
| Containerd | Auf Ubuntu & -/ AL2023 usr/bin/containerd Auf RHEL – /bin/containerd |
| Iptables | Auf Ubuntu & AL2023 -/usr/sbin/iptables Auf RHEL – /sbin/iptables |
| CNI-Plugins | /opt/cni/bin |
| Nachverfolgung installierter Artefakte | /opt/nodeadm/tracker |
### nodeadm init
Bei der Ausführung von `nodeadm init` werden die folgenden Dateien und Dateispeicherorte konfiguriert.
| Name | Pfad |
| --- | --- |
| Kubelet kubeconfig | /var/lib/kubelet/kubeconfig |
| Kubelet-Konfiguration | /etc/kubernetes/kubelet/config.json |
| Kubelet-systemd-Einheit | /.dienst etc/systemd/system/kubelet |
| Konfiguration des Image-Anmeldeinformationsanbieters | /.json etc/eks/image-credential-provider/config |
| Kubelet-env-Datei | /etc/eks/kubelet/environment |
| Kubelet Certs | /.crt etc/kubernetes/pki/ca |
| Containerd-Konfiguration | /.toml etc/containerd/config |
| Konfiguration der Containerd-Kernelmodule | /.conf etc/modules-load.d/containerd |
| AWS Konfigurationsdatei | /etc/aws/hybrid/config |
| AWS Anmeldeinformationsdatei (wenn Anmeldeinformationsdatei aktiviert ist) | /eks-hybrid/.aws/credentials |
| AWS Helper-Systemeinheit signieren | /etc/systemd/system/aws\$1signing\$1helper\$1update.service |
| Sysctl-Konfigurationsdatei | /etc/sysctl.d/99-nodeadm.conf |
| Ca-certificates | /etc/ssl/certs/ca-zertifikate.crt |
| GPG-Schlüsseldatei | /etc/apt/keyrings/docker.asc |
| Docker-Repo-Quelldatei | /.liste etc/apt/sources.list.d/docker |
## Knotenkonfiguration für SSM-Hybridaktivierungen
Im Folgenden finden Sie ein Beispiel für die `nodeConfig.yaml` Verwendung von AWS SSM-Hybrid-Aktivierungen für Anmeldeinformationen für Hybridknoten.
```
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: # Name of the EKS cluster
region: # AWS Region where the EKS cluster resides
hybrid:
ssm:
activationCode: # SSM hybrid activation code
activationId: # SSM hybrid activation id
```
## Knotenkonfiguration für IAM Roles Anywhere
Im Folgenden finden Sie ein Beispiel `nodeConfig.yaml` für AWS IAM Roles Anywhere für Anmeldeinformationen für Hybridknoten.
Wenn `nodeName` Sie AWS IAM Roles Anywhere als Ihren lokalen Anbieter für Anmeldeinformationen verwenden, müssen die in Ihrer `nodeadm` Konfiguration verwendeten Berechtigungen mit den Berechtigungen übereinstimmen, die Sie für Ihre IAM-Rolle für Hybrid Nodes festgelegt haben. Wenn Ihre Berechtigungen für die IAM-Rolle Hybrid Nodes beispielsweise nur zulassen, dass AWS IAM Roles Anywhere die Rolle übernimmt, wenn der Name der Rollensitzung dem CN des Host-Zertifikats entspricht, muss der `nodeName` in Ihrer `nodeadm` Konfiguration dem CN Ihrer Zertifikate entsprechen. Der von Ihnen verwendete `nodeName` kann nicht länger als 64 Zeichen sein. Weitere Informationen finden Sie unter [Vorbereitung der Anmeldeinformationen für Hybridknoten](hybrid-nodes-creds.md).
```
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: # Name of the EKS cluster
region: # AWS Region where the EKS cluster resides
hybrid:
iamRolesAnywhere:
nodeName: # Name of the node
trustAnchorArn: # ARN of the IAM Roles Anywhere trust anchor
profileArn: # ARN of the IAM Roles Anywhere profile
roleArn: # ARN of the Hybrid Nodes IAM role
certificatePath: # Path to the certificate file to authenticate with the IAM Roles Anywhere trust anchor
privateKeyPath: # Path to the private key file for the certificate
```
## Knotenkonfiguration zur Anpassung von kubelet (optional)
Sie können die kubelet-Konfiguration und Flags in Ihrer `nodeadm`-Konfiguration übergeben. Im folgenden Beispiel erfahren Sie, wie Sie eine zusätzliche Knotenbezeichnung `abc.amazonaws.com/test-label` und Konfiguration hinzufügen, um `shutdownGracePeriod` auf 30 Sekunden festzulegen.
```
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: # Name of the EKS cluster
region: # AWS Region where the EKS cluster resides
kubelet:
config: # Map of kubelet config and values
shutdownGracePeriod: 30s
flags: # List of kubelet flags
- --node-labels=abc.company.com/test-label=true
hybrid:
ssm:
activationCode: # SSM hybrid activation code
activationId: # SSM hybrid activation id
```
## Knotenkonfiguration zur Anpassung von containerd (optional)
Sie können eine benutzerdefinierte containerd-Konfiguration in Ihrer `nodeadm`-Konfiguration übergeben. Die containerd-Konfiguration für `nodeadm` akzeptiert Inline-TOML. Im folgenden Beispiel erfahren Sie, wie Sie containerd konfigurieren, um das Löschen entpackter Image-Ebenen im containerd-Inhaltsspeicher zu deaktivieren.
```
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: # Name of the EKS cluster
region: # AWS Region where the EKS cluster resides
containerd:
config: | # Inline TOML containerd additional configuration
[plugins."io.containerd.grpc.v1.cri".containerd]
discard_unpacked_layers = false
hybrid:
ssm:
activationCode: # SSM hybrid activation code
activationId: # SSM hybrid activation id
```
**Anmerkung**
Die Containerversionen 1.x und 2.x verwenden unterschiedliche Konfigurationsformate. containerd 1.x verwendet die Konfigurationsversion 2, während Containerd 2.x die Konfigurationsversion 3 verwendet. Obwohl containerd 2.x weiterhin abwärtskompatibel mit Config Version 2 ist, wird Config Version 3 für eine optimale Leistung empfohlen. Überprüfen Sie Ihre Container-Version mit `containerd --version` oder überprüfen `nodeadm` Sie die Installationsprotokolle. Weitere Informationen zur Versionierung von Konfigurationen finden Sie unter https://containerd.io/releases/
Sie können auch die Containerd-Konfiguration verwenden, um die SELinux Unterstützung zu aktivieren. SELinux Wenn diese Option auf containerd aktiviert ist, stellen Sie sicher, dass Pods, die auf dem Knoten geplant sind, den richtigen SecurityContext haben und seLinuxOptions aktiviert sind. Weitere Informationen für die Konfiguration eines Sicherheitskontexts finden Sie in der [Kubernetes-Dokumentation](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/).
**Anmerkung**
Red Hat Enterprise Linux (RHEL) 8 und RHEL 9 sind standardmäßig SELinux aktiviert und auf dem Host auf Strict gesetzt. Amazon Linux 2023 ist standardmäßig SELinux aktiviert und auf den permissiven Modus eingestellt. Wenn auf dem Host auf den permissiven Modus gesetzt SELinux ist, blockiert die Aktivierung auf containerd keine Anfragen, sondern protokolliert sie entsprechend der SELinux Konfiguration auf dem Host.
```
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: # Name of the EKS cluster
region: # AWS Region where the EKS cluster resides
containerd:
config: | # Inline TOML containerd additional configuration
[plugins."io.containerd.grpc.v1.cri"]
enable_selinux = true
hybrid:
ssm:
activationCode: # SSM hybrid activation code
activationId: # SSM hybrid activation id
```