Kubernetes managé sur Scaleway : Kapsule, Kosmos, et ce que vous payez

Chez Scaleway, le control plane mutualisé de Kapsule est gratuit, celui de Kosmos coûte 0,1444 €/h : la gratuité n'est pas une propriété du mutualisé, c'est une propriété de Kapsule. Cette leçon ouvre le volet conteneurs. Elle départage Kapsule et Kosmos sur un critère unique, chiffre ce qu'un cluster coûte réellement une fois le Load Balancer compté, et liste les décisions que la création fige pour de bon, à commencer par le Private Network, qu'on ne détache jamais. Elle ne construit rien : c'est la carte qu'on lit avant de partir, celle qui évite de découvrir une contrainte de 30 jours après l'avoir signée.

Ce que vous allez apprendre

• Départager Kapsule et Kosmos sur l'origine des nœuds, pas sur une impression.
• Chiffrer un cluster avant de le créer, Load Balancer et registre compris.
• Reconnaître les décisions de création qu'aucune commande ne rattrape.
• Relever vous-même les plafonds et les dates de fin de support à l'API.

Prérequis

Ce volet enseigne ce que Scaleway ajoute à Kubernetes et ce qu'il facture, pas Kubernetes lui-même. Les leçons qui suivent supposent acquis :

• Les bases de Kubernetes, Pods, Deployments, Services et volumes, avec kubectl au quotidien : la formation Kubernetes du site les couvre.
• Un compte Scaleway avec un projet dédié, la CLI scw sur un profil isolé, et kubectl installé.

Kapsule ou Kosmos : lequel pour quel besoin ?

Le critère tient en une question : d'où viennent vos nœuds ? Tout le reste en découle, y compris des contraintes que l'on découvre trop tard si l'on a choisi sur la réputation du nom.

Critère	Kapsule	Kosmos
Origine des nœuds	Instances Scaleway uniquement	n'importe quel fournisseur, votre salle comprise
Private Network	oui	non, réservé à Kapsule
CNI imposé	cilium ou calico	kilo, maillage chiffré
Cas d'usage	tout ce qui vit chez Scaleway	réversibilité, hybride, existant à absorber

Glissez pour voir

On ne convertit pas l'un en l'autre. L'appel d'API SetClusterType fait passer un control plane de mutualisé à dédié et inversement, mais jamais Kapsule vers Kosmos. Changer de famille impose de créer un nouveau cluster et d'y redéployer les charges, avec la migration de données que cela suppose. C'est la première décision irréversible du volet, et elle se prend avant la première commande.

Le choix du CNI n'est pas un détail d'implémentation. kilo monte un réseau maillé chiffré entre des machines qui ne partagent aucun réseau privé, ce qui est exactement le problème de Kosmos et une complexité inutile chez Kapsule. À l'inverse, cilium s'appuie sur eBPF et suppose un réseau plat que seul le Private Network fournit.

L'API propose plus de CNI que le produit n'en supporte

scw k8s version list annonce cinq CNI pour chaque version, kilo et none compris. La documentation de Scaleway est pourtant explicite : Kapsule ne supporte que cilium et calico, et kilo appartient à Kosmos.

Ce genre d'écart revient souvent sur cette plateforme : un listing décrit ce que l'API sait nommer, pas ce que le produit accepte de faire tourner. En cas de divergence, la documentation produit tranche, et l'on garde cilium, qui est la valeur par défaut.

Qu'est-ce que Scaleway gère, et qu'est-ce qui reste à votre charge ?

Scaleway exploite le control plane et injecte trois composants sur chaque nœud ; tout le reste vous appartient. Cette frontière n'est pas théorique : elle explique pourquoi certaines commandes échouent et pourquoi certains incidents ne sont pas de votre ressort.

Le partage des responsabilités sur Kapsule tient en une phrase : Scaleway exploite le control plane et garantit qu'il réponde, vous exploitez tout ce qui tourne dessus. Concrètement, Scaleway maintient l'API server, etcd, le scheduler et le controller manager, fournit des images de nœuds à jour, et met à disposition un cloud controller qui traduit vos objets Kubernetes en ressources facturées, un Service de type LoadBalancer devenant un vrai Load Balancer chez l'hébergeur. Restent à votre charge l'application de ces images, c'est-à-dire le renouvellement des nœuds, ainsi que le dimensionnement des pools, le choix de la version, la résilience de vos déploiements, la persistance de vos données et la fermeture des accès. Cette frontière explique la plupart des surprises rencontrées les premières semaines : un nœud remplacé sans préavis n'est pas un incident mais le fonctionnement normal d'un service managé, et une donnée écrite sur le disque local d'un nœud disparaît avec lui sans que personne n'ait commis d'erreur.

Les trois composants injectés méritent d'être nommés, parce que vous les croiserez au premier incident. Mesuré le 2026-09-12 sur un cluster 1.37.0, un kubectl drain refuse de partir sans --ignore-daemonsets et liste précisément ces trois-là :

ignoring DaemonSet-managed Pods: kube-system/cilium-xxxxx,
kube-system/csi-node-xxxxx, kube-system/konnectivity-agent-xxxxx

cilium porte le réseau, csi-node attache les volumes Block, et konnectivity-agent maintient le lien entre le nœud et un control plane qui vit ailleurs. Ils ne se drainent pas parce qu'ils appartiennent au nœud, pas à votre application. Un nœud sans eux n'est pas un nœud vide, c'est un nœud mort.

Une nuance de sécurité mérite d'être connue avant de stocker quoi que ce soit. Scaleway chiffre les Secrets Kubernetes au repos dans etcd, mais pas l'intégralité d'etcd. La documentation le dit dans ces termes : le chiffrement de tous les objets est « à l'étude », pas implémenté. Concrètement, un ConfigMap contenant une valeur sensible n'est pas protégé par ce chiffrement, alors qu'un Secret l'est. C'est une raison de plus de ne jamais glisser un mot de passe dans un ConfigMap « pour aller vite ».

Control plane mutualisé ou dédié : que change l'engagement de 30 jours ?

Le mutualisé de Kapsule est gratuit et sans engagement ; tous les autres control planes sont facturés à l'heure, et les dédiés vous lient pour 30 jours calendaires.

Control plane	Kapsule	Kosmos
Mutualisé	gratuit	0,1444 €/h, soit 105,41 €/mois
Dédié 4	0,11 €/h	0,2544 €/h
Dédié 8	0,18 €/h	0,3244 €/h
Dédié 16	0,35 €/h	0,4944 €/h

Glissez pour voir

Grille officielle relevée le 2026-09-12. Une seule case de ce tableau est à zéro, et c'est celle de Kapsule mutualisé. Choisir Kosmos coûte donc plus de 100 € par mois avant même d'avoir démarré le premier nœud, ce qui change complètement l'arbitrage de la leçon Kosmos.

C'est aussi la décision la plus coûteuse du volet si on la prend à la légère, parce qu'elle ne se défait pas.

	Mutualisé	Dédié 4	Dédié 8	Dédié 16
Mémoire	jusqu'à 4 Go	4 Go dédiés	8 Go dédiés	16 Go dédiés
API server	1 réplica résilient	2 répliques HA	2 répliques HA	2 répliques HA
SLA	aucun	99,5 %	99,5 %	99,5 %
Journaux d'audit	non	oui	oui	oui
Nœuds maximum	150	250	500	500
etcd maximum	55 Mo	200 Mo	200 Mo	200 Mo

Glissez pour voir

Ne me croyez pas sur parole : ce tableau se relève à l'API, en une commande. C'est la source la plus fiable qui soit, puisqu'elle vient du produit lui-même.

scw k8s cluster-type list region=fr-par -o json \
  | jq -r '.[] | "\(.name)\t\(.max_nodes)\t\(.max_etcd_size / 1000000) Mo\t\(.memory / 1000000000) Go\t\(.sla)"' \
  | column -t -s $'\t' -N 'TYPE,NOEUDS,ETCD,RAM,SLA'

La sortie doit afficher huit lignes, quatre pour Kapsule et quatre pour Kosmos, avec les mêmes plafonds. La même commande porte commitment_delay, qui vaut 2 592 000 secondes sur les types dédiés, soit 30 jours à la seconde près : l'engagement n'est pas une clause commerciale, c'est un champ de l'API.

Trois règles encadrent l'engagement, et elles se combinent d'une façon qu'il vaut mieux avoir lue avant de signer. Monter en gamme remet le compteur à zéro : passer de Dédié 4 à Dédié 8 au vingt-neuvième jour repart pour trente. Descendre est interdit pendant l'engagement, et aucune extension n'est appliquée après. Enfin, supprimer le cluster annule l'engagement et arrête la facturation, ce qui reste la seule sortie rapide.

Le piège qui enferme : l'etcd trop gros pour redescendre

Un cluster dédié dont l'etcd a dépassé 55 Mo ne peut plus revenir à un control plane mutualisé, même l'engagement terminé. Le quota de destination est inférieur à l'occupation réelle, et Scaleway refuse la bascule.

L'etcd grossit avec le nombre d'objets, pas avec le trafic : des milliers de ConfigMap, de Secret ou d'objets laissés par des opérateurs suffisent. Surveillez sa taille dans Cockpit dès que vous passez en dédié, sinon la porte de sortie se referme sans prévenir.

Combien coûte un cluster Kapsule ?

Un cluster de démonstration à trois nœuds DEV1-M coûte 0,0836 €/h, Load Balancer compris. Le control plane n'entre pas dans le calcul, puisqu'il est gratuit en mutualisé. Ce qui se paie, ce sont les nœuds, le Load Balancer que votre premier Service fait naître, et le stockage des images.

Relevez les prix vous-même plutôt que de me croire. Attention à la forme de la réponse : hourly_price n'est pas un nombre mais un objet {currency_code, units, nanos}, si bien qu'une addition le fusionne en un autre objet au lieu de sommer, et qu'un tonumber lève une erreur.

scw instance server-type list zone=fr-par-1 -o json \
  | jq -r '.[] | select(.name | startswith("DEV1"))
           | "\(.name)  \(.hourly_price.units + .hourly_price.nanos / 1000000000) EUR/h"'

La sortie doit afficher quatre lignes, dont DEV1-M 0.020196 EUR/h. Relevé le 2026-09-12 avec scw 2.62.0 :

Poste	Prix relevé	Pour 3 nœuds
Nœud DEV1-M, 3 vCPU, 4 Go	0,020196 €/h	0,060588 €/h
Control plane mutualisé	gratuit	0
Load Balancer lb-s	0,023 €/h	0,023 €/h
Total		0,0836 €/h
Volume système	inclus en Local Storage sur DEV1	0

Glissez pour voir

Le volume système mérite un mot, parce qu'il fait basculer le calcul sur d'autres gammes. Sur les types DEV1, le système tient en Local Storage, déjà compris dans le prix de l'Instance. Les gammes PLAY2, PRO2 et BASIC n'acceptent que du Block Storage : leur volume système se facture en plus. Comparer deux types sur leur seul prix horaire revient donc à comparer deux factures différentes.

Le vrai risque budgétaire n'est pas le cluster, c'est le cluster oublié

Mesuré sur le lab du 2026-09-12 : une session complète de construction, incidents et destruction a duré un quart d'heure et coûté moins de cinq centimes. Les mêmes ressources laissées un mois représentent environ 61 €.

L'ordre de grandeur est ce qui doit rester : un lab Kubernetes ne coûte rien tant qu'on le détruit. Chaque leçon de ce volet se termine donc par un ## Nettoyer dont la dernière étape est une vérification de sortie, pas une capture d'écran.

Quelle version de Kubernetes choisir sur Kapsule ?

Prenez la dernière version mineure disponible : la fenêtre de support Scaleway est de 14 mois, et elle court depuis la sortie, pas depuis votre installation. Choisir une version ancienne, c'est choisir la date à laquelle la mise à jour vous sera imposée.

Les dates ne se lisent pas dans un tableau de documentation qui peut dater : elles se relèvent à l'API, ce qui les rend reproductibles et vérifiables.

scw k8s version list region=fr-par -o json \
  | jq -r '.[] | "\(.name)\tsortie \(.released_at[0:10])\tdépréciée \(.deprecated_at[0:10])\tfin \(.end_of_life_at[0:10])"'

La sortie doit afficher une ligne par version mineure encore proposée. Relevé le 2026-09-12 :

Version	Sortie chez Scaleway	Dépréciation	Fin de support
1.37.0	2026-08-26	2027-08-28	2027-10-28
1.36.4	2026-07-07	2027-07-07	2027-09-07
1.35.8	2026-01-19	2027-01-19	2027-03-19
1.34.11	2025-09-29	2026-09-29	2026-11-29

Glissez pour voir

La 1.34 sera dépréciée dans moins de trois semaines au moment où ces lignes sont écrites : elle disparaîtra des options de création, et les clusters qui la portent recevront un ticket. C'est exactement pourquoi un guide Kubernetes sans date n'a aucune valeur.

La montée automatique ne fait pas ce qu'on croit. La fonction d'auto-upgrade applique les correctifs à l'intérieur d'une version mineure, et seulement eux. Passer de 1.36 à 1.37 reste une décision volontaire. Autre condition, facile à violer sans le savoir : le namespace kube-system doit rester intact, toute modification manuelle pouvant bloquer la montée.

Regarder ce que votre compte propose déjà

Avant de créer quoi que ce soit, trois commandes disent où vous en êtes. Elles ne coûtent rien, ne créent rien, et ancrent la carte dans votre réalité plutôt que dans la mienne.

Commencez par vérifier que vous ne payez pas déjà un cluster oublié :

scw k8s cluster list region=fr-par -o json \
  | jq -r 'if length == 0 then "aucun cluster" else .[] | "\(.name)  \(.status)  \(.version)" end'

La sortie doit afficher aucun cluster sur un compte vierge. Regardez ensuite les types de nœuds réellement disponibles, car le champ availability décide du succès d'une création bien plus sûrement que le catalogue :

scw instance server-type list zone=fr-par-1 -o json \
  | jq -r '.[] | select(.name | startswith("DEV1") or startswith("GP1"))
           | "\(.name)  \(.availability)"'

La sortie doit afficher available sur les gammes DEV1 et GP1. Un type en scarce ou shortage existe au catalogue et peut refuser une création : les gammes PLAY2 et PRO2 sortaient en pénurie le 2026-09-12.

Les briques du volet, et où elles vivent

Portée régionale ou zonale, gratuit ou facturé : ces deux colonnes évitent la moitié des erreurs d'architecture. Une ressource zonale ne se déplace pas d'une zone à l'autre, et une ressource gratuite se labbe sans compter.

Brique	Rôle	Portée	Facturation
Container Registry	stocker et distribuer les images	régionale	au Go stocké
Kapsule control plane	piloter le cluster	régionale	gratuit en mutualisé
Node pool	fournir les machines	zonale	prix des Instances
Private Network	isoler les nœuds	régionale	gratuit
Load Balancer	exposer un Service	zonale	à l'heure
Block Storage	volumes persistants	zonale	au Go provisionné

Glissez pour voir

La ligne qui surprend le plus est celle du registre. Le trafic entrant est toujours gratuit, et le trafic sortant l'est aussi tant qu'il reste dans la même région. Un cluster en fr-par qui tire ses images d'un namespace fr-par ne paie aucun transfert, seulement le stockage. Placer le registre ailleurs que le cluster transforme chaque docker pull en trafic facturé 0,033 €/Go.

Les décisions du volet qu'on ne peut plus reprendre

Quatre choix se figent à la création et ne se corrigent que par la destruction du cluster. Les connaître maintenant coûte cinq minutes ; les découvrir plus tard coûte une migration.

Décision	Ce qui est figé	Pourquoi on ne revient pas en arrière
Kapsule ou Kosmos	la famille du cluster	aucune conversion ; il faut recréer et redéployer
Private Network	le réseau du cluster	auto-créé en /22, non détachable, le cluster ne se déplace pas
Control plane dédié	30 jours calendaires	non résiliable ; toute montée en gamme relance les 30 jours
Nom du cluster	en pratique, oui	le renommer redéploie tout le control plane

Glissez pour voir

Le nom du cluster est le piège inattendu de cette liste. Renommer semble cosmétique et ne l'est pas : le nom est employé par plusieurs composants du control plane, si bien qu'un changement déclenche un redéploiement complet, plus celui de la tâche qui injecte les ressources managées. La documentation de Scaleway annonce des pods bloqués en ContainerCreating, des erreurs de résolution DNS interne et des échecs de montage de ConfigMap, avec un retour à la normale en 5 à 10 minutes. Sur un cluster de production aux heures de pointe, c'est une panne, pas un réglage.

Limites, quotas et plafonds du volet

Trois familles de plafonds se croisent ici, et elles ne se lèvent pas de la même manière. Le plafond produit impose de changer d'architecture, le quota de compte se relève par une validation ou une demande, et la limite technique se contourne par le dimensionnement.

Plafond	Valeur	Source
Nœuds par cluster, control plane mutualisé	150	refus de l'API, relevé le 2026-09-12
Nœuds par cluster, Dédié 8 ou 16	500	doc des offres de control plane
Taille d'etcd, mutualisé	55 Mo	doc des offres de control plane
Clusters Kapsule par Organisation	20, ou 40 identité validée	page des quotas
Clusters à control plane Dédié 4 ou 8	1, ou 4 identité validée	page des quotas
Namespaces et images de registre	99 999	page des quotas
Volume système recommandé	20 Go minimum, 100 Go confortable	FAQ Kubernetes

Glissez pour voir

Le plafond de 150 nœuds se vérifie sans rien provisionner, et c'est ce qui en fait un bon exercice. Une demande de 200 nœuds est refusée à la validation des arguments :

a kapsule cluster can't have more than 150 nodes

Rien n'a été créé, rien n'a été facturé, le pool n'a pas bougé. C'est la signature d'une contrainte structurelle du produit, à distinguer d'un dépassement de quota qui, lui, se négocie avec le support.

Pièges courants du volet

Ces quatre pièges ont un point commun : ils se manifestent après la création, quand le retour en arrière est le plus coûteux. Deux d'entre eux portent le message exact renvoyé par l'API ou par kubectl, de sorte que vous puissiez les reconnaître sans les avoir provoqués.

Symptôme	Cause	Solution
a kapsule cluster can't have more than 150 nodes	plafond produit du control plane mutualisé, pas un quota	passer en control plane dédié, ou répartir sur plusieurs clusters
drain refuse de partir et cite cilium, csi-node, konnectivity-agent	ces DaemonSets appartiennent au nœud, pas à l'application	ajouter --ignore-daemonsets, jamais les supprimer
Un pod reste Pending après l'éviction d'un nœud	topologySpreadConstraints en whenUnsatisfiable: DoNotSchedule devient insatisfiable à N-1 nœuds	utiliser ScheduleAnyway, ou prévoir un nœud de marge
Bascule dédié vers mutualisé refusée, engagement pourtant terminé	l'etcd dépasse les 55 Mo du quota mutualisé	réduire le nombre d'objets, surveiller la taille dans Cockpit

Glissez pour voir

Le troisième piège est le plus instructif, parce qu'il vient de vous. La règle qui répartit proprement les pods entre les nœuds est exactement celle qui les empêche de se replier quand un nœud disparaît. Mesuré le 2026-09-12 : un scw k8s node replace laisse le cluster environ 114 secondes à deux nœuds sur trois, et une contrainte stricte transforme cette fenêtre en indisponibilité.

Antipatterns à éviter

Ces quatre erreurs partagent une même racine : elles traitent un nœud comme une machine durable. Un nœud Kapsule est remplaçable par construction, qu'on le remplace soi-même ou que l'autoréparation s'en charge ; toute pratique qui suppose un nœud stable finit par échouer.

Antipattern	Conséquence	Discipline
Se connecter en SSH pour corriger un nœud	la correction disparaît au premier remplacement de nœud	tout passer par l'API Kubernetes ; désactiver le serveur SSH des nœuds
Stocker un état sur le disque d'un nœud	perte silencieuse des données au remplacement	PersistentVolumeClaim sur Block Storage, dont la classe est déjà par défaut
Mettre une valeur sensible dans un ConfigMap	seuls les Secret sont chiffrés au repos dans etcd	Secret, ou mieux, Secret Manager pour ce qui sort du cluster
Prendre un control plane dédié « pour être tranquille »	30 jours calendaires facturés, non résiliables	démarrer en mutualisé ; passer en dédié quand un plafond réel est atteint

Glissez pour voir

Le premier antipattern mérite une précision, parce que Scaleway lui-même laisse la porte ouverte. Un serveur SSH est installé et configuré par défaut sur les nœuds Kapsule. La documentation est nette : cet accès existe pour le débogage, et toute action doit passer par Kubernetes. Sur un cluster qui compte, cet accès se désactive, ce qui réduit d'autant la surface exposée.

Kubernetes managé sous l'angle Well-Architected

Un cluster managé déplace la frontière de responsabilité, il ne la supprime pas. Les trois piliers ci-dessous posent les questions qu'un auditeur poserait, et la discipline qui y répond.

Fiabilité

Qu'est-ce qui remplace un nœud, au juste ? La réponse tient en trois mécanismes distincts, et les confondre mène à des attentes fausses.

Mécanisme	Déclencheur	Effet sur la taille du pool	Remplacement
scw k8s node delete	vous, volontairement	diminue de 1	non
scw k8s node replace	vous, volontairement	inchangée	oui
autohealing=true	Kapsule, sur un nœud jugé défaillant	inchangée	oui

Glissez pour voir

Les deux premiers sont les vôtres, le troisième ne l'est pas, et il est désactivé par défaut. Mesuré le 2026-09-12 : un pool créé par cluster create pools.0.* sort avec autoscaling=false et autohealing=false. Sans réglage explicite, rien ne remplacera un nœud à votre place, et un delete laisse durablement un cluster plus petit.

Combien de temps dure le trou quand vous remplacez vous-même ? Mesuré sur un cluster 1.37.0 à trois nœuds DEV1-M : l'ancien nœud quitte l'API Kubernetes à 11 secondes, le cluster retrouve trois nœuds Ready à 125 secondes. Soit environ 114 secondes avec un tiers de capacité en moins.

Discipline : dimensionner pour N-1 nœuds, poser un PodDisruptionBudget sur toute charge qui compte, préférer ScheduleAnyway à DoNotSchedule tant qu'il n'y a pas de nœud de marge, et activer autohealing explicitement si vous comptez dessus.

Une seconde question vaut pour l'isolation totale, et la documentation de Scaleway s'y contredit. La page des clusters multi-AZ affirme qu'il n'existe qu'un seul Public Gateway par Private Network, et en tire que perdre la zone qui l'héberge ferait tomber tous les nœuds privés, dans toutes les zones. La FAQ des Public Gateways, elle, conseille d'en attacher plusieurs, venus de zones différentes, à un même Private Network.

Les deux pages ne peuvent pas avoir raison ensemble. Tant que l'écart n'est pas tranché, traitez la passerelle comme un point de défaillance unique jusqu'à preuve du contraire dans votre propre lab : c'est l'hypothèse qui coûte le moins cher si elle est fausse. Une architecture multi-zone qui repose sur un composant mono-zone n'est pas multi-zone.

Sécurité

Qu'est-ce qui reste joignable depuis Internet une fois le cluster créé ? Plus de choses qu'on ne l'imagine, et certaines ne se ferment pas.

Le control plane garde une adresse IP publique : un cluster entièrement privé n'est pas réalisable sur Kapsule, et le seul levier documenté est de supprimer la règle ACL par défaut créée avec le cluster. Les nœuds se privatisent, mais pas au même degré selon le mode : en isolation contrôlée ils gardent une adresse IP publique pour leur trafic sortant, le trafic entrant étant bloqué par le groupe de sécurité ; seule l'isolation totale la leur retire, au prix de la dépendance au Public Gateway.

Discipline : restreindre l'ACL du control plane dès la création plutôt que de la laisser ouverte, désactiver le serveur SSH des nœuds, et réserver les Secret aux valeurs sensibles puisque le chiffrement au repos d'etcd ne couvre qu'eux.

Optimisation des coûts

Qui paiera le Load Balancer que personne n'a créé à la main ? Un Service de type LoadBalancer fait provisionner par le cloud controller un vrai Load Balancer facturé à l'heure. Il n'apparaît dans aucun manifeste et se retrouve sur la facture.

Le danger n'est pas son prix mais son orphelinage : supprimer le cluster sans avoir supprimé le Service laisse le Load Balancer sans personne pour le réclamer, et la facturation continue.

Discipline : supprimer les Service de type LoadBalancer avant le cluster, puis relister scw lb lb list pour confirmer le retour à zéro. Un teardown qui ne vérifie pas n'est pas un teardown.

FAQ : questions fréquentes sur Kubernetes chez Scaleway

Ces réponses reprennent les questions posées avant la première création de cluster, celles dont la réponse engage de l'argent ou une contrainte de 30 jours. Les chiffres viennent de la documentation produit et des relevés à l'API du 2026-09-12.

Kapsule ou Kosmos : quelle différence ?

Kapsule ne contient que des Instances Scaleway ; Kosmos rattache à un control plane managé des machines de n'importe quel fournisseur ou de votre salle. On ne convertit pas l'un en l'autre : il faut recréer le cluster.

Le control plane Kubernetes est-il gratuit chez Scaleway ?

Seul le control plane mutualisé de Kapsule est gratuit. Celui de Kosmos coûte 0,1444 EUR/h, soit 105,41 EUR par mois. Les control planes dédiés sont facturés à l'heure dans les deux familles, avec un engagement de 30 jours calendaires.

Combien de nœuds un cluster Kapsule peut-il contenir ?

150 nœuds avec un control plane mutualisé, 250 avec un dédié 4 Go, 500 avec un dédié 8 ou 16 Go. L'API refuse la demande à la validation des arguments, sans rien provisionner ni facturer.

Peut-on créer un cluster Kapsule entièrement privé ?

Non. La documentation Scaleway indique qu'un control plane sans adresse IP publique n'est pas possible sur Kapsule. Le seul contournement consiste à supprimer la règle ACL par défaut créée avec le cluster.

Combien coûte le Container Registry de Scaleway ?

Les images privées coûtent 0,027 €/Go/mois de stockage ; les images publiques sont gratuites jusqu'à 75 Go. L'entrée est toujours gratuite, et la sortie l'est aussi tant qu'elle reste dans la même région.

Quelle version de Kubernetes choisir sur Kapsule ?

La dernière version mineure disponible, car la fenêtre de support Scaleway est de 14 mois à partir de sa sortie. La 1.37 est sortie le 26 août 2026, sera dépréciée le 28 août 2027 et sans support le 28 octobre 2027.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• Seul le control plane mutualisé de Kapsule est gratuit : celui de Kosmos coûte 0,1444 €/h, soit plus de 100 € par mois.
• Kapsule n'accepte que des Instances Scaleway, Kosmos accepte tout le reste, et on ne convertit jamais l'un en l'autre.
• Le plafond du mutualisé est de 150 nœuds : l'API répond a kapsule cluster can't have more than 150 nodes sans rien provisionner.
• Un control plane dédié engage 30 jours calendaires ; toute montée en gamme relance le compteur, et la descente est interdite pendant l'engagement.
• Un etcd au-delà de 55 Mo interdit le retour au mutualisé, engagement terminé ou non.
• Le Private Network est auto-créé en /22 et non détachable : c'est la décision de création la moins réversible.
• Renommer un cluster redéploie tout son control plane, avec 5 à 10 minutes de perturbation annoncées par Scaleway.
• La 1.34 est dépréciée le 2026-09-29 : relevez les dates avec scw k8s version list, jamais de mémoire.
• Seuls les Secret sont chiffrés au repos dans etcd, pas les ConfigMap.
• Un lab détruit coûte quelques centimes, un lab oublié coûte environ 61 € par mois.

Pour aller plus loin

• Créer un cluster Kapsule : Met en pratique les décisions de cette carte, et mesure ce que chaque étape coûte en temps.
• Kosmos : Approfondit l'arbitrage entre les deux familles, avec les plafonds relevés à l'API.
• Monter un cluster de version : Montre ce que devient un cluster quand la version qu'il porte arrive en fin de support.

Ressources externes

• Offres de control plane Kubernetes : le tableau officiel des plafonds de nœuds et d'etcd, et les conditions exactes de l'engagement de 30 jours.
• FAQ Kubernetes Scaleway : la source des réponses sur le chiffrement d'etcd, le service kapsule-agent et les effets d'un renommage de cluster.
• Politique de support des versions : le calendrier de sortie, de dépréciation et de fin de support, ainsi que les CNI et runtimes réellement supportés.
• Quotas de l'Organisation : le nombre de clusters autorisés selon que le moyen de paiement ou l'identité est validé.
• Sécuriser un cluster avec un Private Network : les modes d'isolation des nœuds et la limite du control plane public.

×

📖 Voir la documentation →