Il progetto

Miglioramenti

Oltre l'isofunzionalità: strumenti, sicurezza e facilità d'uso.

Go: il linguaggio Cloud Native

Il linguaggio Cloud Native

Kubernetes, etcd, containerd, Helm, Prometheus, KubeVirt: lo stesso linguaggio della piattaforma

Ecosistema integrato

client-go, SDK Helm, OVSDB, Prometheus, OIDC: librerie native, nessun bridge

Tipizzato e compilato

Tipizzazione forte, errori rilevati in compilazione, codice più veloce di Python

Build rapide

Un binario statico per servizio, compilazione rapida, multiarchitettura

Container minimali

Un eseguibile, rootless, senza shell né sorgenti, su distroless anziché Ubuntu

Leggero in esecuzione

Nessun interprete e nessun eventlet (tempo di avvio e memoria non misurati nel workspace)

Strumenti: automatizzare, distribuire, pilotare

Tre strumenti che OpenStack non offre in questa forma, scritti in Go come i servizi e forniti con ogni versione di OpenKeel.

La CLI di OpenStack, in Go

ok è il comando openstack riscritto in Go: un unico binario statico, senza Python, virtualenv né plugin da installare.

Tutti i 1.325 comandi di python-openstackclient 10.3.1 e dei suoi plugin, ognuno verificato rispetto alla CLI Python con replay differenziale
Stessi argomenti, formati di output, messaggi di errore e codici di uscita: gli script esistenti continuano a funzionare
Legge clouds.yaml, OS_* e --os-* come l'originale; binari per Linux, macOS e Windows, e un'immagine distroless

export OS_CLOUD=openkeel
ok server list -f json

Per saperne di più

okadm

Deployment plug and play, in lab o in produzione

okadm installa OpenKeel su un cluster Kubernetes con un comando per ogni fase del ciclo di vita, in modalità lab o produzione.

Lab: senza cluster, crea un cluster kind, installa gli operatori di lab e una replica di ogni servizio; --ingress aggiunge il punto di accesso pubblico
Produzione: okadm plan verifica i prerequisiti (versione, ruoli dei nodi, operatori, StorageClass, dominio) e indica la correzione per ciascuno; tre repliche
Installazione idempotente che riprende da dove si era fermata, aggiornamento componente per componente, stato, disinstallazione; client-go e l'SDK di Helm integrati

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

Per saperne di più

Configurator

Pilotare il deployment graficamente

Il Configurator è una console web, installata di default da okadm, per preparare il deployment dei moduli OpenKeel e seguirlo visivamente.

Ruoli dei nodi (control plane, calcolo, rete, storage, container, provisioning) e posizionamento di ogni componente, con trascinamento in una vista topologica per zona di disponibilità
Parametri di ogni servizio: abilitato, repliche, autoscaling, risorse, YAML libero; controlli di quorum, anti-affinità e minimi per ruolo
Monitoraggio visivo: la distribuzione dei componenti sui nodi, lo stato dei pod (pronti, riavvii) e i log di ogni servizio, uniti e ricercabili
Produce i valori di okadm install -f e le etichette dei nodi, oppure etichetta i nodi da sé

Guarda il tour

Meno codice, le stesse garanzie

1,008 kRighe Python negli 19 moduli originali
310 kRighe Go nei moduli OpenKeel
−69%codice, test esclusi

Modulo	Python	Go	Modifica
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%

Righe non vuote e non di commento, test esclusi, contate alla generazione del sito. Sul lato Python viene contato solo il pacchetto del servizio: oslo, neutron-lib, keystonemiddleware e os-brick no, mentre i loro equivalenti risiedono in ciascun modulo Go. I driver e gli agenti sostituiti da Kubernetes scompaiono; i piccoli moduli un tempo innestati su Neutron o Nova crescono, perché diventano servizi autonomi.

Configurazione: da oslo.config a YAML

	OpenStack (Python)	OpenKeel (Go)
File	INI oslo.config, più api-paste.ini, rootwrap.conf e i suoi filtri, logging.conf, policy	Un config.yaml per processo, montato da una ConfigMap
Secret	Password all'interno di connection e transport_url	Campi *_file letti da Secret montati, mai nello YAML
Processo	bind_host, workers, log_file, use_syslog, debug	Gestito da Kubernetes; un unico default.log_level
Driver	Opzioni di tutti i driver inclusi (libvirt, VMware, storage array, ML2…)	Solo le opzioni dei componenti scelti (KubeVirt, CSI, OVN)
Validazione	Un controllo separato con lo strumento oslo-config-validator	Decodifica rigorosa: con una chiave sconosciuta o un valore fuori intervallo, il processo rifiuta di avviarsi
Modifica	Modificare i file su ogni host, riavviare	Nuovo hash della ConfigMap, riavvio progressivo; livello di log tramite SIGHUP

Stessi nomi: gruppi, opzioni e valori predefiniti dell'originale; OPENKEEL_<GROUP>_<OPTION> sovrascrive un valore per un singolo pod.

Meno opzioni: tenere solo ciò che conta

Modulo	Mantenute	Rimosse
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

828opzioni mantenute su 6,945, in 13 moduli
88%delle opzioni oslo rimosse

Dati letti dal file config/dropped-options.md di ogni modulo; ogni opzione rimossa vi è elencata con la relativa motivazione. Rimosse: opzioni deprecate, driver non inclusi, eventlet e lock su file, opzioni di processo gestite da Kubernetes. Mantenute: tutto ciò che modifica l'API, i dati o i limiti (quote, allocation ratio, durata dei token, enforce_scope).

Sicurezza e facilità d'uso

Skyline-OIDC

Accesso alla console tramite un identity provider OIDC: federazione, SSO, token validati con JWKS.

Secret interni a rotazione

Password dei database, account RabbitMQ e chiavi di servizio gestiti come componenti a rotazione, rinnovabili senza interventi manuali.

Credenziali EC2 in Skyline

Creare e gestire le credenziali EC2 (access / secret) dalla console, per accedere allo storage S3.