OpenKeel : la solution Cloud souveraine, française à portée européenne du groupe inherent Découvrir inherent
Déploiement
Un cluster OpenKeel de production ou de lab en une commande.
Sans cluster configuré, okadm propose de créer un cluster kind. Avec --ingress, la console Skyline est servie sur skyline.127.0.0.1.nip.io. Avec --demo, il crée aussi le domaine et le projet demo, prêts à explorer : un réseau et son routeur, une VM derrière un load balancer, un conteneur, des IP flottantes, et des données valorisées d'exemple quand CloudKitty est installé.
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 --demoLes options d'okadm install et leur rôle. okadm upgrade prend les mêmes pour ce qu'il fait (version, composants, valeurs, --grafana, --ingress) ; le cluster est choisi comme le fait kubectl (--kubeconfig, $KUBECONFIG, --context, compte in-cluster).
| Paramètre | Par défaut | Rôle |
|---|---|---|
--mode | production | production (3 nœuds ou plus, labels de rôle, trois répliques, autoscaling) ou lab (un nœud ou plus, une réplique, petits volumes, backends de repli) |
--version | la dernière du manifeste | Version d'OpenKeel à installer (okadm versions les liste) |
--components | tous sauf les optionnels | Composants à installer, leurs dépendances ajoutées (nova amène Keystone, Placement, Glance, Neutron, Cinder) ; optionnels : Ironic, ovn-bgp-agent, CloudKitty, Magnum, et Designate en production |
--no-configurator | — | Écarte openkeel-configurator, sinon installé avec OpenKeel dans les deux modes |
--domain | lab : openkeel.example.com | Domaine DNS public des API et de la console ; obligatoire en production |
--storage-class | production : longhorn ; lab : celle par défaut du cluster | StorageClass bloc des bases de données et des volumes |
-f, --values | — | Fichier de valeurs, répétable (structure du chart parapluie, une section par composant) : l'emporte sur toutes les valeurs par défaut |
--create-kind | — | Lab sans cluster : crée le cluster kind openkeel sans demander (--kind-name pour le renommer) |
--install-prerequisites | actif quand okadm crée le cluster, et en production | Installe les opérateurs qui manquent au cluster ; =false se contente de les vérifier |
--ingress | — | Publie les API et la console Skyline : en lab, Traefik sur 127.0.0.1:80/443 et *.127.0.0.1.nip.io (--ingress-http-port, --ingress-https-port, --ingress-listen-address) ; en production, l'IngressClass du cluster (--ingress-class), Traefik installé s'il n'y en a pas |
--grafana | — | Pile d'observabilité : Prometheus Operator, Loki, Alloy, Grafana et les tableaux de bord OpenKeel ; conservée par les exécutions suivantes |
--ceph-s3 | — | Rook, un cluster Ceph et sa passerelle RGW (API S3 et Swift) authentifiés par Keystone |
--demo | — | Crée le domaine et le projet demo avec une VM, un load balancer et un conteneur (ci-dessous) ; --demo-external-network (par défaut public) désigne le réseau de son routeur et de ses IP flottantes |
--no-default-flavors, --no-default-share-type | — | Ne pas créer les gabarits m1.tiny à m1.xlarge ni le type de partage Manila default |
--no-base-image, --no-public-network | — | Lab : ne pas créer l'image Alpine dans Glance ni le réseau externe partagé public (203.0.113.0/24) |
--timeout | 15m | Durée d'attente maximale de chaque étape |
--dry-run | — | Affiche les étapes et rend chaque chart, sans rien changer |
--progress | auto | live (l'étape en cours redessinée avec son état) ou plain (une ligne toutes les 30 s, pour la CI) |
--chart | le chart intégré à okadm | Chart parapluie local, pour tester une modification de chart sans recompiler okadm |
okadm plan fait les mêmes vérifications sans rien écrire ; okadm status, okadm access (URL, comptes, port-forwards), okadm upgrade et okadm uninstall suivent l'installation.
Chaque étape est idempotente : relancer okadm install ne change rien si tout est en place et reprend une installation interrompue.
Vérifie version Kubernetes, nœuds, opérateurs, StorageClass ; donne la commande de correction de chaque écart
En lab sans cluster : créé via la bibliothèque kind, ports 80 et 443 avec --ingress
Installe les prérequis manquants, attend CRD et Deployments
Chart parapluie embarqué, découpé : openkeel-infra puis une release par composant
MariaDB Galera en TLS, RabbitMQ et vhost ; base, comptes et secrets par composant ; la CA interne et les certificats
Releases openkeel-* dans l'ordre des dépendances, migrations de schéma
m1.tiny à m1.xlarge ; image Alpine 3.24 cloud-init dans Glance
URL de la console Skyline, Keystone, compte admin, clouds.yaml exporté
Les étapes automatisées d'okadm install, dans l'ordre. Chacune attend ce qu'elle crée (CRD Established, Deployments Available, releases Helm et leurs Jobs de migration) et est unchanged quand le cluster est déjà conforme.
| Étape | Production | Lab |
|---|---|---|
| Cluster | Le cluster existant : 3 nœuds Ready ou plus, labels de rôle durcis (control plane, compute, conteneurs, réseau, stockage), zones vérifiées | Créé avec la bibliothèque kind s'il n'y en a pas (--create-kind) : un nœud, kindnet, local-path ; avec --ingress, les ports 80 et 443 redirigés ; les images OpenKeel du moteur de conteneurs local chargées dans le nœud |
| Opérateurs | Installés s'ils manquent : cert-manager, opérateurs MariaDB et RabbitMQ, KubeVirt et CDI (sans émulation), metrics-server (certificats des kubelets vérifiés), Traefik derrière un LoadBalancer quand aucune IngressClass n'est utilisable | Idem, plus PowerDNS et ExternalDNS ; KubeVirt émule sans /dev/kvm ; metrics-server avec --kubelet-insecure-tls ; Traefik sur des hostPorts |
| Namespace, Multus, CRD | Namespace openkeel (Pod Security baseline imposé, restricted en avertissement), plugin Multus thick, CRD OpenKeelTenant et OpenKeelCustomer | Idem, plus l'attachement factice openkeel-ovn (le lab n'a pas Kube-OVN) |
Observabilité (--grafana) | Prometheus Operator, Loki sur S3, Alloy, Grafana, avant les services de données dont les moniteurs ont besoin de leurs CRD | La même pile avec une réplique chacun |
| Services de données | openkeel-infra : MariaDB Galera et RabbitMQ en TLS (tailles des charts, 3 répliques), une base, des comptes et des secrets par composant, la CA interne ; l'opérateur de topologie RabbitMQ configuré pour lui faire confiance ; chaque objet attendu Ready | Une réplique, MariaDB 5 Gio, RabbitMQ 2 Gio ; les correctifs de NetworkPolicy du lab pour kindnet |
| Raccords de plateforme | — | StorageProfile CDI pour local-path, CA du proxy d'upload CDI pour Glance, bases OVN Northbound et Southbound (ovn-central) pour Neutron |
| Composants | Une release Helm par composant, dans l'ordre des dépendances, valeurs par défaut des charts (3 répliques, autoscaling), placement sur les nœuds par labels de rôle ; openkeel-configurator | Chaque réplique à 1, pas d'autoscaling, volumes ReadWriteOnce de 5 Gio au plus, backends de repli (pilote dummy de Manila, Zun sur runc sans Kata, Nova émulé) |
| Contenu du catalogue | Gabarits m1.tiny à m1.xlarge ; type de partage Manila default | Idem, plus l'image Alpine 3.24.3 cloud-init (vérifiée en SHA-512) et le réseau externe partagé public (203.0.113.0/24) |
Stockage objet (--ceph-s3) | Rook, Ceph et RGW (S3 et Swift) authentifiés par Keystone : 3 moniteurs, pools répliqués 3 fois sur des hôtes distincts, 2 passerelles | La même chose avec un moniteur, une réplique et une passerelle, l'OSD sur un périphérique loop du nœud kind |
Publication (--ingress) | Ingresses des API sur l'IngressClass du cluster, <service>.<domaine> | Traefik, skyline.127.0.0.1.nip.io et les API sur *.127.0.0.1.nip.io |
Démo (--demo) | Le projet démo sur le réseau externe indiqué par --demo-external-network | Le projet démo sur public ; avec CloudKitty, des données valorisées d'exemple |
| Bilan | Chaque étape faite, inchangée ou en échec avec sa cause ; cible, mode et composants enregistrés dans la ConfigMap openkeel-okadm-state ; une exécution interrompue reprend où elle s'est arrêtée | Idem |
Installés par okadm en lab ; en production, okadm plan les vérifie et donne la commande de la version testée.
Flavors créés par défaut (hw_rng:allowed et resources:DISK_GB=0, les disques racine sont des PVC) et image Alpine 3.24.3 cloud-init enregistrée dans Glance, vérifiée par SHA-512.
| Nom | vCPU | RAM | Disque |
|---|---|---|---|
| m1.tiny | 1 | 512 Mo | 1 Go |
| m1.small | 1 | 2 Go | 20 Go |
| m1.medium | 2 | 4 Go | 40 Go |
| m1.large | 4 | 8 Go | 80 Go |
| m1.xlarge | 8 | 16 Go | 160 Go |
Console : skyline.127.0.0.1.nip.io avec --ingress, sinon kubectl port-forward svc/openkeel-skyline-api 9998. Compte admin, projet admin, domaine Default ; mot de passe dans le secret openkeel-keystone-admin.
--demo termine l'installation par un projet complet à explorer dans Skyline et avec les CLI. Il demande Keystone, Glance, Cinder, Neutron, ovn-octavia-provider, Nova et Zun ; ce qui existe déjà sous son nom est gardé, si bien qu'une nouvelle exécution complète une démo interrompue.
| Ressource | Ce qu'okadm crée |
|---|---|
Domaine demo | Par l'OpenKeelCustomer demo (réconcilié par keystone-customers) : le domaine, son manager et le projet |
Utilisateur demo | Manager du domaine et du projet, avec le mot de passe de l'utilisateur admin (secret openkeel-keystone-admin) ; admin reçoit le rôle admin dans le projet |
Projet demo | Son groupe de sécurité par défaut ouvre ICMP, SSH et HTTP |
| Réseau | demo-net et demo-subnet (192.168.0.0/24, DHCP), routeur demo-router vers le réseau externe |
VM demo-vm | Gabarit m1.tiny, l'image de base Alpine, un volume de données de 20 Go demo-vm-data, l'utilisateur alpine (mot de passe alpine) créé par cloud-init pour la console et SSH, une IP flottante |
Load balancer demo-lb | Load balancer OVN, TCP 80, la VM comme membre, une IP flottante sur sa VIP |
Conteneur nginx | Conteneur Zun avec un volume de 1 Go sur /data |
| Données valorisées (avec CloudKitty) | Une trame par jour du premier jour du mois dernier à hier, une VM supprimée le mois dernier, des IP flottantes, l'image : la page FinOps / GreenOps de Skyline montre les deux mois ; puis le projet est valorisé chaque heure |
En lab, les IP flottantes viennent de TEST-NET-3 (203.0.113.0/24), des adresses de documentation jamais routées, et l'OVN du lab n'a pas de plan de données : la VM démarre (émulée) et sa console fonctionne, mais rien ne peut la joindre par le réseau.