Aller au contenu

Quiz : Kapsule, Kubernetes managé chez Scaleway

100 Comprendre ⏱ 25 min kuberneteskapsulescaleway

Ce quiz vérifie la compréhension des notions du cours Kapsule : Kubernetes managé chez Scaleway. Visez au moins 10 bonnes réponses sur 12 ; chaque réponse renvoie à la leçon à relire. Le niveau 200 se valide avec le lab.

Les limites et calendriers cités sont ceux du 5 octobre 2026.

1. Dans un cluster Kapsule, qu'est-ce qui reste à votre charge ?

Réponse

Les charges de travail, le RBAC, les NetworkPolicies, la taille des pools, les sauvegardes de vos données, et le calendrier des mises à jour. Scaleway exploite le plan de contrôle, les modules système, les images de nœuds et les intégrations. Ce que vous modifiez dans kube-system devient le vôtre. Leçon 1.

2. Quelles décisions prises à la création d'un cluster ne se changent plus ensuite ?

Réponse

Le réseau privé de rattachement, le plugin réseau (Cilium par défaut, ou Calico), les plages d'adresses des pods et des Services, et les options du plan de contrôle fixées à la création. Un plan d'adressage se décide donc avant, en évitant les chevauchements. Leçon 2.

3. Vous restreignez l'accès à l'API du cluster avec scw k8s acl set et vous ne pouvez plus vous connecter : le message est un délai d'attente, pas un refus. Pourquoi ?

Réponse

La liste d'adresses autorisées filtre avant l'authentification : une adresse non autorisée ne reçoit aucune réponse, d'où le délai d'attente. set remplace toutes les règles : vérifiez que votre adresse (et celle des nœuds et du pipeline) y figure. Leçons 2 et 5.

4. Comment répartir les nœuds d'un cluster sur deux zones ?

Réponse

Un pool est dans une seule zone : on crée un pool par zone, avec les mêmes étiquettes, et l'on répartit les pods avec des contraintes de répartition par zone. Leçons 3 et 8.

5. Sur quoi l'autoscaler de cluster décide-t-il d'ajouter un nœud ?

Réponse

Sur des pods Pending faute de place, évaluée d'après leurs requests (pas leur consommation réelle). Il retire un nœud sous-utilisé (par défaut moins de 50 % pendant 10 minutes) si ses pods peuvent être déplacés. Des requests justes sont la condition d'un autoscaling utile. Leçon 3.

6. Pourquoi réserver une IP flexible pour le Service LoadBalancer du contrôleur d'entrée ?

Réponse

Sans indication, l'adresse du répartiteur est éphémère : elle disparaît avec le Service, et vos enregistrements DNS pointeraient dans le vide après une recréation. Une IP flexible réservée, désignée par l'annotation service.beta.kubernetes.io/scw-loadbalancer-ip-ids, survit au Service. Leçon 4.

7. Un StatefulSet a besoin d'un volume partagé en écriture par plusieurs pods sur plusieurs nœuds. Les classes sbs-* conviennent-elles ?

Réponse

Non : le Block Storage est en ReadWriteOnce, attaché à un seul nœud et lié à sa zone. Pour partager en écriture : File Storage par son pilote CSI (avec les conditions documentées), ou le stockage objet par l'application. Leçon 4.

8. Comment l'IAM de Scaleway et le RBAC de Kubernetes se raccordent-ils ?

Réponse

Par des groupes : les jeux de permissions IAM font apparaître des groupes dans l'identité Kubernetes (scaleway:cluster-read, scaleway:cluster-write, ou system:masters), et chaque groupe IAM devient scaleway:group:<ID>. Des RoleBinding par espace de noms donnent ensuite les droits fins à ces groupes. Leçon 5.

9. Une application dans le cluster doit lire un bucket. Comment lui donner un accès, en l'absence de fédération d'identité chez Scaleway ?

Réponse

Une application IAM dédiée à cet usage, avec une politique minimale, une clé qui expire, rangée dans Secret Manager et livrée dans un Secret du seul espace de noms consommateur (External Secrets), et une rotation planifiée. Leçon 5.

10. Que fait Scaleway si vous ne mettez pas à jour un cluster dont la version arrive en fin de support ?

Réponse

Il le monte d'office vers une version supportée, après notification. La mise à jour automatique ne couvre que les correctifs de la version mineure courante. Il faut donc monter soi-même, une mineure à la fois, d'abord en préproduction. Leçon 6.

11. Pourquoi un cluster coûte-t-il souvent plus cher que ce que consomment réellement ses applications ?

Réponse

Parce que les nœuds se paient selon ce que les pods réservent (requests), pas ce qu'ils utilisent : des requests surévaluées font ajouter des nœuds inutiles. On compare kubectl top aux requests, on ajuste, en gardant de la marge pour la perte d'un nœud. Les répartiteurs, volumes, IP et journaux ingérés s'y ajoutent. Leçon 7.

12. Pourquoi ne faut-il pas exposer le kubeconfig d'un cluster créé par Terraform dans une sortie, ni prendre l'état à la légère ?

Réponse

L'état contient le kubeconfig avec son jeton, même marqué sensible : quiconque lit l'état a un accès d'administrateur au cluster. On protège l'état comme un secret d'administrateur, et l'on n'expose jamais le kubeconfig en output. Leçon 8.

Plan du cours