Configurazione di webhook per nodi ibridi - Amazon EKS
Considerazioni per i cluster in modalità mistaConfigurazione di cluster in modalità mista

Contribuisci a migliorare questa pagina

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Per contribuire a questa guida per l'utente, scegli il GitHub link Modifica questa pagina nel riquadro destro di ogni pagina.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Configurazione di webhook per nodi ibridi

Questa pagina descrive in dettaglio le considerazioni sull’esecuzione di webhook con nodi ibridi. I webhook vengono utilizzati nelle applicazioni Kubernetes e nei progetti open source, come il Controller del bilanciatore del carico di AWS e l’agente osservabilità di CloudWatch, per eseguire funzionalità di mutazione e convalida in fase di runtime.

Reti di pod instradabili

Se riesci a rendere il CIDR del tuo pod on-premises instradabile sulla tua rete on-premises, puoi eseguire webhook su nodi ibridi. Esistono diverse tecniche che puoi utilizzare per rendere il CIDR del pod on-premises instradabile sulla tua rete on-premises, tra cui Border Gateway Protocol (BGP), route statiche o altre soluzioni di instradamento personalizzate. Il BGP è la soluzione consigliata in quanto è più scalabile e facile da gestire rispetto alle soluzioni alternative che richiedono una configurazione del percorso personalizzata o manuale. AWS supporta le funzionalità BGP di Cilium e Calico per la pubblicità dei CIDR dei pod, consulta Configurazione della CNI per nodi ibridi e CIDR dei pod remoti instradabili per ulteriori informazioni.

Reti di pod non instradabili

Se non riesci a rendere il CIDR del tuo pod on-premises instradabile sulla tua rete on-premises e devi eseguire i webhook, ti consigliamo di eseguire tutti i webhook sui nodi cloud nello stesso cluster EKS dei nodi ibridi.

Considerazioni per i cluster in modalità mista

I cluster in modalità mista sono definiti come cluster EKS con nodi ibridi e nodi in esecuzione nel cloud AWS. Quando esegui un cluster in modalità mista, considera i seguenti consigli:

  • Esegui la CNI del VPC sui nodi nel cloud AWS e Cilium o Calico sui nodi ibridi. Cilium e Calico non sono supportati da AWS quando vengono eseguiti su nodi in nel cloud AWS.

  • Configura i webhook per l’esecuzione su nodi nel cloud AWS. Consulta Configurazione dei webhook per i componenti aggiuntivi su come configurare i webhook per e i componenti aggiuntivi di AWS e della community.

  • Se le tue applicazioni richiedono pod in esecuzione su nodi nel cloud AWS per comunicare direttamente con pod in esecuzione su nodi ibridi (“comunicazione est-ovest”) e utilizzi la CNI del VPC sui nodi nel cloud AWS e Cilium o Calico sui nodi ibridi, il CIDR del tuo pod on-premises deve essere instradabile sulla tua rete on-premises.

  • Esegui almeno una replica di CoreDNS sui nodi nel cloud AWS e almeno una replica di CoreDNS sui nodi ibridi.

  • Configura la distribuzione del traffico del servizio per mantenerlo locale rispetto alla zona da cui proviene. Per ulteriori informazioni sulla Distribuzione del traffico del servizio, consulta Configurazione della distribuzione del traffico del servizio.

  • Se utilizzi Application Load Balancer (ALB) o Network Load Balancer (NLB) di AWS per il traffico del carico di lavoro in esecuzione su nodi ibridi, è necessario che sia possibile instradare le destinazioni IP utilizzate con ALB o NLB da AWS.

  • Il componente aggiuntivo Metrics Server richiede la connettività dal piano di controllo EKS all’indirizzo IP del pod Metrics Server. Se esegui il componente aggiuntivo Metrics Server su nodi ibridi, il CIDR del pod on-premises deve essere instradabile sulla rete on-premises.

  • Per raccogliere metriche per i nodi ibridi utilizzando il Servizio gestito da Amazon per Prometheus (AMP), il CIDR del pod on-premises deve essere instradabile sulla rete on-premises. In alternativa, puoi utilizzare il collettore gestito AMP per le metriche e le risorse del piano di controllo EKS in esecuzione nel cloud AWS e il componente aggiuntivo Distro for OpenTelemetry (ADOT) di AWS per raccogliere metriche per i nodi ibridi.

Configurazione di cluster in modalità mista

Per visualizzare i webhook in fase di mutazione e convalida in esecuzione sul cluster, puoi visualizzare il tipo di risorsa Estensioni nel pannello Risorse della console EKS per il cluster oppure utilizzare i seguenti comandi. EKS riporta anche le metriche dei webhook nella dashboard di osservabilità del cluster, consulta Monitora il tuo cluster con la dashboard di osservabilità per ulteriori informazioni.

kubectl get mutatingwebhookconfigurations
kubectl get validatingwebhookconfigurations

Configurazione della distribuzione del traffico del servizio

Quando esegui cluster in modalità mista, ti consigliamo di utilizzare la Distribuzione del traffico del servizio per mantenere il traffico del servizio locale rispetto alla zona da cui proviene. La Distribuzione del traffico del servizio (disponibile per le versioni 1.31 e successive di Kubernetes in EKS) è la soluzione consigliata rispetto al Topology Aware Routing perché è più prevedibile. Con la Distribuzione del traffico del servizio, gli endpoint integri della zona riceveranno tutto il traffico di quella zona. Con il Topology Aware Routing, ciascun servizio deve soddisfare diverse condizioni in quella zona per applicare il routing personalizzato, altrimenti indirizza il traffico in modo uniforme verso tutti gli endpoint.

Se utilizzi Cilium come CNI, devi eseguire la CNI con il set enable-service-topology su true per abilitare la distribuzione del traffico del servizio. Puoi trasferire questa configurazione con il flag di installazione Helm --set loadBalancer.serviceTopology=true oppure puoi aggiornare un’installazione esistente con il comando CLI cilium config set enable-service-topology true di Cilium. L’agente Cilium in esecuzione su ciascun nodo deve essere riavviato dopo aver aggiornato la configurazione per un’installazione esistente.

Nella sezione seguente è riportato un esempio di come configurare la distribuzione del traffico del servizio per il servizio CoreDNS, ti consigliamo di abilitare la stessa opzione per tutti i servizi del cluster per evitare traffico indesiderato tra gli ambienti.

Configurazione delle repliche CoreDNS

Se stai eseguendo un cluster in modalità mista con nodi ibridi e nodi nel cloud AWS, ti consigliamo di avere almeno una replica CoreDNS sui nodi ibridi e almeno una sui tuoi nodi nel cloud AWS. Per evitare problemi di latenza e di rete in una configurazione di cluster in modalità mista, puoi configurare il servizio CoreDNS in modo da preferire la replica CoreDNS più vicina con la Distribuzione del traffico del servizio.

La Distribuzione del traffico del servizio (disponibile per le versioni 1.31 e successive di Kubernetes in EKS) è la soluzione consigliata rispetto al Topology Aware Routing perché è più prevedibile. Nella Distribuzione del traffico del servizio, gli endpoint integri della zona riceveranno tutto il traffico di quella zona. Nel Topology Aware Routing, ciascun servizio deve soddisfare diverse condizioni in quella zona per applicare il routing personalizzato, altrimenti indirizza il traffico in modo uniforme verso tutti gli endpoint. I seguenti passaggi configurano la Distribuzione del traffico del servizio.

Se utilizzi Cilium come CNI, devi eseguire la CNI con il set enable-service-topology su true per abilitare la Distribuzione del traffico del servizio. Puoi trasferire questa configurazione con il flag di installazione Helm --set loadBalancer.serviceTopology=true oppure puoi aggiornare un’installazione esistente con il comando CLI cilium config set enable-service-topology true di Cilium. L’agente Cilium in esecuzione su ciascun nodo deve essere riavviato dopo aver aggiornato la configurazione per un’installazione esistente.

  1. Aggiungi un’etichetta di zona topologica per ciascuno dei tuoi nodi ibridi, ad esempio topology.kubernetes.io/zone: onprem. In alternativa, puoi impostare l’etichetta nella fase nodeadm init, specificando l’etichetta nella configurazione di nodeadm. Consultare Configurazione del nodo per personalizzare kubelet (Facoltativo). Attenzione, ai nodi in esecuzione nel cloud AWS viene applicata automaticamente un’etichetta di zona topologica che corrisponde alla zona di disponibilità (AZ) del nodo.

    kubectl label node hybrid-node-name topology.kubernetes.io/zone=zone

  2. Aggiungi podAntiAffinity all’implementazione di CoreDNS con la chiave della zona di topologia. In alternativa, puoi configurare l’implementazione di CoreDNS durante l’installazione con i componenti aggiuntivi 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
      ...

  3. Aggiungi l’impostazione trafficDistribution: PreferClose alla configurazione del servizio kube-dns per abilitare la Distribuzione del traffico del servizio.

    kubectl patch svc kube-dns -n kube-system --type=merge -p '{
  "spec": {
    "trafficDistribution": "PreferClose"
  }
}'

  4. Puoi confermare che la Distribuzione del traffico del servizio è abilitata visualizzando le slice degli endpoint per il servizio kube-dns. Le sezioni degli endpoint devono mostrare gli hints per le etichette delle zone topologiche, a conferma che la Distribuzione del traffico del servizio è abilitata. Se non vedi l’hints per ciascun indirizzo degli endpoint, la Distribuzione del traffico del servizio non è abilitato.

    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

Configurazione dei webhook per i componenti aggiuntivi

I seguenti componenti aggiuntivi utilizzano i webhook e sono supportati per l’uso con nodi ibridi.

  • Controller del bilanciatore del carico AWS

  • Agente osservabilità di CloudWatch

  • Distro for OpenTelemetry (ADOT) di AWS

  • cert-manager

Consulta le seguenti sezioni per configurare i webhook utilizzati da questi componenti aggiuntivi per l’esecuzione su nodi nel cloud AWS.

Controller del bilanciatore del carico AWS

Per utilizzare il Controller del bilanciatore del carico di AWS in una configurazione di cluster in modalità mista, devi eseguire il controller sui nodi nel cloud AWS. A tale scopo, aggiungi quanto segue alla configurazione dei valori di Helm o specifica i valori utilizzando la configurazione aggiuntiva EKS.

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: eks.amazonaws.com/compute-type
          operator: NotIn
          values:
          - hybrid

Agente osservabilità di CloudWatch

Il componente aggiuntivo Agente osservabilità di CloudWatch dispone di un operatore Kubernetes che utilizza webhook. Per eseguire l’operatore sui nodi nel cloud AWS in una configurazione di cluster in modalità mista, modifica la configurazione dell’operatore Agente osservabilità di CloudWatch. Non puoi configurare l’affinità dell’operatore durante l’installazione con i componenti aggiuntivi Helm ed EKS (consulta problema containers-roadmap #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

Distro for OpenTelemetry (ADOT) di AWS

Il componente aggiuntivo Distro for OpenTelemetry (ADOT) di AWS dispone di un operatore Kubernetes che utilizza i webhook. Per eseguire l’operatore sui nodi nel cloud AWS in una configurazione di cluster in modalità mista, aggiungi quanto segue alla configurazione dei valori di Helm o specifica i valori utilizzando la configurazione aggiuntiva EKS.

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: eks.amazonaws.com/compute-type
          operator: NotIn
          values:
          - hybrid

Se il CIDR del pod non è instradabile sulla rete on-premises, il collettore ADOT deve essere eseguito su nodi ibridi per acquisire le metriche dai nodi ibridi e dai carichi di lavoro in esecuzione su di essi. A tale scopo, modifica la Definizione di risorse personalizzate (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

Puoi configurare il collettore ADOT per acquisire solo le metriche dai nodi ibridi e dalle risorse in esecuzione sui nodi ibridi aggiungendo il seguente relabel_configs a ciascun scrape_configs nella configurazione CRD del collettore ADOT.

relabel_configs:
  - action: keep
    regex: hybrid
    source_labels:
    - __meta_kubernetes_node_label_eks_amazonaws_com_compute_type

Il componente aggiuntivo ADOT presenta un requisito preliminare per installare cert-manager per i certificati TLS utilizzati dal webhook dell’operatore ADOT. cert-manager esegue anche webhook e puoi configurarlo per l’esecuzione su nodi nel cloud AWS con la seguente configurazione dei valori Helm.

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

Il componente aggiuntivo cert-manager esegue i webhook e puoi configurarlo per l’esecuzione su nodi nel cloud AWS con la seguente configurazione dei valori Helm.

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