Le projet

Améliorations

Au-delà de l'iso-fonctionnel : outillage, sécurité et confort.

Go : le langage du Cloud Native

Langage du Cloud Native

Kubernetes, etcd, containerd, Helm, Prometheus, KubeVirt : le même langage que la plateforme

Écosystème intégré

client-go, SDK Helm, OVSDB, Prometheus, OIDC : des bibliothèques natives, sans pont

Typé et compilé

Typage fort, erreurs détectées à la compilation, code plus rapide que Python

Build rapide

Un binaire statique par service, compilation rapide, multi-architecture

Conteneurs minimaux

Un exécutable, rootless, sans shell ni sources, sur distroless et non sur Ubuntu

Sobre à l'exécution

Pas d'interpréteur ni d'eventlet (démarrage et mémoire non mesurés dans l'espace de travail)

Outillage : scripter, déployer, piloter

Trois outils qu'OpenStack n'offre pas sous cette forme, écrits en Go comme les services et livrés avec chaque version d'OpenKeel.

Le CLI OpenStack, en Go

ok est la commande openstack réécrite en Go : un binaire statique unique, sans Python, virtualenv ni plugins à installer.

Les 1 325 commandes de python-openstackclient 10.3.1 et de ses plugins, chacune vérifiée face au CLI Python par rejeu différentiel
Mêmes arguments, formats de sortie, messages d'erreur et codes de retour : les scripts existants continuent de fonctionner
Lit clouds.yaml, OS_* et --os-* comme l'original ; binaires Linux, macOS et Windows, et une image distroless

export OS_CLOUD=openkeel
ok server list -f json

okadm

Déploiement Plug and Play, en lab ou en production

okadm installe OpenKeel sur un cluster Kubernetes avec une commande par étape du cycle de vie, en mode lab ou production.

Lab : sans cluster, il crée un cluster kind, installe les opérateurs de lab et une réplique de chaque service ; --ingress ajoute le point d'entrée public
Production : okadm plan vérifie les prérequis (version, rôles des nœuds, opérateurs, StorageClass, domaine) et indique le correctif de chacun ; trois répliques
Installation idempotente qui reprend là où elle s'est arrêtée, mise à jour composant par composant, état, désinstallation ; client-go et le SDK Helm intégrés

okadm plan --mode production
okadm install --mode lab \
  --create-kind --ingress --demo

Configurator

Piloter le déploiement graphiquement

Le Configurator est une console web, installée par défaut par okadm, pour préparer le déploiement des modules OpenKeel et en assurer le suivi visuel.

Rôles des nœuds (plan de contrôle, calcul, réseau, stockage, conteneurs, provisionnement) et placement de chaque composant, par glisser-déposer dans une vue topologique par zone de disponibilité
Paramètres de chaque service : activation, répliques, autoscaling, ressources, YAML libre ; contrôles du quorum, de l'anti-affinité et des minimums par rôle
Suivi visuel : la répartition des composants sur les nœuds, l'état des pods (prêts, redémarrages) et les journaux de chaque service, fusionnés et filtrables par recherche
Produit les valeurs de okadm install -f et les labels des nœuds, ou pose lui-même les labels

Voir la démonstration

Moins de code, autant de garanties

1,008 klignes Python des 19 modules d'origine
310 klignes Go des modules OpenKeel
−69%de code, tests exclus

Module	Python	Go	Écart
Placement	10,287	10,256	0%
Nova	150,846	20,534	−86%
Zun	30,938	13,947	−55%
Masakari	10,835	9,347	−14%
Cinder	255,934	17,400	−93%
Glance	31,279	14,372	−54%
Manila	135,162	18,285	−86%
Neutron	127,623	25,947	−80%
Octavia (OVN)	5,778	9,042	+56%
Neutron-FWaaS	8,085	9,643	+19%
Neutron-VPNaaS	6,449	11,190	+74%
OVN-BGP-Agent	8,448	5,074	−40%
Keystone	50,584	21,015	−58%
Barbican	18,688	12,851	−31%
Designate	23,671	15,367	−35%
CloudKitty	15,020	12,042	−20%
API EC2	11,570	16,272	+41%
Skyline	18,723	8,590	−54%
ok (CLI)	88,122	59,156	−33%
Total	1,008,042	310,330	−69%

Lignes non vides hors commentaires, tests exclus, comptées à la génération du site. Côté Python, seul le paquet du service est compté : oslo, neutron-lib, keystonemiddleware et os-brick ne le sont pas, alors que leurs équivalents sont dans chaque module Go. Les pilotes et agents remplacés par Kubernetes disparaissent ; les petits modules autrefois greffés sur Neutron ou Nova grossissent, car ils deviennent autonomes.

Configuration : d'oslo.config au YAML

	OpenStack (Python)	OpenKeel (Go)
Fichiers	INI oslo.config, plus api-paste.ini, rootwrap.conf et ses filtres, logging.conf, policy	Un config.yaml par processus, monté depuis une ConfigMap
Secrets	Mots de passe dans connection et transport_url	Champs *_file lus dans des Secrets montés, jamais dans le YAML
Processus	bind_host, workers, log_file, use_syslog, debug	Pris en charge par Kubernetes ; un seul default.log_level
Pilotes	Options de tous les pilotes livrés (libvirt, VMware, baies, ML2…)	Seules les options des briques retenues (KubeVirt, CSI, OVN)
Contrôle	Vérification à part, avec l'outil oslo-config-validator	Décodage strict : clé inconnue ou valeur hors bornes, et le processus refuse de démarrer
Écart	Édition des fichiers sur chaque hôte, redémarrage	Nouveau hash de ConfigMap, rolling restart ; niveau de log par SIGHUP

Mêmes noms : groupes, options et valeurs par défaut de l'original ; OPENKEEL_<GROUP>_<OPTION> surcharge une valeur propre à un pod.

Moins d'options : ne garder que l'utile

Module	Gardées	Retirées
Placement	7	101
Nova	122	1,015
Zun	63	300
Masakari	35	235
Cinder	49	1,411
Glance	66	472
Manila	82	905
Neutron	82	443
Keystone	100	313
Barbican	72	200
Designate	84	300
CloudKitty	50	271
API EC2	16	151

828options gardées sur 6,945, dans 13 modules
88%des options oslo retirées

Comptes lus dans config/dropped-options.md de chaque module ; chaque option retirée y figure avec sa raison. Retirées : dépréciées, pilotes non livrés, eventlet et verrous fichiers, options du processus reprises par Kubernetes. Gardées : tout ce qui change l'API, les données ou les limites (quotas, ratios d'allocation, durée des jetons, enforce_scope).

Sécurité et confort d'usage

Skyline-OIDC

Connexion à la console par un fournisseur d'identité OIDC : fédération, SSO, jetons validés par JWKS.

Secrets internes rotatifs

Mots de passe de base, comptes RabbitMQ et clés de service gérés comme des composants rotatifs, renouvelables sans intervention manuelle.

Credentials EC2 dans Skyline

Création et gestion des identifiants EC2 (access / secret) depuis la console, pour accéder au stockage S3.