Version : 1.0 — 28/07/2026
Public : Support N2
Criticité : P1 — service public le plus visible de la plateforme
| Élément | Valeur |
|---|---|
| URL | elearning.unstim.bj (UAC/UNA/UP en déploiement, même modèle) |
| Namespace | RENSEIGNER_NS_MOODLE |
| Chaîne d'accès | Internet → NAT 102.222.216.6 → HAProxy externe 10.29.113.21 (SNI passthrough) → Ingress 10.29.113.201 → pod web Moodle |
| Base | Cluster CNPG dédié (RENSEIGNER_NOM_CLUSTER_PG) |
| Stockage | PVC Longhorn RWO (moodledata) — contrainte forte, cf. §4 |
| SSO | OIDC vers auth.rber.bj (realm par université) |
| Cron | CronJob Moodle — doit s'exécuter sur le même nœud que le pod web (RWO) |
kubectl config current-context # contexte RKE2 obligatoire
# 1. Pods
kubectl -n RENSEIGNER_NS_MOODLE get pods -o wide
# 2. Base
kubectl -n RENSEIGNER_NS_MOODLE get clusters.postgresql.cnpg.io
# 3. Ingress et endpoints
kubectl -n RENSEIGNER_NS_MOODLE get ingress,endpoints
# 4. Événements récents
kubectl -n RENSEIGNER_NS_MOODLE get events --sort-by=.lastTimestamp | tail -20
# 5. Logs web
kubectl -n RENSEIGNER_NS_MOODLE logs deploy/RENSEIGNER_DEPLOY_MOODLE --tail=100
| Constat | Aller à |
|---|---|
| 503 HAProxy, aucun pod web Ready | §3 |
Pod bloqué ContainerCreating avec erreur Multi-Attach |
§4 |
| Pod démarre mais très long (minutes/heures) | §5 |
| Service up mais lent | §6 |
| Connexion SSO échoue | §7 / Runbook-N2-Keycloak |
describe pod : pourquoi ?curl -k https://10.29.113.201 -H "Host: elearning.unstim.bj" -I depuis le bastion.haproxy-controller) — une NetPol supprimée par erreur coupe le service.Symptôme : pod web ou pod cron bloqué ContainerCreating, event Multi-Attach error for volume.
Cause : moodledata est RWO. Si un Job cron est planifié sur un autre nœud que le pod web, l'attachement échoue — ou pire, bloque le web.
# Qui tient le volume ?
kubectl get volumeattachments | grep RENSEIGNER_PV_MOODLEDATA
kubectl -n RENSEIGNER_NS_MOODLE get pods -o wide # comparer les nœuds web vs cron
Action :
kubectl -n RENSEIGNER_NS_MOODLE delete pod <pod-cron> (delete pod ciblé — jamais kubectl scale).podAffinity vers le pod web, avec exclusion des labels de Job (job-name et batch.kubernetes.io/job-name en DoesNotExist). Si la règle a disparu : N3 (correctif de manifeste).Symptôme : pod Running non Ready pendant très longtemps après un incident ou re-scheduling.
Cause : kubelet exécute un chown récursif sur moodledata (des millions de fichiers) quand le fsGroup ne correspond pas. Précédent : plusieurs heures le 24/07.
Action : ne pas tuer le pod (ça repart de zéro). Vérifier la progression dans les events. Le correctif de fond (fsGroupChangePolicy: OnRootMismatch) est au plan P1 de l'incident — vérifier s'il est appliqué : RENSEIGNER_FAIT_OU_NON. S'il ne l'est pas, ticket N3.
kubectl -n RENSEIGNER_NS_MOODLE get jobs --sort-by=.metadata.creationTimestamp | tail) — un cron en échec depuis des jours dégrade la plateforme (caches, files).| Opération | Commande | Condition |
|---|---|---|
| Purge caches Moodle | kubectl -n RENSEIGNER_NS_MOODLE exec deploy/RENSEIGNER_DEPLOY_MOODLE -- php admin/cli/purge_caches.php |
Hors heures de pointe |
| Mode maintenance ON/OFF | ... -- php admin/cli/maintenance.php --enable / --enablelater=0 |
Toujours annoncer aux N1 avant |
| Relance d'un cron manqué | ... -- php admin/cli/cron.php |
Après résolution d'un blocage §4 |
| Redémarrage pod web | kubectl -n RENSEIGNER_NS_MOODLE delete pod <pod-web> |
Cause identifiée et consignée ; jamais en heure de pointe sans P1 |
Interdit N2 : mise à jour Moodle ou plugins, modification config.php, changement de resources/limits, toute action base de données en écriture.
Administration > Serveur > Tâches planifiées)