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 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 le AWS Load Balancer Controller et l' CloudWatch Observability Agent, pour effectuer des fonctionnalités 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 solutions alternatives qui nécessitent une configuration d'itinéraires personnalisée ou manuelle. AWS prend en charge les fonctionnalités BGP de Cilium et Calico pour les CIDR des pods publicitaires, voir Configurer CNI pour les nœuds hybrides et pour plus d'informations. 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 comportant à la fois des nœuds hybrides et des nœuds exécutés dans AWS le cloud. 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 AWS Cloud et Cilium ou Calico sur des nœuds hybrides. Cilium et Calico ne sont pas pris en charge AWS lors de leur exécution sur des nœuds dans le Cloud. AWS
Configurez les webhooks pour qu'ils s'exécutent sur des nœuds dans le AWS Cloud. Découvrez comment configurer Configuration des webhooks pour les modules complémentaires les webhooks AWS et les modules complémentaires de la communauté.
Si vos applications nécessitent des pods exécutés sur des nœuds dans le AWS Cloud pour communiquer directement avec des pods exécutés sur des nœuds hybrides (« communication est-ouest »), et que vous utilisez le VPC CNI sur les nœuds du AWS Cloud et Cilium ou Calico sur des nœuds hybrides, le CIDR de votre pod sur site doit être routable sur votre réseau local.
Exécutez au moins une réplique de CoreDNS sur des nœuds dans le AWS Cloud et au moins une réplique de CoreDNS sur des 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 équilibreurs de charge d' AWS application (ALB) ou des équilibreurs de charge réseau (NLB) pour le trafic de charge de travail exécuté sur des nœuds hybrides, la ou les cibles IP utilisées avec l'ALB ou le NLB doivent être routables depuis. 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 AWS Cloud, et le module complémentaire AWS Distro for OpenTelemetry (ADOT) pour collecter des métriques pour les 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 exécutez un cluster en mode mixte avec à la fois des nœuds hybrides et des nœuds dans le AWS Cloud, nous vous recommandons de disposer d'au moins une réplique CoreDNS sur les nœuds hybrides et d'au moins une réplique 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 AWS le Cloud reçoivent automatiquement une étiquette de zone de topologie qui correspond à 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 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.

AWS Contrôleur d'équilibrage de charge
CloudWatch Agent d'observabilité
AWS Distro pour OpenTelemetry (ADOT)
cert-manager

Consultez les sections suivantes pour configurer les webhooks utilisés par ces modules complémentaires pour qu'ils s'exécutent sur des nœuds dans le AWS Cloud.

AWS Contrôleur d'équilibreur de charge

Pour utiliser le AWS Load Balancer Controller dans une configuration de cluster en mode mixte, vous devez exécuter le contrôleur sur des nœuds dans le AWS Cloud. 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

CloudWatch Agent d'observabilité

Le module complémentaire CloudWatch Observability Agent possède un opérateur Kubernetes qui utilise des webhooks. Pour exécuter l'opérateur sur des nœuds dans le AWS Cloud dans une configuration de cluster en mode mixte, modifiez la configuration de l'opérateur CloudWatch Observability Agent. 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 pour OpenTelemetry (ADOT)

Le module complémentaire AWS Distro for OpenTelemetry (ADOT) possède un opérateur Kubernetes qui utilise des webhooks. Pour exécuter l'opérateur sur des nœuds dans le AWS Cloud dans une configuration de cluster en mode mixte, ajoutez ce qui suit à 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

L'installation du module complémentaire ADOT nécessite l'installation cert-manager des certificats TLS utilisés par le webhook de l'opérateur ADOT. cert-managerexécute également des webhooks et vous pouvez le configurer pour qu'il s'exécute sur des nœuds dans AWS Cloud avec la configuration des valeurs 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 cert-manager module complémentaire exécute des webhooks et vous pouvez le configurer pour qu'il s'exécute sur des nœuds dans AWS Cloud avec la configuration des valeurs 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