Control plane managé sur 3 DC, node groups GPU, addons console.

Deux programmes CNCF distincts, tous deux déjà publiés sur le landscape. Hikube Managed Kubernetes est Certified Kubernetes Hosted : le cluster que vous utilisez est du Kubernetes conforme CNCF, pas un fork maison. Hidora SA est Kubernetes Certified Service Provider (KCSP) : l’opérateur qui tient le control plane est un prestataire certifié. Les deux inscriptions se vérifient sur le landscape CNCF, ce ne sont pas des badges auto-déclarés. Les clusters tournent sur Talos. Ce n’est pas une certification CNCF AI Conformance : nous ne la revendiquons pas.

Talos Linux n’existe que pour faire tourner Kubernetes. Une Ubuntu ou un Rocky avec kubelet garde SSH, un gestionnaire de paquets et un OS à patcher comme un serveur classique : les nœuds dérivent, la surface d’attaque s’élargit. Talos est immuable. Pas de SSH ni de shell d’admin sur le nœud. La config passe par API. Moins de drift, des upgrades d’image plutôt qu’apt. kubectl et Helm ne changent pas : le cluster reste du Kubernetes standard, certifié CNCF. C’est déjà le socle des clusters Hikube, pas une option.

Oui. Hidora SA opère le control plane avec des réplicas sur Genève, Gland et Lucerne. etcd suit les trois sites : vous n’installez pas les API servers, vous ne surveillez pas le quorum, vous ne déclenchez pas le failover. Le control plane managé est publié à 32 CHF/mois. Un control plane qui survit à la perte d’un site ne suffit pas à lui seul pour l’application : Hikube répartit les workers ; topology spread et PDB pour les pods restent de votre côté. Le guide la procédure sur trois datacenters et l’article l’architecture haute disponibilité détaillent le quorum ; RPO et crédit SLA ne sont pas publiés.

Oui. Les workers tournent dans votre tenant, en node groups. Hikube les répartit automatiquement sur Genève, Gland et Lucerne : vous ne choisissez pas le DC. Kubernetes ne répartit pas les pods tout seul : un Deployment à trois réplicas peut coller les trois dans le même DC. Topology spread et PodDisruptionBudget restent les vôtres. Sans ces contraintes, un cluster bien opéré côté Hikube n’affichera pas la classe HA publiée côté application. C’est le partage classique d’un Kubernetes managé, dit clairement.

Vous créez plusieurs node groups dans le cluster : CPU pour le socle, GPU pour l’inférence ou l’entraînement. L’autoscaling des workers suit la charge. Les node groups GPU utilisent le catalogue NVIDIA publié : L4, L40S, A100-80, RTX 6000 Pro, H100, H200. Ils sont dans l’essai de 14 jours. Le GPU Operator (addon optionnel) installe pilotes et device plugin. HAMi, aussi optionnel, partage une carte entre plusieurs pods et exige le GPU Operator. Détail cartes : le catalogue GPU.

Toujours dans le cluster, vous ne les cochez pas : Cilium (CNI eBPF, réseau et sécurité), CoreDNS (DNS du cluster), Vertical Pod Autoscaler (ajuste les ressources des pods). Optionnels, CLUSTER ADDONS dans la console : Cert-Manager (certificats SSL/TLS automatiques), Ingress NGINX (contrôleur Ingress NGINX), Gateway API (CRDs Kubernetes Gateway API, canal expérimental, nous le disons tel quel), GPU Operator (gestion NVIDIA des GPU), HAMi (virtualisation GPU, partager une carte entre pods, exige GPU Operator), Flux CD (GitOps), Monitoring Agents (logs et métriques), Ouroboros (corrige le hairpin NAT pour ingress-nginx avec PROXY protocol, exige Ingress NGINX), Velero (sauvegarde et restauration Kubernetes). Les administrateurs cluster peuvent surcharger les valeurs Helm de ces addons optionnels dans la console. C’est le levier technique pour l’équipe platform, addon par addon.

Hidora SA opère le control plane, l’OS Talos des nœuds, Cilium, CoreDNS, le VPA, les trois DC et le support ingénieur FR/EN. Vous gardez kubectl, Helm, les workloads, GitOps, le dimensionnement des node groups, topology spread, PDB, et la config des addons optionnels (y compris les overrides Helm dans la console). Registry, VPC et Vault restent dans le même tenant si vous les utilisez. Intégration Terraform et Cluster API en préparation : aujourd’hui l’API Hikube et la console créent le cluster. Ce n’est pas un PaaS qui masque Kubernetes, ni un cluster que vous devez installer à la main.

Équipes platform qui veulent un Kubernetes certifié, pas un PaaS opaque. GitOps (Flux dans la console, ou Argo que vous installez). Inférence et entraînement GPU en Suisse, sur des node groups dédiés. Charges métier déjà conteneurisées qui doivent rester sous droit suisse (nLPD). Sortie d’une région hyperscaler Europe dont la maison-mère reste américaine. Ce n’est pas le premier pas d’un exit VMware encore en VMs : ce parcours est la sortie de VMware.

Monitoring Agents (addon optionnel) collectent logs et métriques dans le cluster. Une pile déployable dans le tenant (Grafana, VictoriaMetrics, VictoriaLogs) : vos métriques ne partent pas par défaut vers un SaaS US. Le détail des charts est dans la doc.

Oui. Conservez Helm, Flux ou Argo. Flux CD est un addon optionnel dans la console. L’API Hikube et la console gèrent le cluster (node groups, addons, kubeconfig) ; Git gère les workloads. Intégration Terraform et Cluster API en préparation : ce n’est pas disponible aujourd’hui. kubectl reste.