En 9.0, VKS était un excellent runtime Kubernetes vSphere-natif, mais opérer la plateforme restait un travail de platform team. Provisionner un namespace propre, y attacher quotas, registry, ingress et identité, c’était une suite d’étapes manuelles que les équipes applicatives ne pouvaient pas déclencher seules. Le gap entre « cluster opéré » et « plateforme self-service » se comblait à coups de scripts maison.
VCF 9.1 attaque ce gap frontalement. Quatre changements — linked clones pour VKS, scale à 500 clusters par Supervisor, Container-as-a-Service simplifié, stockage objet natif en Tech Preview — déplacent la frontière : ce que le platform team faisait à la main devient un construct consommable. Cet article décode chacun, avec le delta 9.0 → 9.1 et l’impact concret côté architecture.
Série « Nouveautés VCF 9.1 » — 3/4
Mini-série sur les nouveautés de VMware Cloud Foundation 9.1 :
- Efficience d’infrastructure & TCO
- Networking & scale
- Kubernetes & self-service (cet article)
- Sécurité & résilience
Crédits visuels
Visuels © Broadcom, repris du blog officiel VCF (liens en fin d’article). Synthèse et analyse personnelles.
VKS & VM Fast-Deploy : les linked clones changent l’échelle
Jusqu’en 9.0, chaque node VKS — control plane comme worker — était un full clone de l’OVA VKr : copie complète du disque source vers le datastore avant le premier boot. Sur un cluster de 6 nodes, c’est six copies de plusieurs Go à provisionner, séquentiellement contraintes par le débit du datastore. Le temps de déploiement d’un cluster, et plus encore le temps d’un rolling upgrade (chaque node recréé), était dominé par cette copie.
9.1 introduit le Fast-Deploy par linked clones pour VKS et les clusters VM. Le mécanisme : un disque parent en lecture seule (issu de la VKr) est instancié une fois, puis chaque node crée un delta disk qui ne stocke que les blocs modifiés par rapport au parent. Le node boote en quelques secondes au lieu d’attendre une copie intégrale. Conceptuellement, c’est le copy-on-write appliqué au provisioning de nodes Kubernetes.
| Aspect | VKS 9.0 (full clone) | VKS 9.1 (linked clone) |
|---|---|---|
| Création d’un node | Copie complète du disque source | Delta disk au-dessus d’un parent partagé |
| Déploiement cluster 6 nodes | Dominé par N copies séquentielles | Quasi-parallèle, temps réduit drastiquement |
| Rolling upgrade | Chaque node = full clone recréé | Chaque node = delta sur parent existant |
| Empreinte stockage initiale | N × taille image | 1 × parent + N deltas (croissants) |
| Couplage I/O | Copie longue, datastore saturé | Lecture parent partagée, écriture delta |
Impact architecte. Le linked clone n’est pas qu’une optimisation de vitesse : il rend l’upgrade opérationnellement banal. Quand recréer 200 nodes coûte des minutes au lieu d’heures, la fenêtre de change rétrécit et le SLA de patch Kubernetes devient tenable sans négocier des maintenances longues. Le trade-off à intégrer : le disque parent partagé devient un point chaud de lecture, et les delta disks grossissent dans le temps. Le dimensionnement storage se raisonne désormais en parent + croissance des deltas, pas en N × image figée.
Scale : 500 clusters Kubernetes par Supervisor
En 9.0, le Supervisor plafonnait bien en deçà de la centaine de clusters workload utilisables sereinement — suffisant pour une équipe, étroit pour un cloud provider interne servant des dizaines de tenants. 9.1 relève la barre à 500 clusters Kubernetes par Supervisor.
| Dimension | VKS 9.0 | VKS 9.1 |
|---|---|---|
| Clusters / Supervisor | Limite basse (dizaines) | Jusqu’à 500 |
| Modèle visé | Équipe / petit multi-tenant | Cloud provider interne à grande échelle |
| Densité par cluster vSphere | 1 plateforme = 1 Supervisor étroit | 1 Supervisor = fleet Kubernetes complète |
Ce que ça débloque : un seul Supervisor peut désormais porter la flotte Kubernetes d’une organisation entière, au lieu de fragmenter en plusieurs Supervisors (et donc plusieurs périmètres de gouvernance, plusieurs plans de contrôle à opérer). Pour un modèle multi-tenant où chaque tenant reçoit un ou plusieurs clusters dédiés, 500 clusters/Supervisor change la cartographie : moins de Supervisors, gouvernance plus simple, mais blast radius plus large.
Impact architecte. 500 clusters n’est pas un quota gratuit. Le Supervisor reste un plan de contrôle partagé : son etcd, ses controllers CAPI, ses quotas de namespace absorbent désormais une charge de réconciliation bien supérieure. Cinq cents clusters, c’est cinq cents boucles de réconciliation CAPI, des centaines de milliers d’objets dans l’API server du Supervisor, et un etcd dont la latence devient critique. La règle : traiter le chiffre comme un plafond architectural validé, pas comme une cible. Dimensionner le Supervisor (control plane HA, IOPS etcd, observabilité du plan de contrôle) avant d’approcher la densité, et garder une marge.
Container-as-a-Service simplifié
En 9.0, mettre un namespace à disposition d’une équipe applicative ressemblait à ça : créer le vSphere Namespace, attacher manuellement les storage policies, configurer les quotas CPU/RAM/storage, brancher un registry, déployer ou rattacher un ingress controller, puis câbler l’identité (mapping SSO, RBAC). Six étapes, six occasions de divergence entre tenants, et un platform team dans le chemin critique de chaque onboarding.
9.1 transforme ça en un véritable Container-as-a-Service self-service. Le provisioning d’un namespace devient une action consommable qui hérite automatiquement des constructs VCF : registry, ingress, quotas et identité sont dérivés du périmètre VCF du tenant plutôt que recâblés à la main. L’équipe applicative demande un namespace ; elle reçoit un namespace déjà gouverné, avec son registry, son entrée ingress et son identité alignée sur le SSO d’entreprise.
Source : Broadcom — VCF Blog
| Étape onboarding namespace | Flux 9.0 (manuel) | Flux 9.1 (CaaS) |
|---|---|---|
| Création du namespace | Action platform team | Self-service consommable |
| Storage policy | Attachement manuel | Héritée du construct VCF |
| Registry | Branchement séparé | Provisionné avec le namespace |
| Ingress | Déploiement / rattachement manuel | Inclus dans le construct |
| Quotas | Définis à la main par profil | Dérivés du périmètre tenant |
| Identité / RBAC | Mapping SSO manuel | Hérité de l’identité VCF |
Impact architecte. Le platform team sort du chemin critique de l’onboarding sans perdre la gouvernance : les guardrails (quotas, identité, policies) sont encodés dans le construct, pas appliqués après coup. Le rôle du platform team se déplace de l’exécution répétitive vers la définition des profils de tenant. C’est exactement le mouvement qu’on cherchait à scripter en 9.0 — sauf que là, c’est natif et cohérent par défaut.
Native Object Storage (Tech Preview)
Le stockage block (PVC → VMDK via CNS) et le stockage fichier étaient déjà self-service en 9.0. Le grand absent : le stockage objet S3-compatible, que les développeurs réclament pour les artefacts, backups applicatifs, datasets et état d’applications cloud-native. En 9.0, il fallait sortir de la plateforme (bucket externe, MinIO auto-géré) — donc une rupture dans le modèle de gouvernance.
9.1 introduit un stockage objet natif S3-compatible en self-service, en Tech Preview. Les développeurs provisionnent des buckets via le même workflow deploy / scale / manage que pour le block et le fichier ; l’IT conserve les guardrails (quotas, policies, identité) sans devenir un goulot. La promesse : combler la dernière catégorie de stockage manquante pour que la plateforme couvre les trois axes (block, fichier, objet) sous une gouvernance unique.
Tech Preview ≠ production
Le stockage objet natif est livré en Tech Preview dans VCF 9.1. Cela signifie : pas de support production, pas de garantie d’API stable, fonctionnalité susceptible d’évoluer ou d’être retirée avant GA. À utiliser pour évaluer et préparer l’architecture cible — jamais pour porter une charge applicative critique ni des données sans plan de repli vers une solution objet supportée.
| Catégorie de stockage | VKS 9.0 | VKS 9.1 |
|---|---|---|
| Block (PVC) | Self-service via CNS | Self-service via CNS |
| Fichier | Self-service | Self-service |
| Objet (S3) | Hors plateforme | Self-service natif (Tech Preview) |
Impact architecte. L’intérêt n’est pas d’utiliser ça en prod maintenant — c’est de cadrer dès aujourd’hui la cible. Si tes équipes consomment du S3 externe ou du MinIO auto-géré, la Tech Preview permet de prototyper la migration et de mesurer le delta de gouvernance, pour être prêt le jour de la GA sans réécrire les patterns d’accès.
Du cluster opéré à la plateforme self-service
Pris isolément, chacun de ces quatre changements est une amélioration. Pris ensemble, ils ferment le gap self-service de bout en bout.
Les linked clones rendent le provisioning et l’upgrade assez rapides pour être self-service — sans eux, exposer la création de clusters aux équipes saturerait le datastore. Le scale à 500 clusters/Supervisor rend l’échelle multi-tenant atteignable sans fragmenter la gouvernance — c’est le pendant Kubernetes du travail de networking & scale traité dans l’article précédent. Le CaaS simplifié encode la gouvernance dans le construct plutôt que dans des runbooks. Le stockage objet complète la couverture pour que les développeurs n’aient plus à sortir de la plateforme.
Le résultat : ce qu’on construisait à la main par-dessus VKS en 9.0 — un parcours décrit pas à pas dans Déployer son premier cluster VKS sur VCF 9 — devient un comportement natif de la plateforme en 9.1. Le platform team ne disparaît pas ; il passe de l’exécution répétitive à la définition des profils, des guardrails et des quotas. C’est la bascule du cluster opéré vers la plateforme self-service.
Pièges & points de vigilance
Linked clones : couplage stockage / I/O à surveiller
500 clusters n'est pas un etcd gratuit
CaaS : la gouvernance des quotas se définit en amont
Object Storage : Tech Preview, pas GA
Héritage d'identité : cohérence SSO à valider
Blast radius : moins de Supervisors = périmètre plus large
Conclusion
Provisioning self-service-able
Les linked clones rendent déploiement et upgrade assez rapides pour être exposés aux équipes sans saturer le stockage. L’upgrade devient opérationnellement banal.
Échelle multi-tenant
500 clusters par Supervisor atteignent l’échelle cloud provider interne sans fragmenter la gouvernance — à condition de dimensionner etcd et le control plane.
Gouvernance encodée
CaaS et stockage objet (Tech Preview) déplacent la gouvernance dans le construct. Le platform team définit les profils, ne les exécute plus.
Prochaine étape. Le quatrième et dernier article de la série traite de la sécurité & résilience de VCF 9.1 — le pendant défensif de cette ouverture self-service : plus on expose la plateforme, plus les guardrails de sécurité et les mécanismes de résilience deviennent structurants. À lire en complément de l’article networking & scale, qui pose les fondations réseau de cette même flotte.
Pour aller plus loin.
Ressources :
- Annonce VCF 9.1 — billet officiel Broadcom
- Release Notes VCF 9.1 — détail des nouveautés et limites
- Documentation VKS — référence officielle vSphere Kubernetes Service
- William Lam — walkthroughs et deep-dives communautaires