Apresentação da API ClusterResourcePlacement

Este artigo descreve a API ClusterResourcePlacement, que permite o posicionamento de recursos de clusters de hub para clusters membros usando o Gerenciador de Frota do Kubernetes do Azure.

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 Manager fornece propagação de recursos do Kubernetes para permitir o gerenciamento em escala dos recursos do Kubernetes. Com o Fleet Manager, você pode criar recursos do Kubernetes em um cluster de hub gerenciado pelo Fleet e propagá-los para clusters de membros selecionados por meio dos Recursos personalizados do Kubernetes: MemberCluster e ClusterResourcePlacement.

O Fleet Manager suporta esses recursos personalizados com base no projeto CNCF KubeFleet, sobre o qual você pode ler mais no site de documentação do KubeFleet.

Visão geral da API ClusterResourcePlacement

Um ClusterResourcePlacement objeto é usado para informar ao agendador de frota como colocar um determinado conjunto de objetos com escopo de cluster do cluster de hub de frota 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 ClusterResourcePlacement, você pode:

• Selecione quais recursos propagar. Esses podem ser recursos do Kubernetes com escopo de cluster definidos usando referências GVK (Kubernetes Group Version Kind) ou um namespace, que propaga o namespace e todos os seus recursos.
• Especifique políticas de posicionamento para selecionar clusters de membros. Essas políticas podem selecionar explicitamente clusters por nomes ou selecionar dinamicamente clusters com base em rótulos e propriedades de cluster.
• 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.

Tipos de colocação

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

• PickFixed coloca o recurso em uma lista específica de clusters de membros por nome.
• PickAll coloca o recurso em todos os clusters de membros ou em todos os clusters de membros que atendem a um critério. Essa política é útil para colocar cargas de trabalho de infraestrutura, como monitoramento de cluster ou aplicativos de relatórios.
• O 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.

Tipo de posicionamento PickFixed

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 pelo nome.

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

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

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

Tipo de posicionamento PickAll

Você pode usar um PickAll tipo de posicionamento para implantar uma carga de trabalho em todos os clusters membros da frota ou em um subconjunto de clusters que correspondam aos critérios definidos.

Ao criar esse tipo de posicionamento, os seguintes tipos de afinidade de cluster podem ser especificados:

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

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

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

Tipo de posicionamento PickN

O PickN tipo 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.

Ao criar esse tipo de posicionamento, os seguintes tipos de afinidade de cluster podem ser especificados:

• requiredDuringSchedulingIgnoredDuringExecution: como essa política é necessária durante o agendamento, ela filtra os clusters com base nos critérios especificados.
• preferredDuringSchedulingIgnoredDuringExecution: como 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, e as afinidades preferenciais fornecem a ordenação de clusters válidos.

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.

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/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pickn-01
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickN
    numberOfClusters: 3
    affinity:
        clusterAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
              weight: 20
              preference:
              - labelSelector:
                  matchLabels:
                    critical-level: 1
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                      critical-allowed: "true"

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

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, use essas restrições para dividir posicionamentos entre regiões ou atualizar 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/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pickn-02
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickN
    topologySpreadConstraints:
    - maxSkew: 2
      topologyKey: region
      whenUnsatisfiable: DoNotSchedule
    - maxSkew: 2
      topologyKey: updateDay
      whenUnsatisfiable: ScheduleAnyway

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

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

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

Domínio de intervenção	PickFixed	Escolher tudo	PickN
placementType	✅	✅	✅
affinity	❌	✅	✅
clusterNames	✅	❌	❌
numberOfClusters	❌	❌	✅
topologySpreadConstraints	❌	❌	✅

Seleção de clusters com base em rótulos e propriedades

Rótulos e propriedades disponíveis para selecionar clusters

Ao usar os tipos de colocação PickN e PickAll, pode utilizar os seguintes rótulos e propriedades como parte das suas políticas.

Etiquetas

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

Etiqueta	Descrição
fleet.azure.com/location	Região do Azure do agrupamento (westus)
fleet.azure.com/resource-group	Grupo de Recursos do Azure do cluster (rg_prodapps_01)
fleet.azure.com/subscription-id	Identificador de Assinatura do Azure no qual o cluster reside. Formatado como UUID/GUID.

Também pode usar qualquer rótulo personalizado que aplicar aos seus clusters.

Propriedades

As seguintes propriedades estão disponíveis para uso como parte das políticas de posicionamento.

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

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

Nome de Propriedade	Descrição
kubernetes-fleet.io/node-count	Nodos disponíveis no cluster de membros.
resources.kubernetes-fleet.io/total-cpu	Total de unidades de recursos da CPU do cluster.
resources.kubernetes-fleet.io/allocatable-cpu	Unidades de recursos de CPU alocáveis do cluster.
resources.kubernetes-fleet.io/available-cpu	Unidades de recursos de CPU disponíveis do cluster.
resources.kubernetes-fleet.io/total-memory	Unidade de recurso de memória total do cluster.
resources.kubernetes-fleet.io/allocatable-memory	Unidades de recursos de memória alocáveis do cluster.
resources.kubernetes-fleet.io/available-memory	Unidades de recursos de memória disponíveis do cluster.
kubernetes.azure.com/custo-por-núcleo-de-CPU	O custo por núcleo de CPU do cluster.
kubernetes.azure.com/per-gb-memory-cost	O custo da memória por cada GiB do cluster.

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

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

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

• Operador: um operador usado para expressar a condição entre a restrição/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 deve ser igual ao valor na condição antes de poder ser escolhido para o posicionamento do recurso.

  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.

A Fleet avalia cada grupo com base nas propriedades especificadas na condição. O não cumprimento das condições listadas em requiredDuringSchedulingIgnoredDuringExecution exclui este cluster membro da colocação de recursos.

Nota

Se um cluster membro não tiver a propriedade especificada na condição, falhará automaticamente essa condição.

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
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - propertySelector:
                    matchExpressions:
                    - name: "kubernetes-fleet.io/node-count"
                      operator: Ge
                      values:
                      - "5"

Como funciona a classificação de propriedades

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

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 Ascending a ordem é usada, agrupamentos de membros com valores observados mais baixos são preferidos. Quando Descending a ordem é usada, agrupamentos de membros com maior valor observado são preferidos.

Ordem decrescente

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

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

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

Agrupamento	Capacidade de CPU disponível
cluster-a	100
cluster-b	20
cluster-c	10

Neste caso, o classificador calcula os seguintes pesos:

Agrupamento	Capacidade de CPU disponível	Cálculo	Peso
cluster-a	100	(100 - 10) / (100 - 10)	100%
cluster-b	20	(20 - 10) / (100 - 10)	11.11%
cluster-c	10	(10 - 10) / (100 - 10)	0%

Ordem crescente

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

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

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

Agrupamento	Custo de núcleo por CPU
cluster-a	1
cluster-b	0.2
cluster-c	0.1

Neste caso, o classificador calcula os seguintes pesos:

Agrupamento	Custo de núcleo por CPU	Cálculo	Peso
cluster-a	1	1 - ((1 - 0.1) / (1 - 0.1))	0%
cluster-b	0.2	1 - ((0.2 - 0.1) / (1 - 0.1))	88,89%
cluster-c	0.1	1 - (0.1 - 0.1) / (1 - 0.1)	100%

Capturas de recursos

O Gestor de Frotas mantém um histórico das 10 políticas de agendamento de posicionamento mais recentemente usadas, juntamente com as versões de recursos que o posicionamento selecionou.

Esses snapshots podem ser usados com estratégias de distribuição em estágios para controlar a versão implantada.

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

Encapsulando recursos usando objetos de envelope

Ao propagar recursos para clusters membros seguindo o modelo hub and spoke, é importante entender que o cluster de hub em si também é um cluster Kubernetes. Qualquer recurso que você queira propagar primeiro será aplicado diretamente ao cluster de hub, o que pode levar a alguns efeitos colaterais potenciais:

1. Efeitos colaterais não intencionais: Recursos como ValidatingWebhookConfigurations, MutatingWebhookConfigurations, ou Admission Controllers ficariam ativos no cluster de hub, potencialmente intercetando e afetando as operações de cluster de hub.

2. Riscos de segurança: os recursos RBAC (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings) destinados a clusters membros podem conceder permissões não intencionais no cluster de hub.

3. Limitações de recursos: Os ResourceQuotas, FlowSchema ou LimitRanges definidos para os clusters membros entrariam em vigor no cluster de hub. Embora esses efeitos colaterais geralmente não causem danos, pode haver casos em que se queira evitar essas restrições no cluster central.

Para evitar esses efeitos colaterais desnecessários, o gerenciador de frota do Kubernetes do Azure fornece recursos personalizados para encapsular objetos para resolver esses problemas. O objeto envelope em si é aplicado ao hub, mas os recursos que ele contém só são extraídos e aplicados quando atingem os clusters membros. Dessa forma, pode-se definir recursos que devem ser propagados sem realmente implantar seu conteúdo no cluster de hub. Para obter mais informações, consulte a documentação sobre objetos de envelope.

Usando tolerações

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, tal 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 de criado.

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

Configurando a estratégia de distribuição

O Fleet usa uma estratégia de atualização contínua para controlar como as atualizações são implementadas em clusters.

No exemplo a seguir, o agendador de frota distribui atualizações para cada cluster sequencialmente, aguardando no mínimo unavailablePeriodSeconds entre clusters. O status de implementação é considerado bem-sucedido se todos os recursos forem aplicados corretamente ao cluster. A verificação do estado da implementação não se propaga para os recursos filho, portanto, por exemplo, não confirma se os pods criados por uma implantação se tornam prontos.

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

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

Determinar o estado do seu posicionamento

O Agendador de frota atualiza os detalhes e o status das decisões de posicionamento no ClusterResourcePlacement objeto. 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 estado de posicionamento para cada membro do cluster, que mostra o estado da implantação em cada 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 clusters aks-member-1 e aks-member-2.

Você pode exibir essas informações usando o kubectl describe crp <name> comando.

kubectl describe crp crp-1

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

Gatilhos de mudança 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 do objeto podem desencadear a remoção e o reagendamento de um volume 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 no grupo, incluindo:
  • Um novo cluster que se torna elegível pode desencadear o posicionamento se o novo cluster atender à política de posicionamento, por exemplo, uma política PickAll.
  • Um cluster com um posicionamento é removido da frota. Dependendo da política, o agendador tenta colocar todas as cargas de trabalho afetadas em clusters restantes sem afetar os posicionamentos existentes.

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

Próximos passos

• Use o posicionamento de recursos de cluster para implantar cargas de trabalho em vários clusters.
• Posicionamento inteligente de recursos do Kubernetes entre clusters com base nas propriedades dos clusters membros.
• Controlando o desalojamento e a perturbação para o posicionamento de recursos do cluster.
• Definição de uma estratégia de distribuição para alocação de recursos de cluster.
• Perguntas frequentes sobre posicionamento de recursos de cluster.