AWS modules complémentaires kube-proxy et CoreDNS CloudWatch Agent d'observabilité Collecteur géré Amazon Managed Prometheus pour nœuds hybrides AWS Distribution 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 cert-manager

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.

Configurer les 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 de modules complémentaires de votre cluster, consultez Modules 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 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	v1.3.3-eksbuild.1 et versions ultérieures, à l’exception de 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 ultérieures
AWS Connecteur CA privé pour Kubernetes	v1.6.0-eksbuild.1 et 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 Community add-ons.

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 et le contrôleur d’équilibreur de charge AWS 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’é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.

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, y compris à 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 et Gé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 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 pour 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, 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.

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

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.

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

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 le ip type de cible pour les charges de travail sur les nœuds hybrides. 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. AWS Application Load Balancer AWS Network Load Balancer

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


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 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é 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, configurez-le enableCredentialsFile: true 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.
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
```
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}}}
```

Flacon Rocket

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.
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
```
2. 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.
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 d'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 d’extensions communautaires compatibles sur des nœuds hybrides et d’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 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

cert-manager utilise des webhooks. 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.

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

Configuration de webhooks