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

Selecione uma versão da documentação:

No operador do Kubernetes do AlloyDB Omni, o agendamento é um processo para corresponder novos pods de banco de dados a nós, equilibrar a distribuição de nós no cluster e ajudar a otimizar o desempenho. Os pods e nós são correspondidos 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.

Nesta página, mostramos como especificar tolerâncias e configurações de programação de afinidade de nós 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 seus pods do AlloyDB Omni em nós livres de outros pods de aplicativos ou corresponder a uma taint específica definida nesses nós, aplique uma ou mais tolerâncias aos nós da seguinte maneira:

  1. Modifique o manifesto do cluster do operador do Kubernetes do AlloyDB Omni para incluir uma seção tolerations na seção schedulingConfig de uma das seguintes seções:
    • primarySpec para instâncias primárias
    • 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 do host de um nó ou outro valor inferido localmente a que a tolerância se aplica. A chave de taint 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 todas as 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, independente do valor dele.
      • equal: o Kubernetes não programa um pod em um nó se os valores forem diferentes. O operador exige o valor true de taint.
    • VALUE: o valor do taint ao qual a tolerância corresponde. Se o operador for Exists, o valor estará vazio. Caso contrário, será uma string normal. Por exemplo, true.
    • TAINT_EFFECT: indica o efeito de taint a ser correspondido. Um campo vazio significa que todos os efeitos de taint precisam ser correspondentes. 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 atuais que não toleram o taint.
  2. Reaplique o manifesto.

Definir a afinidade do nó

O programador do Kubernetes usa a afinidade de nós 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ós.

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

  1. Modifique o manifesto do cluster de banco de dados para incluir a seção nodeaffinity após a seção tolerations na seção schedulingConfig de primarySpec para instâncias principais 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 exatamente com base nas regras definidas.
      • preferredDuringSchedulingIgnoredDuringExecution: o programador do Kubernetes tenta encontrar um nó que atenda à regra definida para programação. No entanto, se não houver um nó desse tipo, o Kubernetes vai programar para um nó diferente no cluster.
    • WAIT_VALUE: indica a ponderação de preferência para os nós especificados. Valores mais altos indicam uma preferência maior. 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: a matriz de valores não pode estar vazia.
      • NotIn: a matriz de valores não pode estar vazia.
      • 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 será interpretado como um número inteiro.
      • Lt: a matriz de valores precisa ter um único elemento, que será 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 não poderá estar vazia.
      • Se o operador for Exists ou DoesNotExist, a matriz de valores precisará 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 o agendamento de pods nas instâncias primárias e de pool de leitura do operador do Kubernetes do AlloyDB Omni. Essa configuração de programação ajuda a garantir que a instância principal do cluster de banco de dados seja programada em nós adequados, 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 de nós.

    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

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

  • A chave de taint 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 especificada, independente 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 o agendamento. Se os nós preferenciais 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.

A regra de afinidade de nó de exemplo indica uma preferência por programar o pod em nós que têm o rótulo another-node-label-key com o valor another-node-label-value. A preferência é fraca, então não é uma exigência 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 exige isso estritamente. Portanto, ela oferece flexibilidade no agendamento.

A seguir