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

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, afinidade de nós e configurações de programação de restrições de propagação de topologia 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 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 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ó assim, o Kubernetes vai programar para um nó diferente no cluster.
    • WAIT_VALUE: indica o peso da 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.

Definir antiafinidade de pods

A antiafinidade de pods impede que o programador do Kubernetes agende 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 usar essa regra de antiafinidade para programar pods de banco de dados em nós diferentes dos pods de 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 seu banco de dados, siga estas etapas:

  1. Modifique o arquivo de manifesto do cluster de banco de dados para incluir o campo podAntiAffinity. Você precisa 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 agenda o pod apenas nas regras definidas.
      • preferredDuringSchedulingIgnoredDuringExecution: o programador do Kubernetes tenta encontrar um nó que atenda à regra definida. Se nenhum nó desse tipo for encontrado, o Kubernetes vai programar o pod para outro nó no cluster.
    • WEIGHT_VALUE: usado quando POD_ANTI_AFFINITY_TYPE é definido como preferredDuringSchedulingIgnoredDuringExecution. Indica o nível de 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 da 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 da topologia

O campo topologySpreadConstraints, localizado em spec da API de pods do Kubernetes e, consequentemente, em schedulingConfig dos manifestos de 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 a alta disponibilidade e o uso equilibrado de recursos, evitando que muitos pods de cluster de banco de dados do AlloyDB Omni sejam colocados em um único ponto de falha.

Para especificar como o cluster de banco de dados do AlloyDB Omni se espalha pela topologia do cluster, inclua a seção topologySpreadConstraints no 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 agenda o pod para um nó se a restrição de distribuição não for atendida. Esse é o valor padrão.
    • ScheduleAnyway: o programador ainda agenda o pod, mas prioriza nós que minimizam o desvio.

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

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
      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ó 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.

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

Os topologySpreadConstraints neste exemplo distribuem pods em diferentes zonas do Kubernetes. O valor maxSkew de 1 indica que pode haver no máximo mais um pod 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 vai permanecer sem programação.

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 pod que impede que pods com o rótulo app: my-app sejam programados no mesmo nome de host.
  • Restrições de propagação de 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