Kapsule : ce qui est managé, et ce qui ne l'est pas

Pourquoi

Signalements tourne depuis un an sur des instances, derrière le répartiteur de charge du cours Le cloud : les fondamentaux, avec la base PostgreSQL managée sig-db. L'application est désormais une image de conteneur publiée dans le registre Scaleway, déployée depuis Git. Lyneko fait déjà tourner ses propres applications sur un cluster Kapsule, lyneko-apps, avec Traefik, Argo CD et External Secrets. La question n'est plus « faut-il Kubernetes ? » (le cours Pourquoi Kubernetes l'a posée) mais : si Signalements migre vers Kapsule, qu'est-ce qui devient le travail de Scaleway, et qu'est-ce qui reste le nôtre ?

« Managé » est un mot que chaque offre remplit différemment. Sans réponse précise, deux dérives apparaissent :

• On croit que « managé » veut dire « sans exploitation » : personne ne suit la version de Kubernetes, personne ne dimensionne les nœuds, et un jour le fournisseur met à jour de force un cluster dont la version n'est plus supportée, à une date qu'on n'a pas choisie.
• À l'inverse, on exploite de trop : on se connecte aux nœuds en SSH pour « corriger » quelque chose, on modifie kube-system, et l'on s'attribue sans le savoir la responsabilité d'un composant que le fournisseur aurait maintenu.

Cette leçon trace la frontière, décrit les types de clusters, leurs limites chiffrées et la politique de versions, puis situe Kapsule parmi les autres Kubernetes managés.

Les concepts

Une responsabilité partagée, appliquée à Kubernetes

Le cours IaaS, PaaS, serverless et la responsabilité partagée a posé le principe. Pour Kubernetes, Scaleway publie un modèle (daté de mai 2026) qui oppose la sécurité du cloud, la sienne, à la sécurité dans le cloud, la vôtre.

La frontière est plus fine pour les nœuds. Scaleway fabrique et corrige l'image du système, crée et remplace les machines. Mais vous choisissez quand appliquer une nouvelle image (par la mise à jour du pool), et vous répondez de la compatibilité de vos charges. Un nœud est un consommable : la FAQ le dit, les nœuds sont à considérer comme sans état et peuvent être supprimés, remplacés ou redémarrés à tout moment.

Ce qui tourne dans le cluster sans être à vous

Dans kube-system d'un cluster neuf, des objets sont apparus que vous n'avez pas créés. Le modèle de Scaleway nomme CoreDNS, kube-proxy, le CNI (Cilium par défaut, Calico en option, voir la leçon 2) et le CSI. D'autres éléments se reconnaissent par leur rôle :

• le cloud controller manager (CCM) vit côté plan de contrôle : il traduit vos Services LoadBalancer en répartiteurs Scaleway et réconcilie les nœuds avec les instances ;
• l'autoscaler de cluster est géré par Scaleway et réglé par le champ autoscaler-config du cluster (leçon 3) ;
• le pilote CSI (csi.scaleway.com) tourne dans kube-system et pilote le Block Storage ; un second pilote, pour File Storage, s'active par une étiquette du cluster (leçon 4) ;
• kapsule-agent, logiciel interne sur chaque nœud, configure le réseau au premier démarrage et active ou coupe le serveur SSH selon une étiquette du nœud.

Deux précisions honnêtes. Scaleway ne publie pas la liste exhaustive de kube-system, et elle varie avec les versions : la source de vérité est votre cluster (commandes plus bas). Quant au serveur de métriques (metrics-server), dont dépendent kubectl top et l'autoscaling horizontal, le modèle de responsabilité ne le nomme pas : vérifiez sur votre cluster s'il est présent et qui le maintient avant de bâtir un HorizontalPodAutoscaler dessus.

Le plan de contrôle : un coffre scellé

Vous ne voyez du plan de contrôle que l'URL de l'API. Pas de machine à votre nom, pas de SSH, pas de pods lisibles par kubectl logs comme dans le cluster kind du cours L'architecture d'un cluster. La configuration individuelle n'est pas possible ; quelques réglages sont exposés (plugins d'admission, feature gates, OIDC, leçon 2). Les journaux du plan de contrôle se consultent dans Cockpit, et le journal d'audit n'existe qu'en offre dédiée.

Les types de clusters

Le champ type choisit l'offre de plan de contrôle. Le tableau de la documentation (validé en septembre 2025, à relire avec scw k8s cluster-type list avant tout engagement) donne :

Les noms de la CLI sont kapsule, kapsule-dedicated-4, -8 et -16 (et leurs équivalents multicloud… pour Kosmos). L'API distingue deux niveaux de résilience : standard (le plan de contrôle est replanifié sur d'autres machines en cas de défaillance) et haute disponibilité (il a des répliques).

Les conditions commerciales pèsent autant que les chiffres :

• le plan de contrôle mutualisé est fourni sans frais : on paie les nœuds, au prix des instances, et les ressources associées ;
• un plan de contrôle dédié est facturé à l'heure avec un engagement de 30 jours : monter de gamme remet le compteur à 30 jours, descendre est impossible pendant l'engagement, supprimer le cluster l'annule ;
• redescendre au mutualisé est impossible si l'etcd dépasse 55 Mo ;
• scw k8s cluster set-type change le type, scw k8s cluster list-available-types indique ce qui est possible.

55 Mo n'est pas un détail : chaque Secret, ConfigMap ou ressource d'opérateur vit dans etcd. Beaucoup de CRD ou de ConfigMaps volumineuses peuvent s'en approcher. Cockpit publie la taille d'etcd : à surveiller comme un disque.

Mono-zone, multi-AZ, régional

Trois formes de cluster, indépendantes du type :

• mono-zone : tout dans une zone ; la perte de la zone arrête les charges ;
• multi-AZ : un seul plan de contrôle, des pools répartis sur plusieurs zones de la région. Si la zone du plan de contrôle tombe, les charges déjà en place continuent mais rien ne se reconfigure ;
• régional : plusieurs répliques du plan de contrôle sur plusieurs zones, réservé aux plans de contrôle dédiés en haute disponibilité d'après la documentation.

Limite documentée à retenir : l'accès réseau au plan de contrôle passe par un répartiteur situé dans la zone principale de la région, y compris pour le dédié haute disponibilité. Si cette zone tombe, l'API est injoignable même avec des nœuds ailleurs. Des nœuds multi-zones protègent vos charges, pas votre capacité d'agir pendant la panne.

Kosmos en une mention

Kosmos est l'offre multi-cloud : un plan de contrôle managé auquel on rattache des machines de n'importe quel fournisseur, avec le plugin réseau Kilo (maillage WireGuard), sans intégration au VPC, et des mises à jour de nœuds externes à la main. On ne passe pas de Kapsule à Kosmos sur un cluster existant (FAQ) : il faut en créer un. Tout ce cours suppose des nœuds en instances Scaleway.

Les versions et leur fin de vie

La communauté publie quatre à six versions mineures par an. Scaleway les propose en général sous quelques jours et supporte chacune au moins douze mois (le calendrier affiche 14 mois). Au 5 octobre 2026 :

• Dépréciation : la version disparaît des options de création, un ticket prévient les clients concernés.
• Fin de support : le cluster est mis à jour automatiquement vers la version mineure suivante, dans les 30 jours, avec notification.

Un cluster en 1.33 ou 1.34 est donc déjà déprécié, et celui en 1.33 a quelques semaines avant la mise à jour forcée. L'équipe qui l'apprend le jour même n'a pas le temps de tester ses charges contre 1.35.

La mise à jour automatique (auto-upgrade) ne concerne que les patchs d'une même mineure (1.36.2 vers 1.36.3), dans une fenêtre de deux heures que vous fixez ; la leçon 6 la détaille. Pour toute demande de support, Scaleway exige d'être à jour du dernier patch de sa version : « 80 % des problèmes » se règlent ainsi, dit la politique.

Les limites d'un cluster

Aucune page ne les rassemble ; voici celles qu'établissent les sources :

• Nœuds : 150, 250 ou 500 selon l'offre. etcd : 55 ou 200 Mo.
• Région : un cluster appartient à une région ; il ne change ni de projet ni d'organisation.
• Réseau privé : rattaché à la création, jamais détaché ni changé (leçon 2).
• Groupe de placement : 20 instances au plus. Types de nœuds : DEV1-S, PLAY2-PICO et STARDUST sont exclus (mémoire insuffisante).
• Plan de contrôle sans adresse publique : impossible ; la parade est de restreindre l'accès par liste d'adresses autorisées.
• Quotas du compte : instances, adresses, répartiteurs, volumes (Organiser un compte pour la production). Le quota bloque souvent avant le plafond de nœuds.

La section « limitations techniques » de la documentation de l'API fait foi : relisez-la à chaque conception.

Kapsule et les autres Kubernetes managés

Même squelette partout (plan de contrôle géré, nœuds à votre charge), des différences surtout dans la facturation et le support, d'après leurs documentations officielles :

• Amazon EKS : plan de contrôle facturé par cluster et par heure ; après le support standard d'une version, un support étendu payant.
• Azure AKS : niveaux Free, Standard et Premium ; les niveaux payants apportent un SLA sur le plan de contrôle.
• Google GKE : mode Autopilot (Google gère aussi les nœuds) ou Standard ; clusters zonaux ou régionaux.
• Kapsule : plan de contrôle mutualisé gratuit sans SLA, ou dédié avec SLA et audit ; nœuds exclusivement en instances Scaleway ; pas de mode sans nœuds, pas de support étendu.

Pour Lyneko, la différence décisive n'est pas le prix mais la juridiction (cours Cloud souverain) et la simplicité, au prix de moins d'options. Les tarifs évoluent : relisez leurs pages avant toute comparaison chiffrée, ce cours n'en reproduit aucun.

En pratique

Ces commandes ne créent rien ; elles ont été vérifiées avec l'aide de la CLI 2.62.0. Les sorties dépendent de votre compte et ne sont pas reproduites.

$ scw k8s cluster-type list region=fr-par
$ scw k8s version list region=fr-par

La première liste les types de la région : disponibilité (available, scarce ou shortage dans le schéma de l'API), nombre maximal de nœuds, délai d'engagement, SLA ; region=all interroge toutes les régions. La seconde liste les versions proposées à la création, avec pour chacune les CNI, plugins d'admission et feature gates possibles. Une version absente du tableau de la section précédente est une version dépréciée.

Pour un cluster existant :

$ scw k8s cluster get <identifiant> region=fr-par -o json
$ scw k8s pool list cluster-id=<identifiant> region=fr-par
$ scw k8s cluster list-available-types <identifiant> region=fr-par

Le premier renvoie type, version, CNI, plages d'adresses, état de la mise à jour automatique ; le deuxième, les pools ; le troisième, les types vers lesquels basculer compte tenu de l'engagement et du stock. Ce sont les objets que vous exploitez, avec vos manifestes Kubernetes.

Puis lisez le namespace système, avec les propriétaires :

$ kubectl -n kube-system get deployments,daemonsets,statefulsets
$ kubectl -n kube-system get pods -o custom-columns=NOM:.metadata.name,PROPRIETAIRE:.metadata.ownerReferences[0].name

Archivez cette liste : ce qui est là à la livraison est maintenu par Scaleway, ce qui s'ajoute est à vous. Dans lyneko-apps, Traefik, Argo CD et External Secrets vivent dans leurs namespaces, jamais dans kube-system, pour que cette liste reste celle du fournisseur.

Enfin, l'équipe de Signalements dresse l'inventaire de la migration, d'après le modèle de Scaleway :

Le tableau est instructif par ce qu'il ajoute : l'équipe gagne les lignes de la machine et du répartiteur, et en gagne de nouvelles (version, RBAC, politiques réseau). Le travail ne diminue pas, il change de nature.

Sous le capot

Pourquoi le mutualisé est gratuit et plafonné. C'est un jeu de composants Kubernetes isolé logiquement qui partage des machines avec d'autres clients ; la documentation parle de 4 Go de mémoire (RAM et swap). La mémoire du serveur d'API croît avec le nombre d'objets et de clients qui surveillent (watch) : plafonner la mémoire plafonne etcd (55 Mo) et le nombre de nœuds. Le dédié achète de la mémoire, des répliques et un SLA.

Quand le plan de contrôle ne répond plus. Les kubelets continuent d'exécuter les conteneurs déjà reçus : les pods en cours ne s'arrêtent pas. Tout ce qui exige une décision s'arrête : plus d'ordonnancement, plus de remplacement par un contrôleur, plus de réaction de l'autoscaling, plus de kubectl apply. Un nœud qui tombe pendant l'intervalle n'est pas remplacé.

Le CCM, une porte vers l'API Scaleway. Un cloud controller manager est un contrôleur Kubernetes propre à un fournisseur : il observe les Services LoadBalancer et les nœuds, et appelle l'API (créer un répartiteur, supprimer un nœud dont l'instance a disparu). Le dépôt scaleway/scaleway-cloud-controller-manager documente ses variables (région, réseau privé PN_ID, type de répartiteur par défaut LB_DEFAULT_TYPE). Sur Kapsule vous ne le configurez pas : vous le pilotez par des annotations de Service (leçon 4).

Des nœuds immuables. La FAQ parle d'un volume système « immuable » : l'OS est une image remplacée à chaque mise à jour, jamais modifiée en place. Toute action doit passer par Kubernetes ou l'API de Kapsule : une session SSH disparaîtra au prochain remplacement.

Le chiffrement d'etcd. Les Secrets sont chiffrés au repos dans etcd, et seuls les Secrets le sont par défaut ; chiffrer tout etcd est « à l'étude ». Un ConfigMap qui contient un mot de passe n'est pas chiffré : la couche protège le bon objet, pas le mauvais choix.

Pièges courants

Croire que le cluster « se met à jour tout seul ». L'auto-upgrade ne couvre que les patchs. Un cluster non suivi passe de 1.33 à 1.34 en novembre sans votre validation, et une API retirée peut casser un manifeste.

Modifier kube-system. Éditer le déploiement de CoreDNS semble inoffensif, et vous en reprend la responsabilité. Utilisez les mécanismes prévus (cours Le DNS du cluster) et tracez vos changements.

Renommer un cluster en production. La FAQ de Scaleway est claire : le nom sert à plusieurs composants, et le renommer redéploie le plan de contrôle et le job qui injecte les ressources gérées. Pendant 5 à 10 minutes : pods bloqués en ContainerCreating, erreurs de DNS interne, échecs de montage de ConfigMap. Le nom n'est pas une étiquette.

Traiter un nœud comme un serveur. Ce que vous y installez à la main disparaît au remplacement. Ce qui doit exister partout passe par un DaemonSet ou par les données utilisateur du pool, dont une erreur cloud-init peut casser le nœud, dépannage à votre charge.

Le mutualisé pour un service qui promet un SLA. Les charges continuent sans plan de contrôle, ce qui rend le mutualisé défendable, mais la promesse ne doit pas reposer sur un composant sans SLA : la décision doit être écrite, pas découverte pendant une panne.

Un cluster multi-zone qu'on croit résilient. Ni un volume (lié à sa zone), ni l'API (zone principale), ni un répartiteur (zonal) ne sont protégés par des pools multi-zones.

Supprimer un cluster en laissant des ressources. scw k8s cluster delete ne supprime par défaut ni volumes ni répartiteurs ; with-additional-resources=true les supprime « au mieux » (volumes y compris en Retain, réseaux privés vides, répartiteurs dont le nom commence par l'identifiant du cluster). Choisissez sciemment : l'oubli se paie chaque mois, la suppression légère se paie en données.

Sécurité

• L'API reste joignable depuis Internet. Le contrôle repose sur l'authentification, le RBAC (leçon 5) et la liste d'adresses autorisées (leçon 2), activée sur les clusters créés après le 8 mars 2025 ; l'entrée par défaut 0.0.0.0/0 laisse tout passer.
• Les nœuds ne sont pas des postes d'administration. Depuis mai 2023 le groupe de sécurité par défaut interdit tout trafic entrant, SSH compris ; la documentation propose aussi de couper le serveur SSH.
• Pas de journal d'audit hors offre dédiée. Répondre à « qui a supprimé ce Deployment ? » repose alors sur Git et l'outil de déploiement.
• Seuls les Secrets sont chiffrés dans etcd. Lyneko utilise External Secrets avec Secret Manager pour que les secrets ne vivent jamais dans Git (Secret Manager).
• Les images et les charges sont à vous : provenance, analyse, NetworkPolicies (Les NetworkPolicies). Le cours Sécurité de Kubernetes ira plus loin.
• Données de santé : le modèle de responsabilité contient une section HDS ; relisez-la avec votre juriste avant de choisir l'offre.

En production

• Choisissez le type sur le SLA à tenir, pas par habitude : le mutualisé convient aux charges qui n'exigent pas de reconfiguration permanente ; il ne convient ni si le contrat exige un SLA de plan de contrôle, ni si l'audit est requis, ni au-delà de 150 nœuds ou 55 Mo d'etcd.
• Alertez sur la taille d'etcd dans Cockpit (leçon 7) et cherchez ce qui l'alourdit : CRD, objets terminés non nettoyés.
• Tenez un calendrier de versions : par cluster, version, dépréciation, fin de support, date de test en préproduction. Montez une mineure à la fois, trois à quatre fois par an, plutôt que de rattraper quatre versions en urgence.
• Un cluster par environnement et frontière de confiance, pas par application : c'est l'unité de version, de réseau et de rayon d'impact, et il est rattaché à un projet non déplaçable (Organiser un compte).
• Décrivez tout en code (leçon 8) : un cluster que personne ne sait reconstruire est un risque, et Terraform avertit avant une recréation.
• Isolez les intégrations propres à Scaleway (annotations scw-loadbalancer-*, classes sbs-*) pour garder la réversibilité du cours Les coûts, le contrat et la sortie.
• Chez Lyneko, lyneko-apps est partagé par des applications internes : un calendrier, un seul endroit où tester. Signalements, avec ses clients externes, justifie son propre cluster, au plan de contrôle choisi selon le SLA promis.

Exercices

1. Qui répond ? (niveau 200). Sur un cluster Kapsule, Scaleway ou l'équipe doit-il agir, et pourquoi : (a) le serveur d'API a redémarré après une panne de machine ; (b) un nœud est NotReady depuis 40 minutes, autoréparation désactivée ; (c) kube-proxy plante après une modification de son DaemonSet par l'équipe ; (d) la 1.34 sort du support dans deux mois ; (e) un Secret contenant un jeton a été committé dans un dépôt.

2. Choisir un plan de contrôle (niveau 200). Signalements comptera 12 nœuds au plus et quelques centaines d'objets. Le contrat des métropoles promet 99,5 % de disponibilité du service, et la sécurité veut pouvoir retrouver qui a modifié un objet. Quel type recommandez-vous, et que reste-t-il à vérifier ?

3. Le calendrier (niveau 200). Au 5 octobre 2026, la préproduction est en 1.34 et lyneko-apps en 1.35. D'après le tableau, quelles dates comptent, et que décidez-vous ?

Récapitulatif

• Scaleway exploite le plan de contrôle, les modules système, les images de nœuds et les intégrations ; vous gardez charges, RBAC, NetworkPolicies, taille des pools, sauvegardes et calendrier des mises à jour.
• Ce que vous modifiez dans kube-system devient le vôtre. Les nœuds sont des consommables sans état.
• Plan de contrôle mutualisé (gratuit, sans SLA, 150 nœuds, 55 Mo d'etcd) ou dédié (4, 8, 16 Go ; SLA 99,5 % ; audit ; engagement 30 jours ; 250 à 500 nœuds ; 200 Mo).
• L'accès à l'API passe par la zone principale de la région : des pools multi-zones ne protègent pas l'accès au plan de contrôle.
• Versions supportées au moins 12 mois ; à la fin du support, Scaleway met à jour en 30 jours. L'auto-upgrade ne couvre que les patchs.
• Seuls les Secrets sont chiffrés dans etcd ; renommer un cluster redéploie son plan de contrôle.
• Face à EKS, AKS et GKE : même squelette, plan de contrôle mutualisé gratuit, pas de support étendu ni de mode sans nœuds, juridiction française.

Pour aller plus loin

• Le modèle de responsabilité partagée de Scaleway pour Kubernetes, à joindre au dossier d'architecture (la version anglaise fait foi pour les valeurs contractuelles).
• La page « Kubernetes control plane offers » de la documentation, pour les conditions d'engagement.
• La leçon 2, pour créer le cluster de Signalements dans un réseau privé.
• Le cours Kubernetes : administrer un cluster, pour ce que fait un administrateur qui exploite lui-même le plan de contrôle.