Container Service for Kubernetes:FAQ sur les nœuds et les pools de nœuds

Sommaire

Pour diagnostiquer et résoudre les problèmes liés aux nœuds, consultez Dépanner les nœuds anormaux .

Utilisation d'instances spot dans un pool de nœuds

Plusieurs types d'instances ECS par pool de nœuds

Oui, c'est possible. Nous recommandons de configurer votre pool de nœuds avec plusieurs types d'instances ECS afin d'éviter les échecs de mise à l'échelle horizontale dus à l'indisponibilité d'un type d'instance ou à des ruptures de stock. Pour ce faire, configurez plusieurs vSwitches dans plusieurs zones de disponibilité, sélectionnez plusieurs types d'instances ECS ou spécifiez des types d'instances en fonction des vCPU et de la mémoire. Une fois le pool de nœuds créé, ajoutez des types d'instances selon les recommandations de niveau d'évolutivité dans la console ou consultez le niveau d'évolutivité d'un pool de nœuds.

Pour obtenir la liste des types d'instances pris en charge et les recommandations de configuration des nœuds, consultez Recommandations de configuration des types d'instances ECS .

Nombre maximal de pods par nœud

Le calcul du nombre maximal de pods par nœud dépend du plugin réseau du cluster. Pour plus d'informations, consultez Nombre maximal de pods par nœud.

• Terway : Le nombre maximal de pods par nœud correspond à la somme des pods sur le réseau de conteneurs et sur le réseau hôte.

• Flannel : La limite correspond à la valeur Number of Pods per Node spécifiée lors de la création du cluster.

Consultez le nombre maximal de pods par nœud, également appelé Pod Quota , sur la page Nodes Nodes de la console.

Vous ne pouvez pas modifier le nombre maximal de pods par nœud après la création d'un cluster. Si un nœud atteint cette limite, effectuez une mise à l'échelle horizontale de vos nœuds pour augmenter la capacité en pods. Pour plus d'informations, consultez Ajuster les pods disponibles sur un nœud.

Ajuster la capacité en pods des nœuds

Le plugin réseau détermine le nombre maximal de pods qu'un nœud worker peut prendre en charge, une limite généralement non modifiable. En mode Terway, cette limite dépend du nombre d'interfaces réseau élastiques (ENI) fournies par l'instance ECS. En mode Flannel, la limite est définie lors de la création du cluster et ne peut plus être modifiée ultérieurement. Si vous atteignez la limite de pods, nous recommandons d'ajouter des nœuds à votre pool de nœuds afin d'augmenter le nombre total de pods disponibles.

Pour plus d'informations, consultez Augmenter le nombre maximal de pods dans un cluster.

Modifier la configuration des nœuds

• Pour garantir la stabilité du service, certains paramètres — notamment ceux liés à la disponibilité et au réseau — sont immuables après la création d'un pool de nœuds. Par exemple, vous ne pouvez pas modifier l'environnement d'exécution de conteneurs ni le VPC auquel appartient un nœud.

• Concernant les paramètres modifiables, les changements apportés à la configuration du pool de nœuds s'appliquent uniquement aux nouveaux nœuds. Les nœuds existants ne sont pas affectés, sauf si vous utilisez des options spécifiques telles que Update ECS Tags of Existing Nodes ou Update Labels and Taints of Existing Nodes.

Consultez Créer et gérer des pools de nœuds pour plus de détails sur les paramètres modifiables et le moment où les changements prennent effet.

Alternativement, pour appliquer une nouvelle configuration, créez un nouveau pool de nœuds avec la configuration souhaitée. Ensuite, isolez et drainez les nœuds de l'ancien pool de nœuds pour migrer vos charges de travail. Une fois la migration terminée, libérez les instances de l'ancien pool de nœuds. Pour obtenir des instructions, consultez Isoler et drainer des nœuds.

Puis-je désactiver Nœuds attendus ?

Si le Scaling Mode d'un pool de nœuds est défini sur Manual, vous devez configurer les Expected Nodes. Cette fonctionnalité ne peut pas être désactivée.

Pour supprimer un nœud spécifique, consultez Supprimer un nœud. Pour ajouter un nœud spécifique, consultez ajouter un nœud existant. Après avoir supprimé un nœud ou ajouté un nœud existant, la valeur Nœuds attendus se met automatiquement à jour pour refléter le nouveau nombre de nœuds. Aucune modification manuelle n'est nécessaire.

Pools de nœuds avec et sans Nœuds attendus

Le paramètre Nœuds attendus définit la capacité prévue d'un pool de nœuds. Ajustez cette valeur pour effectuer une mise à l'échelle horizontale ou verticale du pool de nœuds. Toutefois, certains pools de nœuds hérités peuvent ne pas avoir cette fonctionnalité activée.

Le tableau suivant décrit la réponse du système aux opérations effectuées sur les pools de nœuds avec et sans la fonctionnalité Nœuds attendus activée.

Migrer des nœuds non gérés vers un pool de nœuds

Dans les anciens clusters ACK créés avant le lancement de la fonctionnalité de pool de nœuds, certains nœuds workers peuvent n'appartenir à aucun pool de nœuds. Pour intégrer ces nœuds non gérés dans une gestion groupée et une maintenance automatisée, migrez-les vers un pool de nœuds : créez un pool de nœuds, supprimez les nœuds non gérés du cluster, puis rajoutez leurs instances ECS au pool de nœuds.

Pour ce faire, créez un nouveau pool de nœuds ou étendez un pool existant, supprimez les nœuds non gérés du cluster, puis ajoutez-les au pool de nœuds cible. Pour plus d'informations, consultez Migrer des nœuds non gérés vers un pool de nœuds.

Remplacer l'image système d'un pool de nœuds

Remplacez le système d'exploitation d'un pool de nœuds, par exemple pour migrer d'une version arrivée en fin de vie (EOL) vers une version prise en charge. Avant de commencer, consultez les Notes de version des images système pour connaître les systèmes d'exploitation pris en charge, les versions d'image les plus récentes et les limites d'utilisation.

Consultez Remplacer le système d'exploitation d'un pool de nœuds pour obtenir des instructions détaillées et des considérations importantes.

Libérer une instance ECS spécifique

Pour libérer une instance ECS spécifique, supprimez le nœud. Cette action met automatiquement à jour le nombre de nœuds attendus. N'essayez pas de libérer une instance spécifique en modifiant le nombre de nœuds attendus, car cela déclenche une réduction d'échelle aléatoire et ne garantit pas la suppression de l'instance souhaitée.

Comment résoudre les délais d'expiration lors de l'ajout de nœuds ?

Vérifiez la connectivité réseau entre le nœud et le API Server CLB. Assurez-vous d'abord que le groupe de sécurité répond aux exigences. Pour les limitations des groupes de sécurité lors de l'ajout d'un nœud existant, consultez Limitations. Pour d'autres problèmes de connectivité réseau, consultez FAQ sur la gestion réseau.

Modifier les noms d'hôte des nœuds workers

1. Supprimez le nœud. Pour plus d'informations, consultez Supprimer un nœud.

2. Rajoutez le nœud supprimé au pool de nœuds. Pour plus d'informations, consultez Ajouter manuellement des nœuds.

   Le nœud est alors automatiquement renommé selon la règle de nommage du pool de nœuds.

Mettre à niveau manuellement le noyau d'un nœud GPU

1. Obtenir le kubeconfig d'un cluster et se connecter avec kubectl.

2. Isolez le nœud GPU (par exemple, le nœud cn-beijing.i-2ze19qyi8votgjz*).

   kubectl cordon cn-beijing.i-2ze19qyi8votgjz*****
   
   node/cn-beijing.i-2ze19qyi8votgjz***** cordoned

3. Drainez le nœud GPU sur lequel vous souhaitez mettre à niveau le pilote.

   kubectl drain cn-beijing.i-2ze19qyi8votgjz***** --grace-period=120 --ignore-daemonsets=true
   
   node/cn-beijing.i-2ze19qyi8votgjz***** cordoned
   WARNING: Ignoring DaemonSet-managed pods: flexvolume-9scb4, kube-flannel-ds-r2qmh, kube-proxy-worker-l62sf, logtail-ds-f9vbg
   pod/nginx-ingress-controller-78d847fb96-***** evicted

4. Désinstallez le pilote NVIDIA actuel.

   Remarque

   Le package de pilote désinstallé à cette étape est la version 384.111. Si votre version de pilote n'est pas 384.111, téléchargez le programme d'installation du pilote correspondant sur le site officiel NVIDIA et remplacez 384.111 à cette étape par votre version réelle.

   1. Connectez-vous au nœud GPU et exécutez nvidia-smi pour vérifier la version du pilote.

      sudo nvidia-smi -a | grep 'Driver Version'
      Driver Version                      : 384.111

   2. Téléchargez le programme d'installation du pilote NVIDIA.

      cd /tmp/
      sudo curl -O https://cn.download.nvidia.cn/tesla/384.111/NVIDIA-Linux-x86_64-384.111.run

      Remarque

      Utilisez le programme d'installation pour désinstaller le pilote NVIDIA.

   3. Désinstallez le pilote NVIDIA actuel.

      sudo chmod u+x NVIDIA-Linux-x86_64-384.111.run
      sudo sh ./NVIDIA-Linux-x86_64-384.111.run --uninstall -a -s -q

5. Mettez à niveau le noyau.

   Suivez les procédures de votre système d'exploitation pour mettre à niveau le noyau.

6. Redémarrez l'instance GPU.

   sudo reboot

7. Connectez-vous à nouveau au nœud GPU et installez le kernel devel correspondant.

   sudo yum install -y kernel-devel-$(uname -r)

8. Accédez au site officiel NVIDIA pour télécharger et installer le pilote NVIDIA requis. Cette rubrique utilise la version 410.79 comme exemple.

   # Change to the /tmp directory.
   cd /tmp/
   
   # Download the NVIDIA driver installer.
   sudo curl -O https://cn.download.nvidia.cn/tesla/410.79/NVIDIA-Linux-x86_64-410.79.run
   
   # Add executable permissions to the installer.
   sudo chmod u+x NVIDIA-Linux-x86_64-410.79.run
   
   # Run the installer in silent mode.
   sudo sh ./NVIDIA-Linux-x86_64-410.79.run -a -s -q
   
   # Warm up the GPU.
   sudo nvidia-smi -pm 1 || true
   sudo nvidia-smi -acp 0 || true
   sudo nvidia-smi --auto-boost-default=0 || true
   sudo nvidia-smi --auto-boost-permission=0 || true
   sudo nvidia-modprobe -u -c=0 -m || true

9. Vérifiez le fichier /etc/rc.d/rc.local pour confirmer s'il contient la configuration suivante. Sinon, ajoutez-la manuellement.

   sudo nvidia-smi -pm 1 || true
   sudo nvidia-smi -acp 0 || true
   sudo nvidia-smi --auto-boost-default=0 || true
   sudo nvidia-smi --auto-boost-permission=0 || true
   sudo nvidia-modprobe -u -c=0 -m || true

10. Redémarrez kubelet et Docker.

    sudo service kubelet stop
    sudo service docker restart
    sudo service kubelet start

11. Réactivez le nœud GPU pour autoriser à nouveau la planification des pods dessus.

    kubectl uncordon cn-beijing.i-2ze19qyi8votgjz*****
    
    node/cn-beijing.i-2ze19qyi8votgjz***** uncordoned

12. Vérifiez la version du pod du plugin de périphérique sur le nœud GPU.

    kubectl exec -n kube-system -t nvidia-device-plugin-cn-beijing.i-2ze19qyi8votgjz***** nvidia-smi
    Thu Jan 17 00:33:27 2019
    +-----------------------------------------------------------------------------+
    | NVIDIA-SMI 410.79       Driver Version: 410.79       CUDA Version: N/A      |
    |-------------------------------+----------------------+----------------------+
    | GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
    | Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
    |===============================+======================+======================|
    |   0  Tesla P100-PCIE...  On   | 00000000:00:09.0 Off |                    0 |
    | N/A   27C    P0    28W / 250W |      0MiB / 16280MiB |      0%      Default |
    +-------------------------------+----------------------+----------------------+
    
    +-----------------------------------------------------------------------------+
    | Processes:                                                       GPU Memory |
    |  GPU       PID   Type   Process name                             Usage      |
    |=============================================================================|
    |  No running processes found                                                 |
    +-----------------------------------------------------------------------------+

    Remarque

    Si vous exécutez la commande docker ps et constatez qu'aucun conteneur n'est démarré sur le nœud GPU, consultez Résoudre les problèmes de démarrage des conteneurs sur les nœuds GPU.

Résoudre le démarrage des conteneurs sur les nœuds GPU

sudo service kubelet stop
# Redirecting to /bin/systemctl stop kubelet.service
sudo service docker stop
# Redirecting to /bin/systemctl stop docker.service
sudo service docker start
# Redirecting to /bin/systemctl start docker.service
sudo service kubelet start
# Redirecting to /bin/systemctl start kubelet.service

sudo docker ps
# CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

sudo docker info | grep -i cgroup
Cgroup Driver: cgroupfs

Pour résoudre ce problème, changez le Cgroup Driver de Docker en systemd.

1. Sauvegardez /etc/docker/daemon.json, puis exécutez la commande suivante pour mettre à jour /etc/docker/daemon.json.

   sudo cat >/etc/docker/daemon.json <<-EOF
   {
       "default-runtime": "nvidia",
       "runtimes": {
           "nvidia": {
               "path": "/usr/bin/nvidia-container-runtime",
               "runtimeArgs": []
           }
       },
       "exec-opts": ["native.cgroupdriver=systemd"],
       "log-driver": "json-file",
       "log-opts": {
           "max-size": "100m",
           "max-file": "10"
       },
       "oom-score-adjust": -1000,
       "storage-driver": "overlay2",
       "storage-opts":["overlay2.override_kernel_check=true"],
       "live-restore": true
   }
   EOF

2. Redémarrez Docker et kubelet pour appliquer les modifications.

   sudo service kubelet stop
   # Redirecting to /bin/systemctl stop kubelet.service
   sudo service docker restart
   # Redirecting to /bin/systemctl restart docker.service
   sudo service kubelet start
   # Redirecting to /bin/systemctl start kubelet.service

3. Vérifiez que le Cgroup Driver de Docker est défini sur systemd.

   sudo docker info | grep -i cgroup
   Cgroup Driver: systemd

Migrer les pods d'un nœud défaillant

Pour migrer les pods d'application d'un nœud défaillant, marquez le nœud comme non planifiable, puis drainez-le. Ce processus évacue les pods en toute sécurité et les replanifie sur des nœuds sains.

1. Connectez-vous à la console ACK. Sur la page Nodes, localisez le nœud défaillant. Dans la colonne Actions, choisissez More > Drain.

2. Dépannez le nœud défaillant. Pour plus d'informations, consultez Dépanner les problèmes de nœuds.

Politique d'éviction des nœuds lors de défaillances de zone de disponibilité

Lorsqu'un nœud devient non sain, le contrôleur de nœuds lance une éviction. Le taux d'éviction par défaut est de 0,1 nœud par seconde, contrôlé par le paramètre --node-eviction-rate. Cela signifie que les pods sont évacués d'au plus un nœud toutes les 10 secondes.

Cependant, pour un cluster ACK dont les nœuds sont répartis sur plusieurs zones de disponibilité, le contrôleur de nœuds ajuste cette politique en fonction de l'état de santé de chaque zone de disponibilité et de la taille du cluster.

Une zone de disponibilité peut se trouver dans l'un des trois états de santé suivants.

• FullDisruption : La zone de disponibilité ne comporte aucun nœud sain et au moins un nœud non sain.

• PartialDisruption : La zone de disponibilité contient au moins deux nœuds non sains, et le ratio de nœuds non sains par rapport au nombre total de nœuds (calculé comme (unhealthy nodes / (unhealthy nodes + healthy nodes))) dépasse 0,55.

• Normal : La zone de disponibilité ne répond pas aux critères de FullDisruption ou PartialDisruption.

Les clusters sont également classés par taille :

• Grand cluster : Un cluster comptant plus de 50 nœuds.

• Petit cluster : Un cluster comptant 50 nœuds ou moins.

Le contrôleur de nœuds détermine le taux d'éviction en fonction de ces états :

• Si toutes les zones de disponibilité sont dans un état FullDisruption, l'éviction est désactivée pour l'ensemble du cluster.

• Si au moins une zone de disponibilité n'est pas dans un état FullDisruption, le taux d'éviction est déterminé comme suit :

  • Pour une zone de disponibilité dans un état FullDisruption, le taux d'éviction est fixé à la valeur par défaut de 0,1 nœud par seconde, quelle que soit la taille du cluster.

  • Pour une zone de disponibilité dans un état PartialDisruption, le taux d'éviction dépend de la taille du cluster. Dans un grand cluster, le taux est réduit à 0,01 nœud par seconde. Dans un petit cluster, le taux est fixé à 0, ce qui désactive l'éviction.

  • Pour une zone de disponibilité dans un état Normal, le taux d'éviction est fixé à la valeur par défaut de 0,1 nœud par seconde, quelle que soit la taille du cluster.

Pour plus d'informations, consultez Limites de taux d'éviction.

Personnalisation du chemin kubelet

Non. Le chemin kubelet dans un cluster ACK est /var/lib/kubelet et ne peut pas être modifié. Ne modifiez pas ce chemin.

Monter un disque de données dans un répertoire personnalisé

Cette fonctionnalité est actuellement en version canari. Pour activer cette fonctionnalité, ouvrez un ticket. Une fois activée, le système formate et monte automatiquement tout disque de données ajouté au pool de nœuds dans un répertoire spécifié. Le répertoire de montage est soumis aux restrictions suivantes.

• Ne montez pas de disque de données dans les répertoires critiques suivants du système d'exploitation :

  • /

  • /etc

  • /var/run

  • /run

  • /boot

• Ne montez pas de disque de données dans les répertoires suivants utilisés par le système et les environnements d'exécution de conteneurs, ni dans leurs sous-répertoires :

  • /usr

  • /bin

  • /sbin

  • /lib

  • /lib64

  • /ostree

  • /sysroot

  • /proc

  • /sys

  • /dev

  • /var/lib/kubelet

  • /var/lib/docker

  • /var/lib/containerd

  • /var/lib/container

• Chaque disque de données doit avoir un répertoire de montage unique.

• Le répertoire de montage doit être un chemin absolu commençant par /.

• Le répertoire de montage ne doit pas contenir de caractères de retour chariot ou de saut de ligne (\r et \n) ni se terminer par une barre oblique inverse (\).

Modifier les limites de descripteurs de fichiers

Le nombre maximal de descripteurs de fichiers limite le nombre de fichiers pouvant être ouverts simultanément. Les systèmes Alibaba Cloud Linux et CentOS comportent deux niveaux de limites de descripteurs de fichiers :

• Niveau système : Le nombre maximal de fichiers que tous les processus du système peuvent ouvrir simultanément.

• Niveau utilisateur : Le nombre maximal de fichiers que les processus d'un seul utilisateur peuvent ouvrir.

Les environnements de conteneurs ont une limite supplémentaire de descripteurs de fichiers : le nombre maximal de descripteurs de fichiers par processus au sein d'un conteneur.

Modifier la limite de descripteurs de fichiers au niveau système

Pour obtenir des instructions, consultez Personnaliser les paramètres système pour un pool de nœuds.

Modifier la limite de descripteurs de fichiers par processus

1. Connectez-vous au nœud et vérifiez le fichier /etc/security/limits.conf.

   cat /etc/security/limits.conf

   Utilisez les paramètres suivants pour configurer le nombre maximal de descripteurs de fichiers pour un seul processus sur le nœud :

   ...
   root soft nofile 65535
   root hard nofile 65535
   * soft nofile 65535
   * hard nofile 65535

2. Exécutez la commande sed pour modifier le nombre maximal de descripteurs de fichiers. La valeur recommandée est 65535.

   sed -i "s/nofile.[0-9]*$/nofile 65535/g" /etc/security/limits.conf

3. Connectez-vous à nouveau au nœud et exécutez la commande suivante pour vérifier votre modification.

   Si la sortie correspond à votre valeur configurée, la modification a réussi.

   # ulimit -n
   65535

Modifier la limite de descripteurs de fichiers des conteneurs

1. Connectez-vous au nœud et exécutez la commande suivante pour afficher le fichier de configuration.

   • Nœud containerd : cat /etc/systemd/system/containerd.service

   • Nœud Docker : cat /etc/systemd/system/docker.service

   Les paramètres suivants définissent la limite de descripteurs de fichiers pour un seul processus à l'intérieur d'un conteneur :

   ...
   LimitNOFILE=1048576
   LimitNPROC=1048576
   ...

2. Exécutez les commandes suivantes pour modifier les valeurs des paramètres. La valeur recommandée pour la limite de descripteurs de fichiers est 1048576.

   • Nœud containerd :

     sed -i "s/LimitNOFILE=[0-9a-zA-Z]*$/LimitNOFILE=1048576/g" /etc/systemd/system/containerd.service;sed -i "s/LimitNPROC=[0-9a-zA-Z]*$/LimitNPROC=1048576/g" /etc/systemd/system/containerd.service && systemctl daemon-reload && systemctl restart containerd

   • Nœud Docker :

     sed -i "s/LimitNOFILE=[0-9a-zA-Z]*$/LimitNOFILE=1048576/g" /etc/systemd/system/docker.service && sed -i "s/LimitNPROC=[0-9a-zA-Z]*$/LimitNPROC=1048576/g" /etc/systemd/system/docker.service && systemctl daemon-reload && systemctl restart docker

3. Exécutez la commande suivante pour vérifier la limite de descripteurs de fichiers pour un seul processus à l'intérieur du conteneur.

   Si la sortie correspond à votre valeur configurée, la modification a réussi.

   • Nœud containerd :

     # cat /proc/`pidof containerd`/limits | grep files
     Max open files            1048576              1048576              files

   • Nœud Docker :

     # cat /proc/`pidof dockerd`/limits | grep files
     Max open files            1048576              1048576              files

Mettre à niveau l'environnement d'exécution de conteneurs pour les nœuds workers non gérés

Les clusters hérités créés avant l'introduction des pools de nœuds peuvent contenir des nœuds workers non gérés. Pour mettre à niveau l'environnement d'exécution de conteneurs de ces nœuds, vous devez les migrer vers un pool de nœuds.

Suivez ces étapes :

1. Créer un pool de nœuds : Si aucun pool de nœuds approprié n'existe dans le cluster, créez-en un avec une configuration correspondant aux nœuds non gérés.

2. Supprimer le nœud : Lorsque vous supprimez un nœud, le système l'isole (le marque comme non planifiable) puis draine ses pods pour les évacuer. Si le drainage échoue, le processus de suppression s'arrête. Le nœud n'est supprimé du cluster que si le drainage réussit.

3. Ajouter un nœud existant : Ajoutez le nœud à un pool de nœuds existant. Vous pouvez également créer un pool de nœuds avec zéro nœud, puis y ajouter le nœud. Une fois le nœud ajouté, son environnement d'exécution de conteneurs se met automatiquement à jour pour correspondre à celui spécifié dans la configuration du pool de nœuds.

   Remarque

   Bien que la fonctionnalité de pool de nœuds elle-même soit gratuite, les ressources cloud sous-jacentes utilisées par le pool de nœuds, telles que les instances ECS, sont facturées. Pour plus d'informations, consultez Frais des ressources cloud.

Pool de nœuds affiché comme « Other Nodes »

ACK fournit des méthodes standard pour ajouter des ressources de calcul à un cluster via la console, OpenAPI ou CLI. Pour plus d'informations, consultez Ajouter un nœud existant. Si vous ajoutez des nœuds en utilisant des méthodes extérieures aux flux de travail standard ACK, ACK ne peut pas identifier leur source et les assigne au groupe Other Nodes sur la page Nodes. ACK ne peut pas gérer ces nœuds via un pool de nœuds ; par conséquent, des fonctionnalités telles que la gestion du cycle de vie, l'exploitation et maintenance automatisées et le support technique garanti ne sont pas disponibles.

Si vous continuez à utiliser ces nœuds, vous devez garantir leur compatibilité avec les modules complémentaires du cluster et assumer tous les risques potentiels. Ces risques incluent, sans s'y limiter, les éléments suivants :

• Compatibilité des versions : Lors des mises à niveau du plan de contrôle ou des composants système, le système d'exploitation et les composants de ces nœuds non gérés peuvent devenir incompatibles avec les nouvelles versions, ce qui peut entraîner des interruptions de service.

• Compatibilité de la planification des charges de travail : Le cluster peut ne pas signaler avec précision l'état de ces nœuds, tels que leur zone de disponibilité et leur capacité de ressources restante. Cela peut conduire à des décisions de planification de charges de travail incorrectes, provoquant des problèmes de disponibilité ou une dégradation des performances.

• Compatibilité du plan de données : La compatibilité des composants côté nœud et du système d'exploitation avec le plan de contrôle et les composants système du cluster n'est pas validée, ce qui présente des risques potentiels de stabilité.

• Compatibilité d'exploitation et maintenance : Les opérations de maintenance sur ces nœuds via la console ou OpenAPI peuvent échouer ou produire des résultats inattendus, car le canal de gestion et l'environnement d'exécution pour ces nœuds ne sont pas vérifiés.

Configurer des ACL réseau pour les vSwitches des nœuds

Si le vSwitch d'un pool de nœuds possède une ACL réseau qui refuse le trafic provenant de blocs CIDR requis, les nouveaux nœuds ne pourront pas rejoindre le cluster et resteront dans un état Failed ou Offline.

Suivez ces étapes pour autoriser les blocs CIDR requis et rajouter des nœuds :

1. Configurer des règles d'ACL réseau. Dans les règles inbound et outbound, autorisez le trafic provenant des blocs CIDR suivants :

   1. 100.104.0.0/16 : Le bloc CIDR de gestion pour le plan de contrôle ACK.

   2. 100.64.0.0/10 : Le bloc CIDR de service interne Alibaba Cloud.

   3. 100.100.100.200/32 : L'endpoint du service de métadonnées d'instance ECS.

   4. Les blocs CIDR principaux et secondaires du VPC du cluster, ou le bloc CIDR du vSwitch contenant les nœuds.

2. Supprimer les nœuds défectueux. Supprimez tous les nœuds qui étaient dans un état Failed ou Offline avant l'entrée en vigueur des nouvelles règles d'ACL réseau.

3. Créer et gérer des pools de nœuds ou étendre un pool de nœuds existant pour ajouter de nouveaux nœuds. Un statut Ready sur les nouveaux nœuds confirme que les règles d'ACL réseau sont correctement configurées.