Provisionner un cluster VKS, c’est l’épreuve facile. Le maintenir en vie six mois plus tard avec des upgrades, du capacity management et des incidents qui n’attendent pas, c’est l’épreuve qui sépare les plateformes pérennes des POCs déguisés en production.
Cet article parcourt les opérations day-2 qui structurent un cluster VKS opéré sérieusement : le lifecycle CAPI, les upgrades, le backup, l’observabilité, et le scaling. L’objectif est de donner les pratiques de référence et les pièges que la doc officielle ne souligne pas.
Audience supposée : tu as déjà un cluster VKS qui tourne (voir le guide d’architecte) et tu prépares la mise en production.
Nature de cet article
Synthèse appuyée sur la documentation Broadcom VCF 9, les patterns Cluster API upstream, et les retours communauté autour des upgrades VKr. La valeur est dans la séquence d’étapes et les ordonnancements à respecter.
Le lifecycle CAPI en pratique
VKS s’appuie sur Cluster API. Comprendre ses primitives, c’est comprendre comment tu opères ton cluster — chaque action passe par un manifest YAML appliqué au Supervisor.
Cluster — la ressource racine. Décrit la topologie attendue (control plane replicas, workers, version). Modifier ses champs déclenche une réconciliation par CAPI.
MachineDeployment — l’équivalent d’un Deployment Kubernetes mais pour des VMs nodes. Gère un pool de workers avec rolling update natif.
Machine — une VM individuelle. Possède un cycle de vie propre (provisioning, running, deleting). Suppression d’une Machine déclenche son remplacement par CAPI.
KubeadmControlPlane — gère le control plane. Encapsule la logique d’upgrade etcd + API server, qui ne tolère pas les approximations.
ClusterClass — le template paramétrable installé par le Supervisor. C’est lui qui transforme un manifest CAPI standard en cluster VKS spécifique.
La règle qui change tout. Toutes les modifications passent par le manifest. Pas de kubectl edit direct sur les Machines. Pas de modification manuelle des VMs dans vCenter. Si tu as besoin de “réparer” un node, tu le supprimes via CAPI et tu laisses la réconciliation le recréer. C’est contre-intuitif pour qui vient du monde vSphere classique, mais c’est la seule façon de garder un état cohérent.
Scaling : horizontal vs vertical
Deux dimensions à scaler, deux mécaniques différentes.
Horizontal (ajouter des nodes). Modifier replicas dans le MachineDeployment du worker pool. Augmenter de N à N+1 déclenche le provisioning d’un nouveau worker. Diminuer déclenche un drain + delete propre — les pods sont evacués selon leurs PDB. C’est l’opération courante et sûre.
Vertical (changer le sizing des nodes). Modifier la vmClass (par exemple passer de guaranteed-medium à guaranteed-large) entraîne un rolling replace : chaque node existant est progressivement remplacé par un node de la nouvelle classe. C’est plus lourd, pendant lequel le cluster a temporairement plus de nodes que la cible. Prévoir le quota namespace pour absorber ce surplus transitoire.
Cluster Autoscaler : pas activé par défaut
VKS n’active pas le Cluster Autoscaler par défaut. Il faut le déployer explicitement et le configurer pour interagir avec CAPI. Sans lui, le cluster ne grandit pas tout seul même si les pods sont en Pending. Dans la majorité des cas, c’est volontaire — un autoscaler activé sans gouvernance peut faire exploser la facture côté quota namespace. À activer une fois la maturité opérationnelle suffisante.
Upgrades Kubernetes : la séquence à respecter
Le découplage Supervisor / version VKS est l’argument opérationnel principal de la plateforme. Encore faut-il l’utiliser correctement.
┌─────────────────────────────────────────────────────────┐
│ Supervisor (vCenter embed) │
│ ├── VKr v1.30 (cluster A) ← upgradable │
│ ├── VKr v1.31 (cluster B) ← indépendamment │
│ └── VKr v1.32 (cluster C) ← les uns des autres │
└─────────────────────────────────────────────────────────┘Étape 1 — Récupérer la VKr cible. En mode synchrone (par défaut), la Content Library Subscribed reçoit automatiquement les nouvelles VKr depuis le dépôt Broadcom. En mode asynchrone, l’admin valide et importe manuellement. Vérifier que l’OVA cible est bien présent localement avant tout upgrade.
Étape 2 — Modifier la version dans le manifest Cluster. Changer topology.version de v1.30.0+vmware.1 vers v1.31.0+vmware.1 puis kubectl apply. CAPI déclenche la séquence d’upgrade.
Étape 3 — Upgrade du control plane. KubeadmControlPlane upgrade les nodes du CP un par un, avec validation etcd à chaque étape. Si etcd ne reprend pas le quorum après le redémarrage d’un node, l’upgrade s’arrête. C’est le bon comportement — ne pas forcer un dépassement.
Étape 4 — Upgrade des workers. Une fois le control plane stable, les MachineDeployments démarrent leur rolling update. Les pods sont drainés selon leurs PDB. Plus les PDB sont strictes, plus l’upgrade est lent — c’est l’objectif.
Étape 5 — Validation post-upgrade. Smoke test des workloads critiques, vérification des CRDs (certaines sont versionnées), check de la métrologie (le kubelet change de version, certains labels de métriques aussi).
Skip de version ∉ supporté
Tu ne peux pas sauter une mineure Kubernetes. v1.30 → v1.32 directement = échec garanti. Il faut passer par v1.31. Cela vaut aussi pour les VKr : la séquence respecte la matrice de compatibilité Kubernetes upstream. Lire les release notes VKr avant chaque upgrade pour valider la séquence.
Backup et restore
Sujet souvent reporté à plus tard. À ne pas reporter.
Quoi — snapshot du store etcd qui contient toute la state Kubernetes (resources, secrets, statuses).
Quand — automatique avec KubeadmControlPlane sur des intervalles configurables. Stockage sur un PVC dédié, à exporter régulièrement vers un stockage externe.
Restore — procédure manuelle, complexe. À pratiquer en non-prod avant d’en avoir besoin en prod. Ne couvre que la state du cluster, pas les workloads.
Quoi — backup applicatif au niveau Kubernetes (manifests, PVCs, snapshots CSI). Le standard de facto pour la sauvegarde Kubernetes.
Quand — à déployer dès le démarrage de la production. Schedule régulier sur les namespaces qui portent des workloads stateful. Stockage vers S3 (object storage on-premise ou cloud).
Restore — granulaire (par namespace, par resource), avec ou sans PVCs. C’est la primitive à connaître pour migrer des workloads entre clusters ou récupérer après une suppression accidentelle.
Quoi — snapshot des VMs des nodes au niveau hyperviseur, via vSphere ou un outil tiers (Veeam, Rubrik, etc.).
Quand — utile pour les VMs Supervisor et les nodes du control plane. À éviter pour les workers — restaurer un worker n’a pas de sens, CAPI le remplace plus proprement.
Restore — VM-level, pas resource-level. Insuffisant en isolation pour un cluster Kubernetes — à combiner avec etcd snapshots et Velero.
Recommandation assumée. Velero pour les workloads applicatifs, etcd snapshots automatiques pour la state du cluster, snapshots vSphere pour les VMs Supervisor. Les trois sont complémentaires, aucun ne remplace les autres.
Observabilité : le stack standard
L’écosystème CNCF est utilisable tel quel sur VKS, avec des intégrations vers VCF Operations pour corréler infra et workloads.
┌─ Workloads (pods) ─────────────────────────┐
│ ↓ metrics │
│ ↓ logs │
│ ↓ traces (optionnel) │
├────────────────────────────────────────────┤
│ Prometheus (metrics scrape) │
│ Loki (logs ingestion) │
│ OpenTelemetry Collector (traces) │
├────────────────────────────────────────────┤
│ Grafana (dashboards) │
│ Alertmanager (alerting) │
├────────────────────────────────────────────┤
│ forward → VCF Operations for Logs │
│ forward → VCF Operations for Apps │
└────────────────────────────────────────────┘Métriques. Prometheus Operator déployé via Helm. ServiceMonitor pour les workloads, PodMonitor pour les pods sans Service. La rétention par défaut (15 jours) est insuffisante pour des analyses post-mortem au-delà du sprint — passer à 30-90 jours, et offload les données froides vers Thanos ou Mimir.
Logs. Loki avec Promtail comme collecteur node-level. Architecture simple à opérer, mais penser au sizing des chunks (la valeur par défaut est trop conservatrice pour des clusters avec beaucoup de pods éphémères). Forward des logs critiques vers VCF Operations for Logs pour la corrélation avec les événements vSphere.
Dashboards Grafana. Les dashboards par défaut Kubernetes (kubernetes-mixin) couvrent l’essentiel. Customiser pour les SLI applicatifs, pas pour les métriques infra — ces dernières sont mieux servies par les dashboards VCF Operations.
Alerting. Alertmanager pour les alertes pod-level. Pour les alertes infra (host failure, datastore plein), VCF Operations est mieux placé. Éviter de doubler les sources d’alerte — règle d’or : une alerte, une source.
VCF Operations for Apps : la couche manquante
VCF Operations for Apps (anciennement Aria Operations for Applications, et Wavefront avant) est le composant qui fait le pont entre les métriques Kubernetes et les métriques vSphere. Pour des organisations qui ont déjà investi dans la stack VCF Operations, c’est la couche qui justifie l’écosystème — elle évite de maintenir deux systèmes d’observabilité parallèles.
Capacity management
Le cluster grandit. Le cluster doit aussi être contraint.
Quotas namespace vSphere. CPU, mémoire, storage, nombre de clusters par namespace. Calibrer selon les profils d’équipe : un namespace équipe data ≠ un namespace équipe web. Les quotas sont l’outil de gouvernance le plus efficace contre les dérives de coût — et ils sont gratuits.
ResourceQuota et LimitRange dans le cluster. À l’intérieur d’un cluster, ResourceQuota et LimitRange contrôlent la consommation par namespace Kubernetes. Indispensables sur les clusters multi-tenant.
Capacity planning. Sur la base des métriques Prometheus, modéliser la croissance attendue (nb pods, nb namespaces, RPS) et anticiper l’ajout de capacity. Une fois par trimestre suffit pour la plupart des plateformes — sauf pendant les phases de growth applicative où ça doit être mensuel.
Gotchas et pièges courants
PDB trop strictes = upgrades qui ne finissent pas
Content Library désynchronisée = upgrades silencieux qui échouent
etcd full disk = control plane HS
Loki cardinality explosion
Prometheus storage qui sature pendant l'upgrade
Velero PVC restore : namespaces qui doivent préexister
Upgrades sur cluster avec workloads stateful
Conclusion et suite
Ce qu’il faut retenir. Les opérations day-2 sur VKS sont structurées par CAPI : tout passe par le manifest, jamais par la modification directe. Les upgrades Kubernetes sont découplés du Supervisor mais respectent la matrice upstream — pas de skip de mineure. Velero est non-négociable pour les workloads applicatifs. Le stack observabilité standard fonctionne bien et s’intègre avec VCF Operations. Les gotchas sont rarement dans les composants individuels, plus souvent dans leurs interactions (PDB + upgrade, cardinalité + Loki, etcd + Custom Resources).
Prochaine étape. Le dernier article de cette série traite de GitOps sur VKS : comment automatiser le déploiement applicatif avec Argo CD, gérer les secrets via External Secrets Operator, et étendre le pattern à du multi-cluster. C’est l’étape qui transforme un cluster opéré en plateforme self-service.
Ressources.
Pour aller plus loin :
- Broadcom TechDocs — Managing VKS Clusters — référence opérationnelle
- Cluster API Book — la doc upstream CAPI, lecture indispensable
- Velero Documentation — backup/restore Kubernetes
- Prometheus Operator — déploiement et configuration
- Loki Documentation — guides d’opération
- VCF Operations — intégration observabilité plateforme
Reçois le prochain par email
Les nouveaux articles et séries, envoyés à leur publication. Aucun autre courrier.
