Considerazioni per i cluster in modalità mista Configurazione 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 su che si trova 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 Load AWS Balancer Controller e CloudWatch Observability Agent, per eseguire funzionalità di mutazione e convalida in fase di esecuzione.

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. BGP è la soluzione consigliata in quanto è più scalabile e più facile da gestire rispetto alle soluzioni alternative che richiedono una configurazione personalizzata o manuale dei percorsi. AWS supporta le funzionalità BGP di Cilium e Calico per la pubblicità dei pod CIDR, vedi e per ulteriori informazioni. Configurazione della CNI per nodi ibridi CIDR dei pod remoti instradabili

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 il VPC CNI sui nodi in AWS Cloud e Cilium o Calico sui nodi ibridi. Cilium e Calico non sono supportati da AWS quando vengono eseguiti su nodi in Cloud. AWS
Configura i webhook per l'esecuzione sui nodi nel cloud. AWS Scopri come configurare Configurazione dei webhook per i componenti aggiuntivi i webhook e i componenti aggiuntivi della community. AWS
Se le tue applicazioni richiedono che i pod in esecuzione su nodi in AWS Cloud comunichino direttamente con i pod in esecuzione su nodi ibridi («comunicazione est-ovest») e utilizzi il VPC CNI sui nodi in AWS Cloud e Cilium o Calico sui nodi ibridi, allora il tuo pod CIDR locale deve essere instradabile sulla tua rete locale.
Esegui almeno una replica di CoreDNS sui nodi in AWS Cloud 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 AWS Application Load Balancer (ALB) o Network Load Balancer (NLB) per il traffico dei carichi di lavoro in esecuzione su nodi ibridi, allora i target IP utilizzati con ALB o NLB devono essere instradabili 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 AWS cloud e il componente aggiuntivo AWS Distro for OpenTelemetry (ADOT) per raccogliere le 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 AWS Cloud, ti consigliamo di avere almeno una replica CoreDNS sui nodi ibridi e almeno una replica CoreDNS 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.

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). Nota, ai nodi in esecuzione nel AWS Cloud 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
               
```

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

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"
  }
}'
```

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

AWS Load Balancer Controller
CloudWatch Agente di osservabilità
AWS Distro per OpenTelemetry (ADOT)
cert-manager

Consulta le sezioni seguenti per configurare i webhook utilizzati da questi componenti aggiuntivi per l'esecuzione sui nodi in Cloud. AWS

AWS Controller del sistema di bilanciamento del carico

Per utilizzare il AWS Load Balancer Controller in una configurazione di cluster in modalità mista, è necessario eseguire il controller sui nodi in 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

CloudWatch Observability Agent

L'add-on CloudWatch Observability Agent ha un operatore Kubernetes che utilizza webhook. Per eseguire l'operatore sui nodi in AWS Cloud in una configurazione di cluster in modalità mista, modifica la configurazione dell'operatore Observability Agent. 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

AWS Distro per OpenTelemetry (ADOT)

L'add-on AWS Distro for OpenTelemetry (ADOT) ha un operatore Kubernetes che utilizza webhook. Per eseguire l'operatore sui nodi in AWS Cloud in una configurazione del cluster in modalità mista, aggiungi quanto segue alla configurazione dei valori di Helm o specifica i valori utilizzando la configurazione del componente aggiuntivo 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

L'add-on ADOT ha un requisito preliminare da installare cert-manager per i certificati TLS utilizzati dal webhook dell'operatore ADOT. cert-manageresegue anche webhook ed è possibile configurarlo per l'esecuzione su nodi in AWS Cloud 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`

L'cert-manageradd-on esegue i webhook ed è possibile configurarlo per l'esecuzione su nodi in AWS Cloud 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

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Configurare i componenti aggiuntivi

Configurazione del proxy