Assegnare un cluster di database a un nodo utilizzando la pianificazione

Seleziona una versione della documentazione:

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

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

Questa pagina mostra come specificare le configurazioni di pianificazione di tolleranze, affinità nodo e vincoli di distribuzione della topologia per le istanze principali e del pool di lettura nel manifest 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 sui nodi liberi da altri pod dell'applicazione o per corrispondere a un taint specifico definito su questi nodi, applica una o più tolleranze ai nodi nel seguente modo:

  1. Modifica il file manifest del cluster dell'operatore AlloyDB Omni Kubernetes 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 taint, ad esempio il nome host di un nodo o un altro valore dedotto localmente a cui si applica la tolleranza. La chiave di taint è già definita in 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 il taint è definito indipendentemente dal suo valore.
      • equal: Kubernetes non pianifica un pod su un nodo se i valori sono diversi. L'operatore richiede il valore di incompatibilità true.
    • VALUE: il valore di taint 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 abbinare. 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 contaminato.
      • PreferNoSchedule: Kubernetes evita di inserire nuovi pod sul nodo incompatibile, a meno che non sia necessario.
      • NoExecute: Kubernetes espelle i pod esistenti che non tollerano l'incompatibilità.
  2. Applica di nuovo il manifest.

Definisci 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 da pianificare 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 primarie o di 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 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 dei valori deve essere vuoto.
      • DoesNotExist: l'array dei 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 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. Applica nuovamente il manifest.

Definisci 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 in diversi domini di topologia come zone, nodi o regioni del cluster. Ciò contribuisce a promuovere l'alta disponibilità e l'utilizzo bilanciato delle risorse impedendo a troppi pod del cluster di database AlloyDB Omni di trovarsi in un unico punto di errore.

Per specificare come si distribuisce il 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 come lo scheduler gestisce un pod se 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 dà la priorità ai nodi che riducono al minimo lo sbilanciamento.

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

Esempio

L'esempio seguente illustra la pianificazione dei pod nelle istanze principali e del pool di lettura dell'operatore AlloyDB Omni Kubernetes. Questa configurazione della 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
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: "topology.kubernetes.io/zone"
          whenUnsatisfiable: DoNotSchedule

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

  • La chiave di taint 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 taint con la chiave taint 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 trovare corrispondenze con i nodi. La chiave another-node-label-key rappresenta la chiave dell'etichetta del nodo da corrispondere. 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à nodo 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 stringente.

topologySpreadConstraints in questo esempio distribuisce i pod in diverse zone Kubernetes. Il valore maxSkew di 1 indica che può esserci al massimo un pod in più in una determinata zona 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 i seguenti elementi:

  • Tolleranze che consentono la pianificazione del 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, offrendo quindi flessibilità nella pianificazione.
  • Vincoli di distribuzione della topologia che impongono una distribuzione bilanciata dei pod nelle zone di disponibilità, migliorando la resilienza e l'utilizzo delle risorse.

Passaggi successivi