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 clusters de membros usando o Azure Kubernetes Fleet Manager (Fleet).

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

  • Gerenciando o controle de acesso usando funções e associações de função em vários clusters.
  • Executando 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:

  • Implantação de um aplicativo de veiculação de vídeo em vários clusters em diferentes regiões para uma experiência de visualização de baixa latência.
  • Implantação de um aplicativo de carrinho de compras em duas regiões emparelhadas para que os clientes continuem a comprar durante uma única interrupção de região.
  • Implantação de um aplicativo de computação em lote em clusters com pools de nós spot baratos disponíveis.

É tedioso criar, atualizar e rastrear esses recursos do Kubernetes em vários clusters manualmente. O Fleet fornece propagação de recursos do Kubernetes para permitir o gerenciamento em escala dos recursos do Kubernetes. Com o Fleet, você pode criar recursos do Kubernetes no cluster de hub e propagá-los para clusters de membros selecionados por meio dos Recursos personalizados do Kubernetes: MemberCluster e ClusterResourcePlacement. O Fleet suporta estes recursos personalizados com base numa solução multi-cluster nativa da nuvem de código aberto. Para obter mais informações, consulte a documentação upstream do Fleet.

Importante

Os recursos de visualização do Azure Kubernetes Fleet Manager estão disponíveis com base no autoatendimento e opt-in. As visualizações prévias são fornecidas "como estão" e "conforme disponíveis" e são excluídas dos contratos de nível de serviço e da garantia limitada. As visualizações do Azure Kubernetes Fleet Manager são parcialmente cobertas pelo suporte ao cliente com base no melhor esforço. Como tal, estas funcionalidades não se destinam a utilização em produção.

Fluxo de trabalho de propagação de recursos

Diagrama que mostra como os recursos do Kubernetes são propagados para clusters membros.

O que é um MemberCluster?

Quando um cluster se junta a uma frota, um recurso personalizado correspondente MemberCluster é criado no cluster de hub. Você pode usar esse recurso personalizado para selecionar clusters de destino na propagação de recursos.

Os seguintes rótulos podem ser usados para a seleção de clusters 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 a referência da API MemberCluster.

O que é um ClusterResourcePlacement?

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

Com ClusterResourcePlacemento , você pode:

  • Selecione quais recursos do Kubernetes com escopo de cluster serão propagados para clusters membros.
  • Especifique políticas de posicionamento para selecionar manual ou automaticamente um subconjunto ou todos os clusters membros como clusters de destino.
  • Especifique estratégias de distribuição para implementar com segurança quaisquer atualizações dos recursos selecionados do Kubernetes em vários clusters de destino.
  • Visualize o progresso da propagação para cada cluster de destino.

O ClusterResourcePlacement objeto suporta o uso de ConfigMap para envolver o objeto para ajudar a propagar para clusters membros sem quaisquer efeitos colaterais não intencionais. Os métodos de seleção incluem:

  • Grupo, versão e tipo: Selecione e coloque todos os recursos do tipo determinado.
  • Grupo, versão, tipo e nome: selecione e coloque um recurso específico de um determinado tipo.
  • Grupo, versão, tipo 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 referência da ClusterResourcePlacement 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 do 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órios.
  • PickFixed coloca os recursos em uma lista específica de clusters de membros por nome.
  • PickN é a opção de posicionamento mais flexível e permite a seleção de clusters com base em restrições de dispersão de afinidade ou topologia e é útil ao distribuir cargas de trabalho entre vários clusters apropriados para garantir que a disponibilidade seja desejada.

PickAll Política de Colocação

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

O exemplo a seguir mostra como implantar um test-deployment namespace e todos os seus 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 pega o test-deployment namespace e todos os recursos contidos nele e o implanta em todos os clusters membros da frota com o rótulo fornecido environment . Se todos os clusters forem desejados, você poderá remover o affinity termo completamente.

PickFixed Política de Colocação

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

O exemplo a seguir mostra como implantar o test-deployment namespace em clusters cluster1 de membros 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

PickN Política de Colocação

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

PickN com afinidades

O uso de afinidades com uma PickN política de posicionamento funciona de forma semelhante ao uso de afinidades com o agendamento de pods. Você pode definir as afinidades necessárias e preferidas. As afinidades necessárias impedem a colocação 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. Apenas clusters com o critical-allowed: "true" rótulo são destinos de posicionamento válidos, e é dada preferência aos 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

Você pode usar restrições de dispersão de topologia para forçar a divisão dos posicionamentos de cluster entre limites de topologia para atender aos requisitos de disponibilidade, por exemplo, dividindo posicionamentos entre regiões ou atualizando anéis. Você também pode configurar restrições de cobertura de topologia para evitar 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 várias regiões e tenta agendar entre clusters de membros com dias de atualização diferentes:

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 de restrições de dispersão de topologia upstream Frota.

Estratégia de atualização

O Fleet 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 contínua usando 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 atualizações para cada cluster sequencialmente, aguardando pelo menos unavailablePeriodSeconds entre clusters. O status de distribuição é considerado bem-sucedido se todos os recursos tiverem sido aplicados corretamente ao cluster. A verificação de status da distribuição não ocorre 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 estratégia de implantação upstream Fleet.

Estado da colocação

O Agendador de frota atualiza os detalhes e o status das decisões de posicionamento no ClusterResourcePlacement objeto. Você pode exibir essas informações usando o kubectl describe crp <name> comando. A saída inclui as seguintes informações:

  • As condições que atualmente se aplicam à colocação, que incluem se a colocação foi concluída com sucesso.
  • 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 test namespace e o test-1 ConfigMap em dois clusters membros usando PickN. A colocação foi concluída com sucesso e os recursos foram colocados nos aks-member-1aks-member-2 e clusters.

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 de frota prioriza a estabilidade dos posicionamentos de carga de trabalho existentes. Essa priorização pode limitar o número de alterações que fazem com que uma carga de trabalho seja removida e reagendada. Os cenários a seguir podem desencadear alterações de posicionamento:

  • As alterações na política de posicionamento no objeto podem desencadear a remoção e o ClusterResourcePlacement reagendamento de uma carga de trabalho.
    • As operações de expansão (aumentando numberOfClusters sem outras alterações) colocam cargas de trabalho apenas em novos clusters e não afetam os posicionamentos existentes.
  • Alterações de cluster, incluindo:
    • Um novo cluster que se torne elegível pode acionar o posicionamento se atender à política de posicionamento, por exemplo, uma PickAll política.
    • Um cluster com um posicionamento removido da frota tentará substituir todas as cargas de trabalho afetadas sem afetar seus outros posicionamentos.

As alterações somente de recursos (atualizar os recursos ou atualizar o ResourceSelectorClusterResourcePlacement no objeto) são implantadas gradualmente em posicionamentos existentes, mas não acionam o reagendamento da carga de trabalho.

Tolerâncias

ClusterResourcePlacement Os objetos suportam a especificação de tolerâncias, que se aplicam ao ClusterResourcePlacement objeto. Cada objeto de tolerância consiste 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.

Cada tolerância é usada para tolerar uma ou mais manchas específicas aplicadas no ClusterResourcePlacement. Depois que todas as manchas em um MemberCluster são toleradas, o agendador pode propagar recursos para o cluster. Não é possível atualizar ou remover tolerações de um ClusterResourcePlacement objeto depois que ele é criado.

Para obter mais informações, consulte a documentação upstream do Fleet.

Acesse a API do Kubernetes do cluster de recursos do Fleet

Se você criou um recurso do Azure Kubernetes Fleet Manager com o cluster de hub habilitado, poderá usá-lo para controlar centralmente cenários como a propagação de objetos do Kubernetes. Para acessar a API do Kubernetes do cluster de recursos do Fleet, siga as etapas em Acessar a API do Kubernetes do cluster de recursos do Fleet com o Azure Kubernetes Fleet Manager.

Próximos passos

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