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

Selecione uma versão da documentação:

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

A antiafinidade de pods impede que o programador do Kubernetes programe pods no mesmo nó ou no mesmo domínio de topologia, como zonas ou regiões. Isso garante que as réplicas de um serviço sejam distribuídas para evitar um único ponto de falha.

Para ambientes de produção, recomendamos que você use essa regra de antiafinidade para programar pods de banco de dados em nós diferentes dos pods do operador usando os seguintes rótulos:

schedulingconfig:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchLabels:
          app.kubernetes.io/component: controller
          app.kubernetes.io/name: alloydb-omni-operator
      namespaces:
      - alloydb-omni-system
      topologyKey: kubernetes.io/hostname

Para adicionar regras de antiafinidade de pods ao banco de dados, siga estas etapas:

  1. Modifique o arquivo de manifesto do cluster de banco de dados para incluir o campo podAntiAffinity. É necessário adicionar podAntiAffinity ao campo schedulingConfig no campo primarySpec para instâncias principais ou no campo spec para instâncias do pool de leitura.

    podAntiAffinity:
  POD_ANTI_AFFINITY_TYPE:
  - weight: WEIGHT_VALUE
    podAffinityTerm:
      labelSelector:
        matchExpressions:
        - key: LABEL_KEY
          operator: OPERATOR_VALUE
          values:
          - LABEL_VALUE
      topologyKey: "TOPOLOGY_KEY"

    Substitua as seguintes variáveis:

    • POD_ANTI_AFFINITY_TYPE: use um dos seguintes valores:
      • requiredDuringSchedulingIgnoredDuringExecution: o Kubernetes programa o pod apenas nas regras definidas.
      • preferredDuringSchedulingIgnoredDuringExecution: o programador do Kubernetes tenta encontrar um nó que atenda à regra definida. Se nenhum desses nós for encontrado, o Kubernetes programará o pod em outro nó no cluster.
    • WEIGHT_VALUE: usado quando POD_ANTI_AFFINITY_TYPE está definido como preferredDuringSchedulingIgnoredDuringExecution. Indica a preferência dos nós especificados. Os valores variam de 1 a 100.
    • LABEL_KEY: serve como um indicador de local e facilita a distribuição uniforme de pods no cluster.
    • OPERATOR_VALUE: operador usado para corresponder aos pods especificados. Use um dos seguintes valores:
      • In: a matriz values não pode estar vazia.
      • NotIn: a matriz values não pode estar vazia.
      • Exists: a matriz values precisa estar vazia.
      • DoesNotExist: a matriz values precisa estar vazia.
    • LABEL_VALUE: zero, um ou mais valores de pod para corresponder ao LABEL_KEY.
    • TOPOLOGY_KEY: define o domínio de topologia. Por exemplo, kubernetes.io/hostname para impedir pods no mesmo nó ou topology.kubernetes.io/zone para distribuir pods entre zonas.

  2. Reaplique o arquivo de manifesto.

Definir restrições de distribuição de 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 de 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 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
      podAntiAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - my-app
          topologyKey: "kubernetes.io/hostname"
      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 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.

A regra podAntiAffinity neste exemplo impede que pods com o rótulo app: my-app sejam programados no mesmo nome do host. Isso garante que as réplicas de my-app sejam distribuídas em nós diferentes, melhorando a tolerância a falhas.

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.
  • Uma regra de antiafinidade de pods que impede que pods com o rótulo app: my-app sejam programados no mesmo nome do host.
  • Restrições de distribuição de topologia que impõem uma distribuição equilibrada de pods em zonas de disponibilidade, melhorando a resiliência e a utilização de recursos.

A seguir