Container Service for Kubernetes:Dynamic distribution and descheduling

Prérequis

Avant de commencer, assurez-vous d'avoir :

• Activé Fleet management

• Une instance Fleet avec plusieurs clusters associés

• Accordé l'autorisation AliyunAdcpFullAccess à votre utilisateur RAM

• Installé l'outil de ligne de commande AMC

Étape 1 : Créer une application dans la Fleet

1. Créez un fichier nommé web-demo.yaml contenant le code suivant :

   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

2. Déployez l'application :

   kubectl apply -f web-demo.yaml

Étape 2 : Créer une politique de répartition

1. Créez une politique de répartition dynamique basée sur les pondérations. En définissant dynamicWeight: AvailableReplicas, vous indiquez à la Fleet d'ajuster automatiquement les ratios de répartition des répliques en fonction des ressources disponibles sur tous les nœuds de chaque cluster associé.

   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

2. Vérifiez l'état de répartition de l'application :

   kubectl amc get deploy web-demo -M

   Le résultat attendu est similaire à ce qui suit (les résultats varient selon les ressources disponibles dans chaque cluster associé) :

   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

Étape 3 : Vérifier le désordonnancement

Simulez un scénario où des ressources insuffisantes rendent les répliques non planifiables en appliquant un « taint » à tous les nœuds d'un cluster, puis en redémarrant la charge de travail.

1. Appliquez le taint NoSchedule à tous les nœuds du Cluster1 :

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

2. Redémarrez la charge de travail. Comme tous les nœuds du Cluster1 sont marqués par un taint, les pods redémarrés ne peuvent pas être planifiés et passent à l'état Pending.

   kubectl --kubeconfig=<cluster1.config> rollout restart deploy web-demo

3. Confirmez que les pods du Cluster1 sont à l'état Pending :

   kubectl --kubeconfig=<cluster1.config> get pods

   Les pods apparaissent avec l'état Pending. Ce comportement est normal : attendez que le désordonnanceur détecte ces pods et les replanifie. La Fleet vérifie toutes les 2 minutes la présence de répliques non planifiables et déclenche une replanification après qu'elles soient restées non planifiables pendant plus de 30 secondes.

4. Après environ 3 minutes, vérifiez les résultats de la planification :

   kubectl amc get deploy web-demo -M

   Résultat attendu :

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

   Toutes les répliques du Cluster1 ont été replanifiées vers le Cluster2.