**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. # Exécution de charges de travail sur site sur des nœuds hybrides Dans un cluster EKS avec des nœuds hybrides activés, vous pouvez exécuter des applications sur site et en périphérie sur votre propre infrastructure avec les mêmes clusters, fonctionnalités et outils Amazon EKS que ceux que vous utilisez dans le cloud AWS. Les sections suivantes contiennent des instructions détaillées pour l’utilisation des nœuds hybrides. **Topics** + [Connecter les nœuds hybrides](hybrid-nodes-join.md) + [Connectez des nœuds hybrides avec Bottlerocket](hybrid-nodes-bottlerocket.md) + [Mettre à niveau les nœuds hybrides](hybrid-nodes-upgrade.md) + [Nœuds hybrides de patch](hybrid-nodes-security.md) + [Supprimer des nœuds hybrides](hybrid-nodes-remove.md) # Connecter les nœuds hybrides **Note** Les étapes suivantes s’appliquent aux nœuds hybrides exécutant des systèmes d’exploitation compatibles, à l’exception de Bottlerocket. Pour connaître les étapes à suivre pour connecter un nœud hybride qui exécute Bottlerocket, consultez [Connectez des nœuds hybrides avec Bottlerocket](hybrid-nodes-bottlerocket.md). Cette rubrique décrit comment connecter des nœuds hybrides à un cluster Amazon EKS. Une fois que vos nœuds hybrides ont rejoint le cluster, ils apparaissent avec le statut Not Ready (Non prêt) dans la console Amazon EKS et dans les outils compatibles avec Kubernetes, tels que kubectl. Une fois les étapes décrites sur cette page terminées, passez à la section [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md) pour préparer vos nœuds hybrides à exécuter des applications. ## Prérequis Avant de connecter des nœuds hybrides à votre cluster Amazon EKS, assurez-vous d’avoir suivi toutes les étapes préalables. + Vous disposez d’une connectivité réseau entre votre environnement sur site et la région AWS hébergeant votre cluster Amazon EKS. Pour plus d’informations, consultez [Préparer la mise en réseau pour les nœuds hybrides](hybrid-nodes-networking.md). + Vous disposez d’un système d’exploitation compatible pour les nœuds hybrides installés sur vos hôtes sur site. Pour plus d’informations, consultez [Préparer le système d’exploitation pour les nœuds hybrides](hybrid-nodes-os.md). + Vous avez créé votre rôle IAM des nœuds hybrides et configuré votre fournisseur d’informations d’identification sur site (activations hybrides AWS Systems Manager ou Rôles Anywhere IAM AWS). Pour plus d’informations, consultez [Préparer les informations d’identification pour les nœuds hybrides](hybrid-nodes-creds.md). + Vous avez créé votre cluster Amazon EKS compatible avec les nœuds hybrides. Pour plus d’informations, consultez [Créer un cluster Amazon EKS avec des nœuds hybrides](hybrid-nodes-cluster-create.md). + Vous avez associé votre rôle IAM des nœuds hybrides aux autorisations RBAC de Kubernetes. Pour plus d’informations, consultez [Préparation de l’accès au cluster pour les nœuds hybrides](hybrid-nodes-cluster-prep.md). ## Étape 1 : installer l’interface CLI des nœuds hybrides (`nodeadm`) sur chaque hôte sur site Si vous incluez l’interface CLI des nœuds hybrides Amazon EKS (`nodeadm`) dans vos images de système d’exploitation pré-construites, vous pouvez ignorer cette étape. Pour plus d’informations sur la version hybride des nœuds de `nodeadm`, consultez [Référence des nœuds hybrides `nodeadm`](hybrid-nodes-nodeadm.md). La version hybride des nœuds de `nodeadm` est hébergée dans Amazon S3, avec Amazon CloudFront comme interface. 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\$164 :** ``` 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 ``` ## Étape 2 : installer les dépendances des nœuds hybrides avec `nodeadm` Si vous installez les dépendances des nœuds hybrides dans des images de système d’exploitation précompilées, vous pouvez ignorer cette étape. La commande `nodeadm install` peut être utilisée pour installer toutes les dépendances requises pour les nœuds hybrides. Les dépendances des nœuds hybrides incluent containerd, kubelet, kubectl et les composants AWS SSM ou Rôles Anywhere IAM AWS. Pour plus d’informations sur les composants et les emplacements des fichiers installés par `nodeadm install`, consultez [Référence des nœuds hybrides `nodeadm`](hybrid-nodes-nodeadm.md). Pour plus d’informations sur les domaines qui doivent être autorisés dans votre pare-feu local pour le processus `nodeadm install`, consultez [Préparer la mise en réseau pour les nœuds hybrides](hybrid-nodes-networking.md). Exécutez la commande ci-dessous pour installer les dépendances des nœuds hybrides sur votre hôte local. La commande ci-dessous doit être exécutée par un utilisateur disposant d’un accès sudo/root sur votre hôte. **Important** Les nœuds hybrides CLI (`nodeadm`) doivent être exécutés avec un utilisateur disposant d’un accès sudo/root sur votre hôte. + Remplacez `K8S_VERSION` par la version mineure Kubernetes de votre cluster Amazon EKS, par exemple `1.31`. Consultez les [versions prises en charge par Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) pour obtenir la liste des versions Kubernetes prises en charge. + Remplacez `CREDS_PROVIDER` par le fournisseur d’informations d’identification local que vous utilisez. Les valeurs valides sont `ssm` pour AWS SSM et `iam-ra` pour Rôles Anywhere IAM AWS. ``` nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER ``` ## Étape 3 : connecter les nœuds hybrides à votre cluster Avant de connecter vos nœuds hybrides à votre cluster, assurez-vous d’avoir autorisé l’accès requis dans votre pare-feu local et dans le groupe de sécurité de votre cluster pour la communication entre le plan de contrôle Amazon EKS et les nœuds hybrides. La plupart des problèmes rencontrés à cette étape sont liés à la configuration du pare-feu, à la configuration du groupe de sécurité ou à la configuration du rôle IAM des nœuds hybrides. **Important** Les nœuds hybrides CLI (`nodeadm`) doivent être exécutés avec un utilisateur disposant d’un accès sudo/root sur votre hôte. 1. Créez un fichier `nodeConfig.yaml` sur chaque hôte avec les valeurs pour votre déploiement. Pour une description complète des paramètres de configuration disponibles, voir [Référence des nœuds hybrides `nodeadm`](hybrid-nodes-nodeadm.md). Si votre rôle IAM des nœuds hybrides ne dispose pas des autorisations nécessaires pour l’action `eks:DescribeCluster`, vous devez transmettre votre point de terminaison de l’API Kubernetes, votre offre groupée CA et votre CIDR IPv4 du service Kubernetes dans la section cluster de votre `nodeConfig.yaml`. 1. Utilisez l’exemple `nodeConfig.yaml` ci-dessous si vous utilisez des activations hybrides SSM AWS pour votre fournisseur d’informations d’identification sur site. 1. Remplacez `CLUSTER_NAME` par le nom de votre cluster. 1. Remplacez `AWS_REGION` par la région AWS hébergeant votre cluster. Par exemple, `us-west-2`. 1. Remplacez `ACTIVATION_CODE` par le code d’activation que vous avez reçu lors de la création de votre activation hybride SSM AWS. Pour plus d’informations, consultez [Préparer les informations d’identification pour les nœuds hybrides](hybrid-nodes-creds.md). 1. Remplacez `ACTIVATION_ID` par l’ID d’activation que vous avez reçu lors de la création de votre activation hybride SSM AWS. Vous pouvez récupérer ces informations à partir de la console AWS Systems Manager ou à partir de la commande AWS CLI `aws ssm describe-activations`. ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: CLUSTER_NAME region: AWS_REGION hybrid: ssm: activationCode: ACTIVATION_CODE activationId: ACTIVATION_ID ``` 1. Utilisez l’exemple `nodeConfig.yaml` ci-dessous si vous utilisez Rôles Anywhere IAM AWS pour votre fournisseur d’informations d’identification sur site. 1. Remplacez `CLUSTER_NAME` par le nom de votre cluster. 1. Remplacez `AWS_REGION` par la région AWS hébergeant votre cluster. Par exemple, `us-west-2`. 1. Remplacez `NODE_NAME` par le nom de votre nœud. Le nom du nœud doit correspondre au nom commun (CN) du certificat sur l’hôte si vous avez configuré la stratégie de confiance de votre rôle IAM des nœuds hybrides avec la condition de ressource `"sts:RoleSessionName": "${aws:PrincipalTag/x509Subject/CN}"`. Le `nodeName` que vous utilisez ne doit pas dépasser 64 caractères. 1. Remplacez `TRUST_ANCHOR_ARN` par l’ARN de l’ancre d’approbation que vous avez configurée dans les étapes de la section Préparer les informations d’identification pour les nœuds hybrides. 1. Remplacez `PROFILE_ARN` par l’ARN de l’ancre d’approbation que vous avez configurée dans les étapes pour [Préparer les informations d’identification pour les nœuds hybrides](hybrid-nodes-creds.md). 1. Remplacez `ROLE_ARN` par l’ARN de votre rôle IAM des nœuds hybrides. 1. Remplacez `CERTIFICATE_PATH` par le chemin d’accès sur le disque vers votre certificat de nœud. Si vous ne le précisez pas, la valeur par défaut est `/etc/iam/pki/server.pem`. 1. Remplacez `KEY_PATH` par le chemin d’accès sur le disque vers la clé privée de votre certificat. Si vous ne le précisez pas, la valeur par défaut est `/etc/iam/pki/server.key`. ``` 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. Exécutez la commande `nodeadm init` avec votre `nodeConfig.yaml` pour connecter vos nœuds hybrides à votre cluster Amazon EKS. ``` nodeadm init -c file://nodeConfig.yaml ``` Si la commande ci-dessus s’exécute correctement, votre nœud hybride a rejoint votre cluster Amazon EKS. Vous pouvez vérifier cela dans la console Amazon EKS en accédant à l’onglet Calcul de votre cluster ([assurez-vous que le principal IAM dispose des autorisations nécessaires pour afficher](view-kubernetes-resources.md#view-kubernetes-resources-permissions)) ou avec `kubectl get nodes`. **Important** Vos nœuds auront le statut `Not Ready`, ce qui est normal et dû à l’absence d’un CNI fonctionnant sur vos nœuds hybrides. Si vos nœuds ne se sont pas joints au cluster, consultez [Dépannage des nœuds hybrides](hybrid-nodes-troubleshooting.md). ## Étape 4 : configurer un CNI pour les nœuds hybrides Pour que vos nœuds hybrides soient prêts à exécuter des applications, poursuivez avec les étapes décrites à la section [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md). # Connectez des nœuds hybrides avec Bottlerocket Cette rubrique décrit comment connecter des nœuds hybrides exécutant Bottlerocket à un cluster Amazon EKS. [Bottlerocket](https://aws.amazon.com/bottlerocket/) est une distribution Linux open source sponsorisée et soutenue par. AWS Bottlerocket est spécialement conçu pour héberger des charges de travail conteneurisées. Avec Bottlerocket, vous pouvez améliorer la disponibilité des déploiements conteneurisés et réduire les coûts opérationnels en automatisant les mises à jour de votre infrastructure de conteneurs. Bottlerocket ne comprend que les logiciels essentiels à l’exécution des conteneurs, ce qui améliore l’utilisation des ressources, réduit les menaces de sécurité et diminue les frais généraux liés à la gestion. Seules les VMware variantes de la version v1.37.0 et supérieures de Bottlerocket sont prises en charge avec les nœuds hybrides EKS. VMware des variantes de Bottlerocket sont disponibles pour les versions v1.28 et supérieures de Kubernetes. Les images du système d'exploitation de ces variantes incluent le kubelet, le containerd aws-iam-authenticator et d'autres logiciels requis pour les nœuds hybrides EKS. Vous pouvez configurer ces composants à l’aide d’un fichier de [paramètres](https://github.com/bottlerocket-os/bottlerocket#settings) Bottlerocket qui comprend des données utilisateur encodées en base64 pour les conteneurs de démarrage et d’administration Bottlerocket. La configuration de ces paramètres permet à Bottlerocket d’utiliser votre fournisseur d’informations d’identification de nœuds hybrides pour authentifier les nœuds hybrides sur votre cluster. Une fois que vos nœuds hybrides ont rejoint le cluster, leur statut `Not Ready` s’affiche dans la console Amazon EKS et dans les outils compatibles avec Kubernetes, tels que `kubectl`. Une fois les étapes décrites sur cette page terminées, passez à la section [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md) pour préparer vos nœuds hybrides à exécuter des applications. ## Conditions préalables Avant de connecter des nœuds hybrides à votre cluster Amazon EKS, assurez-vous d’avoir suivi toutes les étapes préalables. + Vous disposez d'une connectivité réseau entre votre environnement sur site et la AWS région hébergeant votre cluster Amazon EKS. Pour plus d’informations, consultez [Préparer la mise en réseau pour les nœuds hybrides](hybrid-nodes-networking.md). + Vous avez créé votre rôle Hybrid Nodes IAM et configuré votre fournisseur d'informations d'identification sur site (activations hybrides de AWS Systems Manager ou AWS IAM Roles Anywhere). Pour plus d’informations, consultez [Préparer les informations d’identification pour les nœuds hybrides](hybrid-nodes-creds.md). + Vous avez créé votre cluster Amazon EKS compatible avec les nœuds hybrides. Pour plus d’informations, consultez [Créer un cluster Amazon EKS avec des nœuds hybrides](hybrid-nodes-cluster-create.md). + Vous avez associé votre rôle IAM des nœuds hybrides aux autorisations RBAC de Kubernetes. Pour plus d’informations, consultez [Préparation de l’accès au cluster pour les nœuds hybrides](hybrid-nodes-cluster-prep.md). ## Étape 1 : créer le fichier TOML des paramètres Bottlerocket Pour configurer Bottlerocket pour les nœuds hybrides, vous devez créer un fichier `settings.toml` contenant la configuration nécessaire. Le contenu du fichier TOML varie en fonction du fournisseur d’informations d’identification que vous utilisez (SSM ou Rôles Anywhere IAM). Ce fichier sera transmis en tant que données utilisateur lors de la mise à disposition de l’instance Bottlerocket. **Note** Les fichiers TOML fournis ci-dessous ne représentent que les paramètres minimaux requis pour initialiser une VMWare machine Bottlerocket en tant que nœud sur un cluster EKS. Bottlerocket fournit une large gamme de paramètres pour répondre à différents cas d'utilisation. Pour d'autres options de configuration au-delà de l'initialisation du nœud hybride, veuillez consulter la [documentation de Bottlerocket](https://bottlerocket.dev/en) pour obtenir la liste complète de tous les paramètres documentés pour la version de Bottlerocket que vous utilisez (par exemple, [voici](https://bottlerocket.dev/en/os/1.51.x/api/settings-index) tous les paramètres disponibles pour Bottlerocket 1.51.x). ### SSM Si vous utilisez AWS Systems Manager comme fournisseur d'informations d'identification, créez un `settings.toml` fichier avec le contenu suivant : ``` [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 ``` Remplacez les espaces réservés par les valeurs suivantes : + `` : le nom de votre cluster Amazon EKS. + `` : point de terminaison du serveur d’API de votre cluster. + `` : Ensemble CA codé en base64 de votre cluster. + ``: La AWS région hébergeant votre cluster, par exemple « us-east-1 ». + `` : le nom d’hôte de l’instance Bottlerocket, qui sera également configuré comme nom de nœud. Il peut s’agir de n’importe quelle valeur unique de votre choix, mais elle doit respecter les [conventions de nommage des objets Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names). De plus, le nom d’hôte que vous utilisez ne peut pas dépasser 64 caractères. REMARQUE : lorsque vous utilisez le fournisseur SSM, ce nom d’hôte et ce nom de nœud seront remplacés par l’ID de l’instance gérée (par exemple, ID `mi-*`) une fois que l’instance aura été enregistrée auprès de SSM. + `` : Contenu codé en base64 de la configuration du conteneur d’administration Bottlerocket. L’activation du conteneur d’administration vous permet de vous connecter à votre instance Bottlerocket avec SSH pour explorer le système et le déboguer. Bien que ce paramètre ne soit pas obligatoire, nous vous recommandons de l’activer afin de faciliter le dépannage. Pour plus d’informations sur l’authentification avec le conteneur d’administration, consultez la [documentation relative au conteneur d’administration Bottlerocket](https://github.com/bottlerocket-os/bottlerocket-admin-container#authenticating-with-the-admin-container). Le conteneur d’administration accepte les entrées utilisateur et clé SSH au format JSON, par exemple : ``` { "user": "", "ssh": { "authorized-keys": [ "" ] } } ``` + `` : Contenu encodé en base64 de la configuration du conteneur d’amorçage Bottlerocket. Pour plus d’informations sur sa configuration, consultez la [documentation relative au conteneur Bottlerocket bootstrap](https://github.com/bottlerocket-os/bottlerocket-bootstrap-container). Le conteneur bootstrap est chargé d'enregistrer l'instance en tant qu'instance gérée par AWS SSM et de la joindre en tant que nœud Kubernetes sur votre cluster Amazon EKS. Les données utilisateur transmises au conteneur Bootstrap prennent la forme d’une invocation de commande qui accepte en entrée le code d’activation hybride SSM et l’ID que vous avez créés précédemment : ``` eks-hybrid-ssm-setup --activation-id= --activation-code= --region= ``` ### Rôles Anywhere IAM Si vous utilisez AWS IAM Roles Anywhere comme fournisseur d'informations d'identification, créez un `settings.toml` fichier avec le contenu suivant : ``` [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 = "" ``` Remplacez les espaces réservés par les valeurs suivantes : + `` : le nom de votre cluster Amazon EKS. + `` : point de terminaison du serveur d’API de votre cluster. + `` : Ensemble CA codé en base64 de votre cluster. + ``: La AWS région hébergeant votre cluster, par exemple « us-east-1 » + `` : le nom d’hôte de l’instance Bottlerocket, qui sera également configuré comme nom de nœud. Il peut s’agir de n’importe quelle valeur unique de votre choix, mais elle doit respecter les [conventions de nommage des objets Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names). De plus, le nom d’hôte que vous utilisez ne peut pas dépasser 64 caractères. REMARQUE : lorsque vous utilisez le fournisseur IAM-RA, le nom du nœud doit correspondre au nom commun (CN) du certificat sur l’hôte si vous avez configuré la stratégie de confiance de votre rôle IAM des nœuds hybrides avec la condition de ressource `"sts:RoleSessionName": "${aws:PrincipalTag/x509Subject/CN}"`. + ``: le contenu codé en base64 de votre AWS fichier de configuration. Le contenu du fichier doit être le suivant : ``` [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 ``` + `` : Contenu codé en base64 de la configuration du conteneur d’administration Bottlerocket. L’activation du conteneur d’administration vous permet de vous connecter à votre instance Bottlerocket avec SSH pour explorer le système et le déboguer. Bien que ce paramètre ne soit pas obligatoire, nous vous recommandons de l’activer afin de faciliter le dépannage. Pour plus d’informations sur l’authentification avec le conteneur d’administration, consultez la [documentation relative au conteneur d’administration Bottlerocket](https://github.com/bottlerocket-os/bottlerocket-admin-container#authenticating-with-the-admin-container). Le conteneur d’administration accepte les entrées utilisateur et clé SSH au format JSON, par exemple : ``` { "user": "", "ssh": { "authorized-keys": [ "" ] } } ``` + `` : Contenu encodé en base64 de la configuration du conteneur d’amorçage Bottlerocket. Pour plus d’informations sur sa configuration, consultez la [documentation relative au conteneur Bottlerocket bootstrap](https://github.com/bottlerocket-os/bottlerocket-bootstrap-container). Le conteneur Bootstrap est chargé de créer les fichiers de certificat hôte et de clé privée de certificat Rôles Anywhere IAM sur l’instance. Ceux-ci seront ensuite utilisés par le `aws_signing_helper` pour obtenir des informations d’identification temporaires afin de s’authentifier auprès de votre cluster Amazon EKS. Les données utilisateur transmises au conteneur bootstrap prennent la forme d’une invocation de commande qui accepte en entrée le contenu du certificat et de la clé privée que vous avez créés précédemment : ``` eks-hybrid-iam-ra-setup --certificate= --key= ``` ## Étape 2 : fournir les données utilisateur à la machine virtuelle Bottlerocket vSphere Une fois le fichier TOML créé, transmettez-le en tant que données utilisateur lors de la création de la machine virtuelle vSphere. N’oubliez pas que les données utilisateur doivent être configurées avant la première mise sous tension de la machine virtuelle. Vous devrez donc le fournir lors de la création de l’instance. Si vous souhaitez créer la VM à l’avance, celle-ci devra être dans un état « poweredOff » jusqu’à ce que vous configuriez les données utilisateur correspondantes. Par exemple, si vous utilisez l’interface CLI `govc` : ### Création d’une machine virtuelle pour la première fois ``` 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= \ ``` ### Mise à jour des données utilisateur pour une machine virtuelle existante ``` 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 ``` Dans les sections ci-dessus, l’option `-e guestinfo.userdata.encoding="base64"` spécifie que les données utilisateur sont encodées en base64. Cette option `-e guestinfo.userdata` transmet le contenu du fichier `settings.toml` encodé en base64 sous forme de données utilisateur à l’instance Bottlerocket. Remplacez les espaces réservés par vos valeurs spécifiques, telles que le modèle OVA Bottlerocket et les détails réseau. ## Étape 3 : vérifier la connexion du nœud hybride Une fois l’instance Bottlerocket démarrée, elle tentera de rejoindre votre cluster Amazon EKS. Vous pouvez vérifier la connexion dans la console Amazon EKS en accédant à l’onglet Calcul de votre cluster ou en exécutant la commande suivante : ``` kubectl get nodes ``` **Important** Vos nœuds auront le statut `Not Ready`, ce qui est normal et dû à l’absence d’un CNI fonctionnant sur vos nœuds hybrides. Si vos nœuds ne se sont pas joints au cluster, consultez [Dépannage des nœuds hybrides](hybrid-nodes-troubleshooting.md). ## Étape 4 : configurer un CNI pour les nœuds hybrides Pour que vos nœuds hybrides soient prêts à exécuter des applications, poursuivez avec les étapes décrites à la section [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md). # Mettre à niveau les nœuds hybrides pour votre cluster Les instructions relatives à la mise à niveau des nœuds hybrides sont similaires à celles des nœuds Amazon EKS autogérés qui s’exécutent dans Amazon EC2. Nous vous recommandons de créer de nouveaux nœuds hybrides sur votre version Kubernetes cible, de migrer en douceur vos applications existantes vers les nœuds hybrides de la nouvelle version Kubernetes, puis de supprimer les nœuds hybrides de l’ancienne version Kubernetes de votre cluster. Avant de lancer une mise à niveau, veillez à consulter les [meilleures pratiques Amazon EKS](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html) en matière de mise à niveau. Les nœuds hybrides Amazon EKS prennent en charge la [même version de Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) que les clusters Amazon EKS avec nœuds cloud, y compris la prise en charge standard et étendue. Les nœuds hybrides Amazon EKS suivent la même [politique de distorsion des versions](https://kubernetes.io/releases/version-skew-policy/#supported-version-skew) pour les nœuds que pour Kubernetes en amont. Les nœuds hybrides Amazon EKS ne peuvent pas être d’une version plus récente que le plan de contrôle Amazon EKS, et les nœuds hybrides peuvent être jusqu’à trois versions mineures Kubernetes plus anciennes que la version mineure du plan de contrôle Amazon EKS. Si vous ne disposez pas de capacité suffisante pour créer de nouveaux nœuds hybrides sur votre version Kubernetes cible dans le cadre d’une stratégie de migration par basculement, vous pouvez également utiliser l’interface CLI nœuds hybrides Amazon EKS (`nodeadm`) pour mettre à niveau la version Kubernetes de vos nœuds hybrides sur place. **Important** Si vous mettez à niveau vos nœuds hybrides sur place avec `nodeadm`, il y a une durée d’indisponibilité pour le nœud pendant le processus où l’ancienne version des composants Kubernetes est arrêtée et où les composants de la nouvelle version Kubernetes sont installés et démarrés. ## Prérequis Avant de procéder à la mise à niveau, assurez-vous d’avoir rempli les conditions préalables suivantes. + La version Kubernetes cible pour la mise à niveau de vos nœuds hybrides doit être égale ou inférieure à la version du plan de contrôle Amazon EKS. + Si vous suivez une stratégie de migration par basculement, les nouveaux nœuds hybrides que vous installez sur votre version Kubernetes cible doivent répondre aux exigences [Configuration préalable requise pour les nœuds hybrides](hybrid-nodes-prereqs.md). Cela inclut le fait d’avoir des adresses IP dans le CIDR du réseau de nœuds distants que vous avez transmis lors de la création du cluster Amazon EKS. + Pour les migrations par basculement et les mises à niveau sur site, les nœuds hybrides doivent avoir accès aux [domaines requis](hybrid-nodes-networking.md#hybrid-nodes-networking-on-prem) pour extraire les nouvelles versions des dépendances des nœuds hybrides. + Vous devez avoir installé kubectl sur votre machine locale ou l’instance que vous utilisez pour interagir avec votre point de terminaison API Amazon EKS Kubernetes. + La version de votre CNI doit prendre en charge la version de Kubernetes vers laquelle vous effectuez la mise à niveau. Si ce n’est pas le cas, mettez à niveau votre version CNI avant de mettre à niveau vos nœuds hybrides. Pour plus d’informations, consultez [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md). ## Mises à niveau liées à la migration par transition (bleu-vert) Les *mises à niveau par migration cutover* désignent le processus consistant à créer de nouveaux nœuds hybrides sur de nouveaux hôtes avec votre version Kubernetes cible, à migrer en douceur vos applications existantes vers les nouveaux nœuds hybrides sur votre version Kubernetes cible, et à supprimer les nœuds hybrides sur l’ancienne version Kubernetes de votre cluster. Cette stratégie est également appelée migration bleu-vert. 1. Connectez vos nouveaux hôtes en tant que nœuds hybrides en suivant les étapes [Connecter les nœuds hybrides](hybrid-nodes-join.md). Lorsque vous exécutez la commande `nodeadm install`, utilisez votre version cible de Kubernetes. 1. Activez la communication entre les nouveaux nœuds hybrides sur la version Kubernetes cible et vos nœuds hybrides sur l’ancienne version Kubernetes. Cette configuration permet aux pods de communiquer entre eux pendant que vous migrez votre charge de travail vers les nœuds hybrides sur la version Kubernetes cible. 1. Vérifiez que vos nœuds hybrides sur votre version Kubernetes cible ont bien rejoint votre cluster et ont le statut Ready. 1. Utilisez la commande suivante pour marquer chacun des nœuds que vous souhaitez supprimer comme non planifiable. Cela permet d’éviter que de nouveaux pods ne soient planifiés ou replanifiés sur les nœuds que vous remplacez. Pour plus d’informations, consultez [le cordon kubelet](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_cordon/) dans la documentation Kubernetes. Remplacez `NODE_NAME` par le nom des nœuds hybrides de l’ancienne version de Kubernetes. ``` kubectl cordon NODE_NAME ``` Vous pouvez identifier et isoler tous les nœuds d’une version particulière de Kubernetes (dans ce cas, `1.28`) à l’aide de l’extrait de code suivant. ``` 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. Si votre déploiement actuel exécute moins de deux réplicas CoreDNS sur vos nœuds hybrides, augmentez horizontalement la capacité du déploiement à au moins deux réplicas. Nous vous recommandons d’exécuter au moins deux réplicas CoreDNS sur des nœuds hybrides afin d’assurer la résilience pendant les opérations normales. ``` kubectl scale deployments/coredns --replicas=2 -n kube-system ``` 1. Videz chacun des nœuds hybrides de l’ancienne version de Kubernetes que vous souhaitez supprimer de votre cluster à l’aide de la commande suivante. Pour plus d’informations sur la mise hors tension des nœuds, consultez la section [Mettre hors tension un nœud](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) en toute sécurité dans la documentation Kubernetes. Remplacez `NODE_NAME` par le nom des nœuds hybrides de l’ancienne version de Kubernetes. ``` kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data ``` Vous pouvez identifier et vider tous les nœuds d’une version particulière de Kubernetes (dans ce cas, `1.28`) à l’aide de l’extrait de code suivant. ``` 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. Vous pouvez utiliser `nodeadm` pour arrêter et supprimer les artefacts des nœuds hybrides de l’hôte. Vous devez exécuter `nodeadm` avec un utilisateur disposant des privilèges root/sudo. Par défaut, `nodeadm uninstall` ne continuera pas s’il reste des pods sur le nœud. Pour plus d’informations, consultez [Référence des nœuds hybrides `nodeadm`](hybrid-nodes-nodeadm.md). ``` nodeadm uninstall ``` 1. Une fois les artefacts des nœuds hybrides arrêtés et désinstallés, supprimez la ressource du nœud de votre cluster. ``` kubectl delete node node-name ``` Vous pouvez identifier et supprimer tous les nœuds d’une version particulière de Kubernetes (dans ce cas, `1.28`) à l’aide de l’extrait de code suivant. ``` 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. Selon votre choix de CNI, il se peut que des artefacts subsistent sur vos nœuds hybrides après avoir exécuté les étapes ci-dessus. Pour plus d’informations, consultez [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md). ## Mises à niveau sur place Le processus de mise à niveau sur place consiste à utiliser `nodeadm upgrade` pour mettre à niveau la version Kubernetes pour les nœuds hybrides sans utiliser de nouveaux hôtes physiques ou virtuels ni de stratégie de migration par basculement. Le processus `nodeadm upgrade` arrête les anciens composants Kubernetes existants qui s’exécutent sur le nœud hybride, désinstalle les anciens composants Kubernetes existants, installe les nouveaux composants Kubernetes cibles et démarre les nouveaux composants Kubernetes cibles. Il est fortement recommandé de mettre à niveau un nœud à la fois afin de minimiser l’impact sur les applications exécutées sur les nœuds hybrides. La durée de ce processus dépend de la bande passante et de la latence de votre réseau. 1. Utilisez la commande suivante pour marquer le nœud que vous mettez à niveau comme non planifiable. Cela permet d’éviter que de nouveaux pods ne soient planifiés ou replanifiés sur le nœud que vous mettez à niveau. Pour plus d’informations, consultez [kubectl cordon](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_cordon/) dans la documentation Kubernetes. Remplacer `NODE_NAME` par le nom du nœud hybride que vous mettez à niveau ``` kubectl cordon NODE_NAME ``` 1. Videz le nœud que vous mettez à niveau à l’aide de la commande suivante. Pour plus d’informations sur la mise hors tension des nœuds, consultez la section [Mettre hors tension un nœud](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) en toute sécurité dans la documentation Kubernetes. Remplacez `NODE_NAME` par le nom du nœud hybride que vous mettez à niveau. ``` kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data ``` 1. Exécutez `nodeadm upgrade` sur le nœud hybride que vous mettez à niveau. Vous devez exécuter `nodeadm` avec un utilisateur disposant des privilèges root/sudo. Le nom du nœud est conservé lors de la mise à niveau pour les fournisseurs d’informations d’identification AWS SSM et Rôles Anywhere IAM AWS. Vous ne pouvez pas changer de fournisseur d’informations d’identification pendant le processus de mise à niveau. Consultez [Référence des nœuds hybrides `nodeadm`](hybrid-nodes-nodeadm.md) pour les valeurs de configuration de `nodeConfig.yaml`. Remplacez `K8S_VERSION` par la version cible de Kubernetes vers laquelle vous effectuez la mise à niveau. ``` nodeadm upgrade K8S_VERSION -c file://nodeConfig.yaml ``` 1. Pour autoriser la planification des pods sur le nœud après la mise à niveau, tapez ce qui suit. Remplacez `NODE_NAME` par le nom du nœud. ``` kubectl uncordon NODE_NAME ``` 1. Vérifiez le statut de vos nœuds hybrides et attendez que vos nœuds s’arrêtent et redémarrent sur la nouvelle version de Kubernetes avec le statut Ready. ``` kubectl get nodes -o wide -w ``` # Mises à jour de sécurité pour les nœuds hybrides Cette rubrique décrit la procédure à suivre pour appliquer des correctifs de sécurité à des packages et dépendances spécifiques s’exécutant sur vos nœuds hybrides. Nous vous recommandons de mettre régulièrement à jour vos nœuds hybrides afin de recevoir les CVE et les correctifs de sécurité. Pour connaître les étapes à suivre pour mettre à niveau la version de Kubernetes, consultez [Mettre à niveau les nœuds hybrides pour votre cluster](hybrid-nodes-upgrade.md). Un exemple de logiciel pouvant nécessiter un correctif de sécurité est `containerd`. ## `Containerd` `containerd` est l’exécution de conteneur Kubernetes standard et la dépendance principale pour les nœuds hybrides EKS, utilisée pour gérer le cycle de vie des conteneurs, y compris le téléchargement d’images et la gestion de l’exécution des conteneurs. Sur un nœud hybride, vous pouvez installer `containerd` via l’interface [CLI nodeadm](https://docs.aws.amazon.com/eks/latest/userguide/hybrid-nodes-nodeadm.html) ou manuellement. En fonction du système d’exploitation de votre nœud, `nodeadm` installera `containerd` à partir du paquet distribué par le système d’exploitation ou du paquet Docker. Lorsqu’un CVE dans `containerd` a été publié, vous disposez des options suivantes pour passer à la version corrigée de `containerd` sur vos nœuds hybrides. ## Étape 1 : vérifier si le correctif a été publié dans les gestionnaires de paquets Vous pouvez vérifier si le correctif CVE `containerd` a été publié pour chaque gestionnaire de paquets OS en consultant les bulletins de sécurité correspondants : + [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) Si vous utilisez le dépôt Docker comme source de `containerd`, vous pouvez consulter les [annonces de sécurité Docker](https://docs.docker.com/security/security-announcements/) pour vérifier la disponibilité de la version corrigée dans le dépôt Docker. ## Étape 2 : choisir la méthode d’installation du correctif Il existe trois méthodes pour corriger et installer les mises à niveau de sécurité sur place sur les nœuds. La méthode que vous pouvez utiliser dépend de la disponibilité du correctif dans le gestionnaire de paquets du système d’exploitation : 1. Installez les correctifs avec `nodeadm upgrade` qui sont publiés dans les gestionnaires de paquets, voir [Étape 2a](#hybrid-nodes-security-nodeadm). 1. Installez les correctifs directement à l’aide des gestionnaires de paquets, voir [Étape 2b](#hybrid-nodes-security-package). 1. Installez des correctifs personnalisés qui ne sont pas publiés dans les gestionnaires de paquets. Veuillez noter qu’il existe des considérations particulières pour les correctifs personnalisés pour `containerd`, [Étape 2c](#hybrid-nodes-security-manual). ## Étape 2a : application d’un correctif avec `nodeadm upgrade` Après avoir vérifié que le correctif CVE `containerd` a été publié dans les référentiels OS ou Docker (Apt ou RPM), vous pouvez utiliser la commande `nodeadm upgrade` pour passer à la dernière version de `containerd`. Comme il ne s’agit pas d’une mise à niveau de la version Kubernetes, vous devez indiquer votre version Kubernetes actuelle dans la commande de mise à niveau `nodeadm`. ``` nodeadm upgrade K8S_VERSION --config-source file:///root/nodeConfig.yaml ``` ## Étape 2b : application de correctifs à l’aide des gestionnaires de paquets du système d’exploitation Vous pouvez également effectuer la mise à jour via le gestionnaire de paquets correspondant et l’utiliser pour mettre à niveau le paquet `containerd` comme suit. **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 ``` ## Étape 2c : correctif CVE `Containerd` non publié dans les gestionnaires de paquets Si la version corrigée `containerd` n’est disponible que par d’autres moyens que le gestionnaire de paquets, par exemple dans les versions GitHub, vous pouvez installer `containerd` à partir du site officiel GitHub. 1. Si la machine a déjà rejoint le cluster en tant que nœud hybride, vous devez alors exécuter la commande `nodeadm uninstall`. 1. Installez les binaires officiels `containerd`. Vous pouvez suivre les [étapes d’installation officielles](https://github.com/containerd/containerd/blob/main/docs/getting-started.md#option-1-from-the-official-binaries) sur GitHub. 1. Exécutez la commande `nodeadm install` avec l’argument `--containerd-source` défini sur `none`, ce qui ignorera l’installation `containerd` via `nodeadm`. Vous pouvez utiliser la valeur de `none` dans la source `containerd` pour tout système d’exploitation exécuté par le nœud. ``` nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER --containerd-source none ``` # Supprimer les nœuds hybrides Cette rubrique décrit comment supprimer les nœuds hybrides de votre cluster Amazon EKS. [Vous devez supprimer vos nœuds hybrides avec l’outil compatible Kubernetes de votre choix, tel que kubectl.](https://kubernetes.io/docs/reference/kubectl/) Les frais liés aux nœuds hybrides cessent lorsque l’objet nœud est supprimé du cluster Amazon EKS. Pour plus d’informations sur la tarification des nœuds hybrides, consultez la section [Tarification d’Amazon EKS](https://aws.amazon.com/eks/pricing/). **Important** La suppression de nœuds perturbe les charges de travail exécutées sur le nœud. Avant de supprimer des nœuds hybrides, nous vous recommandons de vider d’abord le nœud afin de déplacer les pods vers un autre nœud actif. Pour plus d’informations sur la mise hors tension des nœuds, consultez la section [Mettre hors tension un nœud](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) en toute sécurité dans la documentation Kubernetes. Exécutez les étapes kubectl ci-dessous à partir de votre machine locale ou de l’instance que vous utilisez pour interagir avec le point de terminaison API Kubernetes du cluster Amazon EKS. Si vous utilisez un fichier spécifique `kubeconfig`, utilisez l’indicateur `--kubeconfig`. ## Étape 1 : répertorier vos nœuds ``` kubectl get nodes ``` ## Étape 2 : vider votre nœud Pour plus d’informations sur cette commande `kubectl drain`, consultez la section [kubectl drain](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_drain/) dans la documentation Kubernetes. ``` kubectl drain --ignore-daemonsets ``` ## Étape 3 : arrêter et désinstaller les artefacts des nœuds hybrides Vous pouvez utiliser la CLI des nœuds hybrides Amazon EKS (`nodeadm`) pour arrêter et supprimer les artefacts des nœuds hybrides de l’hôte. Vous devez exécuter `nodeadm` avec un utilisateur disposant des privilèges root/sudo. Par défaut, `nodeadm uninstall` ne continuera pas s’il reste des pods sur le nœud. Si vous utilisez Systems Manager (SSM) AWS comme fournisseur d’informations d’identification, la commande `nodeadm uninstall` désenregistre l’hôte en tant qu’instance AWS gérée par SSM. Pour de plus amples informations, consultez [Référence des nœuds hybrides `nodeadm`](hybrid-nodes-nodeadm.md). ``` nodeadm uninstall ``` ## Étape 4 : supprimer votre nœud du cluster Une fois les artefacts des nœuds hybrides arrêtés et désinstallés, supprimez la ressource du nœud de votre cluster. ``` kubectl delete node ``` ## Étape 5 : vérifier s’il reste des artefacts Selon votre choix de CNI, il se peut que des artefacts subsistent sur vos nœuds hybrides après avoir exécuté les étapes ci-dessus. Pour plus d'informations, consultez [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md).