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 para 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 do pool principal e de leitura no seu manifesto do Kubernetes.

Para 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 conjunto 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 serve como 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 a 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. Isto garante que as réplicas de um serviço são distribuídas para evitar ter um único ponto de falha.

Para ambientes de produção, recomendamos que use esta regra de antiafinidade para agendar pods de base de dados em nós diferentes dos pods do operador através das seguintes etiquetas:

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 à sua base de dados, siga estes passos:

  1. Modifique o ficheiro do manifesto do cluster da base de dados para incluir o campo podAntiAffinity. Tem de adicionar podAntiAffinity ao campo schedulingConfig no campo primarySpec para instâncias principais ou no campo spec para instâncias do conjunto 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 satisfaça a regra definida. Se não forem encontrados esses nós, o Kubernetes agenda o pod para 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 entre 1 e 100.
    • LABEL_KEY: serve como indicador de localização e facilita a distribuição uniforme de pods no cluster.
    • OPERATOR_VALUE: operador usado para fazer a correspondência com os agrupamentos 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 tem de estar vazia.
      • DoesNotExist: a matriz values tem de estar vazia.
    • LABEL_VALUE: zero, um ou mais valores de contentor a comparar com o 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 por zonas.

  2. Volte a aplicar o ficheiro de manifesto.

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

O campo topologySpreadConstraints, localizado na API Kubernetes Pod spec e, consequentemente, no schedulingConfig dos manifestos do cluster da base de dados do 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 da base de dados do AlloyDB Omni se distribui pela topologia do cluster, inclua a secção topologySpreadConstraints no schedulingConfig de primarySpec para instâncias principais 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
      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 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 mancha com a chave de mancha 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.

A regra podAntiAffinity neste exemplo impede que os pods com a etiqueta app: my-app sejam agendados no mesmo nome de anfitrião. Isto garante que as réplicas de my-app estão distribuídas por diferentes nós, o que melhora a tolerância a falhas.

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.
  • Uma regra de antiafinidade de agrupamento que impede o agendamento de agrupamentos com a etiqueta app: my-app no mesmo nome de anfitrião.
  • 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?