Assegnare i nodi a un cluster di database 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 e affinità dei nodi 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 senza altri pod di applicazioni o per abbinare una incompatibilità specifica definita su questi nodi, applica una o più tolleranze ai nodi come segue:

  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 di 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 dei nodi.

Per specificare i nodi su cui deve essere pianificata l'esecuzione del database, segui questi passaggi:

  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 di 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 come segue:
      • 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.

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 contribuisce a 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

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.

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.

Passaggi successivi