Considérations relatives aux clusters en mode mixte Configuration de clusters en mode mixte

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 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 et CIDR de pods distants routables.

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


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 distribution du trafic de service 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, 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.

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

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

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

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"
  }
}'
```
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-<id>`  -n kube-system -o yaml
```
```
addressType: IPv4
apiVersion: discovery.k8s.io/v1
endpoints:
- addresses:
  - <your-hybrid-node-pod-ip>
  hints:
    forZones:
    - name: onprem
  nodeName: <your-hybrid-node-name>
  zone: onprem
- addresses:
  - <your-cloud-node-pod-ip>
  hints:
    forZones:
    - name: us-west-2a
  nodeName: <your-cloud-node-name>
  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 #2431 de containers-roadmap).


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

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 les modules complémentaires

Configurer le proxy