Colocação de recursos do Kubernetes do cluster de hub para clusters membros

Este artigo descreve o conceito de colocação de recursos do Kubernetes de clusters de hub para os clusters membros usando o Gerenciador de Frota de Kubernetes do Azure (Frota do Kubernetes).

Os administradores de plataforma geralmente precisam implantar os recursos do Kubernetes em vários clusters por vários motivos, por exemplo:

• Gerenciar o controle de acesso usando funções e associações de funções em vários clusters.
• Executar aplicativos de infraestrutura, como Prometheus ou Flux, que precisam estar em todos os clusters.

Os desenvolvedores de aplicativos geralmente precisam implantar recursos do Kubernetes em vários clusters por vários motivos, por exemplo:

• Implantar um aplicativo de exibição de vídeo em vários clusters em diferentes regiões para obter uma experiência de inspeção de baixa latência.
• Implantar um aplicativo de carrinho de compras em duas regiões emparelhadas para que os clientes continuem fazendo compras durante uma interrupção em uma única região.
• Implantar um aplicativo de computação em lote em clusters com pool de nós spot de baixo custo disponíveis.

É um trabalho desgastante criar, atualizar e rastrear manualmente esses recursos do Kubernetes em vários clusters. A Frota fornece a propagação de recursos do Kubernetes para permitir o gerenciamento em escala dos recursos do Kubernetes. Com a Frota do Kubernetes, é possível criar recursos do Kubernetes no cluster de hub e propagá-los para clusters membros selecionados por meio dos Recursos Personalizados do Kubernetes: MemberCluster e ClusterResourcePlacement.

A Frota do Kubernetes dá suporte a esses recursos personalizados com base em uma solução nativa de nuvem de software livre que você pode ler mais sobre a documentação da Frota de software livre.

Introdução ao ClusterResourcePlacement

Um objeto ClusterResourcePlacement é usado para informar ao agendador de frota como colocar um determinado conjunto de objetos com escopo de cluster do cluster do hub de frota em clusters de membros. Objetos com escopo de namespace, como Deployments, StatefulSets, DaemonSets, ConfigMaps, Secrets e PersistentVolumeClaims, são incluídos quando o namespace que contém é selecionado.

Com ClusterResourcePlacement, você pode:

• Selecione os recursos do Kubernetes com escopo de cluster que serão propagados para os clusters membros.
• Especificar políticas de colocação para selecionar manual ou automaticamente os clusters membros como clusters de destino.
• Especificar estratégias de distribuição para distribuir com segurança todas as atualizações dos recursos do Kubernetes selecionados para vários clusters de destino.
• Exibir o progresso da propagação para cada cluster de destino.

Um exemplo é mostrado no diagrama a seguir.

Encapsulando recursos

ClusterResourcePlacement dá suporte ao uso do ConfigMap para envolver determinados tipos de recursos do Kubernetes para que possam ser preparados no cluster do hub sem efeitos colaterais não intencionais no cluster do hub. Para obter uma lista de tipos de recursos e entender como esse recurso funciona, consulte nossa documentação do objeto de envelope

Tipos de colocação

Os seguintes tipos de colocação estão disponíveis para controlar o número de clusters para os quais um recurso kubernetes especificado precisa ser propagado:

• PickFixed coloca os recursos em uma lista específica de clusters de membros pelo nome.
• PickAll coloca o recurso em todos os clusters de membros ou em todos os clusters membros que atendem a um critério. Essa política é útil para colocar cargas de trabalho de infraestrutura, como monitoramento de cluster ou aplicativos de relatório.
• PickN é a opção de colocação mais flexível e permite a seleção de clusters com base em restrições de afinidade ou espalhamento de topologia, e é útil ao distribuir cargas de trabalho entre vários clusters apropriados para garantir que a disponibilidade seja desejada.

Tipo de colocação PickFixed

Se quiser implementar uma carga de trabalho em um conjunto conhecido de clusters membros você poderá usar uma política de posicionamento PickFixed para selecionar os clusters por nome.

clusterNames é a única opção de política válida para esse tipo de posicionamento.

O exemplo a seguir mostra como implantar o namespace test-deployment em clusters membros cluster1 e cluster2.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-fixed
spec:
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: test-deployment
      version: v1

Tipo de colocação PickAll

Use um tipo de colocação PickAll para implantar uma carga de trabalho em todos os clusters membros da frota ou em um subconjunto de clusters que correspondam aos critérios definidos.

Ao criar esse tipo de colocação, os seguintes tipos de afinidade de cluster podem ser especificados:

• requiredDuringSchedulingIgnoredDuringExecution: como essa política é necessária durante o agendamento, ela filtra os clusters com base nos critérios especificados.

O exemplo a seguir mostra como implantar um namespace prod-deployment e todos os respectivos objetos em todos os clusters rotulados com environment: production:

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pickall
spec:
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                        environment: production
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1

Tipo de colocação PickN

A política de colocação PickN é a opção mais flexível e permite o colocação de recursos em um número configurável de clusters com base em afinidades e restrições de espalhamento da topologia.

Ao criar esse tipo de colocação, os seguintes tipos de afinidade de cluster podem ser especificados:

• requiredDuringSchedulingIgnoredDuringExecution: como essa política é necessária durante o agendamento, ela filtra os clusters com base nos critérios especificados.
• preferredDuringSchedulingIgnoredDuringExecution: como essa política é preferencial, mas não é necessária durante o agendamento, ela classifica os clusters com base nos critérios especificados.

É possível definir afinidades obrigatórias e preferenciais. As afinidades necessárias impedem a colocação em clusters que não correspondem e as afinidades preferenciais fornecem ordenação de clusters válidos.

PickN com afinidades

Usar afinidades com uma política de posicionamento de PickN funciona de maneira semelhante ao uso de afinidades com agendamento de pod.

O exemplo a seguir mostra como implantar uma carga de trabalho em três clusters. Somente os clusters com o rótulo critical-allowed: "true" são destinos de posicionamento válidos, e a preferência fornecida a clusters com o rótulo critical-level: 1:

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pickn-01
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickN
    numberOfClusters: 3
    affinity:
        clusterAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
              weight: 20
              preference:
              - labelSelector:
                  matchLabels:
                    critical-level: 1
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                      critical-allowed: "true"

PickN com restrições de propagação de topologia

Use restrições de espalhamento de topologia para forçar a divisão das colocações do cluster entre limites de topologia para atender aos requisitos de disponibilidade. Por exemplo, use essas restrições para dividir as colocações entre regiões ou atualizar anéis. Também é possível configurar as restrições de propagação de topologia para impedir o agendamento se a restrição não puder ser atendida (whenUnsatisfiable: DoNotSchedule) ou agendar da melhor forma possível (whenUnsatisfiable: ScheduleAnyway).

O exemplo a seguir mostra como espalhar um determinado conjunto de recursos por diversas regiões e tenta agendar entre clusters membros com diferentes dias de atualização.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pickn-02
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickN
    topologySpreadConstraints:
    - maxSkew: 2
      topologyKey: region
      whenUnsatisfiable: DoNotSchedule
    - maxSkew: 2
      topologyKey: updateDay
      whenUnsatisfiable: ScheduleAnyway

Para obter mais informações, consulte a documentação de código aberto da Frota sobre restrições de espalhamento de topologia.

Opções de política de colocação

A tabela resume os campos de política de agendamento disponíveis para cada tipo de colocação.

Selecionar os clusters com base em rótulos e propriedades

Rótulos e propriedades disponíveis para selecionar os clusters

Ao usar os tipos de colocação PickAll e PickN, você poderá usar os seguintes rótulos e propriedades como parte de suas políticas.

Rótulos

Os rótulos a seguir são adicionados automaticamente a todos os clusters de membros e podem ser usados para seleção de cluster de destino em políticas de colocação de recursos.

Também é possível usar os rótulos personalizados aplicados aos clusters.

Propriedades

As propriedades a seguir estão disponíveis para uso como parte das políticas de colocação.

As propriedades de CPU e memória são representadas como unidades de recurso do Kubernetes.

As propriedades de custo são decimais que representam um custo por hora em dólares americanos para a computação do Azure utilizada para nós dentro do cluster. O custo é baseado nos preços públicos do Azure.

Especificar os critérios de correspondência de seleção

Ao usar propriedades de cluster em um critério de política, você especifica:

• Nome: nome da propriedade, que é uma das propriedades listadas nas propriedades neste artigo.

• Operador: um operador usado para expressar a condição entre a restrição/valor desejado e o valor observado no cluster. No momento, os operadores com suporte são os seguintes:

  • Gt (Maior que): o valor observado do cluster de uma determinada propriedade deve ser maior do que o valor na condição antes que ele possa ser escolhido para a colocação do recurso.
  • Ge (Maior ou igual a): o valor observado do cluster de uma determinada propriedade deve ser maior ou igual ao valor na condição antes que ele possa ser escolhido para a colocação do recurso.
  • Lt (Menor que): o valor observado do cluster de uma determinada propriedade deve ser menor do que o valor na condição antes que ele possa ser escolhido para a colocação do recurso.
  • Le (Menor ou igual a): o valor observado do cluster de uma determinada propriedade deve ser menor ou igual ao valor na condição antes que ele possa ser escolhido para a colocação do recurso.
  • Eq (Igual a): o valor observado do cluster de uma determinada propriedade deve ser igual ao valor na condição antes que ele possa ser escolhido para a colocação do recurso.
  • Ne (Diferente de): o valor observado do cluster de uma determinada propriedade deve ser diferente do valor na condição antes que ele possa ser escolhido para a colocação do recurso.

  Se você usar o operador Gt, Ge, Lt, Le, Eqou Ne, a lista de valores na condição deverá ter exatamente um valor.

• Valores: uma lista de valores, que são os valores possíveis da propriedade.

A Frota avalia cada cluster com base nas propriedades especificadas na condição. Se não conseguir satisfazer as condições listadas em requiredDuringSchedulingIgnoredDuringExecution, esse cluster membro será excluído da colocação de recursos.

Aqui está um exemplo de política de colocação para selecionar apenas clusters com cinco ou mais nós.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - propertySelector:
                    matchExpressions:
                    - name: "kubernetes-fleet.io/node-count"
                      operator: Ge
                      values:
                      - "5"

Como funciona a classificação de propriedades

Quando preferredDuringSchedulingIgnoredDuringExecution é usado, um ordenador de propriedades classifica todos os clusters da frota com base em seus valores em uma ordem crescente ou decrescente. Os pesos usados para ordenação são calculados com base no valor especificado.

Um ordenador de propriedades consiste do seguinte:

• Nome: nome da propriedade do cluster.
• Ordem de classificação: a ordem de classificação pode ser Ascending ou Descending. Quando a ordem Ascending é usada, os clusters membros com valor observado mais baixos têm a preferência. Quando a ordem Descending é usada, os clusters membros com valor observado mais alto têm a preferência.

Ordem decrescente

Para a classificação de ordem Decrescente, o peso proporcional é calculado usando a seguinte fórmula:

((Observed Value - Minimum observed value) / (Maximum observed value - Minimum observed value)) * Weight

Por exemplo, digamos que você queira classificar os clusters com base na propriedade capacidade de CPU disponível em ordem decrescente e que você tenha uma frota de três clusters com as seguintes CPUs disponíveis:

Nesse caso, o ordenador calcula os seguintes pesos:

Ordem ascendente.

Para a classificação de ordem Ascendente, o peso proporcional é calculado usando a seguinte fórmula:

(1 - ((Observed Value - Minimum observed value) / (Maximum observed value - Minimum observed value))) * Weight

Por exemplo, digamos que você queira classificar os clusters com base em seu custo por núcleo de CPU em ordem crescente e que você tenha uma frota de três clusters com os seguintes custos de núcleo de CPU:

Nesse caso, o ordenador calcula os seguintes pesos:

Usando tolerâncias

ClusterResourcePlacement objetos dão suporte à especificação de tolerâncias, que se aplicam ao objeto ClusterResourcePlacement. Todos os objetos de tolerância consistem nos seguintes campos:

• key: a chave da tolerância.
• value: o valor da tolerância.
• effect: o efeito da tolerância, como NoSchedule.
• operator: o operador da tolerância, como Exists ou Equal.

Todas as tolerâncias são usadas para tolerarem uma ou mais manchas específicas aplicadas no ClusterResourcePlacement. Depois que todos os taints em um MemberCluster forem tolerados, o agendador poderá propagar recursos no cluster. Não é possível atualizar ou remover tolerâncias de um objeto ClusterResourcePlacement depois de criado.

Para obter mais informações, confira a documentação da Frota de código aberto sobre tolerâncias.

Configurar a estratégia de distribuição

A Frota usa uma estratégia de atualização contínua para controlar como as atualizações são distribuídas nos clusters.

No exemplo a seguir, o agendador de frota distribui atualizações para cada cluster sequencialmente, aguardando pelo menos unavailablePeriodSeconds entre clusters. O status de distribuição é considerado bem-sucedido se todos os recursos foram aplicados corretamente ao cluster. A verificação de status de distribuição não é em cascata para recursos filho, assim, por exemplo, não confirma se os pods criados por uma implantação ficam prontos.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    ...
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

Para obter mais informações, confira documentação da Frota de código aberto sobre estratégia de distribuição.

Determinar o status de colocação

O agendador da Frota atualiza os detalhes e o status das decisões de posicionamento no objeto ClusterResourcePlacement. A saída do script inclui as seguintes informações:

• As condições que atualmente se aplicam ao posicionamento, que incluem se o posicionamento foi concluído com êxito.
• Uma seção de status de posicionamento para cada cluster membro, que mostra o status da implantação nesse cluster.

O exemplo a seguir mostra um ClusterResourcePlacement que implantou o namespace test e o test-1 ConfigMap em dois clusters membros usando PickN. O posicionamento foi concluído com êxito e os recursos foram colocados nos clusters aks-member-1 e aks-member-2 .

É possível visualizar essas informações usando o comando kubectl describe crp <name>.

kubectl describe crp crp-1

Name:         crp-1
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  placement.kubernetes-fleet.io/v1
Kind:         ClusterResourcePlacement
Metadata:
  ...
Spec:
  Policy:
    Number Of Clusters:  2
    Placement Type:      PickN
  Resource Selectors:
    Group:
    Kind:                  Namespace
    Name:                  test
    Version:               v1
  Revision History Limit:  10
Status:
  Conditions:
    Last Transition Time:  2023-11-10T08:14:52Z
    Message:               found all the clusters needed as specified by the scheduling policy
    Observed Generation:   5
    Reason:                SchedulingPolicyFulfilled
    Status:                True
    Type:                  ClusterResourcePlacementScheduled
    Last Transition Time:  2023-11-10T08:23:43Z
    Message:               All 2 cluster(s) are synchronized to the latest resources on the hub cluster
    Observed Generation:   5
    Reason:                SynchronizeSucceeded
    Status:                True
    Type:                  ClusterResourcePlacementSynchronized
    Last Transition Time:  2023-11-10T08:23:43Z
    Message:               Successfully applied resources to 2 member clusters
    Observed Generation:   5
    Reason:                ApplySucceeded
    Status:                True
    Type:                  ClusterResourcePlacementApplied
  Placement Statuses:
    Cluster Name:  aks-member-1
    Conditions:
      Last Transition Time:  2023-11-10T08:14:52Z
      Message:               Successfully scheduled resources for placement in aks-member-1 (affinity score: 0, topology spread score: 0): picked by scheduling policy
      Observed Generation:   5
      Reason:                ScheduleSucceeded
      Status:                True
      Type:                  ResourceScheduled
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully Synchronized work(s) for placement
      Observed Generation:   5
      Reason:                WorkSynchronizeSucceeded
      Status:                True
      Type:                  WorkSynchronized
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully applied resources
      Observed Generation:   5
      Reason:                ApplySucceeded
      Status:                True
      Type:                  ResourceApplied
    Cluster Name:            aks-member-2
    Conditions:
      Last Transition Time:  2023-11-10T08:14:52Z
      Message:               Successfully scheduled resources for placement in aks-member-2 (affinity score: 0, topology spread score: 0): picked by scheduling policy
      Observed Generation:   5
      Reason:                ScheduleSucceeded
      Status:                True
      Type:                  ResourceScheduled
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully Synchronized work(s) for placement
      Observed Generation:   5
      Reason:                WorkSynchronizeSucceeded
      Status:                True
      Type:                  WorkSynchronized
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully applied resources
      Observed Generation:   5
      Reason:                ApplySucceeded
      Status:                True
      Type:                  ResourceApplied
  Selected Resources:
    Kind:       Namespace
    Name:       test
    Version:    v1
    Kind:       ConfigMap
    Name:       test-1
    Namespace:  test
    Version:    v1
Events:
  Type    Reason                     Age                    From                                   Message
  ----    ------                     ----                   ----                                   -------
  Normal  PlacementScheduleSuccess   12m (x5 over 3d22h)    cluster-resource-placement-controller  Successfully scheduled the placement
  Normal  PlacementSyncSuccess       3m28s (x7 over 3d22h)  cluster-resource-placement-controller  Successfully synchronized the placement
  Normal  PlacementRolloutCompleted  3m28s (x7 over 3d22h)  cluster-resource-placement-controller  Resources have been applied to the selected clusters

Gatilhos de alteração de colocação

O agendador da Frota prioriza a estabilidade dos posicionamentos de carga de trabalho existentes. Essa priorização pode limitar o número de alterações fazendo com que uma carga de trabalho seja removida e reagendada. Os seguintes cenários podem disparar alterações de posicionamento:

• As alterações de política de posicionamento no objeto ClusterResourcePlacement podem disparar a remoção e o reagendamento de uma carga de trabalho.
  • As operações de escalar horizontalmente (aumentando numberOfClusters sem outras alterações) colocam as cargas de trabalho apenas em novos clusters e não afetam as colocações existentes.
• Alterações de cluster, incluindo:
  • Um novo cluster tornando-se elegível poderá disparar a colocação se o novo cluster atender à política de colocação, por exemplo, uma política PickAll.
  • Um cluster com uma colocação é removido da frota. Dependendo da política, o agendador tenta colocar todas as cargas de trabalho afetadas nos clusters restantes sem afetar as colocações existentes.

As alterações somente de recursos (atualização dos recursos ou atualização do ResourceSelector no objeto ClusterResourcePlacement) são distribuídas gradualmente em canais existentes, mas não disparam o reagendamento da carga de trabalho.

Próximas etapas

• Configurar a propagação de recursos do Kubernetes do cluster de hub para os clusters membros.
• Colocação inteligente de recursos do Kubernetes em diversos clusters com base nas propriedades de clusters membros