Assegnare un cluster di database a un nodo utilizzando la pianificazione

Seleziona una versione della documentazione:

Nell'operatore Kubernetes di AlloyDB Omni, la pianificazione è un processo per abbinare i nuovi pod di database ai nodi per bilanciare la distribuzione dei nodi nel cluster e contribuire a ottimizzare le prestazioni. I pod e i nodi vengono abbinati in base a diversi criteri e risorse disponibili, come CPU e memoria.

Per ulteriori informazioni sulla pianificazione, consulta Pianificazione, prerilascio ed eliminazione nella documentazione di Kubernetes.

Questa pagina mostra come specificare le configurazioni di pianificazione di tolleranze, affinità dei nodi e vincoli di distribuzione della topologia per le istanze principali e del pool di lettura nel manifest di Kubernetes.

Per informazioni su come definire le incompatibilità sui nodi, consulta Incompatibilità e tolleranze nella documentazione di Kubernetes.

Specificare le tolleranze

Per pianificare i pod di AlloyDB Omni sui nodi privi di altri pod di applicazioni o per abbinare una incompatibilità specifica definita su questi nodi, applica una o più tolleranze ai nodi nel seguente modo:

  1. Modifica il manifest del cluster dell'operatore Kubernetes di AlloyDB Omni in modo da includere una sezione tolerations nella sezione schedulingConfig di una delle seguenti sezioni:
    • primarySpec per le istanze principali
    • spec per le istanze del pool di lettura
         tolerations:
      - key: "TAINT_KEY"
        operator: "OPERATOR_VALUE"
        value: "VALUE"
        effect: "TAINT_EFFECT"

    Sostituisci quanto segue:

    • TAINT_KEY: il nome univoco esistente della chiave di incompatibilità, ad esempio il nome host di un nodo o un altro valore dedotto localmente a cui si applica la tolleranza. La chiave di incompatibilità è già definita su un nodo. Un campo vuoto e il valore OPERATOR_VALUE impostato su exists indicano che la tolleranza deve corrispondere a tutti i valori e a tutte le chiavi.
    • OPERATOR_VALUE: rappresenta la relazione di una chiave con un insieme di valori. Imposta il parametro su uno dei seguenti valori:
      • exists: Kubernetes abbina qualsiasi valore se l'incompatibilità è definita indipendentemente dal valore dell'incompatibilità.
      • equal: Kubernetes non pianifica un pod su un nodo se i valori sono diversi. L'operatore richiede il valore true dell'incompatibilità.
    • VALUE: il valore di incompatibilità a cui corrisponde la tolleranza. Se l'operatore è Exists, il valore è vuoto, altrimenti è una stringa normale. Ad esempio, true.
    • TAINT_EFFECT: indica l'effetto di incompatibilità da abbinare. Un campo vuoto indica che devono essere abbinati tutti gli effetti di incompatibilità. Imposta il parametro su uno dei seguenti valori:
      • NoSchedule: Kubernetes non pianifica nuovi pod sul nodo con incompatibilità.
      • PreferNoSchedule: Kubernetes evita di inserire nuovi pod sul nodo con incompatibilità, a meno che non sia necessario.
      • NoExecute: Kubernetes elimina i pod esistenti che non tollerano l'incompatibilità.
  2. Riapplica il manifest.

Definire l'affinità dei nodi

Lo scheduler Kubernetes utilizza l'affinità dei nodi come insieme di regole per determinare dove inserire un pod. L'affinità dei nodi è una versione più flessibile ed espressiva dei selettori di nodi.

Per specificare i nodi che devono essere pianificati per l'esecuzione del database:

  1. Modifica il manifest del cluster di database in modo da includere la sezione nodeaffinity dopo la sezione tolerations nella sezione schedulingConfig di primarySpec per le istanze principali o spec per le istanze del pool di lettura: 
          nodeaffinity:
         NODE_AFFINITY_TYPE:
         - weight: WAIT_VALUE
           preference:
             matchExpressions:
             - key: LABEL_KEY
               operator: OPERATOR_VALUE
               values:
               - LABEL_KEY_VALUE

    Sostituisci quanto segue:

    • NODE_AFFINITY_TYPE: imposta il parametro su uno dei seguenti valori:
      • requiredDuringSchedulingIgnoredDuringExecution: Kubernetes pianifica il pod esattamente in base alle regole definite.
      • preferredDuringSchedulingIgnoredDuringExecution: lo scheduler Kubernetes tenta di trovare un nodo che soddisfi la regola definita per la pianificazione. Tuttavia, se non esiste un nodo di questo tipo, Kubernetes pianifica su un nodo diverso nel cluster.
    • WAIT_VALUE: indica il peso della preferenza per i nodi specificati. Valori più alti indicano una preferenza più forte. I valori validi vanno da 1 a 100.
    • LABEL_KEY: l'etichetta del nodo per la chiave che funge da indicatore di posizione e facilita la distribuzione uniforme dei pod nel cluster. Ad esempio, disktype=ssd.
    • OPERATOR_VALUE: rappresenta la relazione di una chiave con un insieme di valori. Imposta il parametro su uno dei seguenti valori:
      • In: l'array di valori non deve essere vuoto.
      • NotIn: l'array di valori non deve essere vuoto.
      • Exists: l'array di valori deve essere vuoto.
      • DoesNotExist: l'array di valori deve essere vuoto.
      • Gt: l'array di valori deve avere un singolo elemento, che viene interpretato come un numero intero.
      • Lt: l'array di valori deve avere un singolo elemento, che viene interpretato come un numero intero.
    • LABEL_KEY_VALUE: il valore della chiave di etichetta. Imposta il parametro su un array di valori stringa nel seguente modo:
      • Se l'operatore è In o NotIn, l'array di valori non deve essere vuoto.
      • Se l'operatore è Exists o DoesNotExist, l'array di valori deve essere vuoto.
      • Se l'operatore è Gt o Lt, l'array di valori deve avere un singolo elemento, che viene interpretato come un numero intero.
  2. Riapplica il manifest.

Definire l'anti-affinità dei pod

L'anti-affinità dei pod impedisce allo scheduler Kubernetes di pianificare i pod sullo stesso nodo o nello stesso dominio di topologia, ad esempio zone o regioni. In questo modo, le repliche di un servizio vengono distribuite per evitare di avere un singolo punto di errore.

Per gli ambienti di produzione, ti consigliamo di utilizzare questa regola di anti-affinità per pianificare i pod di database su nodi diversi dai pod dell'operatore utilizzando le seguenti etichette:

schedulingconfig:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchLabels:
          app.kubernetes.io/component: controller
          app.kubernetes.io/name: alloydb-omni-operator
      namespaces:
      - alloydb-omni-system
      topologyKey: kubernetes.io/hostname

Per aggiungere regole di anti-affinità dei pod al database:

  1. Modifica il file manifest del cluster di database in modo da includere il campo podAntiAffinity. Devi aggiungere podAntiAffinity al campo schedulingConfig nel campo primarySpec per le istanze principali o nel campo spec per le istanze del pool di lettura.

    podAntiAffinity:
  POD_ANTI_AFFINITY_TYPE:
  - weight: WEIGHT_VALUE
    podAffinityTerm:
      labelSelector:
        matchExpressions:
        - key: LABEL_KEY
          operator: OPERATOR_VALUE
          values:
          - LABEL_VALUE
      topologyKey: "TOPOLOGY_KEY"

    Sostituisci le seguenti variabili:

    • POD_ANTI_AFFINITY_TYPE: utilizza uno dei seguenti valori:
      • requiredDuringSchedulingIgnoredDuringExecution: Kubernetes pianifica il pod solo in base alle regole definite.
      • preferredDuringSchedulingIgnoredDuringExecution: lo scheduler Kubernetes tenta di trovare un nodo che soddisfi la regola definita. Se non vengono trovati nodi di questo tipo, Kubernetes pianifica il pod su un altro nodo del cluster.
    • WEIGHT_VALUE: utilizzato quando POD_ANTI_AFFINITY_TYPE è impostato su preferredDuringSchedulingIgnoredDuringExecution. Indica la preferenza dei nodi specificati. I valori vanno da 1 a 100.
    • LABEL_KEY: funge da indicatore di posizione e facilita la distribuzione uniforme dei pod nel cluster.
    • OPERATOR_VALUE: operatore utilizzato per la corrispondenza con i pod specificati. Usa uno dei seguenti valori:
      • In: l'array values non deve essere vuoto.
      • NotIn: l'array values non deve essere vuoto.
      • Exists: l'array values deve essere vuoto.
      • DoesNotExist: l'array values deve essere vuoto.
    • LABEL_VALUE: zero, uno o più valori di pod da abbinare a LABEL_KEY.
    • TOPOLOGY_KEY: definisce il dominio di topologia. Ad esempio, kubernetes.io/hostname per impedire i pod sullo stesso nodo o topology.kubernetes.io/zone per distribuire i pod tra le zone.

  2. Riapplica il file manifest.

Definire i vincoli di distribuzione della topologia

Il campo topologySpreadConstraints, che si trova in spec dell'API Pod di Kubernetes e di conseguenza in schedulingConfig dei manifest del cluster di database AlloyDB Omni, controlla la distribuzione dei pod tra diversi domini di topologia come zone, nodi o regioni nel cluster. In questo modo, si promuove l'alta affidabilità e l'utilizzo bilanciato delle risorse, impedendo che troppi pod del cluster di database AlloyDB Omni finiscano su un singolo punto di errore.

Per specificare la distribuzione del cluster di database AlloyDB Omni nella topologia del cluster, includi la sezione topologySpreadConstraints in schedulingConfig di primarySpec per le istanze principali o spec per le istanze del pool di lettura:

schedulingconfig:
      # Other scheduling configs like tolerations, nodeaffinity
      topologySpreadConstraints:
        - maxSkew: MAXSKEW_VALUE
          topologyKey: "TOPOLOGY_KEY"
          whenUnsatisfiable: WHEN_UNSATISFIABLE_VALUE
          # labelSelector: <object> # optional
          # minDomains: <integer> # optional
          # matchLabelKeys: <list> # optional
          # nodeAffinityPolicy: [Honor|Ignore] # optional
          # nodeTaintsPolicy: [Honor|Ignore] # optional

Sostituisci quanto segue:

  • MAXSKEW_VALUE: definisce la differenza massima consentita nel numero di pod corrispondenti tra due domini di topologia. Questo parametro deve essere maggiore di 0.
  • TOPOLOGY_KEY: la chiave delle etichette dei nodi che definisce un dominio di topologia, ad esempio topology.kubernetes.io/zone per le zone. Lo scheduler tenta di bilanciare i pod in questi domini.
  • WHEN_UNSATISFIABLE_VALUE: indica in che modo lo scheduler gestisce un pod se il pod non soddisfa il vincolo di distribuzione. Imposta il parametro su uno dei seguenti valori:
    • DoNotSchedule: lo scheduler non pianifica il pod su un nodo se il vincolo di distribuzione non è soddisfatto. Questo è il valore predefinito.
    • ScheduleAnyway: lo scheduler pianifica comunque il pod, ma assegna la priorità ai nodi che riducono al minimo la distorsione.

Per ulteriori informazioni sui vincoli di distribuzione della topologia dei pod, consulta la documentazione ufficiale di Kubernetes.

Esempio

L'esempio seguente illustra la pianificazione dei pod nelle istanze principali e del pool di lettura dell'operatore Kubernetes di AlloyDB Omni. Questa configurazione di pianificazione consente di garantire che l'istanza principale del cluster di database sia pianificata sui nodi appropriati, consentendo al contempo una certa flessibilità nella selezione dei nodi. Questa flessibilità può essere utile per bilanciare il carico, ottimizzare l'utilizzo delle risorse o rispettare ruoli e caratteristiche specifici dei nodi.

    schedulingconfig:
      tolerations:
      - key: "node-role.kubernetes.io/control-plane"
        operator: "Exists"
        effect: "NoSchedule"
      nodeaffinity:
        preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 1
          preference:
            matchExpressions:
            - key: another-node-label-key
              operator: In
              values:
              - another-node-label-value
      podAntiAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - my-app
          topologyKey: "kubernetes.io/hostname"
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: "topology.kubernetes.io/zone"
          whenUnsatisfiable: DoNotSchedule

La tolleranza di esempio consente di pianificare il pod sui nodi contrassegnati come nodi del control plane a causa dei seguenti dettagli:

  • La chiave di incompatibilità node-role.kubernetes.io/control-plane indica che il nodo ha un nodo del control plane.
  • L'operatore Exists indica che la tolleranza corrisponde a qualsiasi incompatibilità con la chiave di incompatibilità specificata, indipendentemente dal valore.
  • L'effetto NoSchedule indica che i pod non verranno pianificati sul nodo del control plane a meno che non abbiano una tolleranza corrispondente.

Il tipo di affinità dei nodi preferredDuringSchedulingIgnoredDuringExecution specifica che le regole definite per l'affinità dei nodi sono preferite, ma non sono obbligatorie durante la pianificazione. Se i nodi preferiti non sono disponibili, il pod potrebbe comunque essere pianificato su altri nodi. Il valore del peso 1 indica una preferenza debole. I criteri di selezione dei nodi sono definiti nella sezione preference. La sezione matchExpressions contiene un array di espressioni utilizzate per abbinare i nodi. La chiave another-node-label-key rappresenta la chiave dell'etichetta del nodo da abbinare. L'operatore In indica che il nodo deve avere la chiave con uno dei valori specificati. La chiave another-node-label-key deve avere il valore another-node-label-value.

La regola di affinità dei nodi di esempio indica una preferenza per la pianificazione del pod sui nodi con l'etichetta another-node-label-key con il valore another-node-label-value. La preferenza è debole, quindi non è un requisito rigoroso.

La regola podAntiAffinity in questo esempio impedisce la pianificazione dei pod con l'etichetta app: my-app sullo stesso nome host. In questo modo, le repliche di my-app vengono distribuite su nodi diversi, migliorando la tolleranza agli errori.

I topologySpreadConstraints in questo esempio distribuiscono i pod tra diverse zone di Kubernetes. Il valore maxSkew di 1 indica che in una determinata zona può essere presente al massimo un pod in più rispetto al numero minimo di pod in qualsiasi altra zona. L'impostazione whenUnsatisfiable, con un valore di DoNotSchedule, indica che se questo vincolo non può essere soddisfatto, il pod rimane non pianificato.

L'esempio combina quanto segue:

  • Tolleranze che consentono di pianificare il pod sui nodi del control plane tollerando l'incompatibilità NoSchedule.
  • Un'affinità dei nodi che preferisce i nodi con un'etichetta specifica, ma non la richiede rigorosamente; pertanto, offre flessibilità nella pianificazione.
  • Una regola di anti-affinità dei pod che impedisce la pianificazione dei pod con l'etichetta app: my-app sullo stesso nome host.
  • Vincoli di distribuzione della topologia che impongono una distribuzione bilanciata dei pod tra le zone di disponibilità, migliorando la resilienza e l'utilizzo delle risorse.

Passaggi successivi