Comprendre les StatefulSets

Préparation

Le cluster est partagé par les stagiaires : travaillez dans un namespace à vous, étiqueté avec votre compte.

ID=$(whoami)
NS=mongo-$ID
kubectl create namespace $NS
kubectl label namespace $NS mongo=$ID
kubectl config set-context --current --namespace=$NS

Installation semi-manuelle

Créez un Statefulset MongoDB.

Appliquez le fichier mongo-simple.yaml pour créer le StatefulSet. Appliquez ensuite le fichier mongo-service.yaml afin de créer le service headless.

Vérifiez que les pods démarrent bien dand l’odre.

Instanciez un shell dans un pod ubuntu (kubectl run -i --rm --tty shell --image=ubuntu:24.04 -- bash), installez nslookup ou dig et tentez une résolution DNS de :

  • mongo
  • mongo-1.mongo

Que constatez vous ?

Pour initialiser mongoDB utilisez les commandes suivantes :

kubectl exec -it mongo-0 -- mongosh
# Dans le conteneur
rs.initiate({_id: "rs0", members:[{_id: 0, host: "mongo-0.mongo:27017"}]});
rs.add("mongo-1.mongo:27017");
rs.add("mongo-2.mongo:27017");

Tenter un passage à l’échelle du StatefulSet avec kubectl scale, que se passe t’il?

Installation automatisée

Quels sont les axes d’amélioration pour ce StatefulSet?

Réponses
  • support du passage à l’échelle
  • configuration automatique du cluster MongoDB
  • mise en oeuvre d’un stockage persistent.

Supprimer d’abord le StatefulSet MongoDB.

Ajout d’un script de configuration automatisée

Appliquer le fichier mongo-configmap.yaml.

Ajout d’un stockage persistent

En s’inspirant de cet example, modifier le fichier mongo.yaml pour ajouter une section volumeClaimTemplates

Solution en ligne

https://github.com/k8s-school/k8s-school/blob/master/labs/1_kubernetes/.solution/15-14-mongo-pvc.yaml

Vérifier que ls StatefulSet a bien démarré puis lister les PVs et les PVCs.

Vérifier également que tous les noeuds sont abonnés au cluster avec la commande suivante:

kubectl exec mongo-0 -c mongodb -- mongosh --quiet --eval 'rs.status().members.map(m => m.name + " " + m.stateStr)'
Remarque

Le script de configuration présent dans le configmap n’est pas extrêmement robuste et présente des effets de bord. Si un des pods mongo n’est pas présent dans le replicaset mongo alors une solution simple est de supprimer le pod concerné afin qu’il soit recréé automatiquement et que le script de configuration soit de nouveau exécuté.

Chargement des données

curl -O https://raw.githubusercontent.com/mongodb/docs-assets/primer-dataset/primer-dataset.json

# Only the primary accepts writes: connect to the replica set, not to a pod
RS="mongodb://mongo-0.mongo:27017/test?replicaSet=rs0"
kubectl exec -i mongo-0 -c mongodb -- mongoimport --uri "$RS" --collection restaurants --drop < primer-dataset.json

Enfin, tester l’accés aux données :

kubectl exec mongo-0 -c mongodb -- mongosh --quiet "$RS" --eval "db.restaurants.findOne()"

Mise à jour progressive

Canary avec partition, ordre des pods, bascule du primaire et rollback : voir la section Rolling Update du lab en anglais.

Nettoyage

kubectl delete namespace -l mongo=$(whoami)
kubectl config set-context --current --namespace=default

Félicitations, Vous avez manipulé toutes les briques de base pour déployer une application sur un cluster Kubernetes 🚀 !