**Aidez à améliorer cette page**
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien **Modifier cette page sur** qui se trouve dans le volet droit de chaque page.
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Référence des nœuds hybrides `nodeadm`
L’interface CLI nœuds hybrides Amazon EKS (`nodeadm`) simplifie l’installation, la configuration, l’enregistrement et la désinstallation des composants des nœuds hybrides. Vous pouvez inclure `nodeadm` dans votre système d’exploitation des images permettant d’automatiser le démarrage des nœuds hybrides. Pour plus d’informations, consultez [Préparer le système d’exploitation pour les nœuds hybrides](hybrid-nodes-os.md).
La version `nodeadm` pour les nœuds hybrides diffère de la version `nodeadm` utilisée pour l’amorçage des instances Amazon EC2 en tant que nœuds dans les clusters Amazon EKS. Suivez la documentation et les références correspondant à la version `nodeadm` appropriée. Cette page de documentation concerne la version `nodeadm` des nœuds hybrides.
Le code source des nœuds hybrides `nodeadm` est publié dans le référentiel https://github.com/aws/ eks-hybridGitHub .
**Important**
Vous devez exécuter `nodeadm` avec un utilisateur disposant de root/sudo privilèges.
## Télécharger `nodeadm`
La version des nœuds hybrides de `nodeadm` est hébergée sur Amazon S3, géré par Amazon CloudFront. Pour installer `nodeadm` sur chaque hôte sur site, vous pouvez exécuter la commande suivante à partir de vos hôtes sur site.
**Pour les hôtes x86\_64**
```
curl -OL 'https://hybrid-assets.eks.amazonaws.com/releases/latest/bin/linux/amd64/nodeadm'
```
**Pour les hôtes ARM**
```
curl -OL 'https://hybrid-assets.eks.amazonaws.com/releases/latest/bin/linux/arm64/nodeadm'
```
Ajoutez les permissions d’exécution au fichier binaire téléchargé sur chaque hôte.
```
chmod +x nodeadm
```
## `nodeadm install`
La commande `nodeadm install` permet d’installer les artefacts et les dépendances nécessaires pour exécuter et joindre des nœuds hybrides à un cluster Amazon EKS. La commande `nodeadm install` peut être exécutée individuellement sur chaque nœud hybride ou pendant les pipelines de création d’images afin de préinstaller les dépendances des nœuds hybrides dans les images du système d’exploitation.
**Utilisation**
```
nodeadm install [KUBERNETES_VERSION] [flags]
```
**Arguments positionnels**
(Obligatoire) `KUBERNETES_VERSION` La version majeure.mineure d’EKS Kubernetes à installer, par exemple `1.32`
**Indicateurs**
| Nom | Obligatoire | Description |
| --- | --- | --- |
| `-p`,
`--credential-provider` | TRUE | Fournisseur d’informations d’identification à installer. Les valeurs prises en charge sont `iam-ra` et `ssm`. Pour plus d’informations, consultez [Préparer les informations d’identification pour les nœuds hybrides](hybrid-nodes-creds.md). |
| `-s`,
`--containerd-source` | FALSE | Source pour `containerd`. `nodeadm` prend en charge l’installation de `containerd` à partir de la distribution du système d’exploitation, des paquets Docker et le saute l’installation de `containerd`.
**Valeurs**
`distro`- Il s'agit de la valeur par défaut. `nodeadm`installera le dernier `containerd` package distribué par le système d'exploitation du nœud compatible avec la version EKS Kubernetes. `distro`n'est pas une valeur prise en charge pour les systèmes d'exploitation Red Hat Enterprise Linux (RHEL).
`docker`- `nodeadm` installera le dernier `containerd` package créé et distribué par Docker compatible avec la version EKS Kubernetes. `docker`n'est pas une valeur prise en charge pour Amazon Linux 2023.
`none` : `nodeadm` n’installera pas le paquet `containerd`. Vous devez installer `containerd` manuellement avant d’exécuter `nodeadm init`. |
| `-r`,
`--region` | FALSE | Spécifie la AWS région pour le téléchargement d'artefacts tels que l'agent SSM. La valeur par défaut est `us-west-2` . |
| `-t`,
`--timeout` | FALSE | Durée maximale de la commande d’installation. La saisie suit le format de durée. Par exemple `1h23m`. Le délai d’expiration par défaut pour le téléchargement de la commande d’installation est fixé à 20 minutes. |
| `-h`, `--help` | FALSE | Affiche un message d’aide avec les paramètres disponibles pour les métriques, les sous-commandes et les valeurs positionnelles. |
**Exemples**
Installez la version Kubernetes avec AWS Systems `1.32` Manager (SSM) comme fournisseur d'informations d'identification
```
nodeadm install 1.32 --credential-provider ssm
```
Installez la version Kubernetes avec AWS Systems `1.32` Manager (SSM) comme fournisseur d'informations d'identification, Docker comme source containerd, avec un délai de téléchargement de 20 minutes.
```
nodeadm install 1.32 --credential-provider ssm --containerd-source docker --timeout 20m
```
Installez la version Kubernetes `1.32` avec AWS IAM Roles Anywhere comme fournisseur d'informations d'identification
```
nodeadm install 1.32 --credential-provider iam-ra
```
## `nodeadm config check`
La commande `nodeadm config check` vérifie la configuration du nœud fourni afin de détecter d’éventuelles erreurs. Cette commande peut être utilisée pour vérifier et valider l’exactitude d’un fichier de configuration de nœud hybride.
**Utilisation**
```
nodeadm config check [flags]
```
**Indicateurs**
| Nom | Obligatoire | Description |
| --- | --- | --- |
| `-c`,
`--config-source` | TRUE | Source de la configuration nodeadm. Pour les nœuds hybrides, l’entrée doit suivre un URI avec un schéma de fichier. |
| `-h`, `--help` | FALSE | Affiche un message d’aide avec les paramètres disponibles pour les métriques, les sous-commandes et les valeurs positionnelles. |
**Exemples**
```
nodeadm config check -c file://nodeConfig.yaml
```
## `nodeadm init`
La commande `nodeadm init` démarre et connecte le nœud hybride au cluster Amazon EKS configuré. Consultez [Configuration des nœuds pour les activations hybrides SSM](#hybrid-nodes-node-config-ssm) ou [Configuration des nœuds pour Rôles Anywhere IAM](#hybrid-nodes-node-config-iamra) pour plus de détails sur la configuration du fichier `nodeConfig.yaml`.
**Utilisation**
```
nodeadm init [flags]
```
**Indicateurs**
| Nom | Obligatoire | Description |
| --- | --- | --- |
| `-c`,
`--config-source` | TRUE | Source de la configuration `nodeadm`. Pour les nœuds hybrides, l’entrée doit suivre un URI avec un schéma de fichier. |
| `-s`,
`--skip` | FALSE | Phases de `init` à ignorer. Il n’est pas recommandé de sauter l’une des phases, sauf si cela permet de résoudre un problème.
**Valeurs**
`install-validation` ignore la vérification du bon déroulement de la commande d’installation précédente.
`cni-validation` ignore la vérification de l’ouverture des ports VXLAN de Cilium ou Calico CNI si le pare-feu est activé sur le nœud
`node-ip-validation` ignore la vérification si l’adresse IP du nœud se trouve dans un CIDR dans les réseaux de nœuds distants |
| `-h`, `--help` | FALSE | Affiche un message d’aide avec les paramètres disponibles pour les métriques, les sous-commandes et les valeurs positionnelles. |
**Exemples**
```
nodeadm init -c file://nodeConfig.yaml
```
## `nodeadm upgrade`
La commande `nodeadm upgrade` met à niveau tous les artefacts installés vers la dernière version et amorce le nœud pour configurer les artefacts mis à niveau et rejoindre le cluster EKS sur AWS. La mise à niveau est une commande perturbatrice pour les charges de travail exécutées sur le nœud. Veuillez déplacer vos charges de travail vers un autre nœud avant de lancer la mise à niveau.
**Utilisation**
```
nodeadm upgrade [KUBERNETES_VERSION] [flags]
```
**Arguments positionnels**
(Obligatoire) `KUBERNETES_VERSION` La version majeure.mineure d’EKS Kubernetes à installer, par exemple `1.32`
**Indicateurs**
| Nom | Obligatoire | Description |
| --- | --- | --- |
| `-c`,
`--config-source` | TRUE | Source de la configuration `nodeadm`. Pour les nœuds hybrides, l’entrée doit suivre un URI avec un schéma de fichier. |
| `-t`,
`--timeout` | FALSE | Délai d’attente pour le téléchargement des artefacts. La saisie suit le format de durée. Par exemple 1 h 23 min. Le délai d’expiration par défaut pour le téléchargement de la commande de mise à niveau est défini sur 10 minutes. |
| `-s`,
`--skip` | FALSE | Phases de mise à niveau à ignorer. Il n’est pas recommandé de sauter l’une des phases, sauf si cela permet de résoudre un problème.
**Valeurs**
`pod-validation` ignore la vérification si tous les pods ne sont pas en cours d’exécution sur le nœud, à l’exception des ensembles de démons et des pods statiques.
`node-validation` ignore la vérification si le nœud a été bouclé.
`init-validation` ignore la vérification de l’initialisation réussie du nœud avant d’exécuter la mise à niveau.
`containerd-major-version-upgrade`empêche les mises à niveau des versions majeures de containerd lors de la mise à niveau du nœud. |
| `-h`, `--help` | FALSE | Affiche un message d’aide avec les paramètres disponibles pour les métriques, les sous-commandes et les valeurs positionnelles. |
**Exemples**
```
nodeadm upgrade 1.32 -c file://nodeConfig.yaml
```
```
nodeadm upgrade 1.32 -c file://nodeConfig.yaml --timeout 20m
```
## `nodeadm uninstall`
La commande `nodeadm uninstall` arrête et supprime les artefacts que `nodeadm` installe pendant `nodeadm install`, y compris kubelet et containerd. Remarque : La commande de désinstallation ne vide pas et ne supprime pas vos nœuds hybrides de votre cluster. Vous devez exécuter les opérations de vidage et de suppression séparément. Pour plus d’informations, consultez [Supprimer les nœuds hybrides](hybrid-nodes-remove.md). Par défaut, `nodeadm uninstall` ne continuera pas s’il reste des pods sur le nœud. De même, `nodeadm uninstall` ne supprime pas les dépendances CNI ni les dépendances d’autres modules complémentaires Kubernetes que vous exécutez sur votre cluster. Pour supprimer complètement l’installation CNI de votre hôte, consultez les instructions à l’adresse [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md). Si vous utilisez des activations hybrides AWS SSM comme fournisseur d'informations d'identification sur site, la `nodeadm uninstall` commande annule l'enregistrement de vos hôtes en tant qu'instances gérées par SSM. AWS
**Utilisation**
```
nodeadm uninstall [flags]
```
**Indicateurs**
| Nom | Obligatoire | Description |
| --- | --- | --- |
| `-s`,
`--skip` | FALSE | Phases de désinstallation à ignorer. Il n’est pas recommandé de sauter l’une des phases, sauf si cela permet de résoudre un problème.
**Valeurs**
`pod-validation` ignore la vérification si tous les pods ne sont pas en cours d’exécution sur le nœud, à l’exception des ensembles de démons et des pods statiques.
`node-validation` ignore la vérification si le nœud a été bouclé.
`init-validation` ignore la vérification de l’initialisation réussie du nœud avant d’exécuter la désinstallation. |
| `-h`,
`--help` | FALSE | Affiche un message d’aide avec les paramètres disponibles pour les métriques, les sous-commandes et les valeurs positionnelles. |
| `-f`,
`--force` | FALSE | Supprimer de force les répertoires supplémentaires qui pourraient contenir des fichiers restants provenant des composants Kubernetes et CNI.
**WARNING**
Cela supprimera tout le contenu des répertoires Kubernetes et CNI par défaut (`/var/lib/cni`, `/etc/cni/net.d`, etc.). N’utilisez pas cet indicateur si vous stockez vos propres données à ces emplacements.
À partir de nodeadm `v1.0.9`, la commande `./nodeadm uninstall --skip node-validation,pod-validation --force` ne supprime plus le répertoire `/var/lib/kubelet`. En effet, il peut contenir des volumes Pod et des répertoires volume-subpath qui incluent parfois le système de fichiers du nœud monté.
**Conseils pour une manipulation en toute sécurité**
– La suppression des chemins montés peut entraîner la suppression accidentelle du système de fichiers du nœud monté. Avant de supprimer manuellement le répertoire `/var/lib/kubelet`, inspectez soigneusement tous les montages actifs et démontez les volumes en toute sécurité afin d’éviter toute perte de données. |
**Exemples**
```
nodeadm uninstall
```
```
nodeadm uninstall --skip node-validation,pod-validation
```
## `nodeadm debug`
La commande `nodeadm debug` peut être utilisée pour dépanner les nœuds hybrides défectueux ou mal configurés. Il vérifie que les exigences suivantes sont respectées.
+ Le nœud dispose d'un accès réseau aux informations requises AWS APIs pour obtenir les informations d'identification,
+ Le nœud est en mesure d'obtenir des AWS informations d'identification pour le rôle IAM des nœuds hybrides configuré,
+ Le nœud dispose d’un accès réseau au point de terminaison de l’API EKS Kubernetes et la validité du certificat du point de terminaison de l’API EKS Kubernetes,
+ Le nœud est capable de s’authentifier auprès du cluster EKS, son identité dans le cluster est valide et le nœud a accès au cluster EKS via le VPC configuré pour le cluster EKS.
Si des erreurs sont détectées, la sortie de la commande suggère des étapes de dépannage. Certaines étapes de validation affichent les processus enfants. Si celles-ci échouent, le résultat s’affiche dans une section stderr sous l’erreur de validation.
**Utilisation**
```
nodeadm debug [flags]
```
**Indicateurs**
| Nom | Obligatoire | Description |
| --- | --- | --- |
| `-c`, `--config-source` | TRUE | Source de la configuration `nodeadm`. Pour les nœuds hybrides, l’entrée doit suivre un URI avec un schéma de fichier. |
| `--no-color` | FALSE | Désactive la sortie couleur. Utile pour l’automatisation. |
| `-h`, `--help` | FALSE | Affiche un message d’aide avec les paramètres disponibles pour les métriques, les sous-commandes et les valeurs positionnelles. |
**Exemples**
```
nodeadm debug -c file://nodeConfig.yaml
```
## Emplacements des fichiers Nodeadm
### nodeadm installer
Lors de l’exécution `nodeadm install`, les fichiers et emplacements de fichiers suivants sont configurés.
| Artefact | Chemin |
| --- | --- |
| CLI Rôles Anywhere IAM | /usr/local/bin/aws\_assistant à la signature |
| Kubelet binaire | /usr/bin/kubelet |
| Kubectl binaire | usr/local/bin/kubectl |
| Fournisseur d’informations d’identification ECR | /etc/eks/image-credential-provider/ecr-fournisseur d'informations d'identification |
| AWS Authentificateur IAM | /usr/local/bin/aws-iam-authentificateur |
| Configuration SSM CLI | /opt/ssm/ssm-setup-cli |
| SSM Agent | Sur Ubuntu -/snap/amazon-ssm-agent/current/amazon-ssm-agent
Sur RHEL & AL2023 -/-ssm-agent usr/bin/amazon |
| Containerd | Sur Ubuntu & AL2023 -/usr/bin/containerd
Sur RHEL : /bin/containerd |
| iptables | Sur Ubuntu & AL2023 -/usr/sbin/iptables
Sur RHEL : /sbin/iptables |
| Plug-ins CNI | /opt/cni/bin |
| suivi des artefacts installés | /opt/nodeadm/tracker |
### nodeadm init
Lors de l’exécution de `nodeadm init`, les fichiers et emplacements de fichiers suivants sont configurés.
| Nom | Chemin |
| --- | --- |
| Kubelet kubeconfig | /var/lib/kubelet/kubeconfig |
| Configuration Kubelet | /etc/kubernetes/kubelet/config.json |
| Unité de système Kubelet | /etc/systemd/system/kubelet.service |
| Configuration du fournisseur d’informations d’identification d’image | /etc/eks/image-credential-provider/config.json |
| Fichier d’environnement Kubelet | /etc/eks/kubelet/environment |
| Certificats Kubelet | /etc/kubernetes/pki/ca.crt |
| Config de Containerd | /etc/containerd/config.toml |
| Configuration des modules du noyau Containerd | /etc/modules-load.d/containerd.conf |
| AWS fichier de configuration | /etc/aws/hybrid/config |
| AWS fichier d'informations d'identification (si le fichier d'informations d'identification est activé) | /eks-hybrid/.aws/identifiants |
| AWS unité système d'aide à la signature | /etc/systemd/system/aws\_signing\_helper\_update.service |
| fichier de configuration sysctl | /etc/sysctl.d/99-nodeadm.conf |
| Ca-certificates | /etc/ssl/certs/ca-certificates.crt |
| Fichier de clé Gpg | /etc/apt/keyrings/docker.asc |
| Fichier source du dépôt Docker | /etc/apt/sources.list.d/docker.liste |
## Configuration des nœuds pour les activations hybrides SSM
Voici un exemple `nodeConfig.yaml` d'utilisation des activations hybrides AWS SSM pour les informations d'identification des nœuds hybrides.
```
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
```
## Configuration des nœuds pour Rôles Anywhere IAM
Voici un `nodeConfig.yaml` exemple d'identifiant AWS IAM Roles Anywhere pour les nœuds hybrides.
Lorsque vous utilisez AWS IAM Roles Anywhere comme fournisseur d'informations d'identification sur site, celles que `nodeName` vous utilisez dans votre `nodeadm` configuration doivent correspondre aux autorisations que vous avez définies pour votre rôle IAM Hybrid Nodes. Par exemple, si vos autorisations pour le rôle IAM de Hybrid Nodes autorisent uniquement AWS IAM Roles Anywhere à assumer le rôle lorsque le nom de session du rôle est égal au CN du certificat hôte, le `nodeName` CN de votre `nodeadm` configuration doit être le même que le CN de vos certificats. Le `nodeName` que vous utilisez ne peut pas dépasser 64 caractères. Pour de plus amples informations, veuillez consulter [Préparer les informations d’identification pour les nœuds hybrides](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
```
## Configuration du nœud pour personnaliser kubelet (facultatif)
Vous pouvez transmettre la configuration et les métriques kubelet dans votre configuration `nodeadm`. Consultez l’exemple ci-dessous pour savoir comment ajouter une étiquette de nœud `abc.amazonaws.com/test-label` supplémentaire et configurer `shutdownGracePeriod` sur 30 secondes.
```
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
```
## Configuration du nœud pour personnaliser containerd (facultatif)
Vous pouvez passer une configuration containerd personnalisée dans votre configuration `nodeadm`. La configuration containerd pour `nodeadm` accepte TOML en ligne. Consultez l’exemple ci-dessous pour savoir comment configurer containerd afin de désactiver la suppression des couches d’image décompressées dans le magasin de contenu containerd.
```
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
```
**Note**
Les versions 1.x et 2.x de Containerd utilisent différents formats de configuration. Containerd 1.x utilise la version de configuration 2, tandis que containerd 2.x utilise la version de configuration 3. Bien que containerd 2.x reste rétrocompatible avec la version 2 de configuration, la version 3 de configuration est recommandée pour des performances optimales. Vérifiez la version de votre containerd `containerd --version` ou consultez les journaux d'`nodeadm`installation. Pour plus de détails sur la gestion des versions de configuration, consultez https://containerd.io/releases/
Vous pouvez également utiliser la configuration containerd pour activer SELinux le support. SELinux Lorsque cette option est activée sur containerd, assurez-vous que les pods planifiés sur le nœud disposent du SecurityContext approprié et sont activés. seLinuxOptions Vous trouverez plus d’informations sur la configuration d’un contexte de sécurité dans la [documentation Kubernetes](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/).
**Note**
Red Hat Enterprise Linux (RHEL) 8 et RHEL 9 sont SELinux activés par défaut et définis sur strict sur l'hôte. Amazon Linux 2023 est SELinux activé par défaut et est réglé sur le mode permissif. Lorsqu'il SELinux est défini sur le mode permissif sur l'hôte, son activation sur containerd ne bloquera pas les demandes mais les enregistrera conformément à la SELinux configuration de l'hôte.
```
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
```