Distribuisci i carichi di lavoro tra nodi e zone di disponibilità

La distribuzione di un carico di lavoro tra domini di errore come zone di disponibilità e nodi migliora la disponibilità dei componenti e riduce le possibilità di errore per le applicazioni con scalabilità orizzontale. Nelle sezioni seguenti vengono illustrati i modi per distribuire i carichi di lavoro tra nodi e zone di disponibilità.

Utilizza i vincoli di diffusione della topologia dei pod

I vincoli di diffusione della topologia dei pod Kubernetes indicano allo scheduler Kubernetes di distribuire i pod gestiti da ReplicaSet o StatefulSet tra diversi domini di errore (zone di disponibilità, nodi e tipi di hardware). Quando utilizzi i vincoli di diffusione della topologia dei pod, puoi fare quanto segue:

• Distribuisci o concentra i pod su diversi domini di errore a seconda dei requisiti dell'applicazione. Ad esempio, è possibile distribuire i pod per garantire la resilienza e concentrare i pod per le prestazioni di rete.

• Combina diverse condizioni, ad esempio la distribuzione tra zone di disponibilità e la distribuzione tra nodi.

• Specificate l'azione preferita se le condizioni non possono essere soddisfatte:

  • whenUnsatisfiable: DoNotScheduleUtilizzalo con una combinazione di maxSkew e minDomains per creare requisiti rigidi per lo scheduler.

  • Usa whenUnsatisfiable: ScheduleAnyway per ridurremaxSkew.

Se una zona di guasto non è più disponibile, i pod in quella zona non sono integri. Kubernetes riprogramma i pod rispettando, se possibile, il vincolo di diffusione.

Vincoli di diffusione della topologia dei pod

Il codice seguente mostra un esempio di utilizzo dei vincoli di diffusione della topologia pod tra zone di disponibilità o tra nodi:

...
spec:
  selector:
    matchLabels:
      app: <your-app-label>
    replicas: 3
    template:
      metadata:
        labels: <your-app-label>
      spec:
        serviceAccountName: <ServiceAccountName>
...
        topologySpreadConstraints:
        - labelSelector:
            matchLabels:
              app: <your-app-label>
          maxSkew: 1
          topologyKey: topology.kubernetes.io/zone # <---spread those pods evenly over all availability zones
          whenUnsatisfiable: ScheduleAnyway
        - labelSelector:
            matchLabels:
              app: <your-app-label>
          maxSkew: 1
          topologyKey: kubernetes.io/hostname # <---spread those pods evenly over all nodes
          whenUnsatisfiable: ScheduleAnyway

Vincoli di diffusione della topologia predefiniti a livello di cluster

Kubernetes fornisce un set predefinito di vincoli di diffusione della topologia per la distribuzione dei pod tra nodi e zone di disponibilità:

defaultConstraints:
  - maxSkew: 3
    topologyKey: "kubernetes.io/hostname"
    whenUnsatisfiable: ScheduleAnyway
  - maxSkew: 5
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: ScheduleAnyway

Nota

Le applicazioni che richiedono diversi tipi di vincoli di topologia possono sovrascrivere la policy a livello di cluster.

I vincoli predefiniti impostano un valore massimomaxSkew, il che non è utile per le implementazioni con un numero limitato di pod. Al momento, non KubeSchedulerConfiguration può essere modificato in Amazon EKS. Se devi applicare altri set di vincoli di diffusione della topologia, prendi in considerazione l'utilizzo di un controller di ammissione mutante come nella sezione seguente. Puoi anche controllare i vincoli di diffusione della topologia predefiniti se esegui uno scheduler alternativo. Tuttavia, la gestione di pianificatori personalizzati aggiunge complessità e può avere implicazioni sulla resilienza dei cluster e sull'HA. Per questi motivi, non è consigliabile utilizzare uno scheduler alternativo solo per i vincoli di diffusione della topologia.

La politica di Gatekeeper per i vincoli di diffusione della topologia

Un'altra opzione per applicare i vincoli di diffusione della topologia consiste nell'utilizzare una politica del progetto Gatekeeper. Le policy di Gatekeeper sono definite a livello di applicazione.

I seguenti esempi di codice mostrano l'uso di una Gatekeeper OPA policy per la distribuzione. È possibile modificare la politica in base alle proprie esigenze. Ad esempio, applica la policy solo alle distribuzioni che hanno l'etichetta o HA=true scrivi una policy simile utilizzando un policy controller diverso.

Questo primo esempio mostra l'ConstraintTemplateutilizzo con: k8stopologyspreadrequired_template.yml

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8stopologyspreadrequired
spec:
  crd:
    spec:
      names:
        kind: K8sTopologySpreadRequired
      validation:
        openAPIV3Schema:
          type: object
          properties:
            message:
              type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8stopologyspreadrequired

        get_message(parameters, _default) =3D msg {
          not parameters.message
          msg :=_default
        }


        get_message(parameters, _default) =3D msg {
          msg := parameters.message
        }

        violation[{"msg": msg}] {
          input.review.kind.kind ="Deployment"
          not input.review.object.spec.template.spec.topologySpreadConstraint
          def_msg :"Pod Topology Spread Constraints are required for Deployments"
          msg :get_message(input.parameters, def_msg)

        }

Il codice seguente mostra il manifesto constraints YAML: k8stopologyspreadrequired_constraint.yml

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sTopologySpreadRequired
metadata:
  name: require-topologyspread-for-deployments
spec:
  match:
    kinds:
      - apiGroups: ["apps"]
        kinds: ["Deployment"]
    namespaces:  ## Without theses two lines will apply to the whole cluster
      - "example"

Quando utilizzare i vincoli di diffusione della topologia

Prendi in considerazione l'utilizzo dei vincoli di diffusione della topologia per i seguenti scenari:

• Qualsiasi applicazione scalabile orizzontalmente (ad esempio, servizi web stateless)

• Applicazioni con repliche attive-attive o attive-passive (ad esempio database o cache NoSQL)

• Applicazioni con repliche in standby (ad esempio controller)

I componenti di sistema che possono essere utilizzati per lo scenario con scalabilità orizzontale, ad esempio, includono quanto segue:

• Cluster Autoscaler e Karpenter (con e) replicaCount > 1 leader-elect = true

• AWS Controller Load Balancer

• CoredNS

Affinità e antiaffinità dei pod

In alcuni casi, è utile assicurarsi che non più di un pod di un tipo specifico sia in esecuzione su un nodo. Ad esempio, per evitare di programmare più pod che utilizzano molte risorse di rete sullo stesso nodo, puoi utilizzare la regola di antiaffinità con l'etichetta o. Ingress Network-heavy Quando si utilizzaanti-affinity, è anche possibile utilizzare una combinazione dei seguenti elementi:

• Influenze sui nodi ottimizzati per la rete

• Tolleranze corrispondenti su pod con un elevato numero di connessioni di rete

• Affinità dei nodi o selettore di nodi per garantire che i pod che utilizzano molte risorse di rete utilizzino istanze ottimizzate per la rete

Ad esempio, vengono utilizzati i pod con un elevato numero di connessioni di rete. Potresti avere requisiti diversi, come GPU, memoria o archiviazione locale. Per altri esempi di utilizzo e opzioni di configurazione, consulta la documentazione di Kubernetes.

I pod Rebalance

Questa sezione illustra due approcci al ribilanciamento dei pod in un cluster Kubernetes. Il primo utilizza il Descheduler per Kubernetes. Il Descheduler aiuta a mantenere la distribuzione dei pod applicando strategie per rimuovere i pod che violano i vincoli di diffusione della topologia o le regole di antiaffinità. Il secondo approccio utilizza la funzionalità di consolidamento e bin-packing di Karpenter. Il consolidamento valuta e ottimizza continuamente l'utilizzo delle risorse consolidando i carichi di lavoro su un numero inferiore di nodi e in modo più efficiente.

Ti consigliamo di utilizzare Descheduler se non utilizzi Karpenter. Se utilizzi Karpenter e Cluster Autoscaler insieme, puoi usare Descheduler con Cluster Autoscaler per i gruppi di nodi.

Descheduler per nodi senza gruppi

Non c'è alcuna garanzia che i vincoli di topologia rimangano soddisfatti quando i pod vengono rimossi. Ad esempio, il ridimensionamento di un'implementazione potrebbe comportare uno squilibrio nella distribuzione dei pod. Tuttavia, poiché Kubernetes utilizza i vincoli di diffusione della topologia dei pod solo nella fase di pianificazione, i pod rimangono sbilanciati nel dominio di errore.

Per mantenere una distribuzione bilanciata dei pod in tali scenari, puoi utilizzare Descheduler for Kubernetes. Descheduler è uno strumento utile per molteplici scopi, ad esempio per imporre l'età massima dei pod o il time to live (TTL) o per migliorare l'uso dell'infrastruttura. Nel contesto della resilienza e dell'alta disponibilità (HA), considera le seguenti strategie di Descheduler:

• RemovePodsViolatingTopologySpreadConstraint

• RemovePodsViolatingInterPodAntiAffinity

• RemoveDuplicates

Funzionalità di consolidamento e bin-packing di Karpenter

Per i carichi di lavoro che utilizzano Karpenter, puoi utilizzare la funzionalità di consolidamento e bin-packing per ottimizzare l'utilizzo delle risorse e ridurre i costi nei cluster Kubernetes. Karpenter valuta continuamente il posizionamento dei pod e l'utilizzo dei nodi e tenta di consolidare i carichi di lavoro su un numero inferiore di nodi e, ove possibile, impacchettati in modo più efficiente. Questo processo prevede l'analisi dei requisiti di risorse, la considerazione di vincoli come le regole di affinità dei pod e il potenziale spostamento dei pod tra i nodi per migliorare l'efficienza complessiva del cluster. Il codice seguente fornisce un esempio:

apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: 720h

PerconsolidationPolicy, puoi usare WhenUnderutilized oWhenEmpty:

• Quando consolidationPolicy è impostato suWhenUnderutilized, Karpenter considera tutti i nodi per il consolidamento. Quando Karpenter scopre un nodo vuoto o sottoutilizzato, Karpenter tenta di rimuovere o sostituire il nodo per ridurre i costi.

• Quando consolidationPolicy è impostato suWhenEmpty, Karpenter considera per il consolidamento solo i nodi che non contengono pod per il carico di lavoro.

Le decisioni di consolidamento di Karpenter non si basano esclusivamente sulle percentuali di utilizzo della CPU o della memoria che potresti riscontrare negli strumenti di monitoraggio. Karpenter utilizza invece un algoritmo più complesso basato sulle richieste di risorse dei pod e sulle potenziali ottimizzazioni dei costi. Per ulteriori informazioni, consulta la documentazione di Karpenter.