Kubernetes 035 – Volumes : TP WordPress partie 2 solution

TL;DR

Un deploiement WordPress sur Kubernetes devient interessant quand on isole les responsabilites: un volume persistant pour MySQL, un autre eventuellement pour WordPress, des Secrets pour les mots de passe, des Services pour la decouverte et des Deployments pour les pods. Le point cle est de ne pas stocker les donnees dans le filesystem ephemere du conteneur.

La video de reference

Video: https://www.youtube.com/watch?v=LCt1H-gsa3Y

Elle correspond a la correction du TP sur les volumes avec WordPress et prolonge les episodes consacres aux volumes Kubernetes.

Objectif du TP

L’objectif est de deployer WordPress avec une base MySQL en conservant les donnees meme si les pods sont recrees. Sans volume persistant, la suppression d’un pod MySQL peut entrainer la perte de la base.

Le TP permet aussi de revoir une logique classique Kubernetes: on ne met pas toute l’application dans un seul manifest monolithique sans reflechir. On declare chaque brique avec son role.

Architecture minimale

Une solution simple contient:

• un Secret pour les mots de passe MySQL;
• un PVC pour les donnees MySQL;
• un Deployment MySQL;
• un Service interne MySQL;
• un PVC optionnel pour WordPress;
• un Deployment WordPress;
• un Service pour exposer WordPress.

Cette separation facilite la lecture, le debug et la reutilisation.

Exemple de Secret

apiVersion: v1
kind: Secret
metadata:
  name: mysql-secret
type: Opaque
stringData:
  MYSQL_ROOT_PASSWORD: rootpass
  MYSQL_DATABASE: wordpress
  MYSQL_USER: wordpress
  MYSQL_PASSWORD: wordpresspass

En production, il faut eviter de versionner ces valeurs en clair. Pour un TP, cela permet surtout de comprendre le cablage.

PVC pour MySQL

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

Le PVC demande du stockage. Selon le cluster, un StorageClass dynamique provisionne le volume, ou bien il faut creer un PersistentVolume a la main.

Deployments et Services

Le Deployment MySQL doit monter le PVC sur /var/lib/mysql et charger les variables depuis le Secret. Le Service MySQL reste interne et donne a WordPress un nom DNS stable: mysql.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
spec:
  replicas: 1
  selector:
    matchLabels: { app: mysql }
  template:
    metadata:
      labels: { app: mysql }
    spec:
      containers:
        - name: mysql
          image: mysql:8
          envFrom:
            - secretRef: { name: mysql-secret }
          volumeMounts:
            - name: data
              mountPath: /var/lib/mysql
      volumes:
        - name: data
          persistentVolumeClaim: { claimName: mysql-pvc }
---
apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  selector: { app: mysql }
  ports:
    - port: 3306

WordPress consomme ensuite WORDPRESS_DB_HOST=mysql:3306 et les valeurs du Secret. Pour un lab, un Service NodePort peut exposer le port 80; dans un environnement plus propre, on utilisera plutot un Ingress ou un LoadBalancer.

apiVersion: v1
kind: Service
metadata:
  name: wordpress
spec:
  type: NodePort
  selector: { app: wordpress }
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30080

Commandes utiles

kubectl apply -f secret.yaml
kubectl apply -f mysql-pvc.yaml
kubectl apply -f mysql.yaml
kubectl apply -f wordpress.yaml
kubectl get pods,pvc,svc
kubectl describe pvc mysql-pvc

Pour tester la persistance, supprimer le pod MySQL puis verifier que le site retrouve ses donnees.

Liens utiles

• Video: https://www.youtube.com/watch?v=LCt1H-gsa3Y
• Playlist Kubernetes v2: https://www.youtube.com/playlist?list=PLn6POgpklwWo6wiy2G3SjBubF6zXjksap
• Depot Xavki Kubernetes v2: https://gitlab.com/xavki/tutorials-kubernetes-v2
• Volumes Kubernetes: https://kubernetes.io/docs/concepts/storage/volumes/
• Persistent Volumes: https://kubernetes.io/docs/concepts/storage/persistent-volumes/

FAQ

Pourquoi ne pas stocker MySQL dans le conteneur ?

Parce que le filesystem du conteneur est ephemere. Kubernetes peut remplacer un pod a tout moment.

Faut-il un StatefulSet pour MySQL ?

Pour un TP simple, un Deployment peut suffire. Pour une base serieuse, un StatefulSet ou un operateur est plus adapte.

WordPress a-t-il aussi besoin d’un volume ?

Oui si l’on veut conserver les uploads, themes ou plugins installes depuis l’interface.

Erreurs frequentes

• Oublier le PVC MySQL et perdre les donnees au redemarrage.
• Confondre Secret et ConfigMap.
• Utiliser un Service avec un selector qui ne correspond pas aux labels.
• Croire que replicas: 1 rend une base hautement disponible.

Pour pratiquer

Supprimez le pod MySQL, attendez sa recreation, puis reconnectez-vous a WordPress. Ensuite supprimez le PVC dans un namespace de test pour constater la difference entre pod ephemere et stockage persistant.

Notions et definitions

• Service: point d’entree stable devant un ensemble de pods.
• Endpoint ou EndpointSlice: liste des backends reels selectionnes par le Service.
• kube-proxy: composant qui programme les regles reseau necessaires sur chaque noeud.

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

Un Deployment web expose par un Service web-svc permet a un client de viser une IP stable, meme si les pods web sont recrees avec de nouvelles adresses IP.

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

• Creer un Deployment avec un label clair, par exemple app=web.
• Creer un Service dont le selecteur cible ce label.
• Verifier que les endpoints apparaissent et correspondent aux pods attendus.
• Tester depuis un pod de debug plutot que depuis uniquement votre machine locale.

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 le chemin reseau complet entre un client, un Service, kube-proxy et les pods cibles. 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 svc,endpoints,endpointslices -o wide
• kubectl describe svc <service> pour verifier le selecteur, les ports et les endpoints
• kubectl logs -n kube-system -l k8s-app=kube-proxy pour confirmer le mode et les erreurs reseau

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

• confondre Service, Pod IP et endpoint reel
• oublier qu’un Service sans endpoint ne peut pas router de trafic applicatif
• diagnostiquer le CNI alors que le probleme vient du selecteur ou du port du Service

Exercice conseille

Creez deux Deployments nginx avec des labels differents, exposez-en un avec un Service, puis modifiez volontairement le selecteur pour observer la disparition des endpoints.

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 036 – K0S : cluster multi-nodes avec Vagrant.

Conclusion

Ce TP montre que les volumes ne sont pas un detail. Des qu’une application garde de l’etat, le stockage devient une responsabilite explicite du manifest Kubernetes.