Distribución dinámica y desprogramación - Container Service for Kubernetes

La disponibilidad de recursos del clúster cambia con el tiempo. Dado que las decisiones de ubicación del programador se basan en una instantánea puntual de los recursos, las réplicas programadas correctamente pueden volverse no programables si hay fallos en los nodos o se agotan los recursos. De forma predeterminada, ACK One Fleet gestiona esta situación automáticamente: distribuye las réplicas de Deployment, StatefulSet y Job entre los clústeres asociados mediante PropagationPolicy, comprueba cada 2 minutos si existen réplicas no programables y activa la desprogramación cuando alguna réplica permanece en ese estado durante más de 30 segundos.

Requisitos previos

Antes de empezar, asegúrese de contar con lo siguiente:

Fleet management habilitado
Una instancia de Fleet con multiple associated clusters
El permiso AliyunAdcpFullAccess permission otorgado a su usuario de RAM
La herramienta de línea de comandos AMC instalada

Paso 1: Crear una aplicación en el Fleet

Cree un archivo llamado web-demo.yaml con el siguiente contenido:

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

Despliegue la aplicación:
```
kubectl apply -f web-demo.yaml
```

Paso 2: Crear una política de distribución

Cree una distribution policy basada en pesos dinámicos. Al establecer dynamicWeight: AvailableReplicas, se indica al Fleet que ajuste automáticamente las proporciones de asignación de réplicas según los recursos disponibles en todos los nodos de cada clúster asociado.

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

Compruebe el estado de distribución de la aplicación:

kubectl amc get deploy web-demo -M

El resultado esperado es similar al siguiente (los valores varían según los recursos disponibles en cada clúster asociado):

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

Paso 3: Comprobar la desprogramación

Simule un escenario donde la falta de recursos impida la programación de réplicas. Para ello, aplique un taint a todos los nodos de un clúster y reinicie la carga de trabajo.

Aplique un taint NoSchedule a todos los nodos del Cluster1:

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

Reinicie la carga de trabajo. Como todos los nodos del Cluster1 tienen un taint, los pods reiniciados no se pueden programar y entran en estado Pending.
```
kubectl --kubeconfig=<cluster1.config> rollout restart deploy web-demo
```
Confirme que los pods del Cluster1 están en estado Pending:
```
kubectl --kubeconfig=<cluster1.config> get pods
```
Los pods aparecen como Pending. Este comportamiento es esperado; espere a que el desprogramador los detecte y reasigne. El Fleet comprueba cada 2 minutos si hay réplicas no programables y activa la reprogramación tras permanecer en ese estado más de 30 segundos.

Después de aproximadamente 3 minutos, revise los resultados de la programación:

kubectl amc get deploy web-demo -M

Resultado esperado:

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

Todas las réplicas del Cluster1 se han reprogramado en el Cluster2.