Distribuição dinâmica e desescalonamento - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

A disponibilidade de recursos do cluster muda ao longo do tempo. Como as decisões de alocação do agendador se baseiam em um snapshot pontual dos recursos, réplicas agendadas com sucesso podem tornar-se não agendáveis posteriormente devido a falhas em nós ou exaustão de recursos. Por padrão, o ACK One Fleet gerencia essa situação automaticamente: distribui réplicas de Deployment, StatefulSet e Job entre os clusters associados usando PropagationPolicy, verifica a existência de réplicas não agendáveis a cada 2 minutos e aciona o desescalonamento caso alguma réplica permaneça nessa condição por mais de 30 segundos.

Pré-requisitos

Antes de começar, verifique se você possui:

O recurso de Fleet management ativado
Uma instância de Fleet com vários clusters associados
A permissão AliyunAdcpFullAccess concedida ao seu usuário RAM
A ferramenta de linha de comando AMC instalada

Etapa 1: Crie uma aplicação no Fleet

Crie um arquivo chamado web-demo.yaml com o seguinte conteúdo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-demo
  template:
    metadata:
      labels:
        app: web-demo
    spec:
      containers:
      - name: nginx
        image: registry-cn-hangzhou.ack.aliyuncs.com/acs/web-demo:0.5.0
        ports:
        - containerPort: 80

Implante a aplicação:
```
kubectl apply -f web-demo.yaml
```

Etapa 2: Crie uma política de distribuição

Defina uma política de distribuição baseada em pesos dinâmicos. Ao configurar dynamicWeight: AvailableReplicas, você instrui o Fleet a ajustar automaticamente as proporções de alocação de réplicas conforme os recursos disponíveis em todos os nós de cada cluster associado.

apiVersion: policy.one.alibabacloud.com/v1alpha1
kind: PropagationPolicy
metadata:
  name: web-demo
spec:
  resourceSelectors:
  - apiVersion: apps/v1
    kind: Deployment
    name: web-demo
  placement:
    clusterAffinity:
      clusterNames:
      - ${cluster1-id} # Your cluster ID.
      - ${cluster2-id}
    replicaScheduling:
      replicaSchedulingType: Divided
      replicaDivisionPreference: Weighted
      weightPreference:
        dynamicWeight: AvailableReplicas

Verifique o status de distribuição da aplicação:

kubectl amc get deploy web-demo -M

A saída esperada é semelhante à seguinte (os resultados variam conforme os recursos disponíveis em cada cluster associado):

NAME       CLUSTER      READY   UP-TO-DATE   AVAILABLE   AGE   ADOPTION
web-demo   cxxxxxxxx1   2/2     2            2           11s   Y
web-demo   cxxxxxxxx2   3/3     3            3           11s   Y

Etapa 3: Verifique o desescalonamento

Simule um cenário de insuficiência de recursos que torne as réplicas não agendáveis. Para isso, aplique taints em todos os nós de um cluster e reinicie a carga de trabalho.

Aplique um taint NoSchedule em todos os nós do Cluster1:

kubectl --kubeconfig=<cluster1.config> taint nodes foo=bar:NoSchedule --all=true

Reinicie a carga de trabalho. Como todos os nós do Cluster1 possuem taints, os pods reiniciados não podem ser agendados e entram no estado Pending.
```
kubectl --kubeconfig=<cluster1.config> rollout restart deploy web-demo
```
Confirme se os pods no Cluster1 estão no estado Pending:
```
kubectl --kubeconfig=<cluster1.config> get pods
```
Os pods aparecerão como Pending. Esse comportamento é esperado — aguarde o desescalonador detectá-los e reagendá-los. O Fleet verifica réplicas não agendáveis a cada 2 minutos e aciona o reagendamento após elas permanecerem nessa condição por mais de 30 segundos.

Após cerca de 3 minutos, consulte os resultados do agendamento:

kubectl amc get deploy web-demo -M

Saída esperada:

NAME       CLUSTER      READY   UP-TO-DATE   AVAILABLE   AGE   ADOPTION
web-demo   cxxxxxxxx2   5/5     5            5           11s   Y

Todas as réplicas do Cluster1 foram reagendadas para o Cluster2.