Atribua um cluster de base de dados a um nó através do agendamento

Selecione uma versão da documentação:

No operador do Kubernetes do AlloyDB Omni, o agendamento é um processo para fazer corresponder novos pods de base de dados a nós, de modo a equilibrar a distribuição de nós no cluster e ajudar a otimizar o desempenho. Os pods e os nós são correspondidos com base em vários critérios e recursos disponíveis, como a CPU e a memória.

Para mais informações sobre a programação, consulte o artigo Programação, antecipaçã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 dispersão de topologia para instâncias de pool principal e de leitura no manifesto do Kubernetes.

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

Especifique tolerâncias

Para agendar os seus AlloyDB Omni Pods para nós sem outros Pods de aplicações ou para corresponder a uma mancha específica definida nesses nós, aplique uma ou mais tolerâncias aos nós da seguinte forma:

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

    Substitua o seguinte:

    • TAINT_KEY: o nome único existente da chave de contaminação, como o nome do anfitrião de um nó ou outro valor inferido localmente ao qual a tolerância se aplica. A chave de restrição já está definida num nó. Um campo vazio e o OPERATOR_VALUE definido como exists significam que a tolerância tem de corresponder a todos os valores e a todas as chaves.
    • OPERATOR_VALUE: representa a relação de uma chave com um conjunto de valores. Defina o parâmetro para uma das seguintes opções:
      • exists: o Kubernetes corresponde a qualquer valor se a restrição for definida, independentemente do valor da restrição.
      • equal: o Kubernetes não agenda um pod para um nó se os valores forem diferentes. O operador requer o valor true da mancha.
    • VALUE: o valor de contaminação com o qual a tolerância corresponde. Se o operador for Exists, o valor está vazio. Caso contrário, é uma string normal. Por exemplo, true.
    • TAINT_EFFECT: indica o efeito de contaminação a corresponder. Um campo vazio significa que todos os efeitos de contaminação têm de ser correspondentes. Defina o parâmetro para uma das seguintes opções:
      • NoSchedule: o Kubernetes não agenda novos pods no nó contaminado.
      • PreferNoSchedule: o Kubernetes evita colocar novos pods no nó contaminado, a menos que seja necessário.
      • NoExecute: o Kubernetes despeja os pods existentes que não toleram a mancha.
  2. Volte a aplicar o manifesto.

Defina a afinidade de nós

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ós é uma versão mais flexível e expressiva dos seletores de nós.

Para especificar que nós têm de ser agendados para executar a sua base de dados, siga estes passos:

  1. Modifique o manifesto do cluster da base de dados para incluir a secção nodeaffinity após a secção tolerations na secção schedulingConfig de primarySpec para instâncias principais ou spec para instâncias do conjunto de leitura: 
          nodeaffinity:
         NODE_AFFINITY_TYPE:
         - weight: WAIT_VALUE
           preference:
             matchExpressions:
             - key: LABEL_KEY
               operator: OPERATOR_VALUE
               values:
               - LABEL_KEY_VALUE

    Substitua o seguinte:

    • NODE_AFFINITY_TYPE: defina o parâmetro para uma das seguintes opções:
      • requiredDuringSchedulingIgnoredDuringExecution: o Kubernetes agenda o pod exatamente com base nas regras definidas.
      • preferredDuringSchedulingIgnoredDuringExecution: o programador do Kubernetes tenta encontrar um nó que cumpra a regra definida para o agendamento. No entanto, se não existir esse nó, o Kubernetes agenda para um nó diferente no cluster.
    • WAIT_VALUE: indica a ponderação da preferência para os nós especificados. Os valores mais elevados indicam uma preferência mais forte. Os valores válidos variam entre 1 e 100.
    • LABEL_KEY: a etiqueta do nó para a chave que funciona como um indicador de localização 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 para uma das seguintes opções:
      • 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 tem de estar vazia.
      • DoesNotExist: a matriz de valores tem de estar vazia.
      • Gt: a matriz de valores tem de ter um único elemento, que é interpretado como um número inteiro.
      • Lt: a matriz de valores tem de ter um único elemento, que é interpretado como um número inteiro.
    • LABEL_KEY_VALUE: o valor da chave do marcador. Defina o parâmetro como uma matriz de valores de string da seguinte forma:
      • Se o operador for In ou NotIn, a matriz de valores não pode estar vazia.
      • Se o operador for Exists ou DoesNotExist, a matriz de valores tem de estar vazia.
      • Se o operador for Gt ou Lt, a matriz de valores tem de ter um único elemento, que é interpretado como um número inteiro.
  2. Volte a aplicar o manifesto.

Defina restrições de propagação da topologia

O campo topologySpreadConstraints, localizado no spec da API Kubernetes Pod e, consequentemente, no schedulingConfig dos manifestos do cluster da base de dados AlloyDB Omni, controla a forma como os pods são distribuídos por diferentes domínios de topologia, como zonas, nós ou regiões no seu cluster. Isto ajuda a promover a alta disponibilidade e a utilização equilibrada de recursos, impedindo que demasiados pods do cluster de base de dados do AlloyDB Omni aterrem num único ponto de falha.

Para especificar como o cluster de base de dados do AlloyDB Omni se distribui pela topologia do cluster, inclua a secção topologySpreadConstraints no schedulingConfig de primarySpec para instâncias primárias ou spec para instâncias do conjunto 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 o seguinte:

  • MAXSKEW_VALUE: define a diferença máxima permitida no número de agrupamentos correspondentes entre quaisquer dois domínios de topologia. Este parâmetro tem de ser superior a 0.
  • TOPOLOGY_KEY: a chave das etiquetas de nós que define um domínio de topologia, por exemplo, topology.kubernetes.io/zone para zonas. O programador tenta equilibrar os pods nestes domínios.
  • WHEN_UNSATISFIABLE_VALUE: indica como o programador processa um pod se o pod não satisfizer a restrição de distribuição. Defina o parâmetro para uma das seguintes opções:
    • DoNotSchedule: o agendador não agenda o pod para um nó se a restrição de distribuição não for satisfeita. Este é o valor predefinido.
    • ScheduleAnyway: o programador continua a programar o agrupamento, mas dá prioridade aos nós que minimizam a distorção.

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

Exemplo

O exemplo seguinte ilustra o agendamento de pods nas instâncias primárias e de leitura do operador do Kubernetes do AlloyDB Omni. Esta configuração de agendamento ajuda a garantir que a instância principal do cluster de base de dados é agendada em nós adequados, ao mesmo tempo que permite alguma flexibilidade na seleção de nós. Esta flexibilidade pode ser útil para equilibrar a carga, otimizar a utilização de recursos ou aderir a funções e características específicas dos 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
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: "topology.kubernetes.io/zone"
          whenUnsatisfiable: DoNotSchedule

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

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

O tipo de afinidade de nós preferredDuringSchedulingIgnoredDuringExecution especifica que as regras definidas para a afinidade de nós são preferenciais, mas não são obrigatórias durante o agendamento. Se os nós preferidos não estiverem disponíveis, o pod ainda pode ser agendado noutros nós. O valor de ponderação 1 indica uma preferência fraca. Os critérios de seleção de nós estão definidos na secção preference. A secção matchExpressions contém uma matriz de expressões usadas para fazer corresponder nós. A chave another-node-label-key representa a chave da etiqueta do nó a corresponder. O operador In significa que o nó tem de ter a chave com um dos valores especificados. A chave another-node-label-key tem de ter o valor another-node-label-value.

A regra de afinidade de nós de exemplo indica uma preferência pela programação do pod em nós que tenham a etiqueta another-node-label-key com o valor another-node-label-value. A preferência é fraca, pelo que não é um requisito forte.

Os topologySpreadConstraints neste exemplo distribuem pods por diferentes zonas do Kubernetes. O valor maxSkew de 1 indica que pode haver, no máximo, mais um agrupamento em qualquer zona específica em comparação com o número mínimo de agrupamentos em qualquer outra zona. A definição whenUnsatisfiable, com um valor de DoNotSchedule, significa que, se esta restrição não puder ser cumprida, o pod permanece não agendado.

O exemplo combina o seguinte:

  • Tolerâncias que permitem que o Pod seja agendado em nós do plano de controlo tolerando a contaminação NoSchedule.
  • Uma afinidade de nós que prefere nós com uma etiqueta específica, mas não a exige estritamente. Por isso, oferece flexibilidade no agendamento.
  • Restrições de propagação da topologia que aplicam uma distribuição equilibrada de pods nas zonas de disponibilidade, melhorando a resiliência e a utilização de recursos.

O que se segue?