1. Quelle est la difference entre un conteneur Docker et une machine virtuelle ?
Une VM virtualise le hardware complet avec un hyperviseur, incluant un OS complet par instance. Un conteneur Docker partage le noyau de l'hote et isole les processus avec les namespaces et cgroups Linux. Consequences : les conteneurs demarrent en secondes (vs minutes pour une VM), consomment moins de ressources (Mo vs Go), et sont plus denses (dizaines de conteneurs vs quelques VM par hote). Les VM offrent une isolation plus forte (noyau separe) et supportent differents OS. Les conteneurs sont ideaux pour les microservices et le deploiement rapide. En production, on combine souvent les deux : conteneurs sur des VM pour la securite et l'isolation multi-tenant.
2. Expliquez les concepts de Dockerfile et les bonnes pratiques.
Un Dockerfile definit les instructions pour construire une image. Instructions cles : FROM (image de base), RUN (executer des commandes), COPY/ADD (copier des fichiers), WORKDIR (repertoire de travail), ENV (variables d'environnement), EXPOSE (port documente), CMD/ENTRYPOINT (commande par defaut). Bonnes pratiques : utiliser des images de base slim ou alpine (plus legeres et securisees). Multi-stage builds pour separer la compilation du runtime (reduire la taille finale). Ordonner les instructions du moins au plus changeant pour exploiter le cache de layers. Un seul processus par conteneur. Utiliser .dockerignore pour exclure les fichiers inutiles. Ne jamais inclure de secrets dans l'image.
3. Comment fonctionne le networking dans Docker ?
Docker offre plusieurs drivers reseau. bridge (par defaut) : reseau prive entre conteneurs sur le meme hote, NAT pour l'acces externe. Les conteneurs se resolvent par nom sur les reseaux custom (DNS integre). host : le conteneur partage le reseau de l'hote (pas d'isolation, meilleures performances). overlay : reseau multi-hote pour Docker Swarm ou Kubernetes. none : pas de reseau. Les ports sont exposes avec -p host:container. Les reseaux custom isolent les groupes de conteneurs (frontend ne voit pas la database sauf si sur le meme reseau). Docker Compose cree automatiquement un reseau pour les services. En production Kubernetes, chaque Pod a sa propre IP et les services gerent la decouverte.
4. Qu'est-ce que Docker Compose et quand l'utiliser ?
Docker Compose definit et orchestre des applications multi-conteneurs via un fichier docker-compose.yml. Chaque service a sa configuration : image, ports, volumes, variables d'environnement, dependances (depends_on). Commandes : docker compose up (demarrer), down (arreter), logs (voir les logs), exec (executer une commande). Ideal pour : le developpement local (reproduire l'environnement de production), les tests d'integration (base de donnees + app + cache), les demos. Pas recommande pour la production a grande echelle (utiliser Kubernetes). Les volumes nommes persistent les donnees. Les healthchecks definissent quand un service est pret. Les profiles permettent de demarrer des sous-ensembles de services.
5. Expliquez l'architecture de Kubernetes et ses composants principaux.
Control Plane : API Server (point d'entree, toutes les communications passent par lui), etcd (stockage cle-valeur distribue pour l'etat du cluster), Scheduler (place les Pods sur les noeuds selon les ressources et contraintes), Controller Manager (gere les controleurs : ReplicaSet, Deployment, etc.). Worker Nodes : kubelet (agent sur chaque noeud, gere les conteneurs), kube-proxy (gestion du reseau et des services), container runtime (containerd ou CRI-O). Ressources fondamentales : Pod (unite minimale, un ou plusieurs conteneurs), Service (exposition reseau stable), Deployment (gestion declarative des ReplicaSets), ConfigMap/Secret (configuration), PersistentVolume (stockage).
6. Comment fonctionne le deploiement dans Kubernetes (Deployment, Rolling Update) ?
Un Deployment gere de maniere declarative les ReplicaSets et les Pods. Il definit l'image, le nombre de replicas, les ressources, et la strategie de mise a jour. Rolling Update (par defaut) : remplace les anciens Pods progressivement (maxUnavailable et maxSurge controlent le rythme). Zero-downtime si les readiness probes sont bien configurees. Recreate : arrete tous les anciens Pods avant de creer les nouveaux (downtime). Rollback : kubectl rollout undo revient a la revision precedente. L'historique des revisions est conserve (revisionHistoryLimit). Les canary deployments deploient la nouvelle version sur un petit pourcentage de Pods. Les blue-green deployments utilisent deux environments identiques avec un switch de service.
7. Qu'est-ce que les Services Kubernetes et comment exposent-ils les applications ?
Un Service fournit une IP et un DNS stables pour acceder a un ensemble de Pods (selectionnes par labels). Types : ClusterIP (par defaut, accessible uniquement dans le cluster), NodePort (expose sur un port de chaque noeud, range 30000-32767), LoadBalancer (cree un load balancer cloud externe), ExternalName (alias DNS vers un service externe). L'Ingress est un reverse proxy HTTP/HTTPS au-dessus des services, gerant le routage par host/path, le TLS, et le rate limiting. Controllers Ingress populaires : Nginx, Traefik, HAProxy. Service Mesh (Istio, Linkerd) ajoute mTLS, observabilite et traffic management entre les services.
8. Comment gerer la configuration et les secrets dans Kubernetes ?
ConfigMap : stocke la configuration non-sensible (fichiers de config, variables d'environnement). Montable comme volume ou injectee en variables d'environnement. Secret : stocke les donnees sensibles (mot de passe, token, cle), encodees en base64 (pas chiffrees par defaut). Montable comme volume (fichiers) ou variables d'environnement. Bonnes pratiques : activer le chiffrement au repos des Secrets dans etcd. Utiliser des outils externes : Sealed Secrets (chiffrement dans Git), External Secrets Operator (synchronisation avec Vault, AWS Secrets Manager), SOPS (chiffrement de fichiers). Ne jamais commiter des Secrets en clair dans Git. Limiter l'acces aux Secrets avec RBAC.
9. Expliquez les probes Kubernetes (liveness, readiness, startup).
Les probes permettent a Kubernetes de verifier la sante des conteneurs. Liveness probe : verifie que le conteneur fonctionne. Si elle echoue, Kubernetes redemarre le conteneur. Utiliser pour detecter les deadlocks ou les etats bloques. Readiness probe : verifie que le conteneur est pret a recevoir du trafic. Si elle echoue, le Pod est retire du Service (plus de trafic). Utiliser pour les dependances externes (base de donnees, cache). Startup probe : verifie que l'application a demarre. Tant qu'elle n'a pas reussi, les autres probes sont desactivees. Pour les applications lentes au demarrage. Types : HTTP GET, TCP Socket, Exec (commande). Configurer initialDelaySeconds, periodSeconds, failureThreshold selon l'application.
10. Comment gerer le scaling et les ressources dans Kubernetes ?
Requests : ressources minimales garanties pour un Pod (utilisees par le scheduler). Limits : ressources maximales (le conteneur est throttle pour le CPU, OOMKilled pour la memoire si depasse). Toujours definir requests et limits. HPA (Horizontal Pod Autoscaler) : ajuste le nombre de replicas selon les metriques (CPU, memoire, metriques custom). VPA (Vertical Pod Autoscaler) : ajuste les requests/limits automatiquement (redemarrage necessaire). Cluster Autoscaler : ajoute ou supprime des noeuds selon les Pods en attente. PodDisruptionBudget : garantit un nombre minimum de Pods disponibles pendant les operations de maintenance. Resource Quotas et LimitRanges au niveau namespace pour le multi-tenant. Monitorer avec Prometheus et Grafana pour anticiper les besoins de scaling.