Expérience plateforme
Expérience de conception, intégration et exploitation de plateformes Kubernetes sur Nutanix, avec NKP, NDB, Nutanix Objects, réseau, stockage, automatisation et industrialisation des déploiements.
Cette expérience terrain couvre le cycle de vie d’une plateforme on-premise multi-cluster : architecture, installation, réseau, clusters, GitOps, stockage, upgrades, bases de données, object storage et suivi opérationnel des dépendances.
L’expérience couvre la création et le cycle de vie de clusters NKP sur AHV, du management cluster aux workload clusters. Le travail ne s’arrête pas au déploiement Kubernetes : il inclut les dépendances réseau, stockage, registries, addons, RBAC et GitOps.
Créer des clusters de management et de workload sur AHV, intégrer Cluster API et CAPX, préparer Prism Central et Prism Element, puis automatiser les paramètres nécessaires aux control planes, workers, pools, namespaces, RBAC et addons.
Préparer et valider des évolutions NKP, Kommander et Kubernetes en tenant compte des compatibilités entre NKP, Kubernetes, Prism Central, AOS, CAPI et CAPX. Les transitions NKP 2.16, 2.17 et 2.18, ainsi que Kubernetes 1.35 FIPS dans l’environnement concerné, font partie de la chronologie de cette expérience.
Traiter les VIP de control plane, les plages LoadBalancer, MetalLB, ingress, DNS, NTP, IPAM, DHCP, VLAN et flux firewall avant de considérer un cluster comme réellement exploitable.
Configurer et fiabiliser Nutanix CSI, StorageClasses, PVC et volumes persistants. Une configuration présente dans Kubernetes doit être suivie jusqu’à l’exécution réelle des contrôleurs CSI et de leurs plugins.
Intégrer Harbor, des registry mirrors et des pull secrets, tout en traitant les certificats, les proxies et les dépendances Docker Hub ou GitHub dans des environnements initialement contraints.
Le suivi de Cluster API demande de comprendre la réconciliation au-delà des commandes NKP. La validation porte sur le provisioning des VM, l’attribution des NodeRef, les MachineDeployments, les rolling upgrades, les custom attributes et les échanges avec le provider Nutanix, à travers les contrôleurs, les logs CAPI et la compatibilité CAPX, Prism Central et AOS.
Une partie importante de l’expérience porte sur l’exploration d’un modèle DBaaS on-premise avec Nutanix Database Service. L’objectif est de dissocier le cycle de vie des bases de données de celui des applications qui les consomment.
L’intégration avec Kubernetes et le NDB Operator ouvrent un modèle déclaratif et compatible GitOps : les applications consomment une base gérée par NDB, tandis que le lifecycle de la base reste séparé de celui du cluster.
Déployer un Object Store ne consiste pas uniquement à activer une API S3. Il faut traiter les réseaux Storage et Public, l’IPAM, le DHCP, les IP statiques, le DNS, le NTP, le firewall, les certificats, l’IAM, le load balancing, les flux Internet et la réplication.
Nutanix Objects et Ceph/RGW ne désignent pas la même technologie. Objects correspond au stockage objet Nutanix ; Ceph/RGW intervient dans d’autres contextes de plateforme et doit être analysé séparément.
Le réseau représente une part majeure du travail. La disponibilité des clusters dépend d’une allocation d’IP maîtrisée, d’une segmentation lisible et de flux cohérents entre DHCP, IPAM, DNS, routage et firewall.
Le but de l’automatisation est de réduire les opérations manuelles et de rendre la création des clusters reproductible. Les dépôts Git, Flux, les manifests déclaratifs, Terraform et les scripts Bash ou PowerShell structurent cette approche.
Sur une plateforme Kubernetes on-premise, la fiabilité repose sur une lecture complète des dépendances. Une application s’appuie sur Kubernetes, Cluster API, le provider Nutanix, Prism, AHV, le réseau et le stockage. Les vérifications suivent cette chaîne de bout en bout.
L’exploitation inclut aussi la vérification des addons et des signaux utiles : Prometheus, Grafana, alerting, composants Kommander, OpenCost, insights, Velero et contrôles post-upgrade. L’objectif n’est pas d’empiler des outils, mais de savoir quelles informations sont nécessaires pour maintenir une plateforme lisible.
Les différentes couches sont suivies ensemble pour garder une mise en service lisible et une évolution maîtrisée.
Mise en place NKP, conventions de clusters, Harbor, CSI, GitOps et premiers déploiements applicatifs.
NDB, PostgreSQL, Software Profiles, flux réseau, DBaaS et documentation de la création de clusters.
IPAM, DHCP, MetalLB, Nutanix Objects, réseaux Storage et Public, flux Internet et stockage.
Sortie progressive de l’air-gap, upgrades NKP, Kommander, CSI, addons, Ceph, RGW, COSI, Velero, CAPI et CAPX.
Stabilisation avancée, Objects, registries, IAM, S3, industrialisation du provisioning et préparation de migrations.
Cette expérience me permet de concevoir une application en tenant compte dès le départ de son déploiement, de ses données, de son stockage, de sa supervision, de ses mises à jour et de son exploitation.
Parler d’une opportunité ↗