Apresentando o Azure Kubernetes Fleet Manager Colocação Inteligente de Recursos

Aplica-se ao ✔️ Fleet Manager com cluster de hub

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 escalam a sua infraestrutura Kubernetes para além de um único cluster, frequentemente enfrentam complexidades relacionadas com a distribuição de recursos, consistência e sobrecarga de gestão manual. A abordagem tradicional de gerir 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 frequentemente precisam de implementar recursos Kubernetes em múltiplos clusters por várias razões, incluindo:

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

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

Neste artigo, exploramos como pode usar a capacidade inteligente de colocação de recursos do Fleet Manager para gerir a distribuição de recursos Kubernetes com alcance de clusters e namespaces entre clusters membros de uma frota.

A capacidade de colocação de recursos do Fleet Manager baseia-se no projeto KubeFleet CNCF.

Visão geral do processo de colocação de recursos

Para utilizar o posicionamento inteligente de recursos do Fleet Manager, siga estes passos:

1. Preparar os recursos no cluster hub: utilize a implementação contínua, o GitOps ou um método semelhante para aplicar os manifestos das distribuições de recursos no cluster hub do Fleet Manager.
2. Crie uma colocação de recurso: crie um manifesto de colocação que selecione o recurso e defina uma política para escolher quais os clusters membros que recebem o recurso.
3. Aplicar a colocação de recursos no cluster do hub: aplicar o manifesto de colocação ao cluster do hub para começar a distribuir o recurso.
4. O Gestor de Frota agenda os recursos: O Gestor de Frota observa a colocação dos recursos e o âmbito selecionado, e realiza a distribuição dos recursos.
5. Observe a distribuição através da colocação de recursos: consulte a colocação de recursos no cluster hub para verificar o estado do recurso à medida que é lançado.

O Fleet Manager tem uma experiência de portal Azure para colocação de recursos que oferece uma representação mais visual do lançamento.

Componentes de colocação de recursos

Uma colocação de recursos, independentemente do âmbito (cluster ou namespace), consiste nos seguintes componentes:

• Seletores de recursos: selecione os recursos a incluir através de resourceSelectors.
• Política de colocação: defina como escolher clusters através de placementType usando um dos tipos PickAll, PickFixed ou PickN.
• Estratégia de implementação: controle de como os recursos são implementados nos clusters selecionados através da inclusão de 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 recursos

Selecione recursos usando um ou mais resourceSelectors numa localização. Cada seletor de recursos pode especificar:

• Group, Version, Kind (GVK): O tipo de recurso Kubernetes a selecionar.
• Nome: O nome de um recurso específico.
• Seletores de etiquetas: Etiquetas para corresponder a múltiplos 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 colocação

O posicionamento de recursos do Gestor de Frota suporta os seguintes tipos de políticas de colocação para controlar a forma como seleciona clusters:

• O PickFixed coloca recursos nos clusters membros usando os nomes dos seus clusters.
• O PickAll coloca recursos em todos os clusters membros, ou em todos os clusters membros que cumprem um critério. Esta política é útil para colocar cargas de trabalho de infraestrutura, como monitorização de clusters ou aplicações de relatórios.
• PickN é a opção de colocação mais flexível. Permite-lhe selecionar clusters com base em restrições de afinidade ou de dispersão de topologia. Use esta política ao distribuir cargas de trabalho por vários clusters semelhantes para garantir que a disponibilidade é mantida.

Tipo de posicionamento PickFixed

Use PickFixed para selecionar os clusters pelo nome. Fornece os nomes no clusterNames array.

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 posicionamento PickAll

Use PickAll para distribuir recursos entre todos os clusters membros, ou todos os clusters que cumpram um critério que especificar.

Ao criar este tipo de colocação, 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 posicionamento PickN

Use PickN para distribuir recursos num número configurável de clusters com base tanto nas afinidades como nas restrições de dispersão da topologia.

Ao criar este tipo de colocação, 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 esta política é preferida, mas não obrigatória durante o agendamento, ela classifica clusters com base em critérios especificados.

Você pode definir as afinidades necessárias e preferidas. As afinidades necessárias impedem a colocação em clusters que não correspondem. As afinidades preferenciais determinam a ordem dos clusters correspondentes.

PickN com afinidades

Utilizar afinidades com a política de colocação PickN funciona da mesma forma que utilizar afinidades com o agendamento de pods num único cluster Kubernetes.

O exemplo seguinte mostra como implantar um recurso 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/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 espalhamento topológico

Use restrições de dispersão topológica para forçar colocações através dos limites da topologia para satisfazer os requisitos de disponibilidade.

Pode configurar o comportamento das restrições de espalhamento topológico usando a whenUnsatisfiable propriedade:

• DoNotSchedule: se a restrição não puder ser cumprida, reprovar o pedido de colocação.
• Agendar mesmo assim: se a restrição não puder ser satisfeita, aloca os recursos mesmo assim.

O exemplo seguinte mostra como distribuir recursos por múltiplas regiões do Azure e tenta agendar entre clusters de membros com dias de atualização diferentes, usando uma etiqueta updateDaypersonalizada.

Se não for possível satisfazer a distribuição entre regiões do Azure, a colocação falha. Se a restrição updateDay não for satisfeita, o posicionamento acontece ainda assim.

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 propagação de topologia.

Selecione clusters usando etiquetas e propriedades

A colocação inteligente de recursos do Fleet Manager fornece um conjunto de critérios avançados que pode utilizar para determinar como selecionar clusters ao usar os tipos de colocação PickN e PickAll. Nesta secção, aprende como usar estas opções para criar políticas que se adequem às suas necessidades.

Opções de Política de Colocação

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

Etiquetas de agrupamento de membros

Podes rotular o MemberCluster recurso no cluster hub como qualquer recurso Kubernetes.

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

Propriedades do cluster

Use as seguintes propriedades como parte das políticas de colocação.

• As unidades de recurso Kubernetes representam propriedades da CPU e da memória. Para mais informações, consulte Unidades de Recursos no Kubernetes.

• As propriedades de custo são valores decimais que representam um custo por hora, em dólares dos EUA, para a computação do Azure utilizada pelos nós no cluster. O custo baseia-se nos preços públicos do Azure.

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

Quando usar propriedades de cluster num critério de política, especifique:

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

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

  • Gt (Maior que): o valor observado de um cluster da propriedade dada deve ser maior do que o valor na condição antes que ele possa ser selecionado para o posicionamento do recurso.
  • Ge (Maior ou igual a): o valor observado de um cluster da propriedade dada deve ser maior ou igual ao valor na condição antes que ele possa ser escolhido para o posicionamento do recurso.
  • Lt (Menor que): o valor observado de um cluster da propriedade dada deve ser menor do que o valor na condição antes que ele possa ser escolhido para o posicionamento do recurso.
  • Le (Menor ou igual a): o valor observado de um cluster da propriedade dada deve ser menor ou igual ao valor na condição antes que ele possa ser selecionado para o posicionamento do recurso.
  • Eq (Igual a): o valor observado de um cluster da propriedade dada deve ser igual ao valor na condição antes que ele possa ser escolhido para o posicionamento do recurso.
  • Ne (Não igual a): o valor observado de um cluster da propriedade dada não pode ser igual ao valor na condição antes de poder ser escolhido para colocação de recursos.

  Se você usar o operador Gt, Ge, , Lt, LeEq, ou , a Nelista de valores na condição deve ter exatamente um valor.

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

Fleet avalia cada cluster com base nas propriedades que especifica na condição. Se um cluster não cumprir as condições listadas em requiredDuringSchedulingIgnoredDuringExecution, a Frota exclui o cluster da colocação de recursos.

Veja um exemplo de política de posicionamento 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 usa preferredDuringSchedulingIgnoredDuringExecution, um classificador de propriedades classifica todos os clusters da frota com base nos seus valores, numa ordem crescente ou decrescente. Os pesos usados para a encomenda são calculados com base no valor que especifica.

Um classificador de propriedades consiste em:

• Nome: Nome da propriedade do cluster.
• Ordem de classificação: A ordem de classificação pode ser Ascending ou Descending. Quando se usa Ascending a ordem, preferem-se agrupamentos de membros com valores observados mais baixos. Quando se usa Descending a ordem, preferem-se agrupamentos de membros com valor observado mais elevado.

Para mais informações, consulte a documentação da KubeFleet sobre agendamento baseado em propriedades.

Configurando a estratégia de distribuição

A colocação de recursos do Gestor de Frotas utiliza uma estratégia padrão RollingUpdate para controlar como os recursos são distribuídos pelos clusters membros.

No exemplo seguinte, a implantação é efetuada em cada cluster membro sequencialmente, 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 estado de implementação é considerado bem-sucedido se todos os recursos forem corretamente aplicados ao cluster. Este estado não encadeia o estado dos recursos filhos, por isso não confirma que os pods criados num cluster membro por uma implementação ficam prontos.

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

Utilização de tolerâncias

Podes contaminar clusters membros tal como contaminas nós num cluster.

A colocação de recursos suporta o uso de tolerâncias onde 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, tal como NoSchedule.
• operator: O operador da tolerância, como Exists ou Equal.

Cada tolerância é usada para tolerar uma ou mais contaminações específicas aplicadas num MemberCluster. Uma vez que todas as contaminações sejam toleradas, o Gestor de Frota pode distribuir 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.

Utilização de recursos de envelope

O cluster hub do Fleet Manager é também um cluster Kubernetes. Primeiro aplicas qualquer recurso que queiras distribuir ao cluster do hub. Esta abordagem pode conduzir a:

1. Efeitos secundários não intencionais: ValidatingWebhookConfigurations, MutatingWebhookConfigurations ou Admission Controllers tornam-se ativos no hub cluster, podendo intercetar e afetar as operações do hub cluster.

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

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

Para evitar efeitos secundários desnecessários, o Fleet Manager disponibiliza recursos de envelope personalizados (ClusterResourceEnvelope e ResourceEnvelope) para envolver objetos e evitar estes potenciais problemas.

Aplica-se o recurso envelope ao cluster hub, mas os recursos que contém são extraídos e aplicados quando chegam aos clusters membros.

Para obter mais informações, consulte a documentação sobre objetos de envelope.

Determinar o estado do seu posicionamento

A colocação de recursos do Fleet Manager oferece duas formas de visualizar o estado, dependendo do nível de acesso ao cluster do seu 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 mudança de posicionamento

O agendador do Gestor de Frota prioriza a estabilidade das colocações de recursos existentes. Esta prioridade limita o número de alterações que removem e reagendam um recurso.

Os cenários a seguir podem desencadear alterações de posicionamento:

• Alterações na política de colocação no processo de colocação de recursos (ClusterResourcePlacement ou ResourcePlacement) podem levar à remoção e reprogramação de um recurso.
  • As operações de expansão horizontal (aumentar numberOfClusters sem outras alterações) colocam as cargas de trabalho apenas em novos clusters e não afetam as alocações existentes.
• Alterações no agrupamento de membros, incluindo:
  • Um novo grupo de membros se torna elegível e cumpre a política de colocação, por exemplo, uma PickAll política.
  • Remoção de um agrupamento de membros 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 num posicionamento de recurso faz com que o Gestor de Frotas implemente gradualmente os placements existentes, mas não desencadeia o reescalonamento (ou seja, a alteração dos clusters escolhidos) do recurso.

Trabalhar em conjunto com ResourcePlacement e ClusterResourcePlacement

Embora ClusterResourcePlacement assuma que os namespaces representam os limites das aplicações, os padrões de utilização no mundo real são frequentemente mais complexos. As organizações usam frequentemente espaços de nomes como limites de equipa em vez de limites de aplicação, levando a vários desafios que ResourcePlacement abordam diretamente:

Espaços de nomes multi-aplicação: Em muitas organizações, um único espaço de nomes contém múltiplas aplicações independentes pertencentes à mesma equipa. Estas aplicações podem ter:

• Requisitos de ciclo de vida diferentes (uma aplicação pode precisar de atualizações frequentes enquanto outra permanece estável).
• Diferentes necessidades de colocação de clusters (desenvolvimento vs. aplicações de produção).
• Escalabilidade independente e requisitos de recursos.
• Requisitos separados de conformidade ou governação.

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

• Empregos em IA: As cargas de trabalho de aprendizagem automática consistem frequentemente em trabalhos de curta duração e que consomem muitos recursos, que precisam de ser agendados com base na disponibilidade de recursos do cluster, da GPU ou da localização dos dados.
• Cargas de trabalho por lote: Diferentes trabalhos em lote dentro do mesmo espaço de nomes podem ter como alvo diferentes tipos de cluster com base nos requisitos computacionais.

Controlo completo da equipa de aplicação: ResourcePlacement proporciona às equipas de aplicação controlo direto sobre a sua colocação de recursos sem necessidade de intervenção da equipa da plataforma:

• Operações de autoatendimento: As equipas podem gerir as suas próprias estratégias de distribuição de recursos.
• Ciclos de implementação independentes: Diferentes aplicações dentro de um namespace podem ter calendários de implementação independentes.
• Capacidades de sobreposição granular: As equipas podem personalizar configurações de recursos por cluster sem afetar outras aplicações no namespace.

Esta abordagem detalhada garante que ResourcePlacement se pode adaptar a diversas estruturas organizacionais e padrões de carga de trabalho, mantendo a simplicidade e o poder do quadro de agendamento da frota.

Principais diferenças entre ResourcePlacement e ClusterResourcePlacement

A tabela seguinte destaca as principais diferenças entre ResourcePlacement e ClusterResourcePlacement:

Ambos ResourcePlacement e ClusterResourcePlacement partilham as mesmas capacidades essenciais para todos os outros aspetos não listados na tabela de diferenças.

Exemplo de cenário usando ResourcePlacement e ClusterResourcePlacement

ResourcePlacement trabalha com ClusterResourcePlacement (CRP) para fornecer uma solução completa de gestão de recursos multicluster. Compreender esta relação é crucial para uma gestão eficaz da frota.

Fluxo de trabalho típico:

1. Administradores da plataforma: Utilize ClusterResourcePlacement para implementar namespaces em toda a frota.
2. Equipas de aplicação: Usar ResourcePlacement para gerir recursos específicos dentro desses namespaces estabelecidos.

Os exemplos seguintes 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.

Equipa de aplicação: Gerir recursos específicos dentro do namespace utilizando 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

Boas práticas para ResourcePlacement e ClusterResourcePlacement

Quando usar ResourcePlacement com ClusterResourcePlacement, siga estas melhores práticas:

• Estabelecer primeiro os namespaces: Implemente sempre namespaces através do CRP antes de criar ResourcePlacement objetos.
• Monitorizar dependências: Utilize a monitorização de frota para garantir que os CRPs a nível de namespace estão saudáveis antes de implementar RPs dependentes.
• Coordenar políticas: Alinhar as políticas de colocação de CRP e RP de modo a evitar conflitos. Por exemplo, se o CRP colocar o namespace nos clusters A, B e C, o RP pode direcionar qualquer subconjunto desses clusters.
• Limites da equipa: Use CRP para recursos geridos pela plataforma (namespaces, RBAC) e RP para recursos geridos pela aplicação (configurações de app, segredos).

Esta abordagem coordenada garante a ResourcePlacement flexibilidade de que as equipas necessitam, mantendo a infraestrutura fundamental gerida pelos operadores da plataforma.

Seleção, colocação e implementação de recursos

ResourcePlacement Usa os mesmos padrões de colocação que ClusterResourcePlacement:

• Política de colocação: PickAll, PickFixed, e PickN as políticas funcionam de forma idêntica para ambas as APIs.
• Estratégia de implementação: Controlar como as atualizações se propagam entre clusters com os mesmos mecanismos de atualizações contínuas.
• Estado e observabilidade: Monitorize o progresso da implementação utilizando kubectl describe resourceplacement <name> -n <namespace>.
• Funcionalidades avançadas: Utilizar tolerâncias, sobreposições de recursos, restrições de dispersão de topologia e regras de afinidade.

A principal diferença está no âmbito da seleção de recursos . Embora ClusterResourcePlacement normalmente selecione espaços de nomes inteiros e os seus conteúdos, ResourcePlacement proporciona controlo detalhado sobre recursos individuais com âmbito de espaço de nomes.

:::zona-end

Passos seguintes

• Utilize a colocação de recursos do Fleet Manager para distribuir cargas de trabalho em vários clusters.
• Usar o ResourcePlacement para implementar recursos com âmbito de namespace.
• Posicionamento inteligente de recursos do Kubernetes entre clusters com base nas propriedades dos clusters membros.
• Controlar a expulsão e as interrupções na alocação de recursos.
• Definir uma estratégia de lançamento para a colocação de recursos.
• Perguntas Frequentes sobre colocação de recursos do Gestor de Frotas.