Kubernetes privé sur OpenNebula : le guide OneKE pour déployer K8s souverain

Kubernetes est devenu le standard de facto pour le déploiement d’applications. Mais déployer un cluster K8s en production — surtout dans un environnement réglementé — est un défi qui va bien au-delà du kubectl apply. La gestion des certificats, la sécurité réseau, la haute disponibilité du control plane, les sauvegardes et la conformité transforment chaque cluster en un projet à part entière.

OneKE (OpenNebula Kubernetes Engine) résout ce problème : un orchestrateur Kubernetes managé qui déploie des clusters prêts pour la production sur votre cloud privé OpenNebula. Pas de EKS, pas de GKE, pas de dépendance cloud public. Votre infrastructure, votre souveraineté, vos clusters.

Ce guide vous explique pourquoi et comment déployer Kubernetes privé avec OneKE.

---

Le problème du K8s managé public

Le piège du managed K8s

EKS (AWS), GKE (Google) et AKS (Azure) simplifient la vie du DSI — jusqu’à ce qu’ils ne le fassent plus :

Problème	Impact
Vendor lock-in	Migrer hors d’EKS coûte 3-5x le coût de la migration initiale
Egress fees	Chaque Go sortant du cluster coûte 0,09 € — les microservices multi-cloud sont hors de prix
Souveraineté	Le Cloud Act américain permet l’accès aux données hébergées par ces fournisseurs
Coût imprévisible	La facturation à l’usage ne peut pas être budgétisée dans un marché public
Contrôle limité	Le control plane est géré par le fournisseur — vous ne contrôlez pas la version, les patches, les certificats

Pour une organisation réglementée (banque, santé, secteur public), ces problèmes sont rédhibitoires.

La difficulté du K8s « maison »

L’alternative — déployer Kubernetes soi-même avec kubeadm ou kops — résout le problème de souveraineté mais ajoute une charge opérationnelle massive :

• Gestion du control plane et de l’etcd
• Rotation des certificats (tous les 365 jours par défaut)
• Mise à jour des versions (tous les 3-4 mois pour les patches)
• Configuration réseau (CNI, policies, service mesh)
• Sécurité (RBAC, network policies, admission controllers)
• Sauvegarde et restauration d’etcd

OneKE est le juste milieu : la simplicité d’un K8s managé avec la souveraineté d’une infrastructure privée.

---

OneKE : Kubernetes managé, souverain

Ce qu’OneKE apporte

OneKE est l’orchestrateur Kubernetes intégré à OpenNebula. Il déploie et gère des clusters K8s complets sur votre cloud privé :

• Déploiement en 1 commande : un cluster K8s complet en 15 minutes
• Control plane managé : haute disponibilité, mises à jour, certificats automatiques
• Multi-cluster : gérer plusieurs clusters depuis une seule interface
• Sécurité intégrée : RBAC, network policies, chiffrement etcd
• Souveraineté : tout tourne sur votre infrastructure, pas de dépendance cloud public

Architecture d’un cluster OneKE

┌──────────────────────────────────────────────────────┐
│                 OPENNEBULA (Cloud privé)             │
│                                                      │
│  ┌────────────────────────────────────────────────┐  │
│  │              ONEKE (Orchestrateur)                │  │
│  │  • Provisionnement VM                           │  │
│  │  • Installation K8s                               │  │
│  │  • Configuration réseau (Cilium CNI)             │  │
│  │  • Rotation certificats                          │  │
│  │  • Mises à jour rolling                          │  │
│  └──────────────────┬─────────────────────────────┘  │
│                     │                                 │
│  ┌──────────────────▼─────────────────────────────┐  │
│  │             CLUSTER KUBERNETES                   │  │
│  │  ┌────────┐  ┌────────┐  ┌────────┐           │  │
│  │  │Control │  │Control │  │Control │  HA        │  │
│  │  │Plane 1 │  │Plane 2 │  │Plane 3 │           │  │
│  │  └────────┘  └────────┘  └────────┘           │  │
│  │                                                 │  │
│  │  ┌────────┐  ┌────────┐  ┌────────┐           │  │
│  │  │Worker 1│  │Worker 2│  │Worker 3│  Autoscale │  │
│  │  └────────┘  └────────┘  └────────┘           │  │
│  └─────────────────────────────────────────────────┘  │
│                                                      │
│  ┌──────────────────────────────────────────────────┐ │
│  │              SERVICES INTÉGRÉS                    │ │
│  │  • Traefik (Ingress)     • Prometheus (Metrics)   │ │
│  │  • MetalLB (LoadBalancer) • Grafana (Dashboards) │ │
│  │  • Cilium (CNI/Policies) • Vault (Secrets)       │ │
│  └──────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────┘

---

Comparaison : OneKE vs EKS vs K8s maison

Critère	EKS (AWS)	K8s maison (kubeadm)	OneKE (OpenNebula)
Souveraineté	❌ Cloud Act	✅ Complète	✅ Complète
Simplicité	✅ Managé	❌ Complexe	✅ Managé
Egress	0,09 €/Go	0 €	0 €
Control plane	Managé par AWS	À gérer soi-même	Managé par OneKE
Lock-in	Élevé	Nul	Nul
Coût (20 nœuds)	~2 500 €/mois	~800 €/mois + ops	~800 €/mois
Conformité	⚠️ Limitée	✅ Totale	✅ Totale
Patch	Automatique	Manuel	Automatique
Régionalité	⚠️ Data centers US	✅ Vous choisissez	✅ Vous choisissez
SLA control plane	99,95 %	Ce que vous construisez	99,95 % (3 nœuds)

Le choix est clair : OneKE offre la simplicité d’un K8s managé avec la souveraineté d’une infrastructure privée — sans les coûts imprévisibles et le lock-in du cloud public.

---

Sécurité et conformité : K8s conforme NIS2

Les 8 exigences NIS2 que K8s doit satisfaire

Exigence NIS2	Réponse OneKE
Gestion des risques	Infrastructure as Code (Terraform), audit trail Git
Signalisation des incidents	Prometheus Alertmanager, notifications < 24h
Continuité d’activité	HA control plane (3 nœuds), etcd sauvegardé
Chaîne d’approvisionnement	Images conteneur signées, registry privé
Sécurité du réseau	CiliumNetworkPolicy, mTLS, micro-segmentation
Gestion des vulnérabilités	Scan automatique des images, patches rolling
Chiffrement	etcd chiffré, Vault pour les secrets, TLS 1.3
Gouvernance	RBAC granulaire, audit logging, policies as code

DORA : résilience des systèmes financiers

Pour les établissements financiers qui déployent des applications K8s :

• Tests de résilience : chaos engineering sur les pods (pod disruption budgets, node drains)
• Gestion des incidents : audit trail intégré, métriques de disponibilité en temps réel
• Continuité : multi-cluster avec failover automatique
• Tiers : pas de dépendance à un cloud public — l’infrastructure est sous votre contrôle

---

Déploiement OneKE : le guide pas à pas

Prérequis

• OpenNebula installé et fonctionnel
• 3 nœuds minimum pour le control plane (HA)
• 2 nœuds worker minimum
• 4 Go RAM / 2 vCPU par nœud control plane
• 8 Go RAM / 4 vCPU par nœud worker

Étape 1 : Provisionner les nœuds (15 min)

# Via OpenNebula Sunstone ou CLI
onevm create oneke-control-plane --count 3
onevm create oneke-worker --count 3

OneKE provisionne les VM avec l’image de base optimisée (Ubuntu 22.04 LTS durcie).

Étape 2 : Créer le cluster (15 min)

# Depuis OpenNebula Sunstone : OneKE > Create Cluster
# Ou viaCLI :
oneke cluster create production \
  --control-plane 3 \
  --worker 3 \
  --cni cilium \
  --version 1.30

OneKE installe :

• Kubernetes (version sélectionnée)
• Cilium (CNI avec NetworkPolicy)
• Traefik (Ingress controller)
• MetalLB (LoadBalancer pour les services)
• cert-manager (certificats automatiques via Vault)

Étape 3 : Configurer la sécurité (30 min)

# Network Policy par défaut : deny all
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Puis ouvrir uniquement les flux nécessaires :

# Autoriser le trafic entre pods du même namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: same-namespace
  namespace: production
spec:
  podSelector: {}
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: production
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              name: production

Étape 4 : Déployer les applications (variable)

# Récupérer le kubeconfig
oneke cluster kubeconfig production > ~/.kube/config

# Déployer une application
kubectl create namespace mon-app
kubectl apply -f mon-app/ -n mon-app

Étape 5 : Superviser (automatique)

OneKE déploie automatiquement Prometheus + Grafana. Accédez aux dashboards via OpenNebula Sunstone :

• Cluster health : nœuds, pods, ressources
• Application metrics : latence, erreurs, débit
• Security : network policies, RBAC, certificats

---

Les 5 erreurs à éviter avec Kubernetes privé

Erreur 1 : Déployer K8s sans Network Policies

Le réseau Kubernetes est plat par défaut — tous les pods peuvent communiquer avec tous les pods. C’est le vecteur d’attaque n°1.

Solution : OneKE déploie Cilium avec des Network Policies par défaut (deny all, puis open sélectivement).

Erreur 2 : Gérer les certificats manuellement

Les certificats K8s expirent. Quand le control plane tombe à minuit un dimanche, c’est un certificat expiré.

Solution : OneKE gère la rotation automatique des certificats via cert-manager + Vault.

Erreur 3 : Un seul nœud control plane

Un control plane à nœud unique est un point de défaillance unique. Etcd sans réplique, c’est un cluster qui meurt avec son nœud.

Solution : OneKE déploie 3 nœuds control plane par défaut. etcd est répliqué, le cluster survit à la perte d’un nœud.

Erreur 4 : Pas de sauvegarde etcd

etcd est le cœur de K8s. Si etcd perd ses données, le cluster perd tout — pods, services, configurations.

Solution : OneKE configure les sauvegardes etcd automatiques (snapshot toutes les heures, rétention 7 jours).

Erreur 5 : Négliger l’observabilité

Un cluster K8s sans supervision, c’est un cluster dont vous ne savez pas s’il fonctionne.

Solution : OneKE intègre Prometheus + Grafana avec des dashboards prêts à l’emploi. Les alertes NIS2 sont préconfigurées.

---

TCO : OneKE vs EKS vs K8s maison

Pour un cluster de 6 nœuds (3 control plane + 3 workers) en production :

Poste	EKS (AWS)	K8s maison	OneKE
Infrastructure (mois)	2 500 €	800 €	800 €
Egress (mois)	200 €	0 €	0 €
Ops K8s (mois)	0 €	4 000 €	0 €
Support (mois)	300 €	0 €	500 €
Total mensuel	3 000 €	4 800 €	1 300 €
Total annuel	36 000 €	57 600 €	15 600 €

Économie OneKE vs EKS : -57 %
Économie OneKE vs maison : -73 %

Et ce calcul ne compte pas l’egress réel (les microservices génèrent beaucoup de trafic inter-services), ni le coût de l’indisponibilité quand le cluster maison tombe un dimanche.

---

Cas d’usage : les 3 scénarios gagnants

1. Microservices en production

Vous avez 20-50 microservices qui tournaient en VM. La conteneurisation avec K8s réduit les coûts d’infrastructure de 30-50 % et accélère les déploiements.

Avec OneKE : cluster K8s managé sur votre cloud privé, CI/CD GitLab intégré, observabilité native.

2. Migration VMware → K8s

Vous quittez VMware ( Broadcom tax). Plutôt que de recréer les mêmes VM sur OpenNebula, vous conteneurisez et déployez sur OneKE.

Avec OneKE : transition progressive (VM + K8s cohabitent sur le même OpenNebula), migration au rythme de vos équipes.

3. Conformité réglementaire

Vous êtes une banque ou un établissement de santé qui doit héberger ses applications K8s conformément à DORA, NIS2 ou HDS.

Avec OneKE : cluster K8s souverain, conforme, audit trail continu, pas de dépendance cloud public.

---

Conclusion

Kubernetes privé n’a pas à être un cauchemar opérationnel. OneKE apporte la simplicité d’un K8s managé public avec la souveraineté d’une infrastructure privée — sans egress fees, sans lock-in, et en conformité avec NIS2 et DORA.

Pour les DSI qui veulent déployer K8s sans sacrifier la souveraineté ni ajouter une charge opérationnelle insoutenable, OneKE est le bon choix : déployé en 30 minutes, managé en continu, conforme par design.

Cloud Inspire déploie des clusters OneKE sur votre cloud privé OpenNebula en 10 jours, avec ou sans migration d’applications. Si vous voulez K8s sans le cauchemar, parlons-en.