OpenKeel: la solución Cloud soberana, francesa y de alcance europeo, del grupo inherent Descubrir inherent

Componentes · Consola y herramientas

okadm

La CLI de despliegue: plan, install, upgrade, status, uninstall; laboratorio kind o producción.

Go client-go, SDK de Helmopenkeel-okadm

El módulo

okadm checks, installs and upgrades OpenKeel on an existing Kubernetes cluster, with one command per lifecycle step:

okadm plan    --mode lab                         # does the cluster meet the prerequisites? what is missing, how to fix it
okadm install --mode lab                         # no cluster configured: offers to create a kind cluster
okadm upgrade --version 2026.2.1                    # one component at a time, in dependency order
okadm install --mode lab --create-kind --ingress  # kind with 127.0.0.1:80/443 forwarded, Traefik, the console at http://skyline.127.0.0.1.nip.io
okadm status                                     # installed version, Helm releases, state of their pods
okadm uninstall --yes                            # components, then data services; volumes kept unless --purge
okadm install --component csi-tester --pure-endpoint fa.example.org --pure-api-token-file ./api-token
                                                 # only the FlashArray CSI driver and its test application
  • Go module: github.com/openkeel/openkeel-okadm, binary okadm (cmd/okadm)
  • Built on cobra, k8s.io/cli-runtime (kubectl connection flags), client-go and the Helm 3 Go SDK; no kubectl or helm binary is needed
  • The release manifest (which component version makes up each OpenKeel version) is embedded: internal/manifest/releases.yaml

Extracto de openkeel-okadm/README.md (en inglés).

Cómo se prueba la compatibilidad

okadm no reimplementa ninguna API de OpenStack: sus tests verifican los charts e instalaciones que produce, y las nubes que instala se ejercitan con clientes OpenStack reales.

Tests unitarios y golden tests

Tests unitarios y renderizado real del chart

Planes, valores y pasos de instalación con clientes Kubernetes simulados y un releaser de Helm simulado; el chart paraguas real se renderiza con los valores de okadm en ambos modos.

Ejecución

make test (go vet, go test -race -cover ./...), incluido TestRealChartRenders.

Fuente: openkeel-okadm/README.md

De extremo a extremo en un laboratorio

Instalación en un clúster kind nuevo

El binario por sí solo crea el clúster e instala los operadores, la infraestructura, Keystone y Placement.

Ejecución

okadm install --mode lab --components keystone,placement con --create-kind, charts y manifiestos integrados.

Último resultado Todo en Ready, código de salida 0; una segunda ejecución recarga las imágenes y conserva sus etiquetas.

Fuente: openkeel-okadm/README.md

De extremo a extremo en un laboratorio

Clientes reales en un laboratorio instalado con okadm

ok y la CLI openstack de Python ejecutan comandos de lectura sobre cada servicio instalado por okadm.

Ejecución

okadm install --mode lab, y luego ambas CLI en paralelo.

Último resultado 37 / 42 comandos de lectura idénticos (2026-11-02).

Fuente: openkeel-ok/docs/CONFORMANCE.md

Contrato de cliente

Endpoint de load balancer con openstacksdk

La entrada de catálogo load-balancer que registra okadm funciona con openstacksdk y tokens reales de Keystone: LB en ACTIVE, listener, pool, miembro, eliminación en cascada.

Ejecución

okadm install en kind con --components ovn-octavia-provider.

Último resultado Superado (2026-11-01); sin plano de datos en este modo.

Fuente: openkeel-neutron/docs/CONFORMANCE.md

Excluido del rewrite

okadm despliega OpenKeel en un clúster de Kubernetes existente desde un único binario Go, y deja la preparación de los hosts, el plano de datos del lado del host y la infraestructura gestionada a mano a Kubernetes y sus operadores.

Asumido por la plataforma Cloud Native

Preparación de hosts por SSH e inventario de Ansible

Asumido por Kubernetes

Por qué se excluyó

OpenKeel se dirige a un clúster existente (o a un clúster kind en modo laboratorio); okadm plan comprueba los requisitos previos y muestra el comando para cada uno que falte.

Por qué la solución no se ve afectada

No se instala nada en los hosts por SSH; los nodos solo necesitan sus etiquetas de rol de Kubernetes.

Fuente: openkeel-okadm/README.md

Asumido por la plataforma Cloud Native

Agentes libvirt y OVS en los hosts

Asumido por KubeVirt, OVN, CSI

Por qué se excluyó

El plano de datos está formado por componentes de Kubernetes: KubeVirt y CDI, Kube-OVN u OVN, y almacenamiento CSI.

Por qué la solución no se ve afectada

okadm instala o comprueba estos componentes; VM, redes y volúmenes se ejecutan como cargas de trabajo del clúster.

Fuente: openkeel-okadm/README.md

Asumido por la plataforma Cloud Native

MariaDB, RabbitMQ y Memcached desplegados a mano

Asumido por Operadores de Kubernetes

Por qué se excluyó

Unos operadores ejecutan MariaDB Galera y RabbitMQ (sin Memcached: ningún servicio Go lo necesita); okadm crea por componente las bases de datos, usuarios, vhosts y Secrets generados.

Por qué la solución no se ve afectada

Ningún archivo de contraseñas que mantener; cada componente recibe sus propias credenciales en Secrets de Kubernetes.

Fuente: openkeel-okadm/README.md

Mecánica interna simplificada

Cadena de herramientas Python, Ansible y helm o kubectl

Por qué se excluyó

okadm integra client-go, el SDK de Helm 3, los charts y el manifiesto de release.

Por qué la solución no se ve afectada

Instalación, actualización, estado y desinstalación se ejecutan desde un solo binario; solo se descargan imágenes de contenedor.

Fuente: openkeel-okadm/README.md

Aquí solo figura lo que se excluyó por diseño; el trabajo aún no realizado está en los Known gaps del docs/CONFORMANCE.md del módulo. Todos los módulos