Une fois que j'ai supprimé tous les noeuds worker, pourquoi mes pods ne démarrent-ils pas sur les nouveaux noeuds worker ?

Dépannage des échecs de suppression des nœuds de travail et des pods bloqués.

Cloud privé virtuel Infrastructure classique

Vous avez supprimé tous les noeuds worker de votre cluster et il n'existe plus aucun noeud worker. Ensuite, vous avez ajouté un ou plusieurs noeuds worker. Lorsque vous exécutez la commande ci-après,plusieurs pods pour les composants Kubernetes sont bloqués à l'état ContainerCreating, et les pods calico-node sont bloqués à l'état CrashLoopBackOff.

oc -n calico-system get pods

Lorsque vous supprimez tous les noeuds worker de votre cluster, il n'existe aucun noeud worker sur lequel exécuter le pod calico-kube-controllers. Les données du pod du contrôleur Calico ne peuvent pas être mises à jour pour supprimer les données des noeuds worker supprimés. Lorsque le pod de contrôleur Calico commence à s'exécuter à nouveau sur les noeuds worker, ses données ne sont pas mises à jour pour les nouveaux noeuds worker et il ne démarre pas les pods calico-node.

Supprimez les entrées de noeud worker calico-node existantes pour que de nouveaux pods puissent être créés.

Avant de commencer : installez l'interface de ligne de commande Calico.

Exécutez la commande ibmcloud oc cluster config, puis effectuez un copier-coller de la sortie pour définir la variable d'environnement KUBECONFIG. Incluez les options --admin et --network avec la commande ibmcloud oc cluster config. L'option --admin permet de télécharger les clés pour accéder à votre portefeuille d'infrastructure et exécuter des commandes Calico sur vos noeuds worker. L'option --network télécharge le fichier de configuration de Calico pour exécuter toutes les commandes Calico.
```
ibmcloud oc cluster config --cluster CLUSTER_NAME_OR_ID --admin --network
```

Pour les pods calico-node bloqués à l'état CrashLoopBackOff, notez les adresses IP répertoriées sous NODE.

oc -n calico-system get pods -o wide

Dans cet exemple de sortie, le fichier calico-node ne peut pas démarrer sur le noeud worker 10.176.48.106.

NAME                                           READY   STATUS              RESTARTS   AGE     IP              NODE            NOMINATED NODE   READINESS GATES
...
calico-kube-controllers-656c5785dd-kc9x2       1/1     Running             0          25h     10.176.48.107   10.176.48.107   <none>           <none>
calico-node-mkqbx                              0/1     CrashLoopBackOff    1851       25h     10.176.48.106   10.176.48.106   <none>           <none>
coredns-7b56dd58f7-7gtzr                       0/1     ContainerCreating   0          25h     172.30.99.82    10.176.48.106   <none>           <none>

Obtenez les ID des entrées de noeud worker calico-node. Copiez les ID uniquement pour les adresses IP de noeud worker que vous avez obtenues lors de l'étape précédente.
```
calicoctl get nodes -o wide
```
Utilisez les ID pour supprimer les entrées de noeud worker. Une fois que vous avez supprimé les entrées de noeud worker, le contrôleur Calico replanifie les pods calico-node sur les nouveaux noeuds worker.
```
calicoctl delete node <node_ID>
```
Vérifiez que ls pods de composant Kubernetes, y compris les pods calico-node, sont maintenant en cours d'exécution. La planification des pods calico-node et la création des nouveaux pods de composant peuvent prendre plusieurs minutes.
```
oc -n calico-system get pods
```

Pour éviter cette erreur à l'avenir, ne supprimez jamais tous les noeuds worker de votre cluster. Exécutez toujours au moins un noeud worker dans votre cluster, et si vous utilisez Ingress ou des routes pour exposer des applications, exécutez au moins deux noeuds worker par zone.