Pourquoi mes conteneurs ne démarrent-ils pas ?

Vous constatez un ou plusieurs des problèmes suivants :

Les noeuds worker ne peuvent pas créer de nouveaux pods. Les pods sont correctement déployés sur les noeuds worker, mais les conteneurs sont bloqués à l'état ContainerCreating.

Lorsque vous exécutez kubectl describe pod <pod> pour un pod dans l'état ContainerCreating, vous voyez un événement similaire à l'un des événements suivants.

Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "XXX": failed to request 1 IPv4 addresses. IPAM allocated only 0

desc = failed to create pod network sandbox ... error adding container to network "k8s-pod-network": cannot allocate new block due to per host block limit

Lorsque vous exécutez la commande suivante, un ou plusieurs pods calico-node ne démarrent pas sur un noeud worker et sont à l'état CrashLoopBackOff.

Pour 1.29 et versions ultérieures:
```
kubectl logs -n calico-system <calico-node_pod>
```
Pour 1.28 et les versions antérieures:
```
kubectl logs -n kube-system <calico-node_pod>
```
Les dernières lignes des journaux contiennent le message suivant:
```
Unable to autoassign an address - pools are likely exhausted. type="ipipTunnelAddress"
```

Si vous ne voyez aucun des messages relatifs à l'adresse IP répertoriés dans les symptômes, vos conteneurs risquent de ne pas démarrer car le quota du registre a été atteint.

Si l'un des messages d'adresse IP répertoriés dans les symptômes s'affiche, le problème de démarrage de vos conteneurs peut être dû au fait que le gestionnaire IPAM (IP Address Manager) du plug-in Calico a détecté par erreur que toutes les adresses IP de pod du cluster sont utilisées. Étant donné que Calico IPAM détecte aucune adresse IP disponible, il n'affecte pas les adresses IP aux nouveaux pods dans le cluster et les pods ne peuvent pas démarrer.

Correction des problèmes de quota de registre

Virtual Private Cloud Infrastructure classique

Pour corriger des problèmes de quota de registre, libérez de l'espace de stockage dans IBM Cloud Container Registry.

Correction des problèmes d'adresse IP

Virtual Private Cloud Infrastructure classique

Pour corriger des problèmes d'adresse IP, libérez des adresses IP individuelles et des blocs d'adresses IP qui n'ont pas été correctement supprimés dans les enregistrements IPAM de Calico afin de permettre leur réutilisation par les pods de votre cluster.

Votre cluster doit exécuter une version prise en charge. Si votre cluster exécute une version obsolète ou non prise en charge, commencez par mettre à jour votre cluster.

Etape 1 : Libération d'adresses IP individuelles

Commencez par rechercher et libérer des adresses IP individuelles qui n'ont pas été correctement supprimées dans les enregistrements IPAM de Calico afin de permettre leur réutilisation par les pods de votre cluster.

Procédez comme indiqué dans la rubrique Installation et configuration de l'interface de ligne de commande de Calico pour télécharger la version 3.18 ou une version ultérieure du client calicoctl, utilisez la configuration Calico appropriée pour votre cluster et vérifiez que celle-ci fonctionne correctement pour votre cluster cible. Notez que même si votre cluster exécute une version plus ancienne de Calico, vous pouvez toujours utiliser calicoctl version 3.18 pour exécuter les commandes dans les étapes suivantes.

Si vous avez récemment mis à jour votre cluster classique de Kubernetes version 1.18 à 1.19, le cluster utilise le magasin de données KDD pour Calico. Veillez à suivre les étapes pour les clusters 1.19 afin de définir la variable d'environnement DATASTORE_TYPE sur kubernetes et la variable d'environnement KUBECONFIG sur le fichier kube-config de votre cluster. L'ancien fichier calicoctl.cfg pointe vers des données périmées dans etcd qui ne fonctionnent pas avec les rubriques suivantes.
Recherchez les adresses IP détectées par erreur comme étant utilisées par le gestionnaire IPAM de Calico.
```
calicoctl ipam check
```

Dans la sortie, recherchez la section contenant la ligne Scanning for IPs that are allocated but not actually in use.... Si des adresses IP sont allouées dans IPAM mais ne sont pas réellement utilisées, passez à l'étape suivante pour les libérer. Dans cet exemple de sortie, 181 adresses IP peuvent être libérées.

...
Scanning for IPs that are allocated but not actually in use...
Found 181 IPs that are allocated in IPAM but not actually in use.
Scanning for IPs that are in use by a workload or node but not allocated in IPAM...
Found 0 in-use IPs that are not in active IP pools.
Found 0 in-use IPs that are in active IP pools but have no corresponding IPAM allocation.

Check complete; found 181 problems.

Libérez les adresses IP du gestionnaire IPAM de Calico qui étaient précédemment affectées à un noeud final de pod. Notez qu'une fois que vous avez verrouillé le magasin de données dans les étapes suivantes, les pods existants continuent à s'exécuter, mais tous les pods créés restent à l'état ContainerCreating et ne peuvent pas démarrer tant que vous n'avez pas déverrouillé le magasin de données. Ce verrouillage de magasin de données garantit que les enregistrements IPAM ne sont pas modifiés pendant la libération des adresses IP. Pour plus d'informations, voir la documentation open sourceCalico.
1. Verrouillez le magasin de données pour les enregistrements IPAM de Calico.
```
calicoctl datastore migrate lock
```
2. Sauvegardez les résultats de la vérification IPAM.
```
calicoctl ipam check -o report.json
```
3. Libérez les adresses IP inutilisées. Ce processus peut durer jusqu'à 20 minutes en fonction du nombre d'adresses IP à libérer.
```
calicoctl ipam release --from-report=report.json
```
4. Déverrouillez le magasin de données.
```
calicoctl datastore migrate unlock
```
5. Vérifiez que toutes les adresses IP inutilisées sont libérées.
```
calicoctl ipam check
```
  Exemple de sortie
```
Check complete; found 0 problems.
```
Facultatif : pour vérifier que le magasin de données a été correctement déverrouillé et que des adresses IP sont désormais disponibles pour affectation, créez un pod et vérifiez qu'il démarre correctement.
1. Par exemple, créez un pod NGINX simple.
```
kubectl run test --image=nginx --generator=run-pod/v1
```
2. Vérifiez que le pod possède une adresse IP et qu'il fonctionne correctement.
```
kubectl get po test
```
3. Supprimez le pod de test.
```
kubectl delete pod test
```
Passez à la section suivante pour rechercher les blocs d'adresses IP inutilisés.

Etape 2 : Libération de blocs d'adresses IP

A présent, recherchez et supprimez les blocs entiers d'adresses IP qui étaient affectés à un noeud worker mais que celui-ci n'utilise plus.

Il peut arriver que lorsqu'un deuxième ou un troisième bloc d'adresses IP est affecté à un noeud worker, des blocs entiers d'adresses IP que celui-ci utilisait précédemment ne soient plus utilisés. De plus, lorsque vous retirez ou remplacez un noeud worker, le nettoyage du bloc d'adresses IP par le gestionnaire IPAM de Calico peut échouer car il n'existe aucun noeud worker sur lequel exécuter calico-kube-controllers temporairement ou il existe des problèmes liés au plug-in CNI ou au module d'exécution containerd lors du retrait ou du remplacement du noeud worker.

Il est essentiel de s'assurer que des blocs d'adresses IP sont libres pour tous les clusters classiques qui exécutent Kubernetes version 1.19 ou une version ultérieure et pour tous les clusters VPC. Dans ces clusters, le paramètre Calico strictAffinity a pour valeur true, ce qui force un noeud worker à utiliser uniquement les adresses IP issues de ses blocs d'adresses IP au lieu d'utiliser les adresses IP issues de blocs qui sont affectés à d'autres noeuds worker. Avec le temps, les blocs qui sont affectés à des noeuds mais qui ne sont pas utilisés peuvent s'accumuler, en empêchant à terme l'affectation de blocs d'adresses IP aux noeuds worker.

Procédez comme suit pour libérer des adresses IP individuelles :
Choisissez de verrouiller le magasin de données pour les enregistrements IPAM de Calico.
- Si vous verrouillez le magasin de données, les pods existants continuent à s'exécuter, mais tous les pods créés restent à l'état ContainerCreating et ne peuvent pas démarrer tant que vous n'avez pas déverrouillé le magasin de données. Ce verrou de magasin de données garantit que les pods ne peuvent pas être créées une fois que vous avez vérifié les blocs non utilisés, mais avant de libérer les blocs.
- Si vous ne verrouillez pas le magasin de données, vous devez immédiatement vérifier qu'aucun nouveau pod n'a utilisé les adresses IP d'un bloc libéré que vous avez supprimé.
```
calicoctl datastore migrate lock
```
Répertoriez les enregistrements IPAM de Calico. Dans la sortie, recherchez les blocs pour lesquels le paramètre IPS IN USE a pour valeur 0. Cela signifie que ces blocs ne sont pas utilisés par les noeuds worker qui leur sont affectés.
```
calicoctl ipam show --show-blocks
```
Dans cet exemple de sortie, aucune adresse IP du bloc 172.24.10.64/26 n'est utilisée.
```
...
Block    | 172.24.10.64/26  |        64 | 0 (0%)     | 64 (100%)  |
...
```
Procédez comme suit pour libérer chacun des blocs :
1. Vérifiez qu'aucun pod n'utilise une adresse IP issue du bloc.
```
kubectl get pods -A
```
2. Obtenez le BlockAffinity pour le bloc. Remplacez les périodes et la barre oblique dans le bloc par des traits d'union (-). Par exemple, pour le bloc 172.24.10.64/26, le format de la commande suivante est 172-24-10-64-26.
```
kubectl get blockaffinity | grep <block>
```
3. Supprimez le BlockAffinity.
```
kubectl delete blockaffinity <block_affinity>
```
4. Obtenez le IPAMBlock pour le bloc. Remplacez les périodes et la barre oblique dans le bloc par des traits d'union (-). Par exemple, pour le bloc 172.24.10.64/26, le format de la commande suivante est 172-24-10-64-26.
```
kubectl get ipamblock | grep <block>
```
5. Supprimez le IPAMBlock.
```
kubectl delete ipamblock <ipam_block>
```
6. Si vous n'avez pas verrouillé le magasin de données à l'étape 2, vérifiez qu'aucun pod n'a été créé directement avant la suppression du BlockAffinity et de l'IPAMBlock. Si des pods ont été créés, vous devez supprimer à nouveau le BlockAffinity et l'IPAMBlock pour ce bloc. Ensuite, supprimez les pods qui utilisent une adresse IP dans ce bloc en exécutant kubectl delete pod <pod> afin que le pod soit recréé avec une adresse IP d'un bloc différent.
```
kubectl get pods -A
```
7. Répétez ces étapes pour tous les autres blocs pour lesquels le paramètre IPS IN USE a pour valeur 0.
Si vous avez verrouillé le magasin de données à l'étape 2, déverrouillez-le.
```
calicoctl datastore migrate unlock
```