Share via

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

  • Artigo

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

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, é 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. O Fleet dá suporte a esses recursos personalizados com base em uma solução multi cluster nativa de nuvem de código aberto. Para obter mais informações, consulte a documentação da Frota de upstream .

Importante

A versão prévia do recurso Gerenciador de Frota de Kubernetes do Azure está disponível com base em autoatendimento e aceitação. As versões prévias são fornecidas “no estado em que se encontram” e “conforme disponíveis” e são excluídas dos contratos de nível de serviço e da garantia limitada. A versão prévia do Gerenciador de Frota de Kubernetes do Azure é parcialmente coberta pelo suporte ao cliente com base no melhor esforço. Dessa forma, esses recursos não são destinados ao uso em produção.

Fluxo de trabalho de propagação de recursos

Diagrama que mostra como o recurso Kubernetes é propagado para clusters membros.

O que é MemberCluster?

Depois que um cluster une uma frota, um recurso personalizado MemberCluster correspondente é criado no cluster de hub. É possível usar esse recurso personalizado para selecionar os clusters de destino na propagação de recursos.

Os rótulos a seguir poderão ser usados para seleção de cluster de destino na propagação de recursos e são adicionados automaticamente a todos os clusters membros:

  • fleet.azure.com/location
  • fleet.azure.com/resource-group
  • fleet.azure.com/subscription-id

Para obter mais informações, consulte Referência de API MemberCluster.

O que é ClusterResourcePlacement?

Um objeto ClusterResourcePlacement é usado para informar ao agendador do Fleet como colocar um determinado conjunto de objetos com escopo de cluster do cluster do hub em clusters 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 posicionamento para selecionar manual ou automaticamente um subconjunto ou todos 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.

O objeto ClusterResourcePlacement dá suporte para uso de ConfigMap para envelope de objeto e ajudar a propagar aos clusters membros sem efeitos colaterais indesejados. Os métodos de seleção incluem:

  • Agrupar, versão e tipo: selecione e coloque todos os recursos do tipo fornecido.
  • Agrupar, versão, tipo e nome: selecione e coloque um recurso específico de um determinado tipo.
  • Agrupar, versões, tipos e rótulos: selecione e coloque todos os recursos de um determinado tipo que correspondam aos rótulos fornecidos.

Para obter mais informações, consulte a ClusterResourcePlacementreferência de API.

Ao criar o ClusterResourcePlacement, os seguintes tipos de afinidade podem ser especificados:

  • requiredDuringSchedulingIgnoredDuringExecution: como essa afinidade é do tipo necessário durante o agendamento, ela filtra os clusters com base em suas propriedades.
  • preferredDuringSchedulingIgnoredDuringExecution: como essa afinidade é apenas do tipo preferencial, mas não é necessária durante o agendamento, ela fornece classificação preferencial para clusters com base em propriedades especificadas por você, como custo ou disponibilidade de recursos.

Vários tipos de posicionamento estão disponíveis para controlar o número de clusters para os quais o recurso kubernetes precisa ser propagado:

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

Política de posicionamento PickAll

Você pode usar uma política de posicionamento PickAll para implantar uma carga de trabalho em todos os clusters membros da frota (opcionalmente correspondendo a um conjunto de critérios).

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

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

Essa política simples usa o namespace test-deployment e todos os recursos contidos nele e o implanta em todos os clusters membros da frota com o rótulo environment fornecido. Se todos os clusters forem desejados, você poderá remover totalmente o termo affinity.

Política de posicionamento 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.

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

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

Política de posicionamento PickN

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

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. É possível definir afinidades obrigatórias e preferenciais. As afinidades necessárias impedem o posicionamento em clusters que não correspondem às afinidades especificadas, e as afinidades preferenciais permitem ordenar o conjunto de clusters válidos quando uma decisão de posicionamento está sendo tomada.

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/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp
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

É possível usar as restrições de distribuição de topologia para forçar a divisão dos posicionamentos de cluster entre os limites da topologia para atender aos requisitos de disponibilidade, por exemplo, dividindo os posicionamentos entre as regiões ou os anéis de atualização. 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 distribuir um determinado conjunto de recursos por diversas regiões e tentar agendar entre clusters membros com diferentes dias de atualização:

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp
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 da Frota para restrições de propagação de topologia de upstream.

Estratégia de atualização

A Frota usa uma estratégia de atualização contínua para controlar como as atualizações são implementadas em vários posicionamentos de cluster.

O exemplo a seguir mostra como configurar uma estratégia de atualização sem interrupção utilizando as configurações padrão:

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

O agendador distribui as atualizações para cada cluster sequencialmente, aguardando pelo menos unavailablePeriodSeconds entre os 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, por exemplo, não confirma se os pods criados por uma implantação ficam prontos.

Para obter mais informações, consulte a documentação da Frota para estratégia de distribuição de upstream .

Status de posicionamento

O agendador da Frota atualiza os detalhes e o status das decisões de posicionamento no objeto ClusterResourcePlacement. É possível visualizar essas informações usando o comando kubectl describe crp <name>. 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 .

Name:         crp-1
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  placement.kubernetes-fleet.io/v1beta1
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

Alterações de posicionamento

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 os posicionamentos existentes.
  • Alterações de cluster, incluindo:
    • Um novo cluster tornando-se elegível poderá disparar o posicionamento se atender à política de posicionamento, por exemplo, uma política PickAll.
    • Um cluster com um posicionamento removido da frota tentará substituir todas as cargas de trabalho afetadas sem afetar os outros posicionamentos.

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.

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. Você não pode atualizar ou remover tolerâncias de um objeto ClusterResourcePlacement depois que ele foi criado.

Para obter mais informações, consulte a documentação da Frota de upstream .

Acessar a API do Kubernetes do cluster de recursos de Frota

Se você criou um recurso de Gerenciador de Frota de Kubernetes com o cluster do hub ativado, poderá utilizá-lo para controlar centralmente os cenários como a propagação de objetos Kubernetes. Para acessa a API de Kubernetes do cluster de recursos da Frota, siga as etapas descritas em Acessar a API do Kubernetes do cluster de recurso de Frota com o Gerenciador de Frota de Kubernetes do Azure.

Próximas etapas

Configurar a propagação de recursos do Kubernetes do cluster de hub para os clusters membros.