Kosmos : un Kubernetes managé dont les nœuds ne sont pas tous chez Scaleway

Kosmos rattache à un control plane managé par Scaleway des machines venues de n'importe où, et la moitié des automatismes de Kapsule s'arrête à ces machines. Cette leçon dit ce que la liberté multicloud coûte réellement : pas d'intégration VPC, pas d'autoréparation ni d'autoscaling sur les nœuds externes, pas de volumes Block, et des mises à jour à faire nœud par nœud. Vous relèverez les plafonds des deux familles directement à l'API, en une commande, plutôt que de les lire dans un tableau qui peut dater.

Ce que vous allez apprendre

• Décider entre Kapsule et Kosmos sur des critères mesurables.
• Identifier les automatismes qui s'arrêtent aux nœuds externes.
• Relever les plafonds et l'engagement des deux familles à l'API.
• Reconnaître les cas où Kosmos est le mauvais outil.

Qu'est-ce que Kosmos apporte que Kapsule ne peut pas ?

Une seule chose, mais elle est structurante : des nœuds qui ne sont pas des Instances Scaleway. Kapsule ne sait accueillir que des Instances de son propre fournisseur. Kosmos accepte, en plus des Instances, des serveurs Elastic Metal, des machines RiscV, et des serveurs de n'importe quel autre fournisseur, y compris ceux de votre propre salle.

Deux usages le justifient vraiment. Le premier est la réversibilité : garder une partie de la capacité hors de chez Scaleway, pour ne pas dépendre d'un seul fournisseur. Le second est l'absorption d'un existant : rattacher des machines déjà en place à un control plane managé, plutôt que de les migrer.

Tout le reste plaide pour Kapsule, et la suite de cette page explique pourquoi.

Le malentendu le plus courant consiste à choisir Kosmos par principe de précaution, sans qu'aucune machine externe n'existe encore. L'argument paraît prudent : garder la porte ouverte ne coûterait rien. Il coûte en réalité quatre fonctions dès le premier jour, sur la totalité du cluster et pas seulement sur les nœuds qu'on n'a pas. L'intégration VPC disparaît, donc l'isolation réseau de Scaleway aussi. L'autoscaling et l'autoréparation ne s'appliquent plus qu'aux Instances Scaleway, ce qui est le cas de tous vos nœuds, mais les mécanismes deviennent partiels et l'exploitation doit en tenir compte. Le CNI imposé devient kilo, conçu pour un maillage chiffré entre fournisseurs, là où cilium exploiterait un réseau plat. Vous payez donc immédiatement le prix d'une flexibilité que vous n'utilisez pas encore, et rien ne garantit que vous l'utiliserez un jour.

Qu'est-ce que Kosmos retire ?

Les automatismes qui reposent sur l'infrastructure Scaleway s'arrêtent aux nœuds qui n'en font pas partie. C'est logique, et c'est rarement présenté aussi nettement.

Fonction	Kapsule	Kosmos
Origine des nœuds	Instances Scaleway, x86 ou ARM	pools internes : Instances ; pools externes : Elastic Metal, RiscV, autres fournisseurs
Répartition possible	mono-zone ou multi-zone, même région	mono-zone, multi-zone, multi-région, multicloud
CNI	cilium ou calico	kilo, imposé
Autoréparation	oui	Instances Scaleway uniquement
Autoscaling	oui	Instances Scaleway uniquement
Volumes persistants Block	oui	Instances Scaleway uniquement
Intégration VPC	isolation contrôlée ou totale	aucune
Mise à jour des nœuds	gérée par le service	pools externes : manuelle, nœud par nœud

Glissez pour voir

La ligne des mises à jour est celle qui pèse le plus dans la durée. Sur Kapsule, monter un cluster de version est une opération que le service exécute. Sur un pool externe de Kosmos, elle redevient un travail d'exploitation à mener machine par machine, à chaque version. Multipliez par le nombre de nœuds externes et par la fréquence des correctifs, et vous obtenez le vrai coût de la réversibilité.

Kosmos s'appelle « multicloud » dans l'API

Aucun type de cluster ne porte le nom « kosmos ». La commande qui les liste renvoie multicloud, multicloud-dedicated-4, et ainsi de suite.

Le nom commercial et le nom technique diffèrent : cherchez multicloud dans les sorties de la CLI, du provider Terraform et des SDK, pas kosmos.

Pourquoi le CNI kilo est-il imposé ?

Parce que c'est l'architecture retenue par Scaleway pour supporter des nœuds externes, et il faut le dire ainsi plutôt que d'en faire une loi de la nature. La documentation est nette : Kapsule accepte cilium et calico, Kosmos impose kilo.

Ce n'est pas que cilium en serait incapable. Il sait fonctionner en mode tunnel comme en mode routé, et ne réclame pas intrinsèquement un réseau privé plat. Le fait à retenir est donc une décision produit, pas une limite technique de cilium : Scaleway a choisi kilo pour la famille multicloud, et ce choix s'impose à vous.

kilo monte un maillage chiffré entre les nœuds, par-dessus Internet. C'est ce qui rend Kosmos possible, et c'est aussi ce qui explique l'absence d'intégration VPC : le réseau du cluster est construit par le CNI, pas par le fournisseur.

La conséquence à retenir est une conséquence de performance. Le trafic entre deux pods situés chez deux fournisseurs différents traverse Internet, chiffré, avec la latence et la variabilité que cela suppose. Une application dont les composants se parlent beaucoup ne doit pas être répartie à l'aveugle sur un cluster Kosmos : il faut décider quels services vivent ensemble, et les y maintenir par des nodeSelector ou des affinités. Sur Kapsule, la question ne se pose pas, tous les nœuds partageant le même réseau régional.

Relever les plafonds à l'API plutôt que dans un tableau

Une seule commande donne les plafonds réels des huit types de cluster, Kapsule et Kosmos confondus. C'est la source la plus fiable qui soit : elle vient du produit lui-même, et le lecteur peut la rejouer.

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\(.audit_logs_supported)\t\(.sla)"' \
  | column -t -s $'\t' -N 'TYPE,NOEUDS,ETCD,RAM,AUDIT,SLA'

La sortie doit afficher huit lignes. Relevé le 2026-09-12 avec scw 2.62.0 :

TYPE                     NOEUDS  ETCD    RAM    AUDIT  SLA
kapsule                  150     55 Mo   4 Go   false  0
kapsule-dedicated-4      250     200 Mo  4 Go   true   99.5
kapsule-dedicated-8      500     200 Mo  8 Go   true   99.5
kapsule-dedicated-16     500     200 Mo  16 Go  true   99.5
multicloud               150     55 Mo   4 Go   false  0
multicloud-dedicated-4   250     200 Mo  4 Go   true   99.5
multicloud-dedicated-8   500     200 Mo  8 Go   true   99.5
multicloud-dedicated-16  500     200 Mo  16 Go  true   99.5

Les deux familles ont exactement les mêmes plafonds et les mêmes classes de control plane. Elles n'ont pas le même prix, et c'est le fait le plus structurant de cette page.

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. Kosmos coûte donc plus de 100 € par mois avant le premier nœud, là où Kapsule ne coûte rien tant qu'on reste en mutualisé. Le choix ne se joue donc pas seulement sur l'origine des nœuds et sur les automatismes perdus : il se joue aussi sur une facture fixe qui court, que le cluster travaille ou non.

La doc comparative officielle affirme encore que les deux mutualisés sont gratuits

La page officielle de comparaison Kapsule et Kosmos porte une ligne « Free mutualized control plane : Yes / Yes ». La grille tarifaire du même fournisseur, relevée le 2026-09-12, facture pourtant le mutualisé Kosmos 0,1444 €/h, et les conditions contractuelles distinguent explicitement les deux cas.

Les deux pages sont officielles et l'une est périmée. C'est exactement ce que la préséance des sources sert à trancher : une page de référence peut rester en place des mois après que le produit a changé. Sur une question de prix, la grille tarifaire et les conditions font foi, pas un tableau comparatif.

Vérifiez toujours un « c'est gratuit » sur la page de tarifs avant de bâtir une architecture dessus.

L'engagement de 30 jours est un champ de l'API, pas une clause commerciale

La même commande porte commitment_delay, en secondes :

scw k8s cluster-type list region=fr-par -o json \
  | jq -r '.[] | "\(.name) : engagement \(.commitment_delay | tonumber / 86400) jour(s)"'

La sortie doit afficher 0 jour pour kapsule et multicloud, et 30 jours pour les six types dédiés. La valeur brute vaut 2592000, soit 30 × 86 400 à la seconde près.

C'est la meilleure façon de vérifier une contrainte contractuelle : la lire dans le produit plutôt que dans une page de tarifs.

Kapsule ou Kosmos : la décision en trois questions

Lisez ce tableau par la colonne du milieu : elle donne la question à se poser, dans l'ordre où elle se pose.

Critère de décision	Quand il impose Kosmos	Pourquoi Kapsule sinon
Origine des machines	des nœuds existent hors de Scaleway et doivent rester	Kapsule couvre tout ce qui est Instance Scaleway
Élasticité attendue	aucune : les nœuds externes sont dimensionnés à la main	l'autoscaling ne fonctionne que sur Instances Scaleway
Persistance des données	aucune charge avec état sur les nœuds externes	le CSI Block Storage ne couvre que les Instances Scaleway
Isolation réseau	l'isolation Scaleway n'est pas un besoin	Kosmos n'a aucune intégration VPC

Glissez pour voir

La première question tranche à elle seule la grande majorité des cas. Si toutes vos machines sont ou peuvent être des Instances Scaleway, Kosmos n'apporte rien et retire beaucoup. La réversibilité est un argument légitime, mais elle se paie en exploitation quotidienne, pas une fois à la signature.

On ne convertit jamais un cluster d'une famille à l'autre

L'appel d'API SetClusterType fait passer un control plane de mutualisé à dédié et inversement, dans les deux familles. Il ne fait jamais passer de Kapsule à Kosmos ni l'inverse.

Changer de famille impose de créer un nouveau cluster, d'y redéployer les charges et d'y migrer les données. C'est la décision la moins réversible de ce volet, et elle se prend avant la première commande.

Ce que Kosmos ne remplace pas

Kosmos n'est pas une solution de reprise après sinistre, et le présenter ainsi mène à une mauvaise surprise. Le control plane reste unique et hébergé par Scaleway : des nœuds répartis chez trois fournisseurs dépendent tous du même point de pilotage.

Kosmos n'est pas non plus un moyen de réduire la latence en rapprochant les nœuds des utilisateurs : le maillage chiffré entre nœuds ajoute du trafic et des sauts. Pour servir plusieurs zones géographiques, plusieurs clusters régionaux distincts restent la réponse habituelle.

Enfin, Kosmos ne supprime pas la dépendance à Scaleway, il la déplace : vos nœuds sont ailleurs, votre control plane reste ici.

Limites, quotas et plafonds

Plafond	Valeur	Source
Nœuds par cluster, control plane mutualisé	150	scw k8s cluster-type list, 2026-09-12
Nœuds par cluster, dédié 8 ou 16	500	scw k8s cluster-type list, 2026-09-12
Taille d'etcd, mutualisé	55 Mo	scw k8s cluster-type list, 2026-09-12
Engagement d'un control plane dédié	2 592 000 s, soit 30 jours	scw k8s cluster-type list, 2026-09-12
Clusters Kosmos par Organisation	20, ou 40 identité validée	page des quotas
CNI disponible sur Kosmos	kilo uniquement	politique de support des versions

Glissez pour voir

Pièges courants

Les deux premiers symptômes portent la chaîne exacte renvoyée par l'API ou par l'aide de la CLI. Les deux suivants décrivent des comportements documentés par Scaleway, que ce guide n'a pas reproduits en lab faute de nœud externe.

Symptôme	Cause	Solution
scw k8s cluster-type list ne renvoie aucune ligne « kosmos »	le nom technique est multicloud, jamais « kosmos »	chercher multicloud, multicloud-dedicated-4 et leurs variantes
L'aide dit : 'external' is a special node type used to provision instances from other cloud providers in a Kosmos Cluster	le rattachement d'une machine externe passe par ce type de nœud	employer node-type=external sur le pool externe
Un nœud externe tombé n'est jamais remplacé	l'autoréparation ne couvre que les Instances Scaleway	superviser hors du cluster, remplacer manuellement
Impossible d'attacher le cluster à un Private Network	Kosmos n'a aucune intégration VPC	Kapsule si l'isolation réseau Scaleway est requise

Glissez pour voir

Antipatterns à éviter

Ces quatre erreurs achètent la réversibilité sans en payer le prix d'exploitation.

Antipattern	Conséquence	Discipline
Choisir Kosmos « pour ne pas être enfermé » sans nœud externe réel	on perd VPC, autoscaling, CSI et autoréparation pour rien	Kapsule tant qu'aucune machine externe n'existe vraiment
Placer une base de données sur un pool externe	pas de volume Block, donc pas de persistance gérée	charges avec état sur un pool interne, exclusivement
Compter sur l'autoscaling pour absorber un pic	il ne s'applique pas aux nœuds externes	dimensionner les pools externes pour le pic, ou les exclure du chemin critique
Répartir à l'aveugle des services bavards entre fournisseurs	chaque échange traverse Internet, chiffré	grouper les services couplés avec des nodeSelector

Glissez pour voir

Kosmos sous l'angle Well-Architected

Fiabilité

Que se passe-t-il si un nœud externe cesse de répondre ? Rien d'automatique : l'autoréparation ne le couvre pas, et il restera dans le cluster jusqu'à ce que quelqu'un agisse.

Discipline : superviser les nœuds externes hors du cluster, définir une procédure de remplacement écrite, et ne jamais placer sur eux une charge dont l'indisponibilité serait critique.

Excellence opérationnelle

Qui monte les nœuds externes de version, et à quelle fréquence ? Sur les pools externes, la mise à jour est manuelle, nœud par nœud, à chaque version.

Discipline : compter ce travail dans le coût de Kosmos dès la décision, l'automatiser avec votre propre outillage de configuration, et limiter le nombre de nœuds externes à ce qui sert réellement la réversibilité.

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

• Kosmos s'appelle multicloud dans l'API : aucun objet ne porte le nom « kosmos ».
• Mêmes plafonds, pas le même prix : 150 nœuds en mutualisé et 500 en dédié 8 ou 16 des deux côtés, mais le mutualisé Kosmos coûte 0,1444 €/h, soit 105,41 €/mois, quand celui de Kapsule est gratuit.
• La doc comparative officielle affirme encore l'inverse : vérifier un « gratuit » sur la grille tarifaire, jamais sur un tableau de comparaison.
• L'engagement dédié vaut 2592000 secondes, soit 30 jours exactement, et c'est un champ de l'API.
• Autoréparation, autoscaling et volumes Block s'arrêtent aux Instances Scaleway, même sur Kosmos.
• Kosmos n'a aucune intégration VPC : le réseau du cluster est construit par kilo, choix produit de Scaleway et non limite de cilium.
• Les pools externes se mettent à jour manuellement, nœud par nœud, à chaque version.
• On ne convertit jamais Kapsule en Kosmos : il faut créer un nouveau cluster.
• Sans machine externe réelle, Kosmos retire beaucoup et n'apporte rien.

Pour aller plus loin

• Volumes persistants : Détaille le CSI Block Storage, qui ne couvre que les Instances Scaleway.
• Monter un cluster de version : Montre la montée automatique des pools internes, que les pools externes n'ont pas.

Ressources externes

• Différences entre Kapsule et Kosmos : le tableau comparatif officiel, fonction par fonction.
• Créer un cluster Kosmos : la procédure officielle, y compris le rattachement d'un nœud externe.
• Politique de support des versions : les CNI réellement supportés par chaque famille, et le calendrier des versions.
• Projet kilo : le CNI amont imposé par Kosmos, son modèle de maillage chiffré et ses limites.

×

📖 Voir la documentation →