1. Quelle est la différence 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'hôte et isole les processus avec les namespaces et cgroups Linux. Conséquences : 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 hôte). Les VM offrent une isolation plus forte (noyau separe) et supportent différents OS. Les conteneurs sont idéaux pour les microservices et le déploiement rapide. En production, on combine souvent les deux : conteneurs sur des VM pour la sécurité et l'isolation multi-tenant.
2. Expliquez les concepts de Dockerfile et les bonnes pratiques.
Un Dockerfile définit les instructions pour construire une image. Instructions clés : FROM (image de base), RUN (exécuter des commandes), COPY/ADD (copier des fichiers), WORKDIR (répertoire de travail), ENV (variables d'environnement), EXPOSE (port documente), CMD/ENTRYPOINT (commande par défaut). Bonnes pratiques : utiliser des images de base slim ou alpine (plus legeres et sécurisées). Multi-stage builds pour séparer la compilation du runtime (réduire 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 réseau. bridge (par défaut) : réseau prive entre conteneurs sur le même hôte, NAT pour l'accès externe. Les conteneurs se resolvent par nom sur les réseaux custom (DNS integre). host : le conteneur partage le réseau de l'hôte (pas d'isolation, meilleures performances). overlay : réseau multi-hote pour Docker Swarm ou Kubernetes. none : pas de réseau. Les ports sont exposes avec -p host:container. Les réseaux custom isolent les groupes de conteneurs (frontend ne voit pas la database sauf si sur le même réseau). Docker Compose cree automatiquement un réseau pour les services. En production Kubernetes, chaque Pod à sa propre IP et les services gèrent la découverte.
4. Qu'est-ce que Docker Compose et quand l'utiliser ?
Docker Compose définit et orchestre des applications multi-conteneurs via un fichier docker-compose.yml. Chaque service à sa configuration : image, ports, volumes, variables d'environnement, dépendances (depends_on). Commandes : docker compose up (démarrer), down (arrêter), logs (voir les logs), exec (exécuter une commande). Idéal pour : le développement local (reproduire l'environnement de production), les tests d'intégration (base de données + app + cache), les demos. Pas recommande pour la production a grande échelle (utiliser Kubernetes). Les volumes nommés persistent les données. Les healthchecks définissent quand un service est prêt. Les profiles permettent de démarrer des sous-ensembles de services.
5. Expliquez l'architecture de Kubernetes et ses composants principaux.
Control Plane : API Server (point d'entrée, toutes les communications passent par lui), etcd (stockage cle-valeur distribue pour l'état du cluster), Scheduler (place les Pods sur les nœuds selon les ressources et contraintes), Controller Manager (gere les contrôleurs : ReplicaSet, Deployment, etc.). Worker Nodes : kubelet (agent sur chaque nœud, gere les conteneurs), kube-proxy (gestion du réseau et des services), container runtime (containerd ou CRI-O). Ressources fondamentales : Pod (unité minimale, un ou plusieurs conteneurs), Service (exposition réseau stable), Deployment (gestion déclarative des ReplicaSets), ConfigMap/Secret (configuration), PersistentVolume (stockage).
6. Comment fonctionne le déploiement dans Kubernetes (Deployment, Rolling Update) ?
Un Deployment gere de manière déclarative les ReplicaSets et les Pods. Il définit l'image, le nombre de réplicas, les ressources, et la stratégie de mise à jour. Rolling Update (par défaut) : remplace les anciens Pods progressivement (maxUnavailable et maxSurge controlent le rythme). Zero-downtime si les readiness probes sont bien configurées. Recreate : arrête tous les anciens Pods avant de créer les nouveaux (downtime). Rollback : kubectl rollout undo revient à la révision précédente. 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 accéder à un ensemble de Pods (selectionnes par labels). Types : ClusterIP (par défaut, accessible uniquement dans le cluster), NodePort (expose sur un port de chaque nœud, 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, gérant le routage par host/path, le TLS, et le rate limiting. Controllers Ingress populaires : Nginx, Traefik, HAProxy. Service Mesh (Istio, Linkerd) ajoute mTLS, observabilité et traffic management entre les services.
8. Comment gérer 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 données sensibles (mot de passe, token, cle), encodees en base64 (pas chiffrees par défaut). 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'accès aux Secrets avec RBAC.
9. Expliquez les probes Kubernetes (liveness, readiness, startup).
Les probes permettent à Kubernetes de vérifier la santé des conteneurs. Liveness probe : vérifie que le conteneur fonctionne. Si elle echoue, Kubernetes redemarre le conteneur. Utiliser pour détecter les deadlocks ou les états bloques. Readiness probe : vérifie que le conteneur est prêt à recevoir du trafic. Si elle echoue, le Pod est retire du Service (plus de trafic). Utiliser pour les dépendances externes (base de données, cache). Startup probe : vérifie que l'application à démarre. Tant qu'elle n'a pas reussi, les autres probes sont desactivees. Pour les applications lentes au démarrage. Types : HTTP GET, TCP Socket, Exec (commande). Configurer initialDelaySeconds, periodSeconds, failureThreshold selon l'application.
10. Comment gérer 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 mémoire si dépasse). Toujours définir requests et limits. HPA (Horizontal Pod Autoscaler) : ajuste le nombre de réplicas selon les métriques (CPU, mémoire, métriques custom). VPA (Vertical Pod Autoscaler) : ajuste les requests/limits automatiquement (redémarrage nécessaire). Cluster Autoscaler : ajoute ou supprime des nœuds selon les Pods en attente. PodDisruptionBudget : garantit un nombre minimum de Pods disponibles pendant les opérations de maintenance. Resource Quotas et LimitRanges au niveau namespace pour le multi-tenant. Monitorer avec Prometheus et Grafana pour anticiper les besoins de scaling.