Réponses du Quiz Kubernetes
Section 1 : Introduction et historique
Question 1.1 - Réponse : C
Kubernetes vient du grec "kubernêtês" qui signifie "timonier" ou "pilote". C'est une métaphore pour l'orchestration de containers.
Question 1.2 - Réponse : B
Le logo a 7 branches en hommage au personnage Seven of Nine de Star Trek Voyager. Les créateurs du projet étaient fans de la série.
Question 1.3 - Réponse : B
Kubernetes est basé sur Borg, le système interne de Google qui gère leurs containers en production depuis plus de 15 ans.
Question 1.4 - Réponse : B
"k8s" est une abréviation où le 8 représente les 8 lettres entre le K et le S de "Kubernetes" (ubernete).
Section 2 : Architecture et composants
Question 2.1 - Réponse : C
etcd est la base de données clé-valeur distribuée qui stocke tout l'état du cluster (configurations, secrets, état des pods, etc.).
Question 2.2 - Réponse : B
Le Scheduler est responsable d'affecter les pods aux nœuds en fonction des ressources disponibles, des contraintes d'affinité, etc.
Question 2.3 - Réponse : B
Le kubelet est l'agent qui s'exécute sur chaque Worker Node. Il communique avec l'API Server et gère le cycle de vie des pods locaux.
Question 2.4 - Réponse : C
Le dockershim a été retiré dans Kubernetes 1.24 (mai 2022). Les clusters utilisent maintenant containerd ou CRI-O directement.
Question 2.5 - Réponse : B
etcd utilise l'algorithme Raft pour le consensus entre les nœuds du cluster etcd.
Question 2.6 - Réponse : B
Le format DNS standard est <service>.<namespace>.svc.cluster.local. Par exemple : nginx.default.svc.cluster.local.
Section 3 : Pods et Deployments
Question 3.1 - Réponse : B
Le Pod est l'unité de base. Il peut contenir un ou plusieurs containers qui partagent le même réseau et stockage.
Question 3.2 - Réponse : B
Pending signifie que le pod attend d'être planifié sur un nœud. Cela peut être dû à un manque de ressources ou des contraintes d'affinité non satisfaites.
Question 3.3 - Réponse : B
La Readiness Probe vérifie si un container est prêt à recevoir du trafic. Si elle échoue, le pod est retiré des endpoints du Service.
Question 3.4 - Réponse : B
Un Deployment gère le cycle de vie des Pods : réplication, rolling updates, rollbacks, self-healing. Un Pod seul est éphémère et non géré.
Question 3.5 - Réponse : B
kubectl rollout history deployment/<name> affiche l'historique des révisions avec les causes de changement.
Section 4 : Services et réseau
Question 4.1 - Réponse : C
ClusterIP est le type par défaut. Il crée une IP virtuelle accessible uniquement depuis l'intérieur du cluster.
Question 4.2 - Réponse : C
LoadBalancer provisionne un load balancer externe (sur AWS, GCP, Azure) pour exposer le service à Internet.
Question 4.3 - Réponse : B
Un Service utilise un selector basé sur les labels pour identifier les pods à inclure dans ses endpoints.
Question 4.4 - Réponse : C
kubectl port-forward <pod> <local>:<pod> crée un tunnel entre votre machine locale et le pod.
Section 5 : Scaling et self-healing
Question 5.1 - Réponse : B
"Cattle not Pets" signifie que les pods sont comme du bétail : anonymes, remplaçables, éphémères. Contrairement aux "pets" (serveurs nommés qu'on chouchoute).
Question 5.2 - Réponse : C
Le HPA (Horizontal Pod Autoscaler) ajuste automatiquement le nombre de réplicas en fonction de métriques comme le CPU ou la mémoire.
Question 5.3 - Réponse : B
RollingUpdate remplace les pods progressivement, garantissant une disponibilité continue pendant la mise à jour.
Question 5.4 - Réponse : B
kubectl rollout undo deployment/<name> revient à la révision précédente du Deployment.
Section 6 : Objets avancés
Question 6.1 - Réponse : C
kube-system contient tous les composants système : CoreDNS, kube-proxy, metrics-server, etc.
Question 6.2 - Réponse : C
Un DaemonSet garantit qu'une copie du pod s'exécute sur chaque nœud (ou un sous-ensemble). Idéal pour le monitoring, les agents de logs, etc.
Question 6.3 - Réponse : C
Un StatefulSet fournit des identités stables (noms prévisibles), un ordre de déploiement garanti, et du stockage persistant par pod.
Question 6.4 - Réponse : B
Un Job s'exécute une fois jusqu'à complétion. Un CronJob s'exécute selon un planning (syntaxe cron).
Question 6.5 - Réponse : B
Les ConfigMaps stockent des données de configuration non-sensibles (clés-valeurs, fichiers). Les Secrets sont pour les données sensibles.
Section 7 : Ressources et affectation
Question 7.1 - Réponse : B
requests = minimum garanti, utilisé par le scheduler pour placer le pod. limits = maximum autorisé avant throttling/OOMKill.
Question 7.2 - Réponse : B
500m signifie 500 millicores, soit 0.5 CPU (la moitié d'un vCPU).
Question 7.3 - Réponse : B
Si un container dépasse sa limits.memory, il est OOMKilled (Out Of Memory Killed) et redémarré selon la restartPolicy.
Question 7.4 - Réponse : C
Guaranteed : requests = limits pour tous les containers. Ces pods sont les derniers à être évincés en cas de pression sur les ressources.
Question 7.5 - Réponse : C
Les Taints sont appliquées aux nœuds pour repousser les pods. Les pods doivent avoir une Toleration correspondante pour y être schedulés.
Question 7.6 - Réponse : B
kubernetes.io/hostname signifie "même nœud". Avec une Pod Anti-Affinity sur cette clé, les pods seront forcément sur des nœuds différents.
Section 8 : Sécurité
Question 8.1 - Réponse : B
Un Role définit des permissions dans un namespace spécifique. Un ClusterRole est pour les permissions au niveau cluster.
Question 8.2 - Réponse : B
kubectl auth can-i <verb> <resource> --as=<user> permet de tester les permissions d'un utilisateur ou ServiceAccount.
Question 8.3 - Réponse : B
Calico supporte les Network Policies. Flannel (par défaut) ne les supporte pas nativement. Cilium et Weave Net les supportent aussi.
Question 8.4 - Réponse : B
Par défaut, les Secrets sont encodés en base64, pas chiffrés. Il faut activer le chiffrement at-rest d'etcd pour une vraie sécurité.
Question 8.5 - Réponse : B
runAsNonRoot: true empêche le container de s'exécuter en tant que root (UID 0).
Question 8.6 - Réponse : B
ResourceQuota limite les ressources totales d'un namespace (CPU, mémoire, nombre de pods, etc.). LimitRange définit des valeurs par défaut par container.
Section 9 : Monitoring
Question 9.1 - Réponse : B
Prometheus est le standard de facto pour la collecte de métriques dans l'écosystème Kubernetes et cloud-native (projet CNCF).
Question 9.2 - Réponse : B
kube-prometheus-stack installe Prometheus, Grafana, Alertmanager, et des dashboards préconfigurés via Helm.
Question 9.3 - Réponse : B
Un ServiceMonitor est un CRD (Custom Resource Definition) qui indique à Prometheus quels services scraper et comment.
Question 9.4 - Réponse : B
kube_pod_container_status_restarts_total est la métrique qui compte le nombre de restarts d'un container.
Section 10 : Ingress et Traefik
Question 10.1 - Réponse : B
L'Ingress permet d'exposer plusieurs applications web via un seul point d'entrée (un seul LoadBalancer) avec des URLs propres basées sur le hostname ou le path. Sans Ingress, il faudrait un LoadBalancer par service.
Question 10.2 - Réponse : B
L'Ingress Controller (Traefik, NGINX, etc.) est le composant qui lit les objets Ingress et configure dynamiquement le reverse proxy pour router le trafic vers les bons services.
Question 10.3 - Réponse : B
Le challenge DNS-01 est le seul qui permet d'obtenir des certificats wildcard. Il fonctionne en créant un enregistrement TXT _acme-challenge.domain.com pour prouver le contrôle du domaine.
Question 10.4 - Réponse : A
L'annotation traefik.ingress.kubernetes.io/router.tls.certresolver: letsencrypt indique à Traefik quel resolver ACME utiliser pour générer le certificat.
Question 10.5 - Réponse : C
Un LoadBalancer est généralement utilisé pour exposer l'Ingress Controller car il fournit une IP externe unique pour tout le trafic entrant. En interne, l'Ingress Controller route ensuite vers les bons services.
Section 11 : Talos et production
Question 11.1 - Réponse : B
Talos est immutable (filesystem en lecture seule) et n'a pas de SSH. Toute configuration se fait via l'API.
Question 11.2 - Réponse : B
talosctl est le CLI pour gérer les nœuds Talos (configuration, bootstrap, upgrades, logs, etc.).
Question 11.3 - Réponse : B
talosctl kubeconfig récupère le kubeconfig du cluster et le sauvegarde localement.
Question 11.4 - Réponse : B
Talos est secure by default car il n'a pas de shell, pas de SSH, pas de package manager. Seule l'API avec TLS mutuel permet d'interagir avec le système.
Section 12 : Commandes kubectl
Question 12.1 - Réponse : B
kubectl get pods -A (ou --all-namespaces) affiche les pods de tous les namespaces.
Question 12.2 - Réponse : B
kubectl exec -it <pod> -- /bin/sh ouvre un shell interactif dans le container. -it = interactive + TTY.
Question 12.3 - Réponse : B
kubectl get events affiche les événements récents du cluster (créations, erreurs, warnings, etc.).
Question 12.4 - Réponse : B
kubectl top pods affiche la consommation CPU et mémoire des pods. Nécessite metrics-server.
Question 12.5 - Réponse : A
kubectl apply -f <dossier>/ applique tous les fichiers YAML/JSON du dossier récursivement.
Section 13 : Debug
Question 13.1 - Réponse : B
ImagePullBackOff signifie que Kubernetes n'arrive pas à télécharger l'image. Causes possibles : image inexistante, registry inaccessible, credentials manquants.
Question 13.2 - Réponse : B
kubectl describe pod <name> affiche tous les détails du pod, y compris les événements récents (très utile pour le debug).
Question 13.3 - Réponse : B
Vérifier les endpoints (kubectl get endpoints <service>) permet de voir si le Service a bien découvert les pods. Si vide, le selector ne matche probablement pas les labels des pods.
Question 13.4 - Réponse : B
kubectl logs <pod> --previous affiche les logs du container précédent (avant le dernier restart).
Questions bonus : Cas pratiques
Question B.1 - Réponse : C
Un StatefulSet est adapté pour PostgreSQL car il fournit :
- Des noms de pods stables (postgres-0, postgres-1)
- Un PVC persistant par pod
- Un ordre de déploiement/suppression garanti
Question B.2 - Réponse : C
Pod Anti-Affinity avec topologyKey: kubernetes.io/hostname garantit que les pods ne seront pas sur le même nœud.
Question B.3 - Réponse : B
La combinaison Taint + Toleration est la bonne approche :
- Taint le nœud GPU :
kubectl taint nodes gpu-node gpu=true:NoSchedule - Ajouter une Toleration aux pods ML
Cela empêche les autres pods d'utiliser le nœud GPU tout en permettant aux pods ML d'y accéder.
Question B.4 - Réponse : B
Role + RoleBinding dans le namespace "dev" :
- Role : définit les permissions (get, list, watch sur pods)
- RoleBinding : lie le Role à l'utilisateur dans le namespace "dev"
ClusterRole/ClusterRoleBinding donnerait accès à tous les namespaces.
Question B.5 - Réponse : B
ResourceQuota permet de limiter les ressources totales d'un namespace :
spec:
hard:
pods: "10"
requests.cpu: "4"Barème
| Score | Niveau |
|---|---|
| 0-17 | Débutant - Revoir les fondamentaux |
| 18-29 | Intermédiaire - Bonne base, approfondir certains sujets |
| 30-40 | Avancé - Bonnes connaissances, prêt pour la pratique |
| 41-47 | Expert - Excellente maîtrise de Kubernetes |
Total : 47 questions (42 + 5 sur Ingress/Traefik)