Container Service for Kubernetes:Node and node pool FAQ

Index

Pour diagnostiquer et résoudre les problèmes liés aux nœuds, consultez la rubrique Dépannage des 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 vous 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 pénuries de stock. Pour ce faire, configurez plusieurs vSwitch dans plusieurs zones de disponibilité, sélectionnez plusieurs types d'instances ECS ou spécifiez les types d'instances en fonction du nombre de vCPU et de la mémoire. Après la création du pool de nœuds, vous pouvez ajouter des types d'instances en suivant les recommandations de niveau de scalabilité dans la console ou en consultant le niveau de scalabilité d'un pool de nœuds.

Pour obtenir la liste des types d'instances pris en charge et des recommandations de configuration des nœuds, consultez la rubrique 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 plug-in réseau du cluster. Pour plus d'informations, consultez la rubrique 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.

Vous pouvez afficher 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 la rubrique Ajustement des Pods disponibles sur un nœud.

Ajustement de la capacité en pods des nœuds

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

Pour plus d'informations, consultez la rubrique Augmentation du nombre maximal de pods dans un cluster.

Modification de la configuration des nœuds

• Afin de garantir la stabilité des services, certains paramètres, notamment ceux liés à la disponibilité et à la mise en réseau, sont immuables après la création d'un pool de nœuds. Par exemple, vous ne pouvez pas modifier le runtime de conteneur ni le VPC auquel appartient un nœud.

• Pour les paramètres modifiables, les modifications apportées à 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 la rubrique Création et gestion des pools de nœuds pour obtenir des détails sur les paramètres modifiables et le moment où les modifications prennent effet.

Sinon, pour appliquer une nouvelle configuration, vous pouvez créer un nouveau pool de nœuds avec la configuration souhaitée. Ensuite, mettez en quarantaine et videz les nœuds de l'ancien pool de nœuds pour migrer vos charges de travail. Une fois la migration terminée, vous pouvez libérer les instances de l'ancien pool de nœuds. Pour obtenir des instructions, consultez la rubrique Mise en quarantaine et vidage des nœuds.

Puis-je désactiver la fonctionnalité 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 la rubrique Suppression d'un nœud. Pour ajouter un nœud spécifique, consultez la rubrique ajout d'un nœud existant. Après avoir supprimé un nœud ou ajouté un nœud existant, la valeur Expected Nodes est automatiquement mise à jour avec le nouveau nombre de nœuds. Vous n'avez pas besoin de la modifier manuellement.

Pools de nœuds avec et sans la fonctionnalité Nœuds attendus

Le paramètre Expected Nodes définit la capacité cible d'un pool de nœuds. Vous pouvez effectuer une mise à l'échelle horizontale ou verticale d'un pool de nœuds en ajustant cette valeur. 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 pour les pools de nœuds avec et sans la fonctionnalité Expected Nodes activée.

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

Dans les anciens clusters ACK créés avant la publication de la fonctionnalité de pool de nœuds, certains nœuds de travail peuvent ne pas appartenir à un pool de nœuds. Pour placer ces nœuds non gérés sous 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 effectuez une mise à l'échelle horizontale d'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 la rubrique Migration des nœuds non gérés vers un pool de nœuds.

Remplacement de l'image du système d'exploitation d'un pool de nœuds

Vous pouvez remplacer 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 du système d'exploitation pour connaître les systèmes d'exploitation pris en charge, les dernières versions d'images et les limitations d'utilisation.

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

Libération d'une instance ECS spécifique

Pour libérer une instance ECS spécifique, supprimez le nœud. Cette action met automatiquement à jour le nombre attendu de nœuds. N'essayez pas de libérer une instance spécifique en modifiant le nombre attendu de nœuds, car cela déclenche une mise à l'échelle verticale aléatoire et ne garantit pas la suppression de l'instance visé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. Commencez par vérifier que le groupe de sécurité répond aux exigences. Pour connaître les limitations des groupes de sécurité lors de l'ajout d'un nœud existant, consultez la rubrique Limitations. Pour les autres problèmes de connectivité réseau, consultez la rubrique FAQ sur la gestion du réseau.

Modification des noms d'hôte des nœuds de travail

1. Supprimez le nœud. Pour plus d'informations, consultez la rubrique Suppression d'un nœud.

2. Rajoutez le nœud que vous avez supprimé au pool de nœuds. Pour plus d'informations, consultez la rubrique Ajout manuel de nœuds.

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

Mise à niveau manuelle du noyau d'un nœud GPU

1. Obtenir le fichier kubeconfig d'un cluster et s'y connecter avec kubectl.

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

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

3. Évacuez 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 la 384 111, vous devez télécharger le programme d'installation du pilote correspondant depuis le site Web officiel de NVIDIA et remplacer 384.111 dans 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

      Vous devez utiliser 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. Reconnectez-vous au nœud GPU et installez le paquet kernel-devel correspondant.

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

8. Accédez au site Web officiel de NVIDIA pour télécharger et installer le pilote NVIDIA requis. Cette rubrique utilise la version 410.79 à titre d'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. Retirez le nœud GPU de la quarantaine pour permettre à 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 de plug-in 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 la rubrique Résolution des problèmes de démarrage des conteneurs sur les nœuds GPU.

Résolution des problèmes de 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, modifiez le pilote Cgroup de Docker en systemd.

1. Sauvegardez le fichier /etc/docker/daemon.json, puis exécutez la commande suivante pour mettre à jour le fichier /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 pilote Cgroup de Docker est défini sur systemd.

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

Migration des pods depuis un nœud défaillant

Pour migrer les pods d'application depuis un nœud défaillant, marquez le nœud comme non planifiable, puis évacuez-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 la rubrique Dépannage des problèmes de nœuds.

Politique d'évacuation des nœuds en cas de panne de zone de disponibilité

Lorsqu'un nœud devient indisponible, le contrôleur de nœuds initie une évacuation. Le taux d'évacuation 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.

Toutefois, pour un cluster ACK avec des nœuds répartis dans 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 compte aucun nœud sain et au moins un nœud indisponible.

• PartialDisruption : La zone de disponibilité contient au moins deux nœuds indisponibles, et le ratio de nœuds indisponibles par rapport au total des 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 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'évacuation en fonction de ces états :

• Si toutes les zones de disponibilité sont dans un état FullDisruption, l'évacuation 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'évacuation est déterminé comme suit :

  • Pour une zone de disponibilité dans un état FullDisruption, le taux d'évacuation est défini sur 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'évacuation 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 défini sur 0, ce qui désactive l'évacuation.

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

Pour plus d'informations, consultez la documentation Limites de débit pour l'évacuation.

Personnalisation du chemin d'accès de Kubelet

Non. Le chemin d'accès de kubelet dans un cluster ACK est /var/lib/kubelet et ne peut pas être modifié. Ne changez pas ce chemin.

Montage d'un disque de données dans un répertoire personnalisé

Cette fonctionnalité est actuellement en version canary. Pour l'activer, soumettez 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 un disque de données dans les répertoires critiques suivants du système d'exploitation :

  • /

  • /etc

  • /var/run

  • /run

  • /boot

• Ne montez pas un 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 (\).

Modification des 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 disposent de deux niveaux de limites de descripteurs de fichiers :

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

• Niveau utilisateur : 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.

Modification de la limite de descripteurs de fichiers au niveau du système

Pour obtenir des instructions, consultez la rubrique Personnalisation des paramètres du système d'exploitation pour un pool de nœuds.

Modification de 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. Reconnectez-vous au nœud et exécutez la commande suivante pour vérifier votre modification.

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

   # ulimit -n
   65535

Modification de 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 à la 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

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

Les clusters hérités créés avant l'introduction des pools de nœuds peuvent contenir des nœuds de travail non gérés. Pour mettre à niveau l'environnement d'exécution des conteneurs pour 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 le place en quarantaine (le marque comme non planifiable), puis évacue ses pods. Si l'évacuation échoue, le processus de suppression s'arrête. Le nœud n'est supprimé du cluster que si l'évacuation 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. Après l'ajout du nœud, son environnement d'exécution des 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, vous êtes facturé pour les ressources cloud sous-jacentes, telles que les instances ECS, utilisées par le pool de nœuds. Pour plus d'informations, consultez la rubrique Frais liés aux 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 la rubrique Ajouter un nœud existant. Si vous ajoutez des nœuds en utilisant des méthodes en dehors des flux de travail standard d'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, donc des fonctionnalités telles que la gestion du cycle de vie, les opérations et la maintenance automatisées et le support technique garanti ne sont pas disponibles.

Si vous continuez à utiliser ces nœuds, vous devez assurer leur compatibilité avec les modules complémentaires du cluster et assumer tous les risques potentiels. Ces risques incluent, mais ne se limitent pas aux é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, tel que leur zone de disponibilité et leur capacité de ressources restante. Cela peut entraîner des décisions de planification de charge de travail incorrectes, causant 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 pose des risques potentiels de stabilité.

• Compatibilité des opérations et de la 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.

Configuration des listes de contrôle d'accès réseau pour les vSwitch de nœuds

Si le vSwitch d'un pool de nœuds dispose d'une liste de contrôle d'accès 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 les nœuds :

1. Configurer les règles de liste de contrôle d'accès réseau. Dans les règles inbound et outbound, autorisez le trafic provenant des blocs CIDR suivants :

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

   2. 100.64.0.0/10 : Bloc CIDR des services internes Alibaba Cloud.

   3. 100.100.100.200/32 : Endpoint du service de métadonnées des instances 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éfaillants. Supprimez tous les nœuds qui étaient dans un état Failed ou Offline avant que les nouvelles règles de liste de contrôle d'accès réseau ne prennent effet.

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 de liste de contrôle d'accès réseau sont correctement configurées.