Kubernetes 034 – Volumes : TP WordPress partie 1

TL;DR

WordPress illustre tres bien le besoin de persistance: fichiers applicatifs et base de donnees ne doivent pas disparaitre avec les pods. Cette premiere partie pose les objets de base: Secrets, PVC, Deployments et Services.

La video de reference

Video: https://www.youtube.com/watch?v=3fDNxkPQS6o

Elle ouvre un TP stockage applique a une application connue.

Architecture cible

Un deploiement simple contient:

• un composant base de donnees, par exemple MySQL ou MariaDB;
• un composant WordPress;
• un Service interne pour la base;
• un Service pour WordPress;
• un PVC pour les donnees de base;
• un PVC pour les fichiers WordPress si necessaire;
• un Secret pour les mots de passe.

Secret minimal

kubectl create secret generic wordpress-db \
  --from-literal=mysql-root-password='change-me' \
  --from-literal=mysql-password='wordpress'

En production, on evite de mettre les secrets en clair dans l’historique shell.

PVC pour la base

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-data
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi

Le PVC doit passer en Bound avant de considerer le stockage pret.

Service de base

apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  selector:
    app: mysql
  ports:
    - port: 3306
      targetPort: 3306

WordPress utilisera le nom DNS mysql pour joindre la base.

Deployment WordPress

Le Deployment WordPress injecte les variables de connexion et pointe vers le Service MySQL.

env:
  - name: WORDPRESS_DB_HOST
    value: mysql
  - name: WORDPRESS_DB_USER
    value: wordpress

Les mots de passe doivent venir d’un Secret via secretKeyRef.

Ordre de verification

kubectl get pvc
kubectl get pods
kubectl get svc
kubectl logs deploy/mysql
kubectl logs deploy/wordpress
kubectl describe pod -l app=wordpress

Ne debuggez pas WordPress avant que la base et son Service soient corrects.

Liens utiles

• Video: https://www.youtube.com/watch?v=3fDNxkPQS6o
• Depot Xavki Kubernetes v2: https://gitlab.com/xavki/tutorials-kubernetes-v2
• Persistent Volumes: https://kubernetes.io/docs/concepts/storage/persistent-volumes/
• Secrets: https://kubernetes.io/docs/concepts/configuration/secret/
• Deployments: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/

FAQ

WordPress doit-il etre en Deployment ou StatefulSet ?

Pour un lab simple, Deployment suffit. Pour des besoins plus avances, l’architecture doit etre repensee.

La base doit-elle utiliser un PVC ?

Oui, sinon les donnees peuvent disparaitre avec le pod.

Peut-on exposer WordPress en NodePort ?

Oui en lab. En production, on preferera souvent Ingress ou LoadBalancer selon l’environnement.

Erreurs frequentes

• Lancer WordPress avant que MySQL soit pret.
• Oublier le PVC de la base.
• Mettre les mots de passe dans une ConfigMap.
• Confondre le nom du Service MySQL et le nom du pod.

Pour pratiquer

Deployeez d’abord la base, verifiez son PVC et ses logs, puis ajoutez WordPress. Supprimez le pod MySQL et verifiez que les donnees restent presentes apres recreation.

Notions et definitions

• Volume: point de montage rendu disponible dans un conteneur.
• PVC: demande de stockage exprimee par une application.
• PV et StorageClass: ressource de stockage et mecanisme de provisionnement associe.

Ces definitions donnent le vocabulaire minimal pour suivre l’article sans reduire Kubernetes a une simple commande. Chaque notion doit etre reliee a un objet visible avec kubectl ou a un composant du cluster.

Exemple concret

Une base de donnees dans un pod ne doit pas dependre du filesystem ephemere du conteneur; elle utilise un PVC pour retrouver ses donnees apres recreation du pod.

Cet exemple sert de fil conducteur: il montre quel probleme operationnel Kubernetes cherche a resoudre et quelle ressource permet de le formaliser.

How-to rapide

• Identifier si le besoin est ephemere, partage ou persistant.
• Creer un PVC adapte en taille et en mode d’acces.
• Monter ce PVC dans le pod ou le workload.
• Tester la persistence en supprimant puis recreant le pod.

Le how-to est volontairement court: l’idee est d’obtenir un resultat observable, puis d’utiliser les commandes de verification pour comprendre ce qui s’est passe.

Approfondir cet article

Cet episode doit surtout permettre de maitriser la difference entre stockage ephemere, volume attache au pod, volume persistant et provisionnement dynamique. L’objectif n’est pas seulement de refaire les commandes, mais de comprendre quel objet Kubernetes est cree, quel composant le prend en charge et comment verifier le resultat.

Questions a se poser

• Quel est l’etat desire exprime dans Kubernetes ?
• Quel composant observe cet etat et tente de le reconciler ?
• Quels symptomes montrent que l’objet est cree mais pas encore operationnel ?
• Quelle commande donne l’information la plus fiable pour diagnostiquer ?

Commandes de verification

• kubectl get pv,pvc,storageclass -o wide
• kubectl describe pvc <pvc> pour suivre les evenements de binding
• kubectl describe pod <pod> pour verifier les montages et les erreurs de volume

Ces commandes ne sont pas a apprendre par coeur. Elles servent a construire un reflexe: partir de l’objet Kubernetes, lire son etat, puis descendre vers les pods, les events, les logs ou le noeud uniquement si c’est necessaire.

Points de vigilance

• penser qu’un volume persistant resout automatiquement les sauvegardes
• melanger les responsabilites entre PVC, PV et StorageClass
• utiliser hostPath comme solution de production alors qu’il depend fortement du noeud

Exercice conseille

Creez un PVC, montez-le dans un pod de test, ecrivez un fichier, supprimez le pod, puis relancez-le pour verifier ce qui persiste vraiment.

Pour valider la comprehension, gardez une trace courte: manifest utilise, commandes lancees, resultat attendu, resultat observe et correction appliquee. Cette methode rend les episodes suivants beaucoup plus faciles a enchainer.

Lien interne conseille

Pour poursuivre la progression, consultez aussi Kubernetes 035 – Volumes : TP WordPress partie 2 solution.

Conclusion

Ce TP relie les notions vues jusque-la: Deployment, Service, Secret et PVC. WordPress sert de cas concret pour comprendre pourquoi la persistance devient indispensable des que l’application manipule des donnees.