TL;DR
Passer de Docker Compose a Kubernetes consiste a identifier les services, images, ports, variables d’environnement et dependances, puis a les convertir en Deployments et Services. Dockercoin est un bon lab car il contient plusieurs composants applicatifs.
La video de reference
Video: https://www.youtube.com/watch?v=dO534tVgFow
Elle lance le TP Dockercoin qui sera enrichi dans les episodes suivants.
Objectif du lab
Le but n’est pas de convertir automatiquement un fichier Compose. Le but est de comprendre quelle responsabilite Kubernetes donne a chaque objet.
Dans Compose, un service decrit souvent a la fois l’image, le reseau, les ports et parfois le stockage. Dans Kubernetes, on separe davantage les concepts.
Lire le docker-compose
Points a reperer:
- le nom des services;
- les images utilisees;
- les ports publies;
- les variables d’environnement;
- les volumes;
- les dependances implicites;
- les composants internes et externes.
Mapping simple
docker-compose service -> Deployment
port interne -> containerPort
communication interne -> Service ClusterIP
port publie -> Service NodePort, LoadBalancer ou Ingress plus tard
variables -> env, puis ConfigMap ou SecretExemple de squelette
apiVersion: apps/v1
kind: Deployment
metadata:
name: worker
spec:
replicas: 1
selector:
matchLabels:
app: worker
template:
metadata:
labels:
app: worker
spec:
containers:
- name: worker
image: <image-worker>Avancer par petits pas
Il vaut mieux deployer un composant, verifier ses logs, puis ajouter le Service associe. Tout convertir en une seule fois rend le debug beaucoup plus difficile.
kubectl apply -f worker-deployment.yaml
kubectl get pods
kubectl logs deploy/worker
kubectl describe pod -l app=workerLiens utiles
- Video: https://www.youtube.com/watch?v=dO534tVgFow
- Depot Xavki Kubernetes v2: https://gitlab.com/xavki/tutorials-kubernetes-v2
- Deployments: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
- Services: https://kubernetes.io/docs/concepts/services-networking/service/
FAQ
Faut-il utiliser Kompose ?
Cela peut aider, mais pour apprendre il est preferable d’ecrire les objets a la main.
depends_on existe-t-il en Kubernetes ?
Pas de la meme maniere. On gere plutot la robustesse applicative, les retries, readiness et Services.
Tout composant Compose devient-il un Deployment ?
Souvent pour les services stateless, mais pas toujours pour les bases, jobs ou volumes.
Erreurs frequentes
- Chercher une conversion un pour un parfaite.
- Exposer tous les composants vers l’exterieur.
- Oublier les Services internes.
- Ne pas lire les logs composant par composant.
Pour pratiquer
Prenez un Compose simple et listez pour chaque service: image, port, variables, besoin d’exposition. Ecrivez ensuite un Deployment et un Service par composant interne.
Notions et definitions
- ConfigMap: configuration non sensible injectee dans les pods.
- Secret: donnees sensibles encodees et gerees comme ressource Kubernetes.
- Label et annotation: metadata servant respectivement a selectionner et a documenter/enrichir les objets.
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 application peut lire son niveau de log depuis une ConfigMap et son mot de passe depuis un Secret, sans reconstruire l’image Docker.
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
- Sortir les valeurs variables de l’image applicative.
- Creer une ConfigMap ou un Secret selon la sensibilite de la donnee.
- Injecter la valeur en variable d’environnement ou en fichier monte.
- Verifier dans le pod que la valeur est disponible au bon endroit.
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 separation entre image applicative, configuration, metadata et parametrage d’execution. 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 configmap,secret --show-labelskubectl describe pod <pod>pour verifier variables, volumes et referenceskubectl get all -l <cle>=<valeur>pour valider l’usage des labels
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
- stocker une configuration variable directement dans l’image
- confondre Secret Kubernetes et coffre-fort de secrets complet
- sous-estimer l’importance des labels pour filtrer, selectionner et automatiser
Exercice conseille
Externalisez une variable d’environnement dans une ConfigMap, montez-la dans un pod, changez sa valeur, puis observez ce qui change sans redeployer et ce qui demande un redemarrage.
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 024 – TP Dockercoin : deploiements et services.
Conclusion
Dockercoin permet de transformer des notions separees en application complete. La migration vers Kubernetes est surtout un exercice de decoupage clair.