Apresentando o posicionamento inteligente de recursos do Azure Kubernetes Fleet Manager

Aplica-se a ✔️ Fleet Manager com cluster central

O gerenciamento de recursos do Kubernetes em vários clusters apresenta desafios significativos para administradores de plataforma e desenvolvedores de aplicativos. À medida que as organizações dimensionam sua infraestrutura do Kubernetes além de um único cluster, elas geralmente encontram complexidades relacionadas à distribuição de recursos, consistência e sobrecarga de gerenciamento manual. A abordagem tradicional de gerenciar cada cluster de forma independente cria silos operacionais que se tornam cada vez mais difíceis de manter à medida que o tamanho da frota aumenta.

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

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

É entediante e potencialmente propenso a erros criar, atualizar e acompanhar recursos do Kubernetes em vários clusters manualmente.

Neste artigo, exploramos como você pode usar a capacidade de posicionamento inteligente de recursos do Fleet Manager para gerenciar a distribuição de recursos do Kubernetes com escopo de cluster e namespace nos clusters membros de uma frota.

A funcionalidade de posicionamento de recursos do Fleet Manager baseia-se no projeto CNCF do KubeFleet.

Visão geral do processo de posicionamento de recursos

Para usar o posicionamento inteligente de recursos do Fleet Manager, siga estas etapas:

1. Recursos de estágio no cluster de hub: use Implantação Contínua, GitOps ou um método semelhante para aplicar os manifestos para distribuições de recursos no cluster do hub do Fleet Manager.
2. Crie um posicionamento de recurso: crie um manifesto de posicionamento que selecione o recurso e defina uma política para escolher quais clusters membros recebem o recurso.
3. Aplicar o posicionamento de recursos no cluster do hub: aplique o manifesto de posicionamento ao cluster do hub para começar a distribuir o recurso.
4. O Fleet Manager agenda recursos: o Fleet Manager observa o posicionamento do recurso e o escopo selecionado e executa a distribuição dos recursos.
5. Observe a distribuição por meio do posicionamento do recurso: consulte o posicionamento do recurso no cluster do hub para verificar o status do recurso à medida que ele é lançado.

Fleet Manager tem uma experiência de portal Azure para posicionamento de recursos que fornece uma representação mais visual da implementação.

Componentes de posicionamento de recursos

Um posicionamento de recurso, independentemente do escopo (cluster ou namespace), consiste nos seguintes componentes:

• Seletores de recursos: selecione os recursos a serem incluídos por meio de resourceSelectors.
• Política de alocação: defina como escolher clusters por meio de placementType usando um dos tipos PickAll, PickFixed ou PickN.
• Estratégia de implantação: controla como os recursos são implantados nos clusters selecionados, incluindo um strategy opcional.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: namespace-only-crp
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
  policy:
    placementType: PickAll   

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2

Seletores de recurso

Selecione recursos usando um ou mais resourceSelectors em um posicionamento. Cada seletor de recursos pode especificar:

• Grupo, Versão, Tipo (GVK): o tipo de recurso do Kubernetes a ser selecionado.
• Nome: o nome de um recurso específico.
• Seletores de rótulo: rótulos para corresponder a vários recursos.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: namespace-only-crp
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
      selectionScope: NamespaceOnly
  policy:
    placementType: PickAll

Política de posicionamento

O posicionamento de recursos do Fleet Manager dá suporte aos seguintes tipos de política de posicionamento para controlar como ele seleciona clusters:

• PickFixed coloca recursos em clusters membros usando seus nomes de cluster.
• PickAll coloca recursos em todos os clusters de membros ou em todos os clusters membros que atendem a um critério. Essa política é útil para alocar cargas de trabalho de infraestrutura, como monitoramento de clusters ou aplicativos de geração de relatórios.
• PickN é a opção de posicionamento mais flexível. Permite que você selecione clusters com base em restrições de afinidade ou em restrições de distribuição na topologia. Use essa política ao espalhar cargas de trabalho em vários clusters semelhantes para garantir que a disponibilidade seja mantida.

Tipo de colocação PickFixed

Use PickFixed para selecionar os clusters pelo nome. Forneça nomes na clusterNames matriz.

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

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2

Tipo de colocação PickAll

Use PickAll para distribuir recursos em todos os clusters de membros ou em todos os clusters que correspondam a um critério especificado.

Ao criar esse tipo de posicionamento, especifique os seguintes tipos de afinidade de cluster:

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

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

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickall
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                        environment: production

Tipo de colocação PickN

Use PickN para distribuir recursos em um número configurável de clusters com base em afinidades e restrições de propagação de topologia.

Ao criar esse tipo de posicionamento, especifique os seguintes tipos de afinidade de cluster:

• 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 o posicionamento em clusters que não correspondem. As afinidades preferenciais definem a ordem de seleção dos clusters correspondentes.

PickN com afinidades

O uso de afinidades com uma política de posicionamento PickN funciona da mesma forma que o uso de afinidades com o agendamento de pods em um único cluster Kubernetes.

O exemplo a seguir mostra como implantar um recurso 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-critical-preferences
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1
  policy:
    placementType: PickN
    numberOfClusters: 3
    affinity:
        clusterAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
              weight: 20
              preference:
              - labelSelector:
                  matchLabels:
                    critical-level: 1
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                      critical-allowed: "true"

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickn-critical-preferences
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  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 distribuição de topologia

Use restrições de propagação de topologia para forçar posicionamentos entre limites de topologia para atender aos requisitos de disponibilidade.

Você pode configurar o comportamento das restrições de propagação de topologia usando a whenUnsatisfiable propriedade:

• DoNotSchedule: se a restrição não puder ser atendida, a solicitação de posicionamento falhará.
• ScheduleAnyway: se a restrição não puder ser atendida, coloque os recursos de qualquer maneira.

O exemplo a seguir mostra como espalhar recursos em várias regiões Azure e tenta agendar entre clusters membros com dias de atualização diferentes usando um rótulo updateDaypersonalizado.

Quando não for possível alcançar a dispersão entre regiões do Azure, a alocação falhará. Se a restrição updateDay não for atendida, o posicionamento ainda assim ocorre.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pickn-locations-updates
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1
  policy:
    placementType: PickN
    topologySpreadConstraints:
    - maxSkew: 2
      topologyKey: fleet.azure.com/location
      whenUnsatisfiable: DoNotSchedule
    - maxSkew: 2
      topologyKey: updateDay
      whenUnsatisfiable: ScheduleAnyway

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickn-locations-updates
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickN
    topologySpreadConstraints:
    - maxSkew: 2
      topologyKey: fleet.azure.com/location
      whenUnsatisfiable: DoNotSchedule
    - maxSkew: 2
      topologyKey: updateDay
      whenUnsatisfiable: ScheduleAnyway

Para obter mais informações, consulte a documentação do KubeFleet sobre restrições de spread de topologia.

Selecionar clusters usando rótulos e propriedades

O posicionamento inteligente de recursos do Fleet Manager fornece um conjunto de critérios poderosos que você pode usar para determinar como selecionar clusters ao usar os tipos de posicionamento PickN e PickAll. Nesta seção, você aprenderá a usar essas opções para criar políticas que atenda às suas necessidades.

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

A tabela a seguir mostra os campos de política de agendamento disponíveis para cada tipo de posicionamento.

Rótulos de clusters membros

Você pode rotular o MemberCluster recurso no cluster do hub como qualquer recurso do Kubernetes.

Além disso, o Fleet Manager adiciona automaticamente os seguintes rótulos somente de leitura a todos os clusters membros.

Propriedades do cluster

Use as propriedades a seguir como parte das políticas de posicionamento.

• As unidades de recurso do Kubernetes representam as propriedades de CPU e memória. Para obter mais informações, consulte unidades de recursos no Kubernetes.

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

Critérios de correspondência de seleção

Quando você usa propriedades de cluster em um critério de política, especifique:

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

• Operador: um operador que expressa a condição entre a restrição ou o valor desejado e o valor observado no cluster. Os operadores seguintes são atualmente suportados:

  • 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 (Não é igual a): o valor observado de um cluster da propriedade fornecida não deve ser igual ao valor na condição antes que ele possa ser escolhido para o posicionamento 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.

O Fleet avalia cada cluster com base nas propriedades que você especifica na condição. Se um cluster não atender às condições listadas em requiredDuringSchedulingIgnoredDuringExecution, o Fleet excluirá o cluster da alocaçã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-pickall-five-nodes
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - propertySelector:
                    matchExpressions:
                    - name: "kubernetes-fleet.io/node-count"
                      operator: Ge
                      values:
                      - "5"

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickall-five-nodes
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  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 você usa preferredDuringSchedulingIgnoredDuringExecution, um classificador 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 você usa Ascending a ordem, os clusters de membros com valores observados mais baixos são preferenciais. Quando você usa a ordenação Descending, os clusters de membros com maior valor observado são priorizados.

Para obter mais informações, consulte a documentação do KubeFleet sobre agendamento baseado em propriedade.

Configurar a estratégia de distribuição

O posicionamento de recursos do Fleet Manager usa uma estratégia padrão RollingUpdate para controlar como os recursos são distribuídos para clusters membros.

No exemplo a seguir, o posicionamento é aplicado sequencialmente em cada cluster membro, aguardando pelo menos unavailablePeriodSeconds entre os clusters.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pick-all-rolling
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1
  policy:
    placementType: PickAll
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickall-rolling
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickAll
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

O status da implantação é considerado bem-sucedido se todos os recursos forem aplicados corretamente ao cluster. Esse status não configura o status do recurso filho em cascata, portanto, ele não confirma se os pods criados em um cluster membro por uma implantação ficam prontos.

Para obter mais informações, consulte a documentação sobre estratégias de distribuição.

Usando tolerâncias

Você pode manchar clusters de membros da mesma forma que você mancha os nós em um cluster.

As alocações de recursos dão suporte ao uso de tolerâncias em que cada 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 permite ignorar uma ou mais marcações específicas aplicadas a um MemberCluster. Assim que todas as marcações forem toleradas, o Fleet Manager poderá distribuir os recursos para o cluster membro.

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: test-ns
spec:
  policy:
    placementType: PickAll
    tolerations:
      - key: app-team-a
        operator: Exists
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: test-ns
      version: v1
  revisionHistoryLimit: 10
  strategy:
    type: RollingUpdate

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickall-rolling
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickAll
    tolerations:
      - key: app-team-a
        operator: Exists
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

Para obter mais informações, consulte a documentação sobre tolerâncias.

Usando recursos de envelope

O cluster de hub do Fleet Manager também é um cluster do Kubernetes. Primeiro, você aplica qualquer recurso que deseja distribuir para o cluster do hub. Essa abordagem pode levar a:

1. Efeitos colaterais não intencionais: ValidatingWebhookConfigurations, MutatingWebhookConfigurations ou Admission Controllers tornam-se ativos no cluster central, podendo interceptar e afetar operações.

2. Riscos de segurança: os recursos de RBAC (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings) destinados a clusters de membro podem conceder ou restringir permissões no cluster central.

3. Limitações de recursos: ResourceQuotas, FlowSchema ou LimitRanges definidos para clusters de membros entram em vigor no cluster de hub.

Para evitar efeitos colaterais desnecessários, o Fleet Manager fornece recursos de envelope personalizados (ClusterResourceEnvelope e ResourceEnvelope) para encapsular objetos e evitar esses possíveis problemas.

Você aplica o recurso de envelope ao cluster do hub, mas os recursos que ele contém são extraídos e aplicados quando chegam aos clusters de membros.

Para obter mais informações, confira a documentação em Objetos envelope.

Determinar o status de colocação

O posicionamento de recursos do Fleet Manager fornece duas maneiras de exibir o status dependendo do nível de acesso do cluster do hub e dos requisitos:

kubectl describe resourceplacement place-cmap-1

kubectl describe clusterresourceplacement 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

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp-with-status-reporting
spec:
  statusReportingScope: NamespaceAccessible
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
  policy:
    placementType: PickAll

kubectl describe clusterresourceplacementstatuses.v1beta1.placement.kubernetes-fleet.io crp-with-status-reporting -n my-app

Gatilhos de alteração de colocação

O agendador do Fleet Manager prioriza a estabilidade dos posicionamentos de recursos existentes. Essa prioridade limita o número de alterações que removem e reagendam um recurso.

Os seguintes cenários podem disparar alterações de posicionamento:

• As alterações de política de posicionamento no posicionamento do recurso (ClusterResourcePlacement ou ResourcePlacement) podem disparar a remoção e o reagendamento de um recurso.
  • 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 no cluster de membros, incluindo:
  • Um novo cluster membro se torna elegível e passa a atender à política de posicionamento, por exemplo, uma política PickAll.
  • Remoção de um cluster membro da frota. Dependendo da política, o agendador tenta colocar todos os recursos afetados nos clusters restantes sem afetar os posicionamentos existentes.

Atualizar os recursos selecionados (por exemplo, modificar um Deployment) ou atualizar o resourceSelector em um posicionamento de recurso faz com que o Fleet Manager faça a implantação gradual dos posicionamentos existentes, mas não aciona o reagendamento (ou seja, a alteração dos clusters selecionados) do recurso.

Trabalhando juntos com ResourcePlacement e ClusterResourcePlacement

Embora ClusterResourcePlacement suponha que os namespaces representem limites de aplicativo, os padrões de uso do mundo real geralmente são mais complexos. As organizações frequentemente usam namespaces como limites de equipe em vez de limites de aplicativo, levando a vários desafios que ResourcePlacement abordam diretamente:

Namespaces de vários aplicativos: em muitas organizações, um único namespace contém vários aplicativos independentes pertencentes à mesma equipe. Esses aplicativos podem ter:

• Requisitos de ciclo de vida diferentes (um aplicativo pode precisar de atualizações frequentes, enquanto outro permanece estável).
• Diferentes necessidades de posicionamento de cluster (desenvolvimento versus aplicativos de produção).
• Requisitos independentes de dimensionamento e recursos.
• Requisitos de conformidade ou governança separados.

Decisões de agendamento individuais: muitas cargas de trabalho, particularmente trabalhos de IA/ML, exigem decisões de agendamento individuais:

• Trabalhos de IA: as cargas de trabalho de machine learning geralmente consistem em trabalhos de curta duração e com uso intensivo de recursos que precisam ser agendados com base na disponibilidade de recursos de cluster, disponibilidade de GPU ou localidade de dados.
• Cargas de trabalho em lote: trabalhos em lotes diferentes no mesmo namespace podem ter como destino diferentes tipos de cluster com base nos requisitos computacionais.

Controle completo da equipe de aplicativos: ResourcePlacement fornece às equipes de aplicativos controle direto sobre o posicionamento de recursos sem a necessidade de intervenção da equipe de plataforma:

• Operações de autoatendimento: as equipes podem gerenciar suas próprias estratégias de distribuição de recursos.
• Ciclos de implantação independentes: aplicativos diferentes em um namespace podem ter agendas de distribuição independentes.
• Funcionalidades de substituição granular: o Teams pode personalizar as configurações de recursos por cluster sem afetar outros aplicativos no namespace.

Essa abordagem granular garante que ResourcePlacement possa se adaptar a estruturas organizacionais diversas e padrões de carga de trabalho, mantendo a simplicidade e o poder da estrutura de agendamento da Frota.

Principais diferenças entre ResourcePlacement e ClusterResourcePlacement

A tabela a seguir realça as principais diferenças entre ResourcePlacement e ClusterResourcePlacement:

Ambos ResourcePlacement e ClusterResourcePlacement compartilhem os mesmos recursos principais para todos os outros aspectos não listados na tabela de diferenças.

Cenário de exemplo usando ResourcePlacement e ClusterResourcePlacement

ResourcePlacement funciona com ClusterResourcePlacement (CRP) para fornecer uma solução completa de gerenciamento de recursos multicluster. Entender essa relação é crucial para o gerenciamento efetivo de frotas.

Fluxo de trabalho típico:

1. Administradores de plataforma: use ClusterResourcePlacement para implantar namespaces em toda a frota.
2. Equipes de aplicação: use ResourcePlacement para gerenciar recursos específicos dentro desses espaços de nomes já estabelecidos.

Os exemplos a seguir mostram como coordenar CRP e RP.

Administrador da plataforma: crie o namespace usando ClusterResourcePlacement:

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: app-namespace-crp
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
      selectionScope: NamespaceOnly # only namespace itself is placed, no resources within the namespace
  policy:
    placementType: PickAll # If placement type is not PickAll, the application teams needs to know what are the clusters they can place their applications.

Equipe de aplicativos: gerenciar recursos específicos dentro do namespace usando ResourcePlacement:

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2

Práticas recomendadas para ResourcePlacement e ClusterResourcePlacement

Ao usar ResourcePlacement com ClusterResourcePlacement, siga estas práticas recomendadas:

• Estabeleça namespaces primeiro: sempre implante namespaces por meio do CRP antes de criar ResourcePlacement objetos.
• Monitorar dependências: use o monitoramento da Frota para garantir que os CRPs no nível do namespace estejam íntegros antes de implantar RPs dependentes.
• Coordenar políticas: alinhe as políticas de posicionamento de CRP e RP para evitar conflitos. Por exemplo, se o CRP colocar o namespace nos clusters A, B e C, RP poderá direcionar qualquer subconjunto desses clusters.
• Limites de equipe: use CRP para recursos gerenciados por plataforma (namespaces, RBAC) e RP para recursos gerenciados pelo aplicativo (configurações de aplicativo, segredos).

Essa abordagem coordenada garante que ResourcePlacement forneça a flexibilidade de que as equipes precisam, ao mesmo tempo em que mantém a infraestrutura fundamental gerenciada pelos operadores de plataforma.

Seleção, posicionamento e distribuição de recursos

ResourcePlacement usa os mesmos padrões de posicionamento que ClusterResourcePlacement:

• Política de posicionamento: PickAlle PickFixedPickN as políticas funcionam de forma idêntica para ambas as APIs.
• Estratégia de distribuição: controlar como as atualizações se propagam entre clusters com os mesmos mecanismos de atualização sem interrupção.
• Status e observabilidade: Monitore o progresso da implantação usando kubectl describe resourceplacement <name> -n <namespace>.
• Recursos avançados: Usar tolerâncias, substituições de recursos, restrições de propagação de topologia e regras de afinidade.

A principal diferença está no escopo de seleção de recursos . Embora ClusterResourcePlacement normalmente selecione namespaces inteiros e seu conteúdo, ResourcePlacement fornece controle refinado sobre recursos individuais com escopo de namespace.

:::zone-end

Próximas Etapas 

• Use o posicionamento de recursos do Fleet Manager para implantar cargas de trabalho em vários clusters.
• Usando ResourcePlacement para implantar recursos com escopo de namespace.
• Posicionamento inteligente de recursos do Kubernetes entre clusters com base nas propriedades de clusters de membros.
• Controle de despejo e disrupção no posicionamento de recursos.
• Definindo uma estratégia de implantação para uma alocação de recursos.
• Perguntas frequentes sobre o posicionamento de recursos do Fleet Manager.