Dépannage

Ce guide vous aide à diagnostiquer et résoudre les problèmes courants rencontrés lors de l'utilisation des clusters Kubernetes cegedim.cloud.

Problèmes d'Interface Rancher

L'Interface Rancher Bloquée sur "Loading"

Symptômes : Après la connexion, l'interface Rancher affiche "Loading" indéfiniment.

Solution :

1. Essayez d'accéder directement à l'URL du tableau de bord :

   • Pour la région ET : https://rancher-et.cegedim.cloud/dashboard/home

   • Pour EB production : https://rancher-eb.cegedim.cloud/dashboard/home

   • Pour EB non-production : https://rancher-eb-qa.cegedim.cloud/dashboard/home

2. Si le problème persiste, déconnectez-vous et reconnectez-vous

3. Essayez d'utiliser un navigateur différent ou le mode navigation privée/incognito

4. Effacez le cache et les cookies de votre navigateur pour le domaine Rancher

Cluster Non Visible Après la Première Connexion

Symptômes : Après votre première connexion à Rancher, votre cluster n'apparaît pas dans la liste des clusters.

Solution :

1. Déconnectez-vous complètement de Rancher

2. Reconnectez-vous

3. Votre cluster devrait maintenant apparaître dans la liste

4. Si le cluster n'apparaît toujours pas, vérifiez vos droits d'accès via ITCare ou contactez votre administrateur

Impossible d'Accéder à Rancher (Connexion Refusée ou Timeout)

Symptômes : Impossible d'atteindre rancher-et.cegedim.cloud ou rancher-eb.cegedim.cloud.

Solution :

1. Vérifier l'accès réseau : Certaines instances Rancher sont uniquement accessibles depuis le réseau serveur

   • rancher-et.cegedim.cloud - Nécessite un accès réseau serveur (connexion via bastion)

   • rancher-eb.cegedim.cloud (production) - Nécessite un accès réseau serveur (connexion via bastion)

   • rancher-eb-qa.cegedim.cloud (non-production) - Accessible depuis le réseau standard

2. Vérifier le statut de Rancher : Vérifiez si une mise à jour de Rancher est en cours (généralement 15-30 minutes)

Problèmes d'Accès kubectl

Les Commandes kubectl Échouent avec "Connection Refused"

Symptômes : Les commandes kubectl renvoient des erreurs de connexion ou des timeouts.

Causes Possibles et Solutions :

1. Problème de Proxy Rancher

• Si votre kubeconfig utilise l'URL Rancher, Rancher peut être indisponible ou en cours de mise à jour

• Attendez que Rancher soit à nouveau disponible

• Envisagez d'utiliser l'accès direct au cluster si disponible

2. Identifiants Invalides ou Expirés

• Téléchargez un nouveau kubeconfig depuis l'interface Rancher

• Vérifiez que votre jeton n'a pas expiré (vérifiez le cycle de vie du jeton dans Rancher)

3. Connectivité Réseau

• Testez la connectivité : curl -v https://<rancher-url>

• Vérifiez que vous êtes sur le bon réseau (bastion pour ET/EB production)

• Vérifiez les règles de pare-feu et les paramètres de proxy

Le Contexte kubectl Ne Change Pas

Symptômes : Les commandes kubectl affectent le mauvais cluster.

Solution :

# Lister tous les contextes disponibles
kubectl config get-contexts

# Basculer vers le bon contexte
kubectl config use-context <nom-du-contexte>

# Vérifier le contexte actuel
kubectl config current-context

Accès au Cluster et Authentification

Erreurs "Forbidden" Lors de l'Exécution de Commandes kubectl

Symptômes : Les commandes renvoient "Error from server (Forbidden): is forbidden".

Solution :

1. Vérifiez vos droits d'accès dans Rancher : Consultez la page "Gérer les droits" pour vos permissions Projet/Cluster

2. Utilisez SelfSubjectAccessReview : Exécutez la commande suivante pour vérifier vos permissions pour des ressources spécifiques :

kubectl create -f - -o yaml << EOF
apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
spec:
  resourceAttributes:
    group: ""
    resource: "*"
    verb: "*"
EOF

1. Vérifiez les permissions Projet/Namespace : Assurez-vous d'avoir le bon rôle dans le Projet

2. Vérifiez l'appartenance au groupe AD : Confirmez que vous êtes dans les bons groupes G_K8_*

3. Vérifiez la portée du jeton : Assurez-vous d'utiliser un jeton à portée de cluster pour les opérations kubectl

Impossible de Créer des Ressources dans un Namespace

Symptômes : Permission refusée lors de la création de pods, déploiements, etc.

Solution :

1. Vérifiez que le namespace appartient à un Projet auquel vous avez accès

2. Si le namespace a été créé via kubectl (pas l'interface Rancher), il peut être dans le projet "Default" avec un accès restreint

3. Contactez votre administrateur de Projet pour déplacer le namespace vers le bon Projet ou accorder des permissions

Problèmes de Charge de Travail

Pods Bloqués dans l'État "Pending"

Symptômes : Les pods restent dans le statut "Pending" et ne démarrent pas.

Diagnostic :

# Vérifier les détails du pod
kubectl describe pod <nom-du-pod> -n <namespace>

# Recherchez les événements en bas de la sortie

Causes Courantes et Solutions :

1. Ressources Insuffisantes

• Message : "Insufficient cpu" ou "Insufficient memory"

• Solution : Demandez plus de nœuds via ITCare ou réduisez les demandes de ressources

2. Problèmes de Volume Persistant

• Message : "persistentvolumeclaim not found" ou "no persistent volumes available"

• Solution : Vérifiez que le PVC existe et que la classe de stockage est correcte

3. Incompatibilité Node Selector/Affinity

• Message : "No nodes are available that match all of the following predicates"

• Solution : Examinez les règles nodeSelector et affinity

4. Erreurs de Pull d'Image

• Message : "Failed to pull image" ou "ImagePullBackOff"

• Solution : Voir la section "Problèmes de Pull d'Image" ci-dessous

Problèmes de Pull d'Image (ImagePullBackOff)

Symptômes : Les pods échouent avec le statut "ImagePullBackOff" ou "ErrImagePull".

Diagnostic :

kubectl describe pod <nom-du-pod> -n <namespace>
# Recherchez les messages "Failed to pull image"

Causes Courantes et Solutions :

1. Authentification au Registre Privé

• Créez ou vérifiez que le secret de pull d'image existe

• Assurez-vous que le secret est référencé dans la spec du pod ou le compte de service

2. Faute de Frappe dans le Nom de l'Image

• Vérifiez que le nom de l'image et le tag sont corrects

• Vérifiez que l'URL du registre est correctement formatée

3. Connectivité Réseau au Registre

• Vérifiez que le cluster peut atteindre le registre externe

• Vérifiez si des politiques réseau bloquent l'accès au registre

• Demandez une ouverture réseau via ITCare si nécessaire

L'Ingress Ne Route Pas le Trafic

Symptômes : Impossible d'accéder à l'application via l'URL ingress.

Diagnostic :

# Vérifier la configuration ingress
kubectl get ingress -n <namespace>
kubectl describe ingress <nom-ingress> -n <namespace>

# Vérifier le service et les endpoints
kubectl get svc -n <namespace>
kubectl get endpoints <nom-service> -n <namespace>

Causes Courantes et Solutions :

1. Classe Ingress Incorrecte

• Pour Nginx (par défaut) : Aucune annotation de classe nécessaire ou utilisez kubernetes.io/ingress.class: "nginx"

• Pour Nginx externe : Utilisez kubernetes.io/ingress.class: "nginx-ext"

• Pour Traefik : Utilisez la classe ingress Traefik appropriée

• Pour Istio : Utilisez la configuration Istio Gateway

2. Service Non Trouvé ou Mal Configuré

• Vérifiez que le nom et le port du service correspondent au backend ingress

• Vérifiez que le service a des endpoints (pods sélectionnés)

3. Problèmes de Certificat

• Par défaut : Le certificat *.yourclustername.ccs.cegedim.cloud est préconfiguré

• Domaines personnalisés : Demandez la configuration du certificat via ITCare

Problèmes de Stockage Persistant

PVC Bloqué dans l'État "Pending"

Symptômes : Le PersistentVolumeClaim reste "Pending" et les pods ne peuvent pas démarrer.

Diagnostic :

kubectl describe pvc <nom-pvc> -n <namespace>
# Recherchez les messages d'erreur dans Events

Causes Courantes et Solutions :

1. Classe de Stockage Non Trouvée

• Vérifiez le nom de la classe de stockage dans le PVC

• Listez les classes de stockage disponibles : kubectl get storageclass

• Utilisez les classes de stockage basées sur Ceph fournies par cegedim.cloud

2. Quota de Stockage Dépassé

• Vérifiez si le quota de stockage est disponible

• Demandez du stockage supplémentaire via ITCare

3. Ceph CSI Non Disponible

• Vérifiez que Ceph CSI est activé pour votre cluster

• Contactez le support si Ceph CSI n'est pas provisionné

Problèmes de Politique Réseau

Les Pods Ne Peuvent Pas Communiquer Entre Namespaces

Symptômes : Les pods dans différents namespaces ne peuvent pas se joindre.

Comprendre l'Isolation Réseau des Projets Rancher :

• Les pods dans les namespaces au sein du même Projet Rancher peuvent communiquer par défaut

• Les pods dans les namespaces dans différents Projets Rancher ne peuvent pas communiquer sauf autorisation explicite

Solution :

1. Option 1 : Déplacer les namespaces vers le même Projet Rancher (si approprié)

2. Option 2 : Créer une NetworkPolicy pour autoriser explicitement la communication inter-projets

3. Note : Les pods dans le projet "System" peuvent communiquer avec tous les autres projets

Les Pods Ne Peuvent Pas Accéder aux Services Externes

Symptômes : Les pods ne peuvent pas atteindre internet ou les services externes.

Comprendre les Restrictions Réseau :

• Par défaut, les pods ne peuvent atteindre que les services au sein du même VLAN

• L'accès internet nécessite une configuration de proxy ou une ouverture réseau

Solution :

1. Pour l'accès internet : Configurez un proxy HTTP dans vos pods ou demandez une ouverture réseau via ITCare

2. Pour des services externes spécifiques : Demandez une ouverture réseau entre VLANs via ITCare

3. Pour des bases de données/APIs externes : Vérifiez les politiques réseau et les règles de pare-feu

Problèmes de Logging et Surveillance

Les Logs N'Apparaissent Pas dans OpenSearch/ELK

Symptômes : Les logs d'application ne sont pas visibles dans votre plateforme d'agrégation de logs.

Diagnostic :

# Vérifier si les pods de logging sont en cours d'exécution
kubectl get pods -n cattle-logging-system

# Vérifier la taille du buffer (ne devrait pas croître continuellement)
kubectl -n cattle-logging-system get po -l app.kubernetes.io/name=fluentd -o name | \
  xargs -I {} sh -c "kubectl -n cattle-logging-system exec {} -c fluentd -- du -hs /buffers"

Causes Courantes et Solutions :

1. Flow/Output Non Configuré

• Vérifiez que les ressources Flow et Output/ClusterOutput existent pour votre namespace

• Vérifiez que la configuration correspond à votre cluster OpenSearch

2. Champs de Log Conflictuels

• OpenSearch/ELK rejette les logs avec des conflits de type de champ

• Vérifiez les logs fluentd pour les messages "Rejected"

• Voir la configuration détaillée du logging dans le guide "Débuter"

3. Application Produisant du JSON Mal Formé

• Les logs d'application doivent être correctement formatés

• Envisagez d'exclure les pods problématiques du Flow de logging

Problèmes de Migration

L'Application Échoue Après Migration vers RKE2

Symptômes : L'application fonctionnait sur RKE mais échoue sur RKE2.

Causes Courantes et Solutions :

1. Versions d'API Dépréciées

• Exécutez l'outil kubent avant la migration pour détecter les APIs dépréciées

• Mettez à jour les manifestes pour utiliser les versions d'API actuelles

• Voir le Guide de Dépréciation d'API Kubernetes

2. Différences CNI

• Si vous migrez vers Cilium depuis Canal, les politiques réseau peuvent se comporter différemment

• Examinez et testez les politiques réseau après la migration

3. ConfigMaps ou Secrets Manquants

• Vérifiez que tous les ConfigMaps et Secrets ont été migrés

• Vérifiez que les namespaces et noms correspondent exactement

4. Problèmes d'Intégration Externe

• Mettez à jour les pipelines CI/CD avec le nouveau kubeconfig du cluster

• Reconfigurez les connexions à Vault, bases de données et autres services PaaS

• Mettez à jour les intégrations de surveillance et d'alerte

Obtenir de l'Aide

Si vous ne pouvez pas résoudre le problème à l'aide de ce guide :

Ressources en Libre-Service

• Consultez la documentation officielle Kubernetes

• Examinez la documentation Rancher

• Consultez d'autres sections de cette documentation (Architecture, Débuter, etc.)

Contacter le Support

• Pour les problèmes non urgents : Soumettez un ticket via ITCare

• Pour les incidents de production : Contactez l'équipe de support 24x7 (si vous avez l'option de surveillance 24x7)

• Pour l'assistance à la migration : Soumettez un ticket avec le sujet "Demande de Migration RKE vers RKE2"

Informations à Fournir Lors d'une Demande de Support

Pour aider le support à diagnostiquer votre problème rapidement, veuillez fournir :

1. Informations sur le Cluster :

   • Nom du cluster

   • Région (ET, EB)

   • Version Kubernetes

2. Description du Problème :

   • Ce que vous essayiez de faire

   • Ce qui s'est passé vs ce que vous attendiez

   • Quand le problème a commencé

   • Tout changement récent (déploiements, mises à jour, modifications de configuration)

3. Détails Pertinents :

   • Noms du namespace et des ressources affectées

   • Messages d'erreur de kubectl ou de l'interface Rancher

   • Sortie des commandes kubectl describe pertinentes

   • Captures d'écran des erreurs de l'interface Rancher (le cas échéant)

4. Dépannage Déjà Effectué :

   • Étapes que vous avez déjà essayées

   • Résultats de ces tentatives

La plupart des problèmes peuvent être résolus rapidement avec un diagnostic approprié. N'hésitez pas à rassembler les informations pertinentes avant de soumettre un ticket de support - cela aide l'équipe de support à vous assister plus rapidement !