OpenKeel: la soluzione Cloud sovrana, francese e di portata europea, del gruppo inherent Scopri inherent
Deployment
Un cluster OpenKeel di produzione o di laboratorio con un solo comando.
Se non è configurato alcun cluster, okadm propone di creare un cluster kind. Con --ingress, la console Skyline è servita su skyline.127.0.0.1.nip.io. Con --demo, crea anche il dominio e il progetto demo, pronti da esplorare: una rete e il suo router, una VM dietro un load balancer, un container, IP flottanti e, se CloudKitty è installato, dati tariffati di esempio.
okadm plan --mode lab
okadm install --mode lab --create-kind --ingress --demo
export OS_CLOUD=openkeel
ok server listexport OS_CLOUD=openkeel
ok server list
ok loadbalancer create ...okadm plan --mode lab
okadm install --mode lab \
--create-kind --ingress --demoLe opzioni di okadm install e il loro ruolo. okadm upgrade accetta le stesse per ciò che fa (versione, componenti, valori, --grafana, --ingress); il cluster si sceglie come fa kubectl (--kubeconfig, $KUBECONFIG, --context, account in-cluster).
| Parametro | Predefinito | Ruolo |
|---|---|---|
--mode | production | production (3 nodi o più, etichette di ruolo, tre repliche, autoscaling) o lab (un nodo o più, una replica, volumi piccoli, backend sostitutivi) |
--version | l'ultima del manifest | Versione di OpenKeel da installare (okadm versions le elenca) |
--components | tutti tranne gli opzionali | Componenti da installare, con le dipendenze aggiunte (nova porta Keystone, Placement, Glance, Neutron, Cinder); opzionali: Ironic, ovn-bgp-agent, CloudKitty, Magnum e, in produzione, Designate |
--no-configurator | — | Esclude openkeel-configurator, altrimenti installato con OpenKeel in entrambe le modalità |
--domain | lab: openkeel.example.com | Dominio DNS pubblico delle API e della console; obbligatorio in produzione |
--storage-class | produzione: longhorn; lab: quella predefinita del cluster | StorageClass a blocchi dei database e dei volumi |
-f, --values | — | File di valori, ripetibile (struttura del chart ombrello, una sezione per componente): prevale su tutti i valori predefiniti |
--create-kind | — | Lab senza cluster: crea il cluster kind openkeel senza chiedere (--kind-name per rinominarlo) |
--install-prerequisites | attivo quando okadm crea il cluster, e in produzione | Installa gli operatori che mancano al cluster; =false si limita a verificarli |
--ingress | — | Pubblica le API e la console Skyline: in lab, Traefik su 127.0.0.1:80/443 e *.127.0.0.1.nip.io (--ingress-http-port, --ingress-https-port, --ingress-listen-address); in produzione, l'IngressClass del cluster (--ingress-class), con Traefik installato se non ce n'è nessuna |
--grafana | — | Stack di osservabilità: Prometheus Operator, Loki, Alloy, Grafana e le dashboard OpenKeel; mantenuto dalle esecuzioni successive |
--ceph-s3 | — | Rook, un cluster Ceph e il suo gateway RGW (API S3 e Swift) autenticati da Keystone |
--demo | — | Crea il dominio e il progetto demo con una VM, un load balancer e un container (sotto); --demo-external-network (predefinito public) indica la rete del suo router e dei suoi IP flottanti |
--no-default-flavors, --no-default-share-type | — | Niente flavor da m1.tiny a m1.xlarge né tipo di share Manila default |
--no-base-image, --no-public-network | — | Lab: niente immagine Alpine in Glance né rete esterna condivisa public (203.0.113.0/24) |
--timeout | 15m | Quanto può attendere al massimo ogni passo |
--dry-run | — | Mostra i passi e genera ogni chart, senza cambiare nulla |
--progress | auto | live (il passo in corso ridisegnato con il suo stato) o plain (una riga ogni 30 s, per la CI) |
--chart | il chart integrato in okadm | Chart ombrello locale, per provare una modifica di chart senza ricompilare okadm |
okadm plan esegue gli stessi controlli senza scrivere nulla; okadm status, okadm access (URL, account, port-forward), okadm upgrade e okadm uninstall seguono l'installazione.
Ogni passaggio è idempotente: rieseguire okadm install non cambia nulla se tutto è già a posto, e riprende un'installazione interrotta.
Verifica la versione di Kubernetes, i nodi, gli operator e la StorageClass; mostra il comando che risolve ogni lacuna
In laboratorio senza cluster: creato tramite la libreria kind, porte 80 e 443 con --ingress
Installa i prerequisiti mancanti, attende i CRD e i Deployment
Umbrella chart integrato e suddiviso: prima openkeel-infra, poi una release per componente
MariaDB Galera in TLS, RabbitMQ e vhost; database, account e secret per componente; la CA interna e i certificati
release openkeel-* nell'ordine delle dipendenze, migrazioni di schema
da m1.tiny a m1.xlarge; immagine cloud-init Alpine 3.24 in Glance
URL della console Skyline, Keystone, account admin, clouds.yaml esportato
I passi automatizzati di okadm install, in ordine. Ognuno attende ciò che crea (CRD Established, Deployment Available, release Helm e i loro Job di migrazione) ed è unchanged quando il cluster è già conforme.
| Passo | Produzione | Laboratorio |
|---|---|---|
| Cluster | Il cluster esistente: 3 nodi Ready o più, etichette di ruolo rafforzate (control plane, compute, container, rete, storage), zone verificate | Creato con la libreria kind se non ce n'è uno (--create-kind): un nodo, kindnet, local-path; con --ingress, le porte 80 e 443 inoltrate; le immagini OpenKeel del motore di container locale caricate nel nodo |
| Operator | Installati se mancano: cert-manager, operatori MariaDB e RabbitMQ, KubeVirt e CDI (senza emulazione), metrics-server (certificati dei kubelet verificati), Traefik dietro un LoadBalancer quando nessuna IngressClass è utilizzabile | Idem, più PowerDNS ed ExternalDNS; KubeVirt emula senza /dev/kvm; metrics-server con --kubelet-insecure-tls; Traefik su hostPort |
| Namespace, Multus, CRD | Namespace openkeel (Pod Security baseline imposto, restricted come avviso), plugin Multus thick, CRD OpenKeelTenant e OpenKeelCustomer | Idem, più l'attachment segnaposto openkeel-ovn (il lab non ha Kube-OVN) |
Osservabilità (--grafana) | Prometheus Operator, Loki su S3, Alloy, Grafana, prima dei servizi dati i cui monitor hanno bisogno delle loro CRD | Lo stesso stack con una replica ciascuno |
| Servizi dati | openkeel-infra: MariaDB Galera e RabbitMQ in TLS (dimensioni dei chart, 3 repliche), un database, account e secret per componente, la CA interna; l'operatore di topologia di RabbitMQ configurato per fidarsene; ogni oggetto atteso fino a Ready | Una replica, MariaDB 5 GiB, RabbitMQ 2 GiB; le correzioni di NetworkPolicy del lab per kindnet |
| Integrazione con la piattaforma | — | StorageProfile di CDI per local-path, CA del proxy di upload di CDI per Glance, database OVN Northbound e Southbound (ovn-central) per Neutron |
| Componenti | Una release Helm per componente, in ordine di dipendenza, valori predefiniti dei chart (3 repliche, autoscaling), posizionamento sui nodi tramite etichette di ruolo; openkeel-configurator | Ogni replica a 1, niente autoscaling, volumi ReadWriteOnce di al massimo 5 GiB, backend sostitutivi (driver dummy di Manila, Zun su runc senza Kata, Nova emulato) |
| Contenuto del catalogo | Flavor da m1.tiny a m1.xlarge; tipo di share Manila default | Idem, più l'immagine Alpine 3.24.3 cloud-init (verificata con SHA-512) e la rete esterna condivisa public (203.0.113.0/24) |
Object storage (--ceph-s3) | Rook, Ceph e RGW (S3 e Swift) autenticati da Keystone: 3 monitor, pool replicati 3 volte su host diversi, 2 gateway | Lo stesso con un monitor, una replica e un gateway, l'OSD su un dispositivo loop del nodo kind |
Pubblicazione (--ingress) | Ingress delle API sull'IngressClass del cluster, <servizio>.<dominio> | Traefik, skyline.127.0.0.1.nip.io e le API su *.127.0.0.1.nip.io |
Demo (--demo) | Il progetto demo sulla rete esterna indicata da --demo-external-network | Il progetto demo su public; con CloudKitty, dati tariffati di esempio |
| Riepilogo | Ogni passo eseguito, invariato o fallito con la sua causa; obiettivo, modalità e componenti registrati nella ConfigMap openkeel-okadm-state; un'esecuzione interrotta riprende da dove si era fermata | Idem |
Installati da okadm in laboratorio; in produzione, okadm plan li verifica e mostra il comando per la versione testata.
Flavor creati per impostazione predefinita (hw_rng:allowed e resources:DISK_GB=0, i dischi root sono PVC) e un'immagine cloud-init Alpine 3.24.3 registrata in Glance, verificata con SHA-512.
| Nome | vCPU | RAM | Disco |
|---|---|---|---|
| m1.tiny | 1 | 512 MB | 1 GB |
| m1.small | 1 | 2 GB | 20 GB |
| m1.medium | 2 | 4 GB | 40 GB |
| m1.large | 4 | 8 GB | 80 GB |
| m1.xlarge | 8 | 16 GB | 160 GB |
Console: skyline.127.0.0.1.nip.io con --ingress, altrimenti kubectl port-forward svc/openkeel-skyline-api 9998. Account admin, progetto admin, dominio Default; password nel secret openkeel-keystone-admin.
--demo conclude l'installazione con un progetto completo da esplorare in Skyline e con le CLI. Richiede Keystone, Glance, Cinder, Neutron, ovn-octavia-provider, Nova e Zun; ciò che esiste già con il suo nome viene mantenuto, quindi rieseguirlo completa una demo interrotta.
| Risorsa | Cosa crea okadm |
|---|---|
Dominio demo | Tramite l'OpenKeelCustomer demo (riconciliato da keystone-customers): il dominio, il suo manager e il progetto |
Utente demo | Manager del dominio e del progetto, con la password dell'utente admin (secret openkeel-keystone-admin); admin riceve il ruolo admin nel progetto |
Progetto demo | Il suo gruppo di sicurezza predefinito apre ICMP, SSH e HTTP |
| Rete | demo-net e demo-subnet (192.168.0.0/24, DHCP), router demo-router verso la rete esterna |
VM demo-vm | Flavor m1.tiny, l'immagine base Alpine, un volume dati da 20 GB demo-vm-data, l'utente alpine (password alpine) creato da cloud-init per la console e SSH, un IP flottante |
Load balancer demo-lb | Load balancer OVN, TCP 80, la VM come membro, un IP flottante sul suo VIP |
Container nginx | Container Zun con un volume da 1 GB su /data |
| Dati tariffati (con CloudKitty) | Un frame al giorno dal primo giorno del mese scorso a ieri, una VM eliminata il mese scorso, IP flottanti, l'immagine: la pagina FinOps / GreenOps di Skyline mostra entrambi i mesi; poi il progetto viene tariffato ogni ora |
In un lab, gli IP flottanti vengono da TEST-NET-3 (203.0.113.0/24), indirizzi di documentazione mai instradati, e l'OVN del lab non ha piano dati: la VM si avvia (emulata) e la sua console funziona, ma nulla può raggiungerla via rete.