**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.

# Configurer les modules complémentaires pour les nœuds hybrides
<a name="hybrid-nodes-add-ons"></a>

Cette page décrit les considérations relatives à l'exécution de AWS modules complémentaires et de modules complémentaires communautaires sur les nœuds hybrides Amazon EKS. Pour en savoir plus sur les modules complémentaires Amazon EKS et les processus de création, de mise à niveau et de suppression de modules complémentaires de votre cluster, consultez [Modules complémentaires Amazon EKS](eks-add-ons.md). Sauf indication contraire sur cette page, les processus de création, de mise à niveau et de suppression des modules complémentaires Amazon EKS sont les mêmes pour les clusters Amazon EKS dotés de nœuds hybrides que pour les clusters Amazon EKS dotés de nœuds exécutés dans AWS le cloud. Seuls les modules complémentaires inclus dans cette page ont été validés pour leur compatibilité avec les nœuds hybrides Amazon EKS.

Les AWS modules complémentaires suivants sont compatibles avec les nœuds hybrides Amazon EKS.


|  AWS module complémentaire | Versions complémentaires compatibles | 
| --- | --- | 
|  kube-proxy  |  v1.25.14-eksbuild.2 et versions ultérieures  | 
|  CoreDNS  |  v1.9.3-eksbuild.7 et versions ultérieures  | 
|   AWS Distribution pour OpenTelemetry (ADOT)  |  v0.102.1-eksbuild.2 et versions ultérieures  | 
|  CloudWatch Agent d'observabilité  |  v2.2.1-eksbuild.1 et versions ultérieures  | 
|  Agent d'identité du pod EKS  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/hybrid-nodes-add-ons.html)  | 
|  Agent de surveillance des nœuds  |  v1.2.0-eksbuild.1 et versions ultérieures  | 
|  Contrôleur d'instantané CSI  |  v8.1.0-eksbuild.1 et ultérieures  | 
|   AWS Connecteur CA privé pour Kubernetes  |  v1.6.0-eksbuild.1 et ultérieures  | 
|  pilote Amazon FSx CSI  |  v1.7.0-eksbuild.1 et versions ultérieures  | 
|   AWS Fournisseur de pilotes CSI Secrets Store  |  v2.1.1-eksbuild.1 et versions ultérieures  | 

Les modules complémentaires communautaires suivants sont compatibles avec les nœuds hybrides Amazon EKS. Pour en savoir plus sur les modules complémentaires communautaires, consultez [Extensions communautaires](community-addons.md).


| Module complémentaire communautaire | Versions complémentaires compatibles | 
| --- | --- | 
|  Serveur de métriques Kubernetes  |  v0.7.2-eksbuild.1 et versions ultérieures  | 
|  cert-manager  |  v1.17.2-eksbuild.1 et versions ultérieures  | 
|  Exportateur de nœuds Prometheus  |  v1.9.1-eksbuild.2 et versions ultérieures  | 
|  kube-state-metrics  |  v2.15.0-eksbuild.4 et versions ultérieures  | 
|  DNS externe  |  v0.19.0-eksbuild.1 et versions ultérieures  | 

Outre les modules complémentaires Amazon EKS présentés dans les tableaux ci-dessus, le [collecteur du service géré Amazon pour Prometheus](prometheus.md) et le [contrôleur d’équilibreur de charge AWS](aws-load-balancer-controller.md) pour [l’entrée d’applications](alb-ingress.md) (HTTP) et [l’équilibrage de charge](network-load-balancing.md) (TCP/UDP) sont compatibles avec les nœuds hybrides.

Il existe des AWS modules complémentaires et des modules complémentaires communautaires qui ne sont pas compatibles avec les nœuds hybrides Amazon EKS. Les dernières versions de ces modules complémentaires disposent d’une règle anti-affinité pour l’étiquette `eks.amazonaws.com/compute-type: hybrid` par défaut appliquée aux nœuds hybrides. Cela les empêche de s’exécuter sur des nœuds hybrides lorsqu’ils sont déployés dans vos clusters. Si vous avez des clusters comportant à la fois des nœuds hybrides et des nœuds exécutés dans AWS le cloud, vous pouvez déployer ces modules complémentaires dans votre cluster sur des nœuds exécutés dans AWS le cloud. L'Amazon VPC CNI n'est pas compatible avec les nœuds hybrides, et Cilium et Calico sont pris en charge en tant qu'interfaces réseau de conteneurs () CNIs pour les nœuds hybrides Amazon EKS. Pour plus d’informations, consultez [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md).

## AWS modules complémentaires
<a name="hybrid-nodes-add-ons-aws-add-ons"></a>

Les sections suivantes décrivent les différences entre l'exécution de AWS modules complémentaires compatibles sur des nœuds hybrides par rapport aux autres types de calcul Amazon EKS.

## kube-proxy et CoreDNS
<a name="hybrid-nodes-add-ons-core"></a>

EKS installe kube-proxy et CoreDNS en tant que modules complémentaires autogérés par défaut lorsque vous créez un cluster EKS avec l'API AWS et, notamment, à partir de la CLI. AWS SDKs AWS Vous pouvez remplacer ces modules complémentaires par les modules complémentaires Amazon EKS après la création du cluster. Consultez la documentation EKS pour plus de détails sur [Gérer `kube-proxy` dans les Clusters Amazon EKS](managing-kube-proxy.md) et [Gérer CoreDNS pour DNS dans les clusters Amazon EKS](managing-coredns.md). Si vous utilisez un cluster en mode mixte avec à la fois des nœuds hybrides et des nœuds dans le AWS cloud, il est AWS recommandé d'avoir au moins une réplique CoreDNS sur les nœuds hybrides et au moins une réplique CoreDNS sur vos nœuds dans le cloud. AWS Consultez [Configuration des réplicas de CoreDNS](hybrid-nodes-webhooks.md#hybrid-nodes-mixed-coredns) pour les étapes de configuration.

## CloudWatch Agent d'observabilité
<a name="hybrid-nodes-add-ons-cw"></a>

L'opérateur de l'agent CloudWatch Observability utilise des [webhooks](https://kubernetes.io/docs/reference/access-authn-authz/webhook/). Si vous exécutez l’opérateur sur des nœuds hybrides, votre CIDR de pod sur site doit être routable sur votre réseau sur site et vous devez configurer votre cluster EKS avec votre réseau de pods distant. Pour plus d’informations, consultez [Configurer les webhooks pour les nœuds hybrides](hybrid-nodes-webhooks.md).

Les métriques au niveau des nœuds ne sont pas disponibles pour les nœuds hybrides car [CloudWatch Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) dépend de la disponibilité du service IMDS ([Instance Metadata Service](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)) pour les métriques au niveau des nœuds. Les métriques au niveau des clusters, des charges de travail, des pods et des conteneurs sont disponibles pour les nœuds hybrides.

Après avoir installé le module complémentaire en suivant les étapes décrites dans [Installer l' CloudWatch agent avec Amazon CloudWatch Observability, le](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Observability-EKS-addon.html) manifeste du module complémentaire doit être mis à jour pour que l'agent puisse s'exécuter correctement sur des nœuds hybrides. Modifiez la ressource `amazoncloudwatchagents` sur le cluster pour ajouter la variable d’environnement `RUN_WITH_IRSA` comme indiqué ci-dessous.

```
kubectl edit amazoncloudwatchagents -n amazon-cloudwatch cloudwatch-agent
```

```
apiVersion: v1
items:
- apiVersion: cloudwatch.aws.amazon.com/v1alpha1
  kind: AmazonCloudWatchAgent
  metadata:
    ...
    name: cloudwatch-agent
    namespace: amazon-cloudwatch
    ...
  spec:
    ...
    env:
    - name: RUN_WITH_IRSA # <-- Add this
      value: "True" # <-- Add this
    - name: K8S_NODE_NAME
      valueFrom:
        fieldRef:
          fieldPath: spec.nodeName
          ...
```

## Collecteur géré Amazon Managed Prometheus pour nœuds hybrides
<a name="hybrid-nodes-add-ons-amp"></a>

Un collecteur géré par le service géré Amazon pour Prometheus (AMP) consiste en un scraper qui détecte et collecte des métriques à partir des ressources d’un cluster Amazon EKS. AMP gère le scraper pour vous, vous évitant ainsi d’avoir à gérer vous-même les instances, les agents ou les scrapers.

Vous pouvez utiliser les collecteurs gérés AMP sans aucune configuration supplémentaire spécifique aux nœuds hybrides. Cependant, les points de terminaison métriques de vos applications sur les nœuds hybrides doivent être accessibles depuis le VPC, y compris les itinéraires entre le VPC et le CIDRs réseau de pods distants et les ports ouverts dans votre pare-feu sur site. De plus, votre cluster doit disposer d’un [accès privé au point de terminaison du cluster](cluster-endpoint.md).

Suivez les étapes décrites dans la section [Utilisation d'un collecteur AWS géré](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html) dans le guide de l'utilisateur d'Amazon Managed Service for Prometheus.

## AWS Distribution pour OpenTelemetry (ADOT)
<a name="hybrid-nodes-add-ons-adot"></a>

Vous pouvez utiliser le module complémentaire AWS Distro for OpenTelemetry (ADOT) pour collecter des métriques, des journaux et des données de suivi à partir de vos applications exécutées sur des nœuds hybrides. ADOT utilise des [webhooks](https://kubernetes.io/docs/reference/access-authn-authz/webhook/) d’admission pour modifier et valider les demandes de ressources personnalisées du collecteur. Si vous exécutez l’opérateur ADOT sur des nœuds hybrides, votre CIDR de pod sur site doit être routable sur votre réseau sur site et vous devez configurer votre cluster EKS avec votre réseau de pods distant. Pour plus d’informations, consultez [Configurer les webhooks pour les nœuds hybrides](hybrid-nodes-webhooks.md).

Suivez les étapes décrites dans [Getting Started with AWS Distro pour OpenTelemetry utiliser les modules complémentaires EKS](https://aws-otel.github.io/docs/getting-started/adot-eks-add-on) dans la * AWS distribution pour OpenTelemetry* obtenir de la documentation.

## AWS Contrôleur Load Balancer
<a name="hybrid-nodes-add-ons-lbc"></a>

Vous pouvez utiliser le [AWS Load Balancer Controller](aws-load-balancer-controller.md) et l'Application Load Balancer (ALB) ou le Network Load Balancer (NLB) avec le `ip` type de cible pour les charges de travail sur les nœuds hybrides. Les cibles IP utilisées avec l'ALB ou le NLB doivent être routables depuis. AWS[Le contrôleur AWS Load Balancer utilise également des webhooks.](https://kubernetes.io/docs/reference/access-authn-authz/webhook/) Si vous exécutez l'opérateur AWS Load Balancer Controller sur des nœuds hybrides, le CIDR de votre pod local doit être routable sur votre réseau local et vous devez configurer votre cluster EKS avec votre réseau de pods distants. Pour plus d’informations, consultez [Configurer les webhooks pour les nœuds hybrides](hybrid-nodes-webhooks.md).

Pour installer le AWS Load Balancer Controller, suivez les étapes indiquées dans ou. [AWS Application Load Balancer](hybrid-nodes-ingress.md#hybrid-nodes-ingress-alb) [AWS Network Load Balancer](hybrid-nodes-load-balancing.md#hybrid-nodes-service-lb-nlb)

Pour l’entrée avec ALB, vous devez spécifier les annotations ci-dessous. Pour plus d’informations, consultez [Routage du trafic des applications et du trafic HTTP avec des équilibreurs de charge Application Load Balancer](alb-ingress.md).

```
alb.ingress.kubernetes.io/target-type: ip
```

Pour l’équilibrage de charge avec NLB, vous devez spécifier les annotations ci-dessous. Pour plus d’informations, consultez [Acheminer le trafic TCP et UDP avec des Network Load Balancers](network-load-balancing.md).

```
service.beta.kubernetes.io/aws-load-balancer-type: "external"
service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"
```

## Agent d'identité du pod EKS
<a name="hybrid-nodes-add-ons-pod-id"></a>

**Note**  
Pour déployer correctement le module complémentaire EKS Pod Identity Agent sur des nœuds hybrides exécutant Bottlerocket, assurez-vous que votre version de Bottlerocket est au moins v1.39.0. Pod Identity Agent n’est pas pris en charge sur les versions antérieures de Bottlerocket dans les environnements à nœuds hybrides.

L'agent d'identité Amazon EKS Pod d'origine DaemonSet s'appuie sur la disponibilité d'EC2 IMDS sur le nœud pour obtenir les informations d'identification requises AWS . Comme l'IMDS n'est pas disponible sur les nœuds hybrides, à partir de la version 1.3.3-eksbuild.1, le module complémentaire Pod Identity Agent déploie éventuellement un module qui monte les informations d'identification requises. DaemonSet Les nœuds hybrides exécutant Bottlerocket nécessitent une méthode différente pour monter les informations d'identification, et à partir de la version 1.3.7-eksbuild.2, le module complémentaire Pod Identity Agent déploie éventuellement une méthode qui cible spécifiquement les nœuds hybrides Bottlerocket. DaemonSet Les sections suivantes décrivent le processus d'activation de l'option DaemonSets.

### Ubuntu/RHEL/AL2023
<a name="_ubunturhelal2023"></a>

1. Pour utiliser l'agent Pod Identity sur Ubuntu/RHEL/Al 2023 nœuds hybrides, `enableCredentialsFile: true` configurez-le dans la section hybride de la `nodeadm` configuration comme indiqué ci-dessous :

   ```
   apiVersion: node.eks.aws/v1alpha1
   kind: NodeConfig
   spec:
       hybrid:
           enableCredentialsFile: true # <-- Add this
   ```

   Cela permettra à `nodeadm` de créer un fichier d’informations d’identification à configurer sur le nœud sous `/eks-hybrid/.aws/credentials`, qui sera utilisé par les pods `eks-pod-identity-agent`. Ce fichier d'informations d'identification contiendra des AWS informations d'identification temporaires qui seront actualisées périodiquement.

1. Après avoir mis à jour la configuration `nodeadm` sur *chaque* nœud, exécutez la commande `nodeadm init` suivante avec votre `nodeConfig.yaml` pour joindre vos nœuds hybrides à votre cluster Amazon EKS. Si vos nœuds ont déjà rejoint le cluster, exécutez à nouveau la commande `nodeadm init`.

   ```
   nodeadm init -c file://nodeConfig.yaml
   ```

1. Installation `eks-pod-identity-agent` avec prise en charge des nœuds hybrides activée, à l'aide de la AWS CLI ou AWS Management Console.

   1.  AWS CLI : depuis la machine que vous utilisez pour administrer le cluster, exécutez la commande suivante pour effectuer l'installation en `eks-pod-identity-agent` activant la prise en charge des nœuds hybrides. Remplacez `my-cluster` par le nom de votre cluster.

      ```
      aws eks create-addon \
          --cluster-name my-cluster \
          --addon-name eks-pod-identity-agent \
          --configuration-values '{"daemonsets":{"hybrid":{"create": true}}}'
      ```

   1.  AWS Management Console: Si vous installez le module complémentaire Pod Identity Agent via la AWS console, ajoutez ce qui suit à la configuration facultative pour déployer DaemonSet celui qui cible les nœuds hybrides.

      ```
      {"daemonsets":{"hybrid":{"create": true}}}
      ```

### Flacon Rocket
<a name="_bottlerocket"></a>

1. Pour utiliser l’agent Pod Identity sur les nœuds hybrides Bottlerocket, ajoutez l’indicateur `--enable-credentials-file=true` à la commande utilisée pour les données utilisateur du conteneur de démarrage Bottlerocket, comme décrit dans [Connectez des nœuds hybrides avec Bottlerocket](hybrid-nodes-bottlerocket.md).

   1. Si vous utilisez le fournisseur d’informations d’identification SSM, votre commande devrait ressembler à ceci :

      ```
      eks-hybrid-ssm-setup --activation-id=<activation-id> --activation-code=<activation-code> --region=<region> --enable-credentials-file=true
      ```

   1. Si vous utilisez le fournisseur d’informations d’identification Rôles Anywhere IAM, votre commande devrait ressembler à ceci :

      ```
      eks-hybrid-iam-ra-setup --certificate=<certificate> --key=<private-key> --enable-credentials-file=true
      ```

      Cela configurera le script bootstrap pour créer un fichier d’informations d’identification sur le nœud sous `/var/eks-hybrid/.aws/credentials`, qui sera utilisé par les pods `eks-pod-identity-agent`. Ce fichier d'informations d'identification contiendra des AWS informations d'identification temporaires qui seront actualisées périodiquement.

1. Installation `eks-pod-identity-agent` avec prise en charge des nœuds hybrides Bottlerocket activée, à l'aide de la CLI AWS ou. AWS Management Console

   1.  AWS CLI : depuis la machine que vous utilisez pour administrer le cluster, exécutez la commande suivante pour effectuer l'installation en activant la prise en charge `eks-pod-identity-agent` des nœuds hybrides Bottlerocket. Remplacez `my-cluster` par le nom de votre cluster.

      ```
      aws eks create-addon \
          --cluster-name my-cluster \
          --addon-name eks-pod-identity-agent \
          --configuration-values '{"daemonsets":{"hybrid-bottlerocket":{"create": true}}}'
      ```

   1.  AWS Management Console: Si vous installez le module complémentaire Pod Identity Agent via la AWS console, ajoutez ce qui suit à la configuration facultative pour déployer le module DaemonSet qui cible les nœuds hybrides Bottlerocket.

      ```
      {"daemonsets":{"hybrid-bottlerocket":{"create": true}}}
      ```

## Contrôleur d'instantané CSI
<a name="hybrid-nodes-add-ons-csi-snapshotter"></a>

À partir de la version`v8.1.0-eksbuild.2`, le [module complémentaire CSI Snapshot Controller](csi-snapshot-controller.md) applique une règle d'anti-affinité souple pour les nœuds hybrides, préférant que le contrôleur `deployment` s'exécute sur EC2 dans la même région AWS que le plan de contrôle Amazon EKS. La colocation `deployment` dans la même AWS région que le plan de contrôle Amazon EKS améliore la latence.

## Modules complémentaires communautaires
<a name="hybrid-nodes-add-ons-community"></a>

Les sections suivantes décrivent les différences entre l’exécution d’extensions communautaires compatibles sur des nœuds hybrides et d’autres types de calcul Amazon EKS.

## Serveur de métriques Kubernetes
<a name="hybrid-nodes-add-ons-metrics-server"></a>

Le plan de contrôle doit atteindre l’adresse IP du pod du serveur de métriques (ou l’adresse IP du nœud si hostNetwork est activé). Par conséquent, à moins que vous n’exécutiez Metrics Server en mode hostNetwork, vous devez configurer un réseau de pods distant lors de la création de votre cluster Amazon EKS, et vous devez rendre vos adresses IP de pods routables. La mise en œuvre du protocole de passerelle frontière (BGP) avec le CNI est une méthode courante pour rendre les adresses IP de vos pods routables.

## cert-manager
<a name="hybrid-nodes-add-ons-cert-manager"></a>

 `cert-manager` utilise des [webhooks.](https://kubernetes.io/docs/reference/access-authn-authz/webhook/) Si vous utilisez `cert-manager` sur des nœuds hybrides, votre CIDR de pod sur site doit être routable sur votre réseau sur site et vous devez configurer votre cluster EKS avec votre réseau de pods distant. Pour plus d’informations, consultez [Configurer les webhooks pour les nœuds hybrides](hybrid-nodes-webhooks.md).