Formation Kubernetes : apprendre, administrer, sécuriser

Kubernetes est l'orchestrateur de conteneurs de la CNCF : vous décrivez l'état voulu de votre application, il le réalise et le maintient sur un ensemble de machines, y compris quand l'une d'elles tombe. Cette formation gratuite vous mène des premiers Pods à l'administration d'un cluster durci : 14 modules pédagogiques, 100 leçons et une banque de 1 189 questions, soit environ 60 heures de travail. Elle s'adresse aux administrateurs système, aux SRE et aux développeurs qui déploient sur Kubernetes, et prépare les cinq certifications CNCF, de la KCNA à la CKS.

Qu'est-ce que Kubernetes et comment fonctionne-t-il ?

Kubernetes, abrégé K8s, automatise le déploiement, la mise à l'échelle et la réparation d'applications conteneurisées réparties sur un groupe de machines appelé cluster. Créé par Google, il est aujourd'hui hébergé par la CNCF (Cloud Native Computing Foundation).

Son principe de fonctionnement tient en un mécanisme, la boucle de réconciliation. Vous déclarez un état voulu, par exemple trois exemplaires d'une application, et des contrôleurs comparent en permanence cette déclaration à l'état observé du cluster. Dès qu'un écart apparaît, machine tombée ou conteneur planté, un contrôleur agit pour le résorber sans qu'on le lui demande. C'est ce mécanisme, et non une supervision humaine, qui rend les applications résilientes et permet de les redimensionner en modifiant une seule valeur.

Le cluster se divise en deux rôles. Le Control Plane décide : l'API Server reçoit toutes les requêtes, etcd stocke l'état déclaré, le Scheduler choisit sur quelle machine placer chaque Pod, et le Controller Manager fait tourner les boucles de réconciliation. Les Worker Nodes exécutent : le kubelet y lance les conteneurs via un moteur d'exécution comme containerd, et kube-proxy y programme les règles réseau.

Le chemin d'un déploiement suit toujours cet ordre. Votre manifeste part de kubectl apply vers l'API Server, qui le valide et l'écrit dans etcd. Le Scheduler voit apparaître un Pod sans machine assignée et lui en attribue une. Le kubelet de cette machine récupère la définition, demande à containerd de télécharger l'image et de démarrer le conteneur. Comprendre cette chaîne est ce qui vous permettra plus tard de savoir où regarder quand un Pod ne démarre pas.

Que contient la formation Kubernetes, et combien de temps demande-t-elle ?

La formation compte 14 modules pédagogiques et 100 leçons, pour environ 60 heures de travail effectif, lecture et manipulation comprises. Elle est gratuite, accessible sans inscription, et sa banque d'entraînement compte 1 189 questions.

Ce que vous suivez	Volume
Modules pédagogiques	14
Leçons	100
Durée estimée	environ 60 heures
Banque de questions	1 189
Exercices de certification	62 (22 CKA, 20 CKAD, 20 CKS)
Cluster de manipulation	k3d ou Kind, en local
Travaux pratiques	dépôt containers-training
Certifications visées	KCNA, KCSA, CKAD, CKA, CKS

Glissez pour voir

Ces heures ne mesurent pas un temps de lecture. Elles comptent la reproduction des manipulations sur un vrai cluster, parce que Kubernetes ne se maîtrise pas en lisant du YAML : il se maîtrise en observant ce que le cluster fait de ce YAML.

La répartition ci-dessous vous permet de caler votre rythme et de repérer les modules que vous pouvez sauter si vous avez déjà de la pratique. Les niveaux correspondent à ceux du parcours.

Module	Niveau	Leçons	Durée
Fondamentaux	Débutant	4	1 h 20
Architecture du cluster	Débutant	6	3 h 25
Les ressources de base	Débutant	10	6 h 10
Déployer ses applications	Intermédiaire	9	7 h
Workloads avancés	Intermédiaire	4	2 h 35
Réseau et exposition	Intermédiaire	4	2 h 20
Stockage persistant	Intermédiaire	2	1 h 55
Scheduling et capacité	Intermédiaire	6	3 h 25
Installer un cluster	Avancé	7	6 h
Administrer le cluster	Avancé	3	1 h 20
Opérer au quotidien	Avancé	16	6 h 50
Sécurité des workloads	Avancé	3	1 h 30
Sécuriser le cluster	Avancé	14	9 h 20
Certifications	Avancé	12	7 h

Glissez pour voir

Deux modules dominent : Sécuriser le cluster avec 14 leçons et Opérer au quotidien avec 16. Ce déséquilibre est volontaire. La plupart des formations Kubernetes s'arrêtent au déploiement réussi, alors que l'essentiel du temps passé sur un cluster consiste à le durcir, à diagnostiquer un incident et à le mettre à jour sans coupure.

Comment suivre sa progression dans le parcours ?

Chaque leçon porte une case à cocher, et votre progression est enregistrée dans votre navigateur, sans compte ni inscription. Aucune donnée ne part sur un serveur.

La page Mon parcours affiche le programme complet, module par module, avec le pourcentage d'avancement. En haut de chaque leçon, un bandeau rappelle où vous en êtes ; en bas, un bouton marque la leçon comme lue et vous emmène à la suivante. Une formation de soixante heures se suit rarement d'une traite : ce suivi existe pour que vous puissiez la reprendre après trois semaines sans chercher où vous en étiez.

Le parcours, module par module

La formation se lit dans l'ordre si vous débutez. Si vous pratiquez déjà, entrez directement par le module qui vous manque : chaque leçon est autonome et rappelle ses prérequis.

Comprendre le cluster avant de déployer

Les trois premiers modules construisent le socle. Vous créez un cluster local dès la deuxième leçon, puis vous ouvrez le capot pour savoir ce qui s'y passe.

• Concepts clés, premier cluster k3d ou Kind et premier déploiement : la boucle complète, du cluster vide à l'application accessible.
• Architecture Kubernetes : le Control Plane, les Worker Nodes, etcd, les interfaces CNI, CSI et CRI et CoreDNS.
• Les ressources de base : Pods, Deployments, ReplicaSets, Services, ConfigMaps, Secrets, Namespaces et les rolling updates.

Livrer une application qui tient en production

Quatre modules séparent une application qui démarre d'une application exploitable : la santé déclarée, les ressources réservées, le type de workload adapté et l'exposition maîtrisée.

• Écrire des manifests, gérer les images, init containers et sidecars, probes, requests et limits et le débogage applicatif.
• Les workloads qui ne sont pas des Deployments : StatefulSets pour les bases de données, DaemonSets pour un Pod par nœud, Jobs et CronJobs pour le traitement ponctuel, opérateurs pour les applications qui gèrent leur propre cycle de vie.
• Stockage persistant et StorageClass : le provisionnement dynamique de volumes, sans lequel aucune donnée ne survit à un redéploiement.
• Scheduling et capacité : placement des Pods, quotas par namespace et autoscaling horizontal.

Le module Réseau et exposition mérite un mot, parce que c'est là que les débutants se perdent le plus. Un Service donne une adresse stable à un groupe de Pods : ClusterIP la rend joignable dans le cluster seulement, NodePort ouvre un port sur chaque nœud, LoadBalancer demande une adresse externe au fournisseur. Au-dessus, un Ingress ou la Gateway API ajoutent le routage HTTP par nom de domaine et par chemin, et les Network Policies filtrent les flux entre Pods.

Installer, opérer, réparer

Trois modules couvrent le métier d'administrateur, celui qui commence quand le cluster existe déjà.

• Options d'installation : kubeadm, Kubespray, Talos Linux, RKE2, k0s et le control plane hautement disponible.
• Administrer le cluster : la sauvegarde et la restauration d'etcd, puis le diagnostic d'un composant du control plane.
• Opérer au quotidien : le plus gros module du parcours, avec une méthode de diagnostic, la préparation d'une maintenance et la mise à jour d'un cluster.

Trois incidents concentrent l'essentiel des appels à l'aide, et chacun a sa leçon dédiée. Un CrashLoopBackOff signale un conteneur qui démarre puis meurt en boucle, donc un problème applicatif ou de configuration. Un Pod Pending n'a pas trouvé de machine capable de l'accueillir, donc un problème de capacité ou de contrainte de placement. Un ImagePullBackOff bloque avant même le démarrage, sur le téléchargement de l'image. Savoir lire cette différence évite des heures perdues au mauvais endroit.

Durcir le cluster et les workloads

Deux modules, 17 leçons au total, forment la partie la plus dense de la formation. Elle correspond au programme de la CKS et complète le hub transverse Sécuriser Kubernetes.

• Sécurité des workloads : le moindre privilège appliqué au conteneur, avec le Security Context, les ServiceAccounts et le RBAC.
• Sécuriser le cluster : audit CIS Benchmark, Pod Security Standards, admission controllers et le comparatif VAP, Kyverno ou Gatekeeper, sécurité de la chaîne d'approvisionnement, scan d'images, journaux d'audit et détection runtime avec Falco.

Pourquoi faut-il un orchestrateur quand on sait déjà utiliser Docker ?

Parce que Docker lance des conteneurs sur une machine, alors que la production impose de les répartir sur plusieurs, de les redémarrer sans intervention et de les mettre à jour sans coupure. Le tableau ci-dessous oppose le geste manuel et son équivalent Kubernetes.

Ce que vous faites à la main	Ce que Kubernetes fait pour vous
Démarrer chaque conteneur, machine par machine	Déclarer « 3 répliques » et laisser le Scheduler les placer
Surveiller et redémarrer après une panne	Les contrôleurs recréent le Pod sans intervention
Ajouter des serveurs quand le trafic monte	L'autoscaling ajuste les répliques selon la charge mesurée
Couper le service pour déployer une version	Rolling update progressif, avec retour arrière possible
Noter quelque part quel conteneur tourne où	L'état déclaré vit dans etcd et se lit avec kubectl get

Glissez pour voir

Le point décisif est la deuxième ligne. Avec Docker seul, la réparation dépend de quelqu'un qui la déclenche. Avec Kubernetes, l'écart entre l'état voulu et l'état réel est corrigé par une boucle automatique, à trois heures du matin comme à midi.

Quels prérequis faut-il avant de commencer Kubernetes ?

Trois compétences sont indispensables : administrer un Linux en ligne de commande, savoir construire et lancer un conteneur, et lire du YAML sans se tromper d'indentation. Le reste s'apprend ici.

Les fondamentaux Linux viennent en premier : terminal, permissions, services, lecture de journaux. Kubernetes ne remplace pas cette compétence, il la suppose, et le premier incident de cluster vous renverra directement vers journalctl sur un nœud.

Le socle conteneurs avec Docker vient ensuite. Kubernetes orchestre des conteneurs : si l'image, les couches, les variables d'environnement et les volumes ne sont pas clairs, tout le vocabulaire du cluster restera flou. Le YAML est le troisième pilier, tous les manifestes en dépendent.

Deux compétences sont recommandées sans être bloquantes. Les bases réseau TCP/IP rendent lisibles les Services, le DNS interne et les Network Policies. Et Git devient indispensable dès que vos manifestes sortent de votre poste. Comptez deux à quatre semaines pour ces bases si vous partez de zéro.

Ce que je défends

Cette formation a des opinions, et il vaut mieux les connaître avant de s'y engager.

On apprend sur un cluster local, pas sur un service managé. Un cluster k3d ou Kind démarre en moins d'une minute, ne coûte rien et se détruit sans conséquence. Un service managé masque justement ce qu'il faut comprendre : le control plane, etcd, les certificats. Payez pour un cluster managé quand vous saurez ce qu'il vous épargne.

Les images se référencent par digest, jamais par latest. Un tag est mutable : la même déclaration peut télécharger deux contenus différents à deux jours d'intervalle, ce qui rend un déploiement non reproductible et un incident inexplicable. La forme canonique image:tag@sha256:… fige le contenu exact, et c'est celle utilisée dans tous les manifestes du site.

Requests et limits ne sont pas optionnels. Un Pod sans requests fausse les décisions du Scheduler, un Pod sans limits peut consommer toute la mémoire d'un nœud et faire tomber des voisins innocents. C'est la première cause d'incident sur les clusters mal réglés, et le seul remède est de les déclarer dès le premier manifeste.

Le RBAC se conçoit en même temps que l'application. Un ServiceAccount dédié, un Role limité au namespace, et surtout pas le compte par défaut avec un ClusterRoleBinding vers cluster-admin posé « en attendant ». Ce genre de raccourci ne se retire jamais, et il transforme la compromission d'un conteneur en compromission du cluster.

Générer du YAML avec une IA n'est pas maîtriser Kubernetes. Un assistant produit un manifeste syntaxiquement valide en quelques secondes. Il ne diagnostique pas un Pod bloqué en CrashLoopBackOff, ne dit pas si une NetworkPolicy ouvre trop de flux, et n'explique pas pourquoi un HPA refuse de monter en charge. La compétence à construire est celle-là : comprendre ce qui se passe dans le cluster, et pourquoi.

Lecture conseillée

La référence absolue pour apprendre Kubernetes : Kubernetes in Action 2nd Edition, Marko Luksa. 800 pages d'explications progressives, à jour 1.27+. Le seul livre que je relis quand je doute d'un concept.

Lien affilié Amazon. Acheter via ce lien soutient le site sans surcoût pour vous.

Ce que je vous déconseille

Quatre erreurs reviennent assez souvent pour mériter d'être nommées avant que vous ne les commettiez.

Commencer par Helm. Empaqueter une application dont vous ne savez pas encore décrire les objets revient à masquer le sujet que vous devez apprendre. Écrivez d'abord des manifestes bruts, comprenez ce qu'un Deployment génère, puis abstrayez. Un chart mal compris est bien plus difficile à déboguer qu'un fichier YAML explicite.

Mettre une base de données en Deployment. Les répliques d'un Deployment sont interchangeables et n'ont ni identité stable ni volume attitré. Une base de données a besoin des deux, et c'est exactement ce que fournit un StatefulSet. L'erreur ne se voit pas au premier déploiement, elle se voit à la première perte de données.

Traiter les Secrets Kubernetes comme un coffre-fort. Un objet Secret est encodé en base64, pas chiffré. Sans chiffrement d'etcd au repos ni RBAC restrictif, toute personne qui lit l'objet lit la valeur. La leçon sur les Secrets explique ce qu'ils protègent réellement, et ce qu'il faut ajouter.

Viser la CKS avant d'avoir administré un cluster. Ce n'est pas seulement une règle d'inscription, la CKA est un prérequis obligatoire de la CKS. C'est aussi une question de sens : durcir un composant qu'on ne sait pas exploiter revient à appliquer une recette sans comprendre ce qu'elle casse.

Sur quel cluster les manipulations sont-elles validées ?

Toutes les commandes kubectl publiées sont exécutées sur un cluster local avant d'être écrites, avec la sortie réelle reprise dans le guide. Le cluster de référence est monté avec k3d ou Kind, deux outils qui font tourner Kubernetes dans des conteneurs sur votre poste.

Deux processeurs et 4 Go de mémoire suffisent pour suivre la quasi-totalité du parcours. Seuls les modules d'installation demandent davantage, puisqu'ils montent un cluster multi-nœuds avec kubeadm ou une distribution complète. Aucun compte cloud n'est nécessaire, à aucun moment.

Voici la forme minimale d'un manifeste conforme aux règles du site, avec l'image figée par digest et non par tag :

apiVersion: v1
kind: Pod
metadata:
  name: mon-pod
spec:
  containers:
    - name: nginx
      image: nginx:1.27-alpine@sha256:65645c7bb6a0661892a8b03b89d0743208a18dd2f3f17a54ef4b76fb8e2f2a10
      ports:
        - containerPort: 80

L'application et la vérification se font en deux commandes. La seconde doit afficher le Pod en état Running :

kubectl apply -f pod-nginx.yaml
kubectl get pod mon-pod -o wide

Les travaux pratiques complets vivent dans le dépôt containers-training. Ils reprennent chaque concept du parcours sous forme d'exercice guidé : création de Pods et de Deployments, configuration par ConfigMaps et Secrets, exposition par Services et Ingress, autoscaling et déploiement avec Helm.

Comment valider ses acquis et préparer les certifications CNCF ?

Trois dispositifs valident la compétence : un contrôle de connaissances de 15 questions en fin de fondamentaux, une banque de 1 189 questions par niveau, et 62 exercices chronométrés au format des examens pratiques.

Le contrôle de connaissances clôt le premier module : 15 questions en 10 minutes, objectif 80 %. En dessous, reprenez les trois leçons du module avant de continuer, sinon la suite du parcours reposera sur des bases incertaines. Un second bilan ferme le module des ressources de base.

La banque d'entraînement compte 1 189 questions réparties sur 58 thèmes, dont 175 de niveau débutant, 625 de niveau intermédiaire et 336 de niveau avancé. Elle est accessible par niveau depuis la page examens et sert de révision courte entre deux chapitres.

La CNCF propose cinq certifications Kubernetes, et non trois comme on le lit souvent. Deux sont des QCM de niveau associate, trois sont des examens 100 % pratiques où vous résolvez des tâches sur un vrai cluster en ligne de commande, documentation officielle accessible.

Certification	Pour qui	Format	Durée	Prérequis
KCNA	Découverte de Kubernetes et du cloud native	QCM	90 min	aucun
KCSA	Sécurité, niveau associate	QCM	90 min	aucun
CKAD	Développeurs qui déploient sur le cluster	Pratique	2 h	aucun
CKA	Administrateurs et SRE	Pratique	2 h	aucun
CKS	Sécurité avancée du cluster et des workloads	Pratique	2 h	CKA requise

Glissez pour voir

La différence entre CKA et CKAD ne porte pas sur la difficulté mais sur le point de vue : la CKA regarde le cluster depuis l'infrastructure, la CKAD depuis l'application qui tourne dessus. Choisissez celle qui correspond à votre quotidien, la révision sera bien plus rapide. Le comparatif complet, avec l'ordre de passage recommandé, se trouve dans choisir sa certification Kubernetes.

Chaque examen pratique dispose de son guide de préparation, de son aide-mémoire de commandes et de ses exercices chronométrés : 22 exercices pour la CKA, 20 pour la CKAD et 20 pour la CKS. Chacun suit le format de l'examen : énoncé court, objectif observable, contrainte de temps. Visez 80 % de réussite avant de réserver votre session.

FAQ : questions fréquentes sur Kubernetes

Voici les réponses aux questions que se posent le plus souvent les personnes qui débutent avec Kubernetes : ce qu'il fait, son coût, sa différence avec Docker, les prérequis, le temps d'apprentissage et le choix de la certification.

Qu'est-ce que Kubernetes et à quoi ça sert ?

**Kubernetes** (abrégé **K8s**) est un **orchestrateur de conteneurs** open source créé par Google, aujourd'hui maintenu par la **CNCF**. Il sert à **déployer**, mettre à l'échelle et **fiabiliser** des applications conteneurisées sur un ensemble de machines appelé **cluster**. ### Ce que Kubernetes fait pour vous | Sans Kubernetes | Avec Kubernetes | |---|---| | Démarrage manuel des conteneurs | Déploiement déclaratif automatisé | | Panne = intervention humaine | Auto-réparation : redémarrage et reprogrammation | | Montée en charge à la main | Autoscaling selon la charge réelle | | Mise à jour risquée | Rolling update et rollback intégrés | Concrètement, vous décrivez l'**état souhaité** de votre application dans des fichiers YAML, et Kubernetes se charge d'**atteindre puis de maintenir** cet état, même quand un serveur tombe en panne.

Kubernetes est-il gratuit ?

Oui, Kubernetes est open source et gratuit (licence Apache 2.0), maintenu par la CNCF. Vous ne payez que l'infrastructure qui l'heberge : vos propres serveurs, ou un service manage (GKE, EKS, AKS) qui facture les machines et parfois le plan de controle.

Quelle est la différence entre Docker et Kubernetes ?

C'est la confusion la plus fréquente chez les débutants. **Docker** et **Kubernetes** ne sont pas concurrents : ils agissent à deux niveaux différents et se **complètent**. ### Docker vs Kubernetes | Critère | Docker | Kubernetes | |---|---|---| | **Rôle** | Construit et exécute des conteneurs | Orchestre des conteneurs à grande échelle | | **Périmètre** | Une seule machine | Un **cluster** de machines | | **Résilience** | Aucune par défaut | Auto-réparation et réplication | | **Montée en charge** | Manuelle | Automatique via le **HPA** | En pratique : **Docker** (ou un autre moteur compatible **OCI**) fabrique l'image et lance le conteneur ; **Kubernetes** décide sur quelle machine le faire tourner, en combien d'exemplaires, et le relance s'il tombe. On utilise donc le plus souvent **les deux ensemble**.

Kubernetes ou Docker Swarm : lequel choisir ?

Docker Swarm est plus simple a demarrer mais limite ; Kubernetes est plus complexe mais standard de l'industrie, avec un ecosysteme immense et l'auto-reparation avancee. Pour apprendre et pour la production a grande echelle, Kubernetes s'est impose ; Swarm reste viable pour de petits cas.

Quels sont les prérequis pour apprendre Kubernetes ?

Avant de vous lancer dans Kubernetes, vous devez maîtriser **trois fondamentaux** indispensables. Sans eux, vous risquez de vous perdre dans la complexité de l'orchestration. ### Prérequis essentiels | Compétence | Niveau requis | Concepts clés | Temps d'acquisition | |------------|---------------|---------------|---------------------| | **Linux** | Intermédiaire | Terminal, permissions, processus, systemd | 2-4 semaines | | **Docker** | Intermédiaire | Images, conteneurs, volumes, Dockerfile | 2-3 semaines | | **YAML** | Débutant | Syntaxe, indentation, listes, dictionnaires | 2-3 jours | | **Réseau** | Bases | TCP/IP, DNS, ports, load balancing | 1-2 semaines | ### Commandes Linux à connaître ```bash # Gestion fichiers ls -la cd /var/log cat fichier.txt grep "error" /var/log/syslog # Gestion processus ps aux top kill -9 <PID> # Réseau curl http://localhost:8080 netstat -tuln ping google.com ``` ### Compétences Docker requises ```bash # Lancer un conteneur docker run -d -p 80:80 nginx # Construire une image docker build -t mon-app:v1 . # Inspecter docker ps docker logs <container> docker exec -it <container> /bin/sh ``` ### Syntaxe YAML pour Kubernetes ```yaml # Structure de base d'un manifest apiVersion: v1 kind: Pod metadata: name: mon-pod labels: app: nginx spec: containers: - name: nginx image: nginx:1.25 ports: - containerPort: 80 ``` ### Checklist avant de commencer - [ ] Savoir naviguer dans un terminal Linux - [ ] Comprendre les permissions (chmod, chown) - [ ] Lancer et gérer des conteneurs Docker - [ ] Écrire un Dockerfile simple - [ ] Comprendre la syntaxe YAML (indentation !) - [ ] Connaître les bases réseau (IP, ports, DNS)

Combien de temps faut-il pour maîtriser Kubernetes ?

Le temps d'apprentissage dépend de votre niveau de départ et de vos objectifs. Voici un **parcours réaliste** basé sur une pratique régulière. ### Roadmap d'apprentissage | Phase | Durée | Compétences acquises | Objectif | |-------|-------|---------------------|----------| | **Niveau 1 - Bases** | 2-4 semaines | Pods, Services, Deployments | Déployer une app simple | | **Niveau 2 - Configuration** | 4-6 semaines | ConfigMaps, Secrets, Probes, Volumes | App production-ready | | **Niveau 3 - Production** | 4-6 semaines | RBAC, Network Policies, HPA, Helm | Cluster sécurisé | | **Niveau 4 - Expert** | 2-3 mois | Opérateurs, CRD, troubleshooting avancé | Architecture K8s | ### Estimation totale - **Bases opérationnelles** : 1-2 mois - **Prêt pour la production** : 3-4 mois - **Certification CKA/CKAD** : 4-6 mois - **Expert/Architecte** : 12+ mois ### Planning hebdomadaire recommandé ``` Lundi-Vendredi : 30-60 min/jour (théorie + pratique) Week-end : 2-3h (projet pratique, TP) Exemple semaine 1 : - Lun : Architecture K8s (vidéo + lecture) - Mar : Installation Minikube (pratique) - Mer : Premier Pod (hands-on) - Jeu : Deployments (théorie + pratique) - Ven : Services (ClusterIP, NodePort) - Sam : TP complet - déployer une app ``` ### Facteurs d'accélération | Facteur | Impact | Conseil | |---------|--------|--------| | **Pratique quotidienne** | ★★★ | 30 min/jour > 4h/week-end | | **Projets réels** | ★★★ | Déployer votre propre app | | **Cluster local** | ★★ | Minikube/Kind toujours disponible | | **Communauté** | ★★ | Slack CNCF, forums, meetups | | **TP guidés** | ★★ | Suivre des exercices structurés | ### Erreurs qui ralentissent - ❌ Lire sans pratiquer - ❌ Sauter les prérequis (Docker, Linux) - ❌ Vouloir tout apprendre d'un coup - ❌ Ne pas comprendre les erreurs (copier/coller) - ❌ Ignorer les logs et événements

CKA ou CKAD : quelle certification Kubernetes choisir ?

Les deux certifications sont **100% pratiques** (2h sur un vrai cluster). Le choix dépend de votre **profil métier** et de vos objectifs. ### Comparatif CKA vs CKAD | Critère | CKA | CKAD | |---------|-----|------| | **Public cible** | Admins, SRE, DevOps | Développeurs | | **Focus** | Cluster (installation, sécurité, troubleshooting) | Applications (déploiement, configuration) | | **Durée** | 2 heures | 2 heures | | **Questions** | 15-20 | 15-20 | | **Score requis** | 66% | 66% | | **Prérequis** | 6-12 mois pratique K8s | 3-6 mois pratique K8s | | **Difficulté** | ★★★ | ★★☆ | | **Validité** | 3 ans | 3 ans | | **Prix** | $395 | $395 | ### Domaines CKA (Administrateur) ``` Cluster Architecture (25%) ├── Installation avec kubeadm ├── Upgrade cluster └── Backup/restore etcd Workloads & Scheduling (15%) ├── Deployments, scaling ├── ConfigMaps, Secrets └── Node affinity, taints Services & Networking (20%) ├── Services (ClusterIP, NodePort, LB) ├── Ingress controllers └── Network Policies Storage (10%) ├── PV, PVC ├── StorageClass └── Volume modes Troubleshooting (30%) ├── Logs, events ├── Cluster components └── Application debugging ``` ### Domaines CKAD (Développeur) ``` Application Design & Build (20%) ├── Dockerfile, multi-container Pods ├── Init containers └── Volumes Application Deployment (20%) ├── Deployments, rolling updates ├── Helm basics └── Blue/green, canary Application Observability (15%) ├── Probes (liveness, readiness) ├── Logs, debugging └── Monitoring basics Application Environment (25%) ├── ConfigMaps, Secrets ├── ServiceAccounts └── Resources (requests, limits) Services & Networking (20%) ├── Services ├── Ingress └── Network Policies ``` ### Quel choix selon votre profil ? | Votre profil | Certification recommandée | |--------------|---------------------------| | Développeur backend/frontend | **CKAD** puis CKA | | Admin système / SRE | **CKA** puis CKAD | | DevOps Engineer | **CKA** puis CKAD | | Architecte Cloud | **CKA** + CKAD | | Reconversion | **CKAD** (plus accessible) | ### Conseil stratégique Si vous hésitez, commencez par la **CKAD** : - Courbe d'apprentissage plus douce - Compétences directement applicables - Prépare le terrain pour la CKA

Peut-on apprendre Kubernetes sans viser de certification ?

**Absolument.** La certification valide vos compétences, mais la vraie valeur est dans ce que vous **savez faire concrètement**. Beaucoup de professionnels utilisent K8s quotidiennement sans certification. ### Certification vs Compétences réelles | Aspect | Sans certification | Avec certification | |--------|-------------------|--------------------| | **Compétences** | Identiques si pratique régulière | Validées officiellement | | **Employabilité** | Démo portfolio + expérience | Badge reconnu + filtre ATS | | **Salaire** | Négociation sur expérience | +10-15% en moyenne | | **Coût** | 0€ | $395 + temps préparation | | **Stress** | Apprentissage libre | Examen chronométré | ### Quand la certification est utile ✅ **Recommandée si** : - Recherche d'emploi (filtre automatique des CV) - Changement de carrière (preuve de compétence) - Entreprise qui valorise les certifications - Besoin de structurer son apprentissage - Client exige des certifications (consulting) ❌ **Pas nécessaire si** : - Poste actuel utilise déjà K8s - Portfolio de projets démontrable - Petite structure / startup - Budget limité ### Alternative : construire un portfolio ```bash # Projets qui démontrent vos compétences : 1. Déployer une app multi-tier └── Frontend + Backend + Base de données └── Ingress avec TLS └── ConfigMaps, Secrets 2. Pipeline CI/CD complet └── Build Docker └── Push registry └── Deploy sur K8s └── Tests automatisés 3. Monitoring stack └── Prometheus + Grafana └── Alerting └── Dashboards custom 4. GitOps avec ArgoCD └── Repo Git = source de vérité └── Sync automatique └── Rollback facile ``` ### Parcours sans certification | Étape | Durée | Livrable | |-------|-------|----------| | Bases K8s | 1 mois | App déployée sur Minikube | | Production-ready | 1 mois | App avec Probes, ConfigMaps, Secrets | | CI/CD | 2 semaines | Pipeline GitLab/GitHub Actions | | Monitoring | 2 semaines | Stack Prometheus/Grafana | | Projet perso | 1 mois | App complète sur repo GitHub | ### Conseil Concentrez-vous d'abord sur la **pratique**. Si vous maîtrisez K8s concrètement, la certification devient une formalité (1-2 semaines de révision suffisent).

Comment pratiquer Kubernetes sans serveur cloud ?

Plusieurs solutions permettent de créer un **cluster Kubernetes local** gratuitement sur votre machine. C'est suffisant pour **90% de l'apprentissage**. ### Comparatif des solutions locales | Outil | Ressources | Installation | Cas d'usage | Recommandé pour | |-------|------------|--------------|-------------|------------------| | **Minikube** | 2 CPU, 4 GB RAM | Facile | Dev, apprentissage | Débutants ★★★ | | **Kind** | 2 CPU, 2 GB RAM | Très facile | CI/CD, tests | DevOps ★★★ | | **K3s** | 1 CPU, 512 MB RAM | Facile | Edge, IoT, léger | Production légère ★★ | | **Docker Desktop** | 4 CPU, 8 GB RAM | Intégré | Dev Mac/Windows | Développeurs ★★ | | **Rancher Desktop** | 4 CPU, 4 GB RAM | Facile | Alternative Docker Desktop | Multi-runtime ★★ | ### Installation Minikube (recommandé) ```bash # Linux curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 sudo install minikube-linux-amd64 /usr/local/bin/minikube # macOS brew install minikube # Windows (PowerShell admin) winget install minikube # Démarrer le cluster minikube start --cpus=2 --memory=4096 # Vérifier kubectl get nodes minikube status # Addons utiles minikube addons enable ingress minikube addons enable metrics-server minikube addons enable dashboard # Accéder au dashboard minikube dashboard ``` ### Installation Kind (Kubernetes in Docker) ```bash # Installation curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.20.0/kind-linux-amd64 chmod +x ./kind sudo mv ./kind /usr/local/bin/kind # Créer un cluster kind create cluster --name mon-cluster # Cluster multi-nœuds cat <<EOF | kind create cluster --config=- kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes: - role: control-plane - role: worker - role: worker EOF # Supprimer kind delete cluster --name mon-cluster ``` ### Premier déploiement de test ```bash # Créer un deployment kubectl create deployment nginx --image=nginx # Exposer le service kubectl expose deployment nginx --port=80 --type=NodePort # Voir le résultat kubectl get pods,svc # Accéder (Minikube) minikube service nginx # Nettoyer kubectl delete deployment nginx kubectl delete service nginx ``` ### Ressources machine recommandées | Niveau | RAM | CPU | Disque | |--------|-----|-----|--------| | Minimum | 8 GB | 2 cores | 20 GB | | Confortable | 16 GB | 4 cores | 50 GB | | Multi-clusters | 32 GB | 8 cores | 100 GB | ### Alternatives cloud gratuites Si votre machine est limitée : - **Killercoda** : Labs K8s gratuits dans le navigateur - **Play with Kubernetes** : Cluster éphémère (4h) - **Google Cloud Free Tier** : $300 crédits - **AWS Free Tier** : t2.micro (limité mais gratuit)

Quel parcours suivre pour devenir administrateur Kubernetes (CKA) ?

Le parcours **administrateur Kubernetes** mène à la certification **CKA** et aux postes SRE/DevOps. Il couvre l'installation, la configuration, la sécurité et le troubleshooting de clusters. ### Roadmap CKA complète | Phase | Durée | Thèmes | Validation | |-------|-------|--------|------------| | **1. Fondamentaux** | 2-4 sem | Architecture, kubectl, Pods | Quiz architecture | | **2. Workloads** | 3-4 sem | Deployments, Services, ConfigMaps | App déployée | | **3. Cluster Admin** | 4-6 sem | kubeadm, etcd, upgrades | Cluster installé | | **4. Stockage** | 2-3 sem | PV, PVC, StorageClass | Volume persistant | | **5. Réseau** | 3-4 sem | Services, Ingress, Network Policies | App exposée + sécurisée | | **6. Sécurité** | 3-4 sem | RBAC, ServiceAccounts, secrets | Cluster hardened | | **7. Troubleshooting** | 3-4 sem | Logs, events, debugging | Incidents résolus | | **8. Préparation exam** | 2-4 sem | Killer.sh, examens blancs | Score >75% | ### Phase 1 : Architecture (semaines 1-4) ```bash # Comprendre les composants kubectl get nodes kubectl get pods -n kube-system # Control Plane # - kube-apiserver : point d'entrée API # - etcd : stockage cluster # - kube-scheduler : placement Pods # - kube-controller-manager : boucles de contrôle # Worker Nodes # - kubelet : agent sur chaque nœud # - kube-proxy : règles réseau # - container runtime : containerd/CRI-O # Commandes essentielles kubectl cluster-info kubectl get componentstatuses kubectl describe node <node-name> ``` ### Phase 3 : Installation cluster (kubeadm) ```bash # Sur le control plane sudo kubeadm init --pod-network-cidr=10.244.0.0/16 # Configurer kubectl mkdir -p $HOME/.kube sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config # Installer CNI (Calico) kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml # Joindre les workers kubeadm token create --print-join-command # Sur chaque worker : sudo kubeadm join <control-plane>:6443 --token ... --discovery-token-ca-cert-hash ... # Backup etcd (critique !) ETCDCTL_API=3 etcdctl snapshot save backup.db \ --endpoints=https://127.0.0.1:2379 \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key ``` ### Phase 6 : Sécurité RBAC ```yaml # Role : permissions dans un namespace apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: dev name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch"] --- # RoleBinding : assigner le Role apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-pods namespace: dev subjects: - kind: User name: alice roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io ``` ### Phase 7 : Troubleshooting (30% de l'examen !) ```bash # Diagnostic Pod kubectl describe pod <pod-name> kubectl logs <pod-name> --previous kubectl get events --sort-by='.lastTimestamp' # Diagnostic Node kubectl describe node <node-name> ssh <node> systemctl status kubelet ssh <node> journalctl -u kubelet -f # Diagnostic Cluster kubectl get componentstatuses kubectl get pods -n kube-system sudo crictl ps # sur le nœud # Erreurs fréquentes # CrashLoopBackOff → kubectl logs # ImagePullBackOff → vérifier image/registry # Pending → kubectl describe (events) # OOMKilled → augmenter limits ``` ### Checklist avant examen CKA - [ ] Cluster installé avec kubeadm (from scratch) - [ ] Backup/restore etcd fonctionnel - [ ] Upgrade cluster maîtrisé - [ ] RBAC configuré (Role, RoleBinding) - [ ] Network Policies appliquées - [ ] Ingress controller déployé - [ ] Troubleshooting : 5 scénarios résolus - [ ] Killer.sh : 2 sessions complètes - [ ] Temps : chaque question <5 min

Quel parcours suivre pour un développeur sur Kubernetes (CKAD) ?

Le parcours **développeur Kubernetes** mène à la certification **CKAD**. L'objectif : savoir **packager, déployer et configurer** vos applications pour qu'elles tournent sur K8s. ### Roadmap CKAD complète | Phase | Durée | Thèmes | Validation | |-------|-------|--------|------------| | **1. Conteneurs** | 1-2 sem | Dockerfile, images, registries | Image buildée et pushée | | **2. Pods** | 2-3 sem | Pods, multi-containers, init containers | Pod complexe déployé | | **3. Deployments** | 2-3 sem | Deployments, rolling updates, rollback | App scalée | | **4. Configuration** | 3-4 sem | ConfigMaps, Secrets, env vars | App configurée | | **5. Observabilité** | 2-3 sem | Probes, logs, debugging | App résiliente | | **6. Services** | 2-3 sem | Services, Ingress | App exposée | | **7. Packaging** | 2-3 sem | Helm, Kustomize | Chart Helm créé | | **8. Préparation** | 2-3 sem | Killer.sh, examens blancs | Score >75% | ### Phase 2 : Maîtriser les Pods ```yaml # Pod multi-containers apiVersion: v1 kind: Pod metadata: name: app-with-sidecar spec: initContainers: - name: init-db image: busybox command: ['sh', '-c', 'until nc -z db-service 5432; do sleep 2; done'] containers: - name: app image: mon-app:v1 ports: - containerPort: 8080 volumeMounts: - name: shared-logs mountPath: /var/log/app - name: log-shipper image: fluent/fluent-bit volumeMounts: - name: shared-logs mountPath: /var/log/app volumes: - name: shared-logs emptyDir: {} ``` ### Phase 4 : Configuration (ConfigMaps & Secrets) ```yaml # ConfigMap apiVersion: v1 kind: ConfigMap metadata: name: app-config data: DATABASE_HOST: "postgres.default.svc" LOG_LEVEL: "info" config.json: | { "feature_x": true, "max_connections": 100 } --- # Secret apiVersion: v1 kind: Secret metadata: name: app-secrets type: Opaque stringData: DATABASE_PASSWORD: "super-secret" API_KEY: "abc123" --- # Utilisation dans un Pod apiVersion: v1 kind: Pod metadata: name: app spec: containers: - name: app image: mon-app:v1 envFrom: - configMapRef: name: app-config - secretRef: name: app-secrets volumeMounts: - name: config-volume mountPath: /etc/config volumes: - name: config-volume configMap: name: app-config ``` ### Phase 5 : Probes (résilience) ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: app spec: replicas: 3 template: spec: containers: - name: app image: mon-app:v1 resources: requests: cpu: "100m" memory: "128Mi" limits: cpu: "500m" memory: "512Mi" livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 10 periodSeconds: 5 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 5 periodSeconds: 3 startupProbe: httpGet: path: /healthz port: 8080 failureThreshold: 30 periodSeconds: 10 ``` ### Phase 7 : Helm basics ```bash # Créer un chart helm create mon-app # Structure mon-app/ ├── Chart.yaml ├── values.yaml ├── templates/ │ ├── deployment.yaml │ ├── service.yaml │ └── ingress.yaml # Installer helm install mon-app ./mon-app -f values-prod.yaml # Mettre à jour helm upgrade mon-app ./mon-app --set image.tag=v2 # Rollback helm rollback mon-app 1 ``` ### Raccourcis kubectl (vitesse = clé CKAD) ```bash # Créer rapidement kubectl run nginx --image=nginx --port=80 kubectl create deployment nginx --image=nginx --replicas=3 kubectl expose deployment nginx --port=80 --type=NodePort # Générer YAML (ne pas écrire from scratch !) kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml kubectl create deployment nginx --image=nginx --dry-run=client -o yaml > deploy.yaml # Alias essentiels alias k=kubectl export do="--dry-run=client -o yaml" # Exemples k run nginx --image=nginx $do > pod.yaml k create deploy nginx --image=nginx $do > deploy.yaml ``` ### Checklist avant examen CKAD - [ ] Pods multi-containers maîtrisés - [ ] ConfigMaps et Secrets (envFrom, volumeMounts) - [ ] Probes (liveness, readiness, startup) - [ ] Resources (requests, limits) - [ ] Services et Ingress - [ ] Jobs et CronJobs - [ ] Helm install/upgrade/rollback - [ ] Raccourcis kubectl fluides - [ ] Killer.sh : 2 sessions complètes - [ ] Chaque question <4 min

La certification CKS (sécurité) vaut-elle le coup ?

La **CKS** (Certified Kubernetes Security Specialist) est la certification **la plus avancée**. Elle s'adresse aux professionnels expérimentés qui veulent se spécialiser en sécurité Kubernetes. ### Prérequis et positionnement | Critère | CKS | |---------|-----| | **Prérequis** | CKA valide (obligatoire) | | **Expérience recommandée** | 1-2 ans K8s en production | | **Durée examen** | 2 heures | | **Score requis** | 67% | | **Validité** | 2 ans (vs 3 ans CKA/CKAD) | | **Prix** | $395 | | **Difficulté** | ★★★★ (la plus difficile) | ### Domaines couverts ``` Cluster Setup (10%) ├── Network Policies pour isoler les Pods ├── CIS Kubernetes Benchmark └── Ingress avec TLS Cluster Hardening (15%) ├── RBAC : moindre privilège ├── ServiceAccounts : tokens, automount └── Restriction des API non nécessaires System Hardening (15%) ├── Réduire la surface d'attaque (AppArmor, seccomp) ├── Limiter les syscalls └── Kernel hardening Minimize Microservice Vulnerabilities (20%) ├── SecurityContext (runAsNonRoot, readOnlyRootFilesystem) ├── Pod Security Standards ├── Gestion des Secrets (encryption at rest) └── Runtime sandboxing (gVisor, Kata) Supply Chain Security (20%) ├── Scan d'images (Trivy, Grype) ├── Signature d'images (Cosign, Notary) ├── Admission controllers (OPA Gatekeeper, Kyverno) └── Base images minimales Monitoring & Logging (20%) ├── Audit logs Kubernetes ├── Détection d'anomalies (Falco) └── Analyse comportementale ``` ### Exemple : Pod Security ```yaml apiVersion: v1 kind: Pod metadata: name: secure-pod spec: securityContext: runAsNonRoot: true runAsUser: 1000 fsGroup: 2000 containers: - name: app image: mon-app:v1 securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities: drop: - ALL resources: limits: cpu: "500m" memory: "512Mi" ``` ### Pour qui est la CKS ? ✅ **Recommandée si** : - Security Engineer / DevSecOps - SRE senior responsable de la sécurité - Consultant sécurité cloud - Architecte avec focus sécurité - Évolution de carrière vers la sécurité ❌ **Pas prioritaire si** : - Moins de 1 an d'expérience K8s - Rôle purement développeur - Pas de responsabilité sécurité - CKA pas encore obtenue ### ROI de la CKS | Bénéfice | Impact | |----------|--------| | Salaire | +15-25% vs CKA seule | | Postes accessibles | Security Engineer, DevSecOps | | Crédibilité | Expertise reconnue | | Rareté | Moins de 10% des certifiés K8s | ### Parcours recommandé ``` 1. CKA (6-12 mois expérience K8s) ↓ 2. Production K8s (6-12 mois) ↓ 3. CKS (focus sécurité) ```

Quelles ressources pour se préparer aux certifications Kubernetes ?

La préparation aux certifications K8s combine **théorie**, **pratique intensive** et **simulation d'examen**. Voici les meilleures ressources par catégorie. ### Ressources officielles (gratuites) | Ressource | Type | URL | Usage | |-----------|------|-----|-------| | **kubernetes.io/docs** | Documentation | kubernetes.io | Référence pendant l'examen | | **Kubernetes The Hard Way** | Tutorial | github.com/kelseyhightower | Comprendre les internals | | **CNCF Training** | Cours gratuits | training.linuxfoundation.org | Bases solides | ### Plateformes de formation (payantes) | Plateforme | Prix | Points forts | Recommandé pour | |------------|------|--------------|------------------| | **Killer.sh** | Inclus exam | Simulateur identique | Tous (essentiel) | | **KodeKloud** | $15-30/mois | Labs interactifs, parcours complet | Débutants → CKA/CKAD | | **Udemy (Mumshad)** | $15-30 | Cours + labs, très complet | CKA/CKAD | | **A Cloud Guru** | $35/mois | Multicloud, certifications | Multi-certifications | | **Linux Foundation** | $300+ | Officiel, certification bundle | Budget entreprise | ### Killer.sh : le simulateur essentiel ```bash # Inclus avec l'inscription à l'examen CNCF # 2 sessions de simulation (36h chacune) # Environnement identique à l'examen Conseils Killer.sh : 1. Faire la 1ère session 2 semaines avant l'examen 2. Analyser chaque erreur en détail 3. Refaire les questions ratées 4. Faire la 2ème session 3-5 jours avant 5. Viser >80% avant de passer l'examen réel ``` ### Labs pratiques gratuits | Plateforme | Durée | Niveau | Accès | |------------|-------|--------|-------| | **Killercoda** | Illimité | Débutant-Intermédiaire | killercoda.com | | **Play with K8s** | 4h/session | Débutant | labs.play-with-k8s.com | | **Katacoda** | Variable | Tous | katacoda.com | | **Google Qwiklabs** | Crédits | Intermédiaire | qwiklabs.com | ### Livres recommandés ``` Débutant : - "Kubernetes: Up and Running" (O'Reilly) - "The Kubernetes Book" (Nigel Poulton) CKA/CKAD : - "Certified Kubernetes Administrator Study Guide" (Benjamin Muschko) - "Certified Kubernetes Application Developer Study Guide" (Benjamin Muschko) Avancé : - "Production Kubernetes" (O'Reilly) - "Kubernetes Patterns" (O'Reilly) ``` ### Planning de révision optimisé ``` 8 semaines avant : ├── Semaine 1-2 : Cours complet (KodeKloud/Udemy) ├── Semaine 3-4 : Labs pratiques intensifs ├── Semaine 5-6 : Killer.sh session 1 + révision points faibles ├── Semaine 7 : Killer.sh session 2 └── Semaine 8 : Révision finale + examen Quotidien (dernières 2 semaines) : ├── 30 min : Révision théorie (domaines faibles) ├── 60 min : Pratique kubectl (sans doc) └── 30 min : Questions type examen ``` ### Checklist pré-examen - [ ] Documentation K8s bookmarkée (sections utiles) - [ ] Alias kubectl configurés (`alias k=kubectl`) - [ ] Killer.sh : score >75% sur les 2 sessions - [ ] Chaque domaine d'examen couvert - [ ] Vitesse : <5 min par question - [ ] Environnement test : webcam, micro, pièce calme - [ ] ID valide prêt - [ ] Check technique PSI (navigateur, webcam)

Kubernetes est-il indispensable pour un DevOps ?

Kubernetes est devenu le **standard de facto** pour l'orchestration de conteneurs. Sa maîtrise est un **atout majeur** pour tout profil DevOps, même si vous n'administrez pas directement de clusters. ### Kubernetes dans l'écosystème DevOps | Domaine DevOps | Rôle de Kubernetes | Importance | |----------------|-------------------|------------| | **CI/CD** | Target de déploiement | ★★★ Essentiel | | **Infrastructure as Code** | Manifests YAML, Helm | ★★★ Essentiel | | **GitOps** | ArgoCD, Flux | ★★★ Essentiel | | **Monitoring** | Prometheus, Grafana | ★★★ Essentiel | | **Sécurité** | RBAC, Network Policies | ★★ Important | | **Logging** | ELK, Loki | ★★ Important | ### Statistiques du marché (2024-2025) ``` Adoption Kubernetes : ├── 96% des organisations utilisent ou évaluent K8s (CNCF Survey) ├── 78% en production ├── 5.6M+ développeurs utilisent K8s └── Croissance : +30% par an Offres d'emploi DevOps : ├── 85% mentionnent Kubernetes ├── 70% mentionnent Docker ├── 60% mentionnent Terraform └── K8s = compétence #1 demandée Salaires DevOps (France, 2024) : ├── Sans K8s : 45-55k€ ├── Avec K8s : 55-70k€ ├── Expert K8s : 70-90k€ └── +20-30% avec certifications ``` ### Profils DevOps et niveau K8s requis | Profil | Niveau K8s requis | Compétences clés | |--------|-------------------|------------------| | **DevOps Junior** | Bases | Deployments, Services, kubectl | | **DevOps Engineer** | Intermédiaire | Helm, CI/CD, monitoring | | **SRE** | Avancé | Troubleshooting, scaling, sécurité | | **Platform Engineer** | Expert | Architecture, opérateurs, multi-cluster | | **DevSecOps** | Avancé | RBAC, Network Policies, scanning | ### Pipeline CI/CD typique avec K8s ```yaml # .gitlab-ci.yml stages: - build - test - deploy build: stage: build script: - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA . - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA deploy-staging: stage: deploy script: - kubectl config use-context staging - helm upgrade --install app ./chart \ --set image.tag=$CI_COMMIT_SHA - kubectl rollout status deployment/app deploy-prod: stage: deploy script: - kubectl config use-context production - helm upgrade --install app ./chart \ --set image.tag=$CI_COMMIT_SHA when: manual only: - main ``` ### Alternatives à Kubernetes | Solution | Cas d'usage | Quand préférer | |----------|-------------|----------------| | **Docker Compose** | Dev local, petites apps | <10 conteneurs, 1 serveur | | **Docker Swarm** | Simplicité, petit cluster | Équipe petite, migration Docker | | **Nomad** | Multi-workload | VMs + conteneurs + batch | | **ECS/Fargate** | AWS native | 100% AWS, serverless | | **Cloud Run** | GCP serverless | Apps stateless, scaling auto | ### Conclusion **Kubernetes n'est pas obligatoire**, mais sa maîtrise : - Ouvre 85% des offres DevOps - Augmente le salaire de 20-30% - Permet de travailler sur des projets complexes - Est transférable (tous les clouds, on-premise) **Recommandation** : même si vous n'administrez pas de clusters, comprenez les concepts (Pods, Services, Deployments) pour collaborer efficacement avec les équipes infra et débugger en production.

Où trouver un tuto Kubernetes gratuit et complet ?

Ce parcours est un tuto Kubernetes gratuit et complet : plus de 50 guides pas à pas, du premier pod jusqu'à l'administration et la sécurité d'un cluster, avec des travaux pratiques sur un cluster local k3d ou minikube. Aucune inscription ni paiement.

Existe-t-il une formation Kubernetes avancée de niveau expert ?

Oui. Après les fondamentaux, le parcours couvre des sujets avancés : sécurité et durcissement (RBAC, Network Policies, CKS), opération en production (monitoring, autoscaling HPA, maintenance) et préparation aux certifications CKA, CKAD et CKS de niveau administrateur et expert.

×

📖 Voir la documentation →