OpenKeel: die souveräne französische Cloud-Lösung mit europäischer Reichweite der inherent-Gruppe inherent entdecken
Deployment
Ein OpenKeel-Produktions- oder -Laborcluster mit einem einzigen Befehl.
Ist kein Cluster konfiguriert, bietet okadm an, einen kind-Cluster zu erstellen. Mit --ingress wird die Skyline-Konsole unter skyline.127.0.0.1.nip.io bereitgestellt. Mit --demo legt es außerdem die Domain und das Projekt demo an, bereit zum Erkunden: ein Netzwerk mit Router, eine VM hinter einem Load Balancer, einen Container, Floating IPs und, wenn CloudKitty installiert ist, bewertete Beispieldaten.
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 --demoDie Optionen von okadm install und ihre Rolle. okadm upgrade nimmt dieselben für das, was es tut (Version, Komponenten, Werte, --grafana, --ingress); der Cluster wird wie bei kubectl gewählt (--kubeconfig, $KUBECONFIG, --context, In-Cluster-Konto).
| Parameter | Standard | Rolle |
|---|---|---|
--mode | production | production (3 oder mehr Knoten, Rollen-Labels, drei Repliken, Autoscaling) oder lab (ein oder mehr Knoten, eine Replik, kleine Volumes, Ersatz-Backends) |
--version | die neueste des Manifests | Zu installierende OpenKeel-Version (okadm versions listet sie auf) |
--components | alle außer den optionalen | Zu installierende Komponenten, ihre Abhängigkeiten werden ergänzt (nova bringt Keystone, Placement, Glance, Neutron, Cinder mit); optional: Ironic, ovn-bgp-agent, CloudKitty, Magnum und in Produktion Designate |
--no-configurator | — | Lässt openkeel-configurator weg, das sonst in beiden Modi mit OpenKeel installiert wird |
--domain | Lab: openkeel.example.com | Öffentliche DNS-Domain der APIs und der Konsole; in Produktion Pflicht |
--storage-class | Produktion: longhorn; Lab: die Standard-StorageClass des Clusters | Block-StorageClass der Datenbanken und Volumes |
-f, --values | — | Values-Datei, wiederholbar (Aufbau des Umbrella-Charts, ein Abschnitt je Komponente): hat Vorrang vor allen Standardwerten |
--create-kind | — | Lab ohne Cluster: legt den kind-Cluster openkeel ohne Rückfrage an (--kind-name, um ihn umzubenennen) |
--install-prerequisites | aktiv, wenn okadm den Cluster anlegt, und in Produktion | Installiert die Operatoren, die dem Cluster fehlen; =false prüft sie nur |
--ingress | — | Veröffentlicht die APIs und die Skyline-Konsole: im Lab Traefik auf 127.0.0.1:80/443 und *.127.0.0.1.nip.io (--ingress-http-port, --ingress-https-port, --ingress-listen-address); in Produktion die IngressClass des Clusters (--ingress-class), Traefik wird installiert, wenn keine vorhanden ist |
--grafana | — | Observability-Stack: Prometheus Operator, Loki, Alloy, Grafana und die OpenKeel-Dashboards; bleibt bei späteren Läufen erhalten |
--ceph-s3 | — | Rook, ein Ceph-Cluster und sein RGW-Gateway (S3- und Swift-APIs), von Keystone authentifiziert |
--demo | — | Legt die Domain und das Projekt demo mit einer VM, einem Load Balancer und einem Container an (unten); --demo-external-network (Standard public) bezeichnet das Netz seines Routers und seiner Floating IPs |
--no-default-flavors, --no-default-share-type | — | Keine Flavors m1.tiny bis m1.xlarge und kein Manila-Share-Typ default |
--no-base-image, --no-public-network | — | Lab: kein Alpine-Image in Glance und kein gemeinsames externes Netz public (203.0.113.0/24) |
--timeout | 15m | Wie lange jeder Schritt höchstens wartet |
--dry-run | — | Zeigt die Schritte und rendert jedes Chart, ohne etwas zu ändern |
--progress | auto | live (der laufende Schritt wird mit seinem Zustand neu gezeichnet) oder plain (eine Zeile alle 30 s, für CI) |
--chart | das in okadm eingebaute Chart | Lokales Umbrella-Chart, um eine Chart-Änderung zu testen, ohne okadm neu zu bauen |
okadm plan führt dieselben Prüfungen aus, ohne etwas zu schreiben; okadm status, okadm access (URLs, Konten, Port-Forwards), okadm upgrade und okadm uninstall folgen auf die Installation.
Jeder Schritt ist idempotent: Ein erneutes okadm install ändert nichts, wenn alles vorhanden ist, und setzt eine unterbrochene Installation fort.
Prüft Kubernetes-Version, Knoten, Operatoren und StorageClass; gibt für jede Lücke den Befehl zu ihrer Behebung aus
Im Labor ohne Cluster: über die kind-Bibliothek erstellt, Ports 80 und 443 mit --ingress
Installiert die fehlenden Voraussetzungen, wartet auf CRDs und Deployments
Eingebettetes, aufgeteiltes Umbrella-Chart: zuerst openkeel-infra, dann ein Release pro Komponente
MariaDB Galera in TLS, RabbitMQ und vhost; Datenbank, Konten und Secrets je Komponente; die interne CA und die Zertifikate
openkeel-*-Releases in der Reihenfolge der Abhängigkeiten, Schemamigrationen
m1.tiny bis m1.xlarge; Alpine-3.24-cloud-init-Image in Glance
URL der Skyline-Konsole, Keystone, Admin-Konto, exportierte clouds.yaml
Die automatisierten Schritte von okadm install, der Reihe nach. Jeder wartet auf das, was er anlegt (CRDs Established, Deployments Available, Helm-Releases und ihre Migrations-Jobs), und ist unchanged, wenn der Cluster bereits übereinstimmt.
| Schritt | Produktion | Labor |
|---|---|---|
| Cluster | Der vorhandene Cluster: 3 oder mehr Ready-Knoten, gehärtete Rollen-Labels (Control Plane, Compute, Container, Netzwerk, Speicher), Zonen geprüft | Mit der kind-Bibliothek erstellt, wenn keiner existiert (--create-kind): ein Knoten, kindnet, local-path; mit --ingress werden die Ports 80 und 443 weitergeleitet; die OpenKeel-Images der lokalen Container-Engine werden in den Knoten geladen |
| Operatoren | Installiert, wenn sie fehlen: cert-manager, MariaDB- und RabbitMQ-Operatoren, KubeVirt und CDI (ohne Emulation), metrics-server (Kubelet-Zertifikate geprüft), Traefik hinter einem LoadBalancer, wenn keine IngressClass nutzbar ist | Ebenso, dazu PowerDNS und ExternalDNS; KubeVirt emuliert ohne /dev/kvm; metrics-server mit --kubelet-insecure-tls; Traefik auf hostPorts |
| Namespace, Multus, CRDs | Namespace openkeel (Pod Security baseline erzwungen, restricted als Warnung), Multus-Thick-Plugin, CRDs OpenKeelTenant und OpenKeelCustomer | Ebenso, dazu der Platzhalter-Anhang openkeel-ovn (das Lab hat kein Kube-OVN) |
Observability (--grafana) | Prometheus Operator, Loki auf S3, Alloy, Grafana, vor den Datendiensten, deren Monitore ihre CRDs brauchen | Derselbe Stack mit je einer Replik |
| Datendienste | openkeel-infra: MariaDB Galera und RabbitMQ in TLS (Chart-Größen, 3 Repliken), je Komponente eine Datenbank, Konten und Secrets, die interne CA; der Topology-Operator von RabbitMQ vertraut ihr; auf jedes Objekt wird bis Ready gewartet | Eine Replik, MariaDB 5 GiB, RabbitMQ 2 GiB; die NetworkPolicy-Korrekturen des Labs für kindnet |
| Plattform-Anbindung | — | CDI-StorageProfile für local-path, CA des CDI-Upload-Proxys für Glance, OVN-Northbound- und -Southbound-Datenbanken (ovn-central) für Neutron |
| Komponenten | Ein Helm-Release je Komponente, in Abhängigkeitsreihenfolge, Chart-Standardwerte (3 Repliken, Autoscaling), Platzierung auf den Knoten über Rollen-Labels; openkeel-configurator | Jede Replik auf 1, kein Autoscaling, Volumes ReadWriteOnce mit höchstens 5 GiB, Ersatz-Backends (Dummy-Treiber von Manila, Zun auf runc ohne Kata, Nova emuliert) |
| Kataloginhalt | Flavors m1.tiny bis m1.xlarge; Manila-Share-Typ default | Ebenso, dazu das Alpine-3.24.3-cloud-init-Image (per SHA-512 geprüft) und das gemeinsame externe Netz public (203.0.113.0/24) |
Objektspeicher (--ceph-s3) | Rook, Ceph und RGW (S3 und Swift), von Keystone authentifiziert: 3 Monitore, Pools dreifach über Hosts repliziert, 2 Gateways | Dasselbe mit einem Monitor, einer Replik und einem Gateway, das OSD auf einem Loop-Device des kind-Knotens |
Veröffentlichung (--ingress) | Ingresses der APIs auf der IngressClass des Clusters, <service>.<domain> | Traefik, skyline.127.0.0.1.nip.io und die APIs unter *.127.0.0.1.nip.io |
Demo (--demo) | Das Demo-Projekt auf dem mit --demo-external-network angegebenen externen Netz | Das Demo-Projekt auf public; mit CloudKitty bewertete Beispieldaten |
| Zusammenfassung | Jeder Schritt erledigt, unverändert oder mit Ursache fehlgeschlagen; Ziel, Modus und Komponenten in der ConfigMap openkeel-okadm-state festgehalten; ein unterbrochener Lauf setzt dort fort, wo er stehen blieb | Ebenso |
Im Labor von okadm installiert; in der Produktion prüft okadm plan sie und gibt den Befehl für die getestete Version aus.
Standardmäßig erstellte Flavors (hw_rng:allowed und resources:DISK_GB=0, Root-Disks sind PVCs) und ein in Glance registriertes Alpine-3.24.3-cloud-init-Image, mit SHA-512 geprüft.
| Name | vCPU | RAM | Festplatte |
|---|---|---|---|
| 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 |
Konsole: skyline.127.0.0.1.nip.io mit --ingress, andernfalls kubectl port-forward svc/openkeel-skyline-api 9998. Konto admin, Projekt admin, Domain Default; Passwort im Secret openkeel-keystone-admin.
--demo schließt die Installation mit einem vollständigen Projekt ab, das man in Skyline und mit den CLIs erkunden kann. Es braucht Keystone, Glance, Cinder, Neutron, ovn-octavia-provider, Nova und Zun; was unter seinem Namen schon existiert, bleibt erhalten, sodass ein erneuter Lauf eine unterbrochene Demo vervollständigt.
| Ressource | Was okadm anlegt |
|---|---|
Domain demo | Über den OpenKeelCustomer demo (von keystone-customers abgeglichen): die Domain, ihr Manager und das Projekt |
Benutzer demo | Manager der Domain und des Projekts, mit dem Passwort des Benutzers admin (Secret openkeel-keystone-admin); admin erhält die Admin-Rolle im Projekt |
Projekt demo | Seine Standard-Sicherheitsgruppe öffnet ICMP, SSH und HTTP |
| Netzwerk | demo-net und demo-subnet (192.168.0.0/24, DHCP), Router demo-router zum externen Netz |
VM demo-vm | Flavor m1.tiny, das Alpine-Basis-Image, ein 20-GB-Datenvolume demo-vm-data, der von cloud-init für Konsole und SSH angelegte Benutzer alpine (Passwort alpine), eine Floating IP |
Load Balancer demo-lb | OVN-Load-Balancer, TCP 80, die VM als Mitglied, eine Floating IP auf seiner VIP |
Container nginx | Zun-Container mit einem 1-GB-Volume unter /data |
| Bewertete Daten (mit CloudKitty) | Ein Frame pro Tag vom ersten Tag des Vormonats bis gestern, eine im Vormonat gelöschte VM, Floating IPs, das Image: Die FinOps-/GreenOps-Seite von Skyline zeigt beide Monate; danach wird das Projekt stündlich bewertet |
Im Lab stammen die Floating IPs aus TEST-NET-3 (203.0.113.0/24), Dokumentationsadressen, die nie geroutet werden, und das OVN des Labs hat keine Datenebene: Die VM startet (emuliert) und ihre Konsole funktioniert, aber nichts erreicht sie über das Netz.