133 lines
6.5 KiB
JSON
133 lines
6.5 KiB
JSON
{
|
||
"title": "Worker nodes",
|
||
"questions": [
|
||
{
|
||
"question": "Que fait la commande 'kubectl drain <node-name>' ?",
|
||
"explanation": "Le 'drain' prépare un nœud pour la maintenance en expulsant les Pods existants (vers d'autres nœuds via leurs Controllers) et en marquant le nœud comme non-planifiable (cordon).",
|
||
"answers": [
|
||
{ "text": "Supprime tous les Pods du cluster", "correct": false },
|
||
{ "text": "Redémarre kubelet", "correct": false },
|
||
{ "text": "Déplace les Pods vers d’autres nœuds", "correct": true },
|
||
{ "text": "Vide les fichiers de logs", "correct": false }
|
||
]
|
||
},
|
||
{
|
||
"question": "Lequel de ces outils est un runtime de conteneurs compatible avec Kubernetes ?",
|
||
"explanation": "Pour être compatible, un runtime doit implémenter l'interface CRI. containerd, CRI-O ou Podman (via cri-o) en font partie.",
|
||
"answers": [
|
||
{ "text": "Cilium", "correct": false },
|
||
{ "text": "Podman", "correct": true },
|
||
{ "text": "Kubectl", "correct": false },
|
||
{ "text": "Kubelet", "correct": false }
|
||
]
|
||
},
|
||
{
|
||
"question": "Quel composant exécute les conteneurs à la demande du kubelet ?",
|
||
"explanation": "La Container Runtime Interface (CRI) est l'interface standard qui permet au kubelet d'interagir avec différents moteurs de conteneurs sans connaître leurs spécificités internes.",
|
||
"answers": [
|
||
{ "text": "etcd", "correct": false },
|
||
{ "text": "scheduler", "correct": false },
|
||
{ "text": "kube-proxy", "correct": false },
|
||
{ "text": "CRI", "correct": true }
|
||
]
|
||
},
|
||
{
|
||
"question": "Le mode iptables de kube-proxy peut devenir lent avec des milliers de Services.",
|
||
"explanation": "iptables utilise une recherche séquentielle (O(n)). Plus il y a de règles (services), plus le temps de traitement augmente. IPVS est alors recommandé.",
|
||
"answers": [
|
||
{ "text": "Vrai", "correct": true },
|
||
{ "text": "Faux", "correct": false }
|
||
]
|
||
},
|
||
{
|
||
"question": "Quel outil permet de surveiller l’état du service kubelet sur un nœud Linux ?",
|
||
"explanation": "Kubelet tournant généralement comme un service système (Systemd) sur les nœuds, la commande standard est 'systemctl status kubelet'.",
|
||
"answers": [
|
||
{ "text": "systemctl status kubelet", "correct": true },
|
||
{ "text": "kubectl logs kubelet", "correct": false },
|
||
{ "text": "docker ps", "correct": false },
|
||
{ "text": "journalctl -u kubelet", "correct": true }
|
||
]
|
||
},
|
||
{
|
||
"question": "Kube-proxy fonctionne uniquement sur le control plane",
|
||
"explanation": "Kube-proxy doit tourner sur chaque nœud (Worker et Master) pour gérer les règles réseau permettant la communication vers les Services.",
|
||
"answers": [
|
||
{ "text": "Vrai", "correct": false },
|
||
{ "text": "Faux", "correct": true }
|
||
]
|
||
},
|
||
{
|
||
"question": "Quel fichier contient les manifests locaux de Pods lus automatiquement par le kubelet ?",
|
||
"explanation": "Le chemin par défaut pour les Static Pods (Pods gérés par Kubelet sans passer par l'API Server) est souvent défini dans ce répertoire via le paramètre staticPodPath.",
|
||
"answers": [
|
||
{ "text": "/var/lib/kubelet/config/pod.yaml", "correct": true },
|
||
{ "text": "/etc/kubernetes/manifests", "correct": true },
|
||
{ "text": "/etc/pod.d/", "correct": false },
|
||
{ "text": "/var/run/kubernetes.json", "correct": false }
|
||
]
|
||
},
|
||
{
|
||
"question": "runc est le composant bas niveau qui crée réellement les conteneurs avec les namespaces et cgroups Linux.",
|
||
"explanation": "runc est l'implémentation de référence de l'OCI (Open Container Initiative) qui dialogue avec le noyau Linux pour isoler les processus.",
|
||
"answers": [
|
||
{ "text": "Vrai", "correct": true },
|
||
{ "text": "Faux", "correct": false }
|
||
]
|
||
},
|
||
{
|
||
"question": "Les Static Pods peuvent être créés même si l'API Server n'est pas disponible.",
|
||
"explanation": "Oui, car le Kubelet surveille un dossier local sur le disque. Il lance les Pods qu'il y trouve sans attendre d'ordre du Control Plane.",
|
||
"answers": [
|
||
{ "text": "Vrai", "correct": true },
|
||
{ "text": "Faux", "correct": false }
|
||
]
|
||
},
|
||
{
|
||
"question": "Le kubelet utilise le modèle pull pour obtenir l'état désiré depuis l'API Server.",
|
||
"explanation": "Le Kubelet 'watch' l'API Server. Il tire (pull) les informations concernant les Pods qui lui sont assignés.",
|
||
"answers": [
|
||
{ "text": "Vrai", "correct": true },
|
||
{ "text": "Faux", "correct": false }
|
||
]
|
||
},
|
||
{
|
||
"question": "Quelle commande réactive la planification sur un Node après maintenance ?",
|
||
"explanation": "'uncordon' retire la marque 'node.kubernetes.io/unschedulable' et permet au scheduler d'y placer de nouveaux Pods.",
|
||
"answers": [
|
||
{ "text": "kubectl enable", "correct": false },
|
||
{ "text": "kubectl resume", "correct": false },
|
||
{ "text": "kubectl uncordon", "correct": true },
|
||
{ "text": "kubectl activate", "correct": false }
|
||
]
|
||
},
|
||
{
|
||
"question": "Quel protocole utilise le kubelet pour communiquer avec le runtime via CRI ?",
|
||
"explanation": "L'interface CRI est basée sur gRPC, ce qui permet des communications performantes et fortement typées entre Kubelet et le runtime.",
|
||
"answers": [
|
||
{ "text": "WebSocket", "correct": false },
|
||
{ "text": "TCP Socket", "correct": false },
|
||
{ "text": "gRPC", "correct": true },
|
||
{ "text": "REST API", "correct": false }
|
||
]
|
||
},
|
||
{
|
||
"question": "Quel mode de kube-proxy offre une performance constante O(1) grâce aux hash tables ?",
|
||
"explanation": "IPVS (IP Virtual Server) utilise des tables de hachage pour rediriger le trafic, ce qui le rend beaucoup plus performant que les listes séquentielles d'iptables sur de grands clusters.",
|
||
"answers": [
|
||
{ "text": "userspace", "correct": false },
|
||
{ "text": "iptables", "correct": false },
|
||
{ "text": "nftables", "correct": false },
|
||
{ "text": "ipvs", "correct": true }
|
||
]
|
||
},
|
||
{
|
||
"question": "Le kubelet communique avec le Control Plane via l’API server.",
|
||
"explanation": "L'API Server est le seul point de contact du Kubelet pour rapporter l'état des nœuds et recevoir les spécifications des Pods.",
|
||
"answers": [
|
||
{ "text": "Vrai", "correct": true },
|
||
{ "text": "Faux", "correct": false }
|
||
]
|
||
}
|
||
]
|
||
} |