Atribuir nós a um cluster de banco de dados usando a programação

No operador AlloyDB Omni no Kubernetes, a programação é um processo para associar novos pods de banco de dados a nós, a fim de equilibrar a distribuição de nós no cluster e ajudar a otimizar o desempenho. Os pods e nós são combinados com base em vários critérios e recursos disponíveis, como CPU e memória.

Para mais informações sobre programação, consulte Programação, preempção e remoção na documentação do Kubernetes.

Esta página mostra como especificar tolerâncias e configurações de programação de afinidade de nó para instâncias de pool primário e de leitura no manifesto do Kubernetes.

Para saber como definir taints em nós, consulte Taints e tolerâncias na documentação do Kubernetes.

Especificar tolerâncias

Para programar os pods Omni do AlloyDB em nós sem outros pods de aplicativos ou corresponder a um taint específico definido nesses nós, aplique uma ou mais tolerâncias aos nós da seguinte maneira:

  1. Modifique o manifesto do cluster do operador do AlloyDB Omni Kubernetes para incluir uma seção tolerations na seção schedulingConfig de uma das seguintes seções:
    • primarySpec para instâncias principais
    • spec para instâncias do pool de leitura
         tolerations:
      - key: "TAINT_KEY"
        operator: "OPERATOR_VALUE"
        value: "VALUE"
        effect: "TAINT_EFFECT"

    Substitua:

    • TAINT_KEY: o nome exclusivo da chave de taint, como o nome de domínio de um nó ou outro valor inferido localmente ao qual a tolerância se aplica. A chave de contaminação já está definida em um nó. Um campo vazio e o OPERATOR_VALUE definido como exists significam que a tolerância precisa corresponder a todos os valores e chaves.
    • OPERATOR_VALUE: representa a relação de uma chave com um conjunto de valores. Defina o parâmetro como um dos seguintes:
      • exists: o Kubernetes corresponde a qualquer valor se o taint for definido, independentemente do valor dele.
      • equal: o Kubernetes não programa um pod para um nó se os valores forem diferentes. O operador exige o valor true do taint.
    • VALUE: o valor de taint com que a tolerância corresponde. Se o operador for Exists, o valor estará vazio. Caso contrário, será uma string regular. Por exemplo, true.
    • TAINT_EFFECT: indica o efeito de taint a ser correspondido. Um campo vazio significa que todos os efeitos de contaminação precisam ser correspondidos. Defina o parâmetro como um dos seguintes:
      • NoSchedule: o Kubernetes não programa novos pods no nó contaminado.
      • PreferNoSchedule: o Kubernetes evita colocar novos pods no nó com taint, a menos que seja necessário.
      • NoExecute: o Kubernetes remove os pods que não toleram o taint.
  2. Aplique o manifesto novamente.

Definir a afinidade do nó

O programador do Kubernetes usa a afinidade de nó como um conjunto de regras para determinar onde colocar um pod. A afinidade de nó é uma versão mais flexível e expressiva dos seletores de nó.

Para especificar quais nós precisam ser programados para executar o banco de dados, siga estas etapas:

  1. Modifique o manifesto do cluster do banco de dados para incluir a seção nodeaffinity após a seção tolerations na seção schedulingConfig de primarySpec para instâncias primárias ou spec para instâncias de pool de leitura: 
          nodeaffinity:
         NODE_AFFINITY_TYPE:
         - weight: WAIT_VALUE
           preference:
             matchExpressions:
             - key: LABEL_KEY
               operator: OPERATOR_VALUE
               values:
               - LABEL_KEY_VALUE

    Substitua:

    • NODE_AFFINITY_TYPE: defina o parâmetro como um dos seguintes:
      • requiredDuringSchedulingIgnoredDuringExecution: o Kubernetes programa o pod com base exatamente nas regras definidas.
      • preferredDuringSchedulingIgnoredDuringExecution: o programador do Kubernetes tenta encontrar um nó que atenda à regra definida para a programação. No entanto, se não houver esse nó, o Kubernetes vai programar um nó diferente no cluster.
    • WAIT_VALUE: indica o peso de preferência dos nós especificados. Valores mais altos indicam uma preferência mais forte. Os valores válidos são de 1 a 100.
    • LABEL_KEY: o rótulo do nó para a chave que serve como um indicador de local e facilita a distribuição uniforme de pods no cluster. Por exemplo, disktype=ssd.
    • OPERATOR_VALUE: representa a relação de uma chave com um conjunto de valores. Defina o parâmetro como um dos seguintes:
      • In: o array de valores precisa estar preenchido.
      • NotIn: o array de valores precisa estar preenchido.
      • Exists: a matriz de valores precisa estar vazia.
      • DoesNotExist: a matriz de valores precisa estar vazia.
      • Gt: a matriz de valores precisa ter um único elemento, que é interpretado como um número inteiro.
      • Lt: a matriz de valores precisa ter um único elemento, que é interpretado como um número inteiro.
    • LABEL_KEY_VALUE: o valor da chave do rótulo. Defina o parâmetro como uma matriz de valores de string da seguinte maneira:
      • Se o operador for In ou NotIn, a matriz de valores precisa estar preenchida.
      • Se o operador for Exists ou DoesNotExist, a matriz de valores precisa estar vazia.
      • Se o operador for Gt ou Lt, a matriz de valores precisará ter um único elemento, que será interpretado como um número inteiro.
  2. Reaplique o manifesto.

Exemplo

O exemplo a seguir ilustra a programação de pods nas instâncias principais e de pool de leitura do AlloyDB Omni Kubernetes Operator. Essa configuração de programação ajuda a garantir que a instância principal do cluster de banco de dados seja programada nos nós apropriados, permitindo alguma flexibilidade na seleção de nós. Essa flexibilidade pode ser útil para equilibrar a carga, otimizar o uso de recursos ou aderir a funções e características específicas do nó.

    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

O exemplo de tolerância permite que o pod seja programado em nós marcados como nós do plano de controle devido aos seguintes detalhes:

  • A chave de contaminação node-role.kubernetes.io/control-plane indica que o nó tem um nó de plano de controle.
  • O operador Exists significa que a tolerância corresponde a qualquer taint com a chave de taint especificada, independentemente do valor.
  • O efeito NoSchedule significa que os pods não serão programados no nó do plano de controle, a menos que tenham uma tolerância correspondente.

O tipo de afinidade de nó preferredDuringSchedulingIgnoredDuringExecution especifica que as regras definidas para a afinidade de nó são preferenciais, mas não obrigatórias durante a programação. Se os nós preferidos não estiverem disponíveis, o pod ainda poderá ser programado em outros nós. O valor de peso 1 indica uma preferência fraca. Os critérios de seleção de nós são definidos na seção preference. A seção matchExpressions contém uma matriz de expressões usadas para corresponder a nós. A chave another-node-label-key representa a chave do rótulo do nó a ser correspondido. O operador In significa que o nó precisa ter a chave com um dos valores especificados. A chave another-node-label-key precisa ter o valor another-node-label-value.

O exemplo de regra de afinidade de nó indica uma preferência para programar o pod em nós com o rótulo another-node-label-key e o valor another-node-label-value. A preferência é fraca, então não é um requisito forte.

O exemplo combina o seguinte:

  • Tolerâncias que permitem que o pod seja programado em nós do plano de controle, tolerando o taint NoSchedule.
  • Uma afinidade de nó que prefere nós com um rótulo específico, mas não o exige estritamente. Por isso, ela oferece flexibilidade na programação.

A seguir