Atribuir um cluster de banco de dados a um nó usando o agendamento

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

Esta página mostra como especificar tolerâncias, afinidade de nós e configurações de agendamento de restrições de distribuição de topologia para instâncias principais e de pool de leitura no manifesto do Kubernetes.

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

Especificar tolerâncias

Para programar os pods do AlloyDB Omni em nós livres de 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 no 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 atual 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, independentemente 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 do taint.
   • VALUE: o valor do taint ao qual a tolerância corresponde. Se o operador for Exists, o valor estará vazio. Caso contrário, ele 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 correspondidos. Defina o parâmetro como um dos seguintes:
     • NoSchedule: o Kubernetes não programa novos pods no nó com taint.
     • 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 afinidade de 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 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 do 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 agendamento. No entanto, se não houver esse nó, o Kubernetes será programado para um nó diferente no cluster.
   • WAIT_VALUE: indica o peso de preferência para os 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: 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.

Definir restrições de distribuição da topologia

O campo topologySpreadConstraints, localizado na spec da API de pods do Kubernetes e, consequentemente, na schedulingConfig dos manifestos do cluster de banco de dados do AlloyDB Omni, controla como os pods são distribuídos em diferentes domínios de topologia, como zonas, nós ou regiões no cluster. Isso ajuda a promover alta disponibilidade e utilização equilibrada de recursos, evitando que muitos pods de cluster de banco de dados do AlloyDB Omni cheguem a um único ponto de falha.

Para especificar como o cluster de banco de dados do AlloyDB Omni é distribuído na topologia do cluster, inclua a seção topologySpreadConstraints na schedulingConfig de primarySpec para instâncias principais ou spec para instâncias do pool de leitura:

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

Substitua:

• MAXSKEW_VALUE: define a diferença máxima permitida no número de pods correspondentes entre dois domínios de topologia. Esse parâmetro precisa ser maior que 0.
• TOPOLOGY_KEY: a chave dos rótulos de nós que define um domínio de topologia, por exemplo, topology.kubernetes.io/zone para zonas. O programador tenta equilibrar os pods nesses domínios.
• WHEN_UNSATISFIABLE_VALUE: indica como o programador processa um pod se ele não atender à restrição de distribuição. Defina o parâmetro como um dos seguintes:
  • DoNotSchedule: o programador não programa o pod em um nó se a restrição de distribuição não for atendida. Esse é o valor padrão.
  • ScheduleAnyway: o programador ainda programa o pod, mas prioriza nós que minimizam a distorção.

Para mais informações sobre restrições de distribuição da topologia de pods, consulte a documentação oficial do Kubernetes.

Exemplo

O exemplo a seguir ilustra a programação de pods em instâncias principais e de pool de leitura do operador do AlloyDB Omni no Kubernetes. Essa configuração de agendamento 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 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
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: "topology.kubernetes.io/zone"
          whenUnsatisfiable: DoNotSchedule

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ó do 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 sã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 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 para 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 é um requisito forte.

As topologySpreadConstraints neste exemplo distribuem pods em diferentes zonas do Kubernetes. O valor maxSkew de 1 indica que pode haver no máximo um pod a mais em qualquer zona em comparação com o número mínimo de pods em qualquer outra zona. A configuração whenUnsatisfiable, com um valor de DoNotSchedule, significa que, se essa restrição não puder ser atendida, o pod permanecerá não programado.

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.
• Restrições de distribuição da topologia que impõem uma distribuição equilibrada de pods em zonas de disponibilidade, aumentando a resiliência e melhorando a utilização de recursos.

A seguir

• Configurar o AlloyDB Omni para produção