Assegnare i nodi a un cluster di database utilizzando la pianificazione

In AlloyDB Omni Kubernetes Operator, la pianificazione è un processo per abbinare i nuovi pod di database ai nodi in modo da 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 alle risorse disponibili, come CPU e memoria.

Per ulteriori informazioni sulla pianificazione, consulta Pianificazione, prelazione ed espulsione nella documentazione di Kubernetes.

Questa pagina mostra come specificare le tolleranze e le configurazioni di pianificazione dell'affinità dei nodi per le istanze del pool principale e di lettura nel manifest di Kubernetes.

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

Specifica le tolleranze

Per pianificare i pod AlloyDB Omni su nodi privi di altri pod di applicazioni o corrispondere a un contaminante specifico definito su questi nodi, applica una o più tolleranze ai nodi come segue:

  1. Modifica il file manifest del cluster dell'operatore Kubernetes 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 contaminazione, ad esempio il nome host di un nodo o un altro valore dedotto localmente a cui si applica la tolleranza. La chiave di contaminazione è già definita su un nodo. Un campo vuoto e 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 corrisponde a qualsiasi valore se l'alterazione è definita indipendentemente dal suo valore.
      • equal: Kubernetes non pianifica un pod su un nodo se i valori sono diversi. L'operatore richiede il valore dell'incompatibilità true.
    • VALUE: il valore dell'alterazione 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 contaminazione da associare. Un campo vuoto indica che tutti gli effetti di contaminazione devono corrispondere. Imposta il parametro su uno dei seguenti valori:
      • NoSchedule: Kubernetes non pianifica nuovi pod sul nodo con stato compromesso.
      • PreferNoSchedule: Kubernetes evita di posizionare nuovi pod sul nodo con stato tainted, a meno che non sia necessario.
      • NoExecute: Kubernetes esegue l'espulsione dei pod esistenti che non tollerano l'incompatibilità.
  2. Applica di nuovo il manifest.

Definire l'affinità dei nodi

Lo scheduler Kubernetes utilizza l'affinità dei nodi come insieme di regole per determinare dove posizionare un pod. L'affinità dei nodi è una versione più flessibile ed espressiva dei selettori dei 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 in base esattamente 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 esegue la pianificazione su un altro nodo del cluster.
    • WAIT_VALUE: indica il peso della preferenza per i nodi specificati. Valori più elevati 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 della 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 dell'etichetta. Imposta il parametro su un array di valori di 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. Applica di nuovo il manifest.

Esempio

L'esempio seguente illustra la pianificazione dei pod nelle istanze del pool di lettura e principali dell'operatore Kubernetes AlloyDB Omni. Questa configurazione della 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 la pianificazione del pod sui nodi contrassegnati come nodi del piano di controllo per i seguenti dettagli:

  • La chiave di contaminazione node-role.kubernetes.io/control-plane indica che il nodo ha un nodo del piano di controllo.
  • L'operatore Exists indica che la tolleranza corrisponde a qualsiasi contaminazione con la chiave di contaminazione specificata, indipendentemente dal valore.
  • L'effetto NoSchedule indica che i pod non verranno pianificati sul nodo del piano di controllo 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 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 associare. 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 e il valore another-node-label-value. La preferenza è debole, quindi non è un requisito importante.

L'esempio combina quanto segue:

  • Tolleranza che consente la pianificazione del pod sui nodi del piano di controllo tollerando l'incompatibilità NoSchedule.
  • Un'affinità dei nodi che preferisce i nodi con un'etichetta specifica, ma non la richiede strettamente; di conseguenza, offre flessibilità nella pianificazione.

Passaggi successivi