AWS modules complémentaires kube-proxy et CoreDNS CloudWatch Agent d'observabilité Collecteur géré par Amazon Managed Prometheus pour nœuds hybrides AWS Distro pour OpenTelemetry (ADOT)AWS Contrôleur Load Balancer Agent d'identité du pod EKS Contrôleur d'instantané CSI Modules complémentaires communautaires Serveur de métriques Kubernetes gestionnaire de certificats

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.

Configuration des modules complémentaires pour les nœuds hybrides

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 des modules complémentaires de votre cluster, consultezModules complémentaires Amazon EKS. 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 sur cette page ont été validés pour leur compatibilité avec Amazon EKS Hybrid Nodes.

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 Distro 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	v1.3.3-eksbuild.1 et versions ultérieures, sauf pour Bottlerocket v1.3.7-eksbuild.2 et versions ultérieures pour Bottlerocket
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 versions ultérieures
AWS Connecteur CA privé pour Kubernetes	v1.6.0-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, consultezModules complémentaires communautaires.

Module complémentaire communautaire	Versions complémentaires compatibles
Serveur de métriques Kubernetes	v0.7.2-eksbuild.1 et versions ultérieures
gestionnaire de certificats	v1.17.2-eksbuild.1 et versions ultérieures
Prometheus Node Exporter	v1.9.1-eksbuild.2 et versions ultérieures
kube-state-metrics	v2.15.0-eksbuild.4 et versions ultérieures

Outre les modules complémentaires Amazon EKS présentés dans les tableaux ci-dessus, Amazon Managed Service pour Prometheus Collector et le Load AWS Balancer Controller pour l'entrée d'applications (HTTP) et l'équilibrage de charge (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'eks.amazonaws.com/compute-type: hybridétiquette 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 Configuration d'un CNI pour les nœuds hybrides.

AWS modules complémentaires

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

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 des modules complémentaires Amazon EKS après la création du cluster. Consultez la documentation EKS pour plus de détails sur Gestion kube-proxy dans des clusters Amazon EKS etGérer CoreDNS pour DNS dans les clusters Amazon EKS. 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 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épliques CoreDNS les étapes de configuration.

CloudWatch Agent d'observabilité

L'opérateur de l'agent CloudWatch Observability utilise des webhooks. Si vous exécutez l'opérateur 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.

Les métriques au niveau des nœuds ne sont pas disponibles pour les nœuds hybrides car CloudWatch Container Insights dépend de la disponibilité du service IMDS (Instance Metadata Service) pour les métriques au niveau des nœuds. Les métriques au niveau du cluster, de la charge de travail, du pod et du conteneur 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 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 amazoncloudwatchagents ressource du cluster pour ajouter la variable d'RUN_WITH_IRSAenvironnement 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é par Amazon Managed Prometheus pour nœuds hybrides

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

Vous pouvez utiliser les collecteurs gérés par AMP sans 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. En outre, votre cluster doit disposer d'un accès de point de terminaison privé.

Suivez les étapes décrites dans la section Utilisation d'un collecteur AWS géré dans le guide de l'utilisateur d'Amazon Managed Service for Prometheus.

AWS Distro pour OpenTelemetry (ADOT)

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 d'admission pour muter et valider les demandes de ressources personnalisées du collecteur. Si vous exécutez l'opérateur ADOT 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.

Suivez les étapes décrites dans Getting Started with AWS Distro pour OpenTelemetry utiliser les modules complémentaires EKS dans la AWS distribution pour OpenTelemetry obtenir de la documentation.

AWS Contrôleur Load Balancer

Vous pouvez utiliser le AWS Load Balancer Controller et l'Application Load Balancer (ALB) ou le Network Load Balancer (NLB) avec l'adresse IP de type cible pour les charges de travail sur des nœuds hybrides connectés à Direct Connect ou à un VPN. AWS AWS Site-to-Site La ou les cibles IP utilisées avec l'ALB ou le NLB doivent être routables depuis. AWSLe contrôleur AWS Load Balancer utilise également des webhooks. 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.

Pour installer le AWS Load Balancer Controller, suivez les étapes indiquées dans ou. Installez le contrôleur AWS Load Balancer avec Helm Installer le AWS Load Balancer Controller avec des manifestes

Pour l'entrée avec ALB, vous devez spécifier les annotations ci-dessous. Pour obtenir des instructions, consultez Acheminez le trafic d'applications et le trafic HTTP avec des équilibreurs de charge d'application.


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

Pour l'équilibrage de charge avec NLB, vous devez spécifier les annotations ci-dessous. Pour obtenir des instructions, consultez Acheminez le trafic TCP et UDP avec des équilibreurs de charge réseau.


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

Note

Pour déployer avec succès 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 la version v1.39.0. Le Pod Identity Agent n'est pas pris en charge sur les versions antérieures de Bottlerocket dans les environnements de nœuds hybrides.

L'agent d'identité Amazon EKS Pod d'origine DaemonSet s'appuie sur la disponibilité de l' EC2 IMDS sur le nœud pour obtenir les informations d' AWS identification requises. 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

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 ci-dessous/eks-hybrid/.aws/credentials, qui sera utilisé par les eks-pod-identity-agent pods. Ce fichier d'informations d'identification contiendra des AWS informations d'identification temporaires qui seront actualisées périodiquement.
Après avoir mis à jour la nodeadm configuration sur chaque nœud, exécutez la nodeadm init commande suivante nodeConfig.yaml pour joindre vos nœuds hybrides à votre cluster Amazon EKS. Si vos nœuds ont déjà rejoint le cluster, réexécutez toujours la init commande.
```
nodeadm init -c file://nodeConfig.yaml
```
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}}}'
```
2. 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}}}
```

Bottlerocket

Pour utiliser l'agent Pod Identity sur les nœuds hybrides Bottlerocket, ajoutez l'--enable-credentials-file=trueindicateur à la commande utilisée pour les données utilisateur du conteneur Bottlerocket bootstrap, comme décrit dans. Connectez des nœuds hybrides avec Bottlerocket
1. Si vous utilisez le fournisseur d'informations d'identification SSM, votre commande doit ressembler à ceci :
```
eks-hybrid-ssm-setup --activation-id=<activation-id> --activation-code=<activation-code> --region=<region> --enable-credentials-file=true
```
2. Si vous utilisez le fournisseur d'informations d'identification IAM Roles Anywhere, votre commande doit se présenter comme suit :
```
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 situé en dessous/var/eks-hybrid/.aws/credentials, qui sera utilisé par les eks-pod-identity-agent pods. Ce fichier d'informations d'identification contiendra des AWS informations d'identification temporaires qui seront actualisées périodiquement.
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}}}'
```
2. 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

À partir de la versionv8.1.0-eksbuild.2, le module complémentaire CSI Snapshot Controller applique une règle anti-affinité souple pour les nœuds hybrides, préférant que le contrôleur deployment s'exécute EC2 dans la même AWS région 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

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

Serveur de métriques Kubernetes

Le plan de contrôle doit atteindre l'adresse IP du pod du serveur Metrics (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 distants lors de la création de votre cluster Amazon EKS, et vous devez rendre les adresses IP de vos pods routables. La mise en œuvre du protocole BGP (Border Gateway Protocol) avec le CNI est un moyen courant de rendre les adresses IP de votre pod routables.

gestionnaire de certificats

cert-managerutilise des webhooks. Si vous exécutez cert-manager 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.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Configurer CNI

Configurer les webhooks