**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 webhooks pour les nœuds hybrides
Cette page détaille les considérations relatives à l’exécution de webhooks avec des nœuds hybrides. Les webhooks sont utilisés dans les applications Kubernetes et les projets open source, tels que l’AWS Load Balancer Controller et l’agent d’observabilité CloudWatch, pour exécuter des fonctions de mutation et de validation lors de l’exécution.
**Réseaux de pods routables**
Si vous pouvez rendre votre pod CIDR sur site routable sur votre réseau sur site, vous pouvez exécuter des webhooks sur des nœuds hybrides. Il existe plusieurs techniques que vous pouvez utiliser pour rendre votre pod CIDR sur site routable sur votre réseau sur site, notamment le protocole de passerelle frontière (BGP), les routes statiques ou d’autres solutions de routage personnalisées. BGP est la solution recommandée, car elle est plus évolutive et plus facile à gérer que les autres solutions qui nécessitent une configuration personnalisée ou manuelle des routes. AWS prend en charge les capacités BGP de Cilium et Calico pour la publicité des CIDR de pod. Pour plus d’informations, consultez [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md) et [CIDR de pods distants routables](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-pod-cidrs).
**Réseaux de pods non routables**
Si vous *ne pouvez pas* rendre votre pod CIDR sur site routable sur votre réseau sur site et que vous devez exécuter des webhooks, nous vous recommandons d’exécuter tous les webhooks sur des nœuds cloud dans le même cluster EKS que vos nœuds hybrides.
## Considérations relatives aux clusters en mode mixte
Les *clusters en mode mixte* sont définis comme des clusters EKS qui comportent à la fois des nœuds hybrides et des nœuds fonctionnant dans le cloud AWS. Lorsque vous exécutez un cluster en mode mixte, tenez compte des recommandations suivantes :
+ Exécutez le VPC CNI sur des nœuds dans le cloud AWS et Cilium ou Calico sur des nœuds hybrides. Cilium et Calico ne sont pas pris en charge par AWS lorsqu’ils sont exécutés sur des nœuds dans le Cloud AWS.
+ Configurez les webhooks pour qu’ils s’exécutent sur des nœuds dans le cloud AWS. Consultez [Configuration des webhooks pour les modules complémentaires](#hybrid-nodes-webhooks-add-ons) pour découvrir comment configurer les webhooks avec AWS et les modules complémentaires communautaires.
+ Si vos applications nécessitent que les pods exécutés sur des nœuds dans le cloud AWS communiquent directement avec les pods exécutés sur des nœuds hybrides (« communication est-ouest ») et que vous utilisez le VPC CNI sur les nœuds dans le cloud AWS, et Cilium ou Calico sur les nœuds hybrides, alors votre CIDR de pod sur site doit être routable sur votre réseau sur site.
+ Exécutez au moins un réplica de CoreDNS sur les nœuds dans le cloud AWS et au moins un réplica de CoreDNS sur les nœuds hybrides.
+ Configurez la distribution du trafic de service afin que celui-ci reste localisé dans la zone d’où il provient. Pour plus d’informations sur la distribution du trafic de service, voir [Configuration de la distribution du trafic de service](#hybrid-nodes-mixed-service-traffic-distribution).
+ Si vous utilisez des Application Load Balancers (ALB) ou des Network Load Balancers (NLB) AWS pour le trafic de charge de travail s’exécutant sur des nœuds hybrides, les cibles IP utilisées avec l’ALB ou le NLB doivent être routables à partir d’AWS.
+ Le module complémentaire Metrics Server nécessite une connectivité entre le plan de contrôle EKS et l’adresse IP du pod Metrics Server. Si vous exécutez le module complémentaire Metrics Server sur des nœuds hybrides, votre CIDR de pod sur site doit être routable sur votre réseau sur site.
+ Pour collecter des métriques pour les nœuds hybrides à l’aide des collecteurs gérés par le service géré Amazon pour Prometheus (AMP), votre CIDR de pod sur site doit être routable sur votre réseau sur site. Vous pouvez également utiliser le collecteur géré AMP pour les métriques et les ressources du plan de contrôle EKS s’exécutant dans le cloud AWS, ainsi que le module complémentaire AWS Distro for OpenTelemetry (ADOT) pour collecter les métriques des nœuds hybrides.
## Configuration de clusters en mode mixte
Pour afficher les webhooks de mutation et de validation exécutés sur votre cluster, vous pouvez consulter le type de ressource **Extensions** dans le panneau **Ressources** de la console EKS de votre cluster, ou utiliser les commandes suivantes. EKS rapporte également les métriques webhook dans le tableau de bord d’observabilité du cluster. Pour plus d’informations, consultez [Surveillez votre cluster à l’aide du tableau de bord d’observabilité](observability-dashboard.md).
```
kubectl get mutatingwebhookconfigurations
```
```
kubectl get validatingwebhookconfigurations
```
### Configuration de la distribution du trafic de service
Lorsque vous utilisez des clusters en mode mixte, nous vous recommandons d’utiliser la [https://kubernetes.io/docs/reference/networking/virtual-ips/#traffic-distribution](https://kubernetes.io/docs/reference/networking/virtual-ips/#traffic-distribution) afin de maintenir le trafic de service local dans la zone d’où il provient. La distribution du trafic des services (disponible pour les versions 1.31 et ultérieures de Kubernetes dans EKS) est la solution recommandée par rapport au [routage topologique](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/), car elle est plus prévisible. Avec la distribution du trafic de service, les terminaux sains de la zone recevront tout le trafic destiné à cette zone. Avec le routage topologique, chaque service doit remplir plusieurs conditions dans cette zone pour appliquer le routage personnalisé, sinon il achemine le trafic de manière uniforme vers tous les points de terminaison.
Si vous utilisez Cilium comme CNI, vous devez exécuter le CNI avec le paramètre `enable-service-topology` défini sur `true` pour activer la distribution du trafic de service. Vous pouvez transmettre cette configuration avec l’indicateur d’installation Helm `--set loadBalancer.serviceTopology=true` ou mettre à jour une installation existante à l’aide de la commande CLI Cilium `cilium config set enable-service-topology true`. L’agent Cilium exécuté sur chaque nœud doit être redémarré après la mise à jour de la configuration d’une installation existante.
La section suivante présente un exemple de configuration de la distribution du trafic de service pour le service CoreDNS. Nous vous recommandons d’activer cette option pour tous les services de votre cluster afin d’éviter tout trafic inter-environnements indésirable.
### Configuration des réplicas de CoreDNS
Si vous utilisez un cluster en mode mixte avec à la fois des nœuds hybrides et des nœuds dans le cloud AWS, nous vous recommandons d’avoir au moins un réplica CoreDNS sur les nœuds hybrides et au moins un réplica CoreDNS sur vos nœuds dans le cloud AWS. Pour éviter les problèmes de latence et de réseau dans une configuration de cluster en mode mixte, vous pouvez configurer le service CoreDNS pour qu’il privilégie le réplica CoreDNS le plus proche avec la [distribution du trafic de service](https://kubernetes.io/docs/reference/networking/virtual-ips/#traffic-distribution).
La *distribution du trafic de service* (disponible pour les versions 1.31 et ultérieures de Kubernetes dans EKS) est la solution recommandée par rapport au [routage topologique](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/), car elle est plus prévisible. Dans la distribution du trafic en service, les points de terminaison sains de la zone recevront tout le trafic destiné à cette zone. Dans le routage sensible à la topologie, chaque service doit remplir plusieurs conditions dans cette zone pour appliquer le routage personnalisé, sinon il achemine le trafic de manière uniforme vers tous les points de terminaison. Les étapes suivantes permettent de configurer la distribution du trafic de service.
Si vous utilisez Cilium comme CNI, vous devez exécuter le CNI avec le paramètre `enable-service-topology` défini sur `true` pour activer la distribution du trafic de service. Vous pouvez transmettre cette configuration avec l’indicateur d’installation Helm `--set loadBalancer.serviceTopology=true` ou mettre à jour une installation existante à l’aide de la commande CLI Cilium `cilium config set enable-service-topology true`. L’agent Cilium exécuté sur chaque nœud doit être redémarré après la mise à jour de la configuration d’une installation existante.
1. Ajoutez une étiquette de zone topologique pour chacun de vos nœuds hybrides, par exemple `topology.kubernetes.io/zone: onprem`. Vous pouvez également définir l’étiquette au niveau de la phase `nodeadm init` en spécifiant l’étiquette dans votre configuration `nodeadm`, voir [Configuration du nœud pour personnaliser kubelet (facultatif)](hybrid-nodes-nodeadm.md#hybrid-nodes-nodeadm-kubelet). Remarque : Les nœuds exécutés dans le cloud AWS se voient automatiquement attribuer une étiquette de zone topologique correspondant à la zone de disponibilité (AZ) du nœud.
```
kubectl label node hybrid-node-name topology.kubernetes.io/zone=zone
```
1. Ajoutez `podAntiAffinity` au déploiement CoreDNS avec la clé de zone de topologie. Vous pouvez également configurer le déploiement de CoreDNS lors de l’installation à l’aide des modules complémentaires EKS.
```
kubectl edit deployment coredns -n kube-system
```
```
spec:
template:
spec:
affinity:
...
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- podAffinityTerm:
labelSelector:
matchExpressions:
- key: k8s-app
operator: In
values:
- kube-dns
topologyKey: kubernetes.io/hostname
weight: 100
- podAffinityTerm:
labelSelector:
matchExpressions:
- key: k8s-app
operator: In
values:
- kube-dns
topologyKey: topology.kubernetes.io/zone
weight: 50
...
```
1. Ajoutez le paramètre `trafficDistribution: PreferClose` à la configuration du service `kube-dns` pour activer la distribution du trafic du service.
```
kubectl patch svc kube-dns -n kube-system --type=merge -p '{
"spec": {
"trafficDistribution": "PreferClose"
}
}'
```
1. Vous pouvez confirmer que la distribution du trafic de service est activée en consultant les tranches de point de terminaison du service `kube-dns`. Vos tranches de point de terminaison doivent afficher les étiquettes `hints` de votre zone topologique, ce qui confirme que la distribution du trafic de service est activée. Si vous ne voyez pas l’adresse de chaque point de terminaison `hints`, cela signifie que la distribution du trafic de service n’est pas activée.
```
kubectl get endpointslice -A | grep "kube-dns"
```
```
kubectl get endpointslice [.replaceable]`kube-dns-` -n kube-system -o yaml
```
```
addressType: IPv4
apiVersion: discovery.k8s.io/v1
endpoints:
- addresses:
-
hints:
forZones:
- name: onprem
nodeName:
zone: onprem
- addresses:
-
hints:
forZones:
- name: us-west-2a
nodeName:
zone: us-west-2a
```
### Configuration des webhooks pour les modules complémentaires
Les modules complémentaires suivants utilisent des webhooks et sont compatibles avec les nœuds hybrides.
+ Contrôleur de l'équilibreur de charge AWS
+ Agent d’observabilité CloudWatch
+ AWS Distro for OpenTelemetry (ADOT)
+ `cert-manager`
Consultez les sections suivantes pour configurer les webhooks utilisés par ces modules complémentaires afin qu’ils s’exécutent sur les nœuds dans Cloud AWS.
#### Contrôleur de l'équilibreur de charge AWS
Pour utiliser l’AWS Load Balancer Controller dans une configuration de cluster en mode mixte, vous devez exécuter le contrôleur sur les nœuds dans le Cloud AWS. Pour ce faire, ajoutez les éléments suivants à votre configuration des valeurs Helm ou spécifiez les valeurs à l’aide de la configuration du module complémentaire EKS.
```
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- hybrid
```
#### Agent d’observabilité CloudWatch
Le module complémentaire Agent d’observabilité CloudWatch dispose d’un opérateur Kubernetes qui utilise des webhooks. Pour exécuter l’opérateur sur des nœuds du AWS cloud dans une configuration de cluster en mode mixte, modifiez la configuration de l’opérateur Agent d’observabilité CloudWatch. Vous ne pouvez pas configurer l’affinité des opérateurs lors de l’installation avec les modules complémentaires Helm et EKS (voir le [problème \$12431 de containers-roadmap](https://github.com/aws/containers-roadmap/issues/2431)).
```
kubectl edit -n amazon-cloudwatch deployment amazon-cloudwatch-observability-controller-manager
```
```
spec:
...
template:
...
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- hybrid
```
#### AWS Distro for OpenTelemetry (ADOT)
Le module complémentaire AWS Distro pour OpenTelemetry (ADOT) dispose d’un opérateur Kubernetes qui utilise des webhooks. Pour exécuter l’opérateur sur les nœuds dans le cloud AWS dans une configuration de cluster en mode mixte, ajoutez les éléments suivants à votre configuration de valeurs Helm ou spécifiez les valeurs à l’aide de la configuration du module complémentaire EKS.
```
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- hybrid
```
Si votre CIDR de pod n’est pas routable sur votre réseau sur site, le collecteur ADOT doit alors s’exécuter sur des nœuds hybrides afin de récupérer les métriques de vos nœuds hybrides et des charges de travail qui s’y exécutent. Pour ce faire, modifiez la définition de ressource personnalisée (CRD).
```
kubectl -n opentelemetry-operator-system edit opentelemetrycollectors.opentelemetry.io adot-col-prom-metrics
```
```
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: In
values:
- hybrid
```
Vous pouvez configurer le collecteur ADOT pour qu’il ne récupère que les métriques des nœuds hybrides et des ressources s’exécutant sur des nœuds hybrides en ajoutant les éléments `relabel_configs` suivants à chaque `scrape_configs` dans la configuration CRD du collecteur ADOT.
```
relabel_configs:
- action: keep
regex: hybrid
source_labels:
- __meta_kubernetes_node_label_eks_amazonaws_com_compute_type
```
Le module complémentaire ADOT doit installer `cert-manager` pour pouvoir utiliser les certificats TLS utilisés par le webhook de l’opérateur ADOT. `cert-manager` exécute également des webhooks et vous pouvez le configurer pour qu’il s’exécute sur des nœuds dans le cloud AWS à l’aide de la configuration Helm suivante.
```
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- hybrid
webhook:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- hybrid
cainjector:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- hybrid
startupapicheck:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- hybrid
```
#### `cert-manager`
Le module complémentaire exécute des webhooks `cert-manager` et vous pouvez le configurer pour qu’il s’exécute sur des nœuds dans le cloud AWS à l’aide de la configuration Helm suivante.
```
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- hybrid
webhook:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- hybrid
cainjector:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- hybrid
startupapicheck:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- hybrid
```