Déployer son premier cluster VKS sur VCF 9 : le guide d'architecte

On me demande souvent si VKS est juste TKG avec un nouveau nom. Réponse courte : non. Réponse un peu plus longue : c’est l’objet de cet article.

L’idée ici n’est pas de parcourir les slides Broadcom. C’est de décoder comment l’écosystème CNCF a été branché dans vSphere, d’identifier les décisions d’architecture qui engagent pour plusieurs années, et de fournir un manifeste YAML de référence que tu peux adapter à ton contexte le jour J.

Audience supposée : tu connais Kubernetes, tu as déjà opéré vSphere, et tu veux comprendre le modèle VKS avant de t’engager — ou avant de convaincre ton équipe de s’y engager.

VKS, c’est quoi en 2026

L’histoire commence avec Tanzu Kubernetes Grid. TKG était un projet distinct, déployé sur vSphere mais indépendant de lui — son propre lifecycle, ses propres versions, sa propre complexité opérationnelle.

TKG Service a marqué une première intégration : Kubernetes provisionné depuis le Supervisor vSphere, avec des abstractions communes. Mais la couture restait visible.

VKS est la prochaine étape. Le renommage n’est pas cosmétique : il acte un élargissement fonctionnel. VKS est désormais un Supervisor Service de première classe, upgradable indépendamment du Supervisor lui-même. C’est le changement qui change tout en termes de lifecycle.

Positionnement dans VCF 9. VKS est le runtime Kubernetes natif de la plateforme. Il est CNCF-conformant — ce qui signifie que tes manifests Kubernetes standards fonctionnent sans modification. La distribution VKr (VMware Kubernetes release) est un OVA signé et versionné, équivalent conceptuel d’une AMI pour ton control plane et tes nodes.

Face à la concurrence. OpenShift apporte plus d’opinions et plus d’outillage opérationnel intégré, au prix d’une adhérence plus forte. Rancher excelle sur les déploiements multi-cloud et les clusters hétérogènes. EKS Anywhere cible les équipes déjà dans l’écosystème AWS. VKS vise l’organisation qui a déjà investi dans vSphere et qui veut Kubernetes sans sortir de la gouvernance vCenter. Les trade-offs sont différents — pas question de dire que l’un est meilleur, mais de choisir selon le contexte.

La feature qui mérite d’être retenue : VKS est upgradable sans toucher au Supervisor. Pour une organisation qui gère des cycles de mise à jour vSphere contraints par les changements, c’est un argument opérationnel concret.

L’architecture sous le capot

Comprendre VKS, c’est comprendre comment six composants s’articulent. On les parcourt vite, on revient sur les deux qui comptent vraiment.

Deux composants méritent qu’on s’y arrête.

Le Supervisor est le point de défaillance central. Il héberge l’API server Kubernetes et orchestre tous les clusters VKS du cluster vSphere. S’il casse, tous les clusters du même cluster vSphere sont impactés au plan control plane — les workloads continuent de tourner, mais plus aucune opération Kubernetes ne passe. Le Supervisor doit être sur une topologie vSphere HA. Ce n’est pas une recommandation, c’est une exigence opérationnelle.

Le VKr change fondamentalement le lifecycle. Jusqu’ici, upgrader Kubernetes sous vSphere impliquait souvent d’upgrader la plateforme. Avec VKr, le Supervisor peut héberger plusieurs versions Kubernetes simultanément. Un cluster en v1.30 et un autre en v1.32 peuvent coexister sur le même Supervisor. L’upgrade d’un cluster VKS ne touche pas les autres. C’est ce découplage qui donne à VKS son argument opérationnel principal.

Les prérequis

Ce que la doc officielle ne met pas toujours en avant clairement.

Les trois chemins de consommation

VKS propose trois façons de provisionner un cluster. Elles ne se valent pas — chacune vise un profil d’utilisateur précis.

Recommandation assumée. LCI pour la découverte et les POC. kubectl + YAML pour la production single-tenant ou les petites platefrom teams avec culture GitOps. VCF Automation pour le multi-tenant avec gouvernance formelle. Ne pas sur-ingénier dès le départ : commencer par kubectl, migrer vers VCFA quand la demande le justifie.

Walkthrough LCI en 6 étapes

Le chemin le plus rapide pour un premier cluster. Basé sur le walkthrough de William Lam, référencé en fin d’article.

1. Installer le service LCI comme Supervisor Service depuis le Broadcom Support Portal. Le manifest est disponible dans la section Free Downloads → vSphere Supervisor Services. L’installation se fait depuis l’UI vCenter → Workload Management → Supervisor Services.

2. Accéder à LCI depuis vSphere UI (onglet dédié dans Workload Management) ou en interface autonome à l’URL du service. L’interface se connecte automatiquement au Supervisor du cluster vSphere courant.

3. Création guidée — sélectionner le namespace cible, la class de cluster (small/medium/large), la version VKr, et le nombre de nodes. LCI propose des combinaisons validées et prévient si les quotas namespace sont insuffisants.

4. Générer le YAML — LCI exporte le manifeste CAPI correspondant aux choix effectués. Ce YAML est exactement ce qu’on aurait écrit à la main. C’est aussi le moyen le plus rapide de comprendre la structure CAPI sans partir d’une page blanche.

5. Appliquer via kubectl ou VCF CLI. Le manifeste peut être versionné dans Git à ce stade pour initialiser un repository GitOps.

6. Télécharger le kubeconfig depuis LCI ou via kubectl une fois le cluster provisionné. La commande de récupération :

# Connexion au Supervisor
kubectl vsphere login --server=supervisor.example.com --insecure-skip-tls-verify

# Switch vers le namespace cible
kubectl config use-context platform-team

# Application du manifest
kubectl apply -f cluster.yaml

# Vérification du provisioning
kubectl get clusters -n platform-team

# Récupération du kubeconfig workload cluster
kubectl vsphere login --server=supervisor.example.com \
  --tanzu-kubernetes-cluster-namespace platform-team \
  --tanzu-kubernetes-cluster-name production-cluster-01

Le manifeste YAML décortiqué

Le manifeste CAPI pour un cluster VKS est court. Chaque ligne a une raison d’être.

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: production-cluster-01
  namespace: platform-team       # vSphere Namespace cible
spec:
  clusterNetwork:
    services:
      cidrBlocks: ["10.96.0.0/12"]      # Plage IPs services Kubernetes
    pods:
      cidrBlocks: ["192.168.0.0/16"]    # Plage IPs pods
    serviceDomain: cluster.local
  topology:
    class: tanzukubernetescluster       # ClusterClass installé par le Supervisor
    version: v1.32.0+vmware.1           # Version VKr à utiliser
    controlPlane:
      replicas: 3                       # HA obligatoire — jamais 1 en prod
    workers:
      machineDeployments:
        - class: node-pool
          name: workers
          replicas: 3
    variables:
      - name: vmClass
        value: guaranteed-medium        # Classe VM pour les nodes
      - name: storageClass
        value: vsan-default-storage-policy
      - name: defaultStorageClass
        value: vsan-default-storage-policy

apiVersion et kind. On utilise Cluster API v1beta1 — le même upstream que tout autre déploiement CAPI. VKS ne réinvente pas la spec, il la spécialise via des ClusterClasses et des variables. Un ingénieur qui connaît CAPI reconnaît immédiatement la structure.

clusterNetwork. Les ranges CIDR doivent être alignés avec le plan d’adressage global de l’organisation. En multi-environnement (dev/staging/prod), utiliser des plages disjointes pour éviter les collisions si jamais des clusters doivent communiquer via VPN ou peering. Ne jamais laisser les defaults si tu opères plusieurs clusters.

topology.class. La référence à tanzukubernetescluster pointe vers le ClusterClass installé par le Supervisor. C’est ce qui différencie un cluster VKS d’un cluster CAPI générique : la ClusterClass embarque toute la logique d’intégration vSphere (templates de machines, bootstrap, CNI). Ne pas modifier cette valeur.

topology.version. La notation +vmware.1 est le suffixe VMware. Elle identifie la VKr exact à déployer, avec ses patches backportés. Utiliser toujours une version disponible dans la Content Library synchronisée — le provisioning échoue silencieusement si l’OVA n’est pas présent localement.

controlPlane.replicas. 3 minimum, toujours. Le quorum etcd fonctionne sur des nombres impairs. Avec 1 seul control plane node, la perte d’un hôte ESXi rend le cluster inopérant. Avec 3, tu perds un hôte et ton cluster continue de fonctionner normalement.

vmClass. La classe VM détermine les reservations CPU et mémoire des nodes. Les classes guaranteed-* réservent les ressources garantissant les performances. Les classes best-effort-* ne réservent rien — acceptables pour du dev/test, à éviter absolument en production. guaranteed-medium (4 vCPU / 16 Go) est un bon point de départ pour un cluster applicatif standard.

storageClass. La storage policy vSphere qui sera utilisée pour tous les PersistentVolumes du cluster. Cette policy doit exister dans vSphere et être attachée au namespace cible. En vSAN ESA, la politique RAID-6 avec chiffrement est un bon défaut production.

Day-2 operations

La liste de courses ne s’arrête pas au provisioning. Ce qui se passe après détermine si le cluster tient dans le temps.

Persistent Volumes. CNS (Cloud Native Storage) matérialise chaque PVC en un VMDK provisionné automatiquement sur le datastore couvert par la storage policy du cluster. Du point de vue du workload : un PVC standard Kubernetes. Du point de vue du storage admin : un VMDK visible dans vCenter, snapshotable, réplicable avec les outils vSphere habituels. Les deux mondes sont réconciliés sans couche d’abstraction custom.

Services LoadBalancer. L’intégration native avec NSX Advanced LB (Avi) alloue une IP depuis un pool dédié pour chaque service de type LoadBalancer. Le pool IP est configuré dans le namespace vSphere. Pas de MetalLB à déployer, pas de configuration BGP à maintenir — l’intégration est transparente pour les développeurs.

Ingress. VKS ne déploie pas de contrôleur Ingress par défaut. Le choix appartient au platform team : Contour pour les environnements avec intégration NSX, NGINX pour les équipes qui le connaissent déjà. À déployer via Helm ou en tant que package VKS selon la version. External-DNS peut être greffé pour automatiser les enregistrements DNS vers Microsoft DNS ou AWS Route 53.

Observabilité. Le stack standard fonctionne : Prometheus Operator + Grafana + Loki déployés dans le cluster, avec forward des logs et métriques vers VCF Operations for Logs pour corréler l’infra vSphere et les workloads Kubernetes. Un article dédié Broadcom (avril 2026) détaille l’intégration VKS + VCF Operations.

External-DNS. L’automatisation des enregistrements DNS depuis Kubernetes est supportée via le chart External-DNS standard, avec le provider adapté au serveur DNS de l’organisation. À configurer avec un compte de service dédié, pas avec des credentials admin.

Service mesh. Istio est disponible via le package standard VKS depuis la version 3.4 — déployable sans modifications custom. Pour les équipes qui n’ont pas de culture service mesh, ne pas forcer : les NetworkPolicies Antrea + mTLS Antrea couvrent la majorité des besoins de sécurité réseau sans la complexité opérationnelle d’un service mesh complet.

Upgrade asynchrone : la feature sous-estimée

Historiquement, upgrader Kubernetes sous vSphere obligeait à upgrader la plateforme. Plus en VCF 9.

Le découplage Supervisor ↔ version VKS. Le Supervisor héberge plusieurs versions VKr simultanément. Un cluster en v1.30 et un cluster en v1.32 peuvent coexister sur le même Supervisor, dans le même cluster vSphere. La version de Kubernetes des workload clusters n’est plus liée au cycle de vie vCenter.

Enregistrement synchrone vs asynchrone. VKS supporte deux modes d’enregistrement des nouvelles versions VKr. Le mode synchrone (défaut) télécharge automatiquement les nouvelles VKr depuis la Content Library. Le mode asynchrone permet de contrôler manuellement quelles versions sont disponibles — indispensable pour les environnements avec validation interne ou contraintes de change management. En air-gapped, la VKr doit être importée manuellement via la procédure de offline VKr relocation documentée par Broadcom.

En pratique. Le cycle de patch Kubernetes (3 mois typiquement) peut désormais être découplé du cycle de mise à jour vSphere (trimestriel ou semestriel selon l’organisation). Les équipes sécurité peuvent imposer un SLA de patch Kubernetes sans bloquer sur les cycles infrastructure.

Gotchas et limites réelles

Ce que les slides marketing ne disent pas.

Conclusion et suite

Ce qu’il faut retenir. VKS repose sur trois piliers : le Supervisor comme plan de contrôle vSphere-natif, CAPI comme moteur déclaratif standard, et VKr comme distribution versionnable et découplée. Les trois chemins de consommation (LCI, kubectl, VCFA) répondent à des maturités différentes. Le manifeste YAML est du CAPI standard avec des variables VMware — accessible pour n’importe quel ingénieur Kubernetes. Le day-2 (volumes, LB, observabilité) s’appuie sur des patterns connus, intégrés dans la stack vSphere.

Prochaine étape. L’article suivant traite de l’industrialisation : comment utiliser Terraform et VCF Automation pour provisionner des clusters VKS en self-service multi-tenant, avec des politiques de gouvernance formalisées et un catalogue de services. C’est le chemin naturel une fois que le premier cluster en kubectl tourne en production.

Ressources.

Pour aller plus loin :

• Broadcom TechDocs — Architecture VKS — référence officielle sur les composants Supervisor, CAPI, VKr
• Broadcom TechDocs — Déploiement de clusters VKS — procédures de provisioning pas à pas
• William Lam — MS-A2 VCF 9.0 Lab: Configuring VKS — walkthrough LCI de référence avec captures
• VCF Blog — Istio on VKS — intégration service mesh
• VCF Blog — Observability on VKS — stack observabilité VKS + VCF Operations