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

Recursos

FAQ

Las respuestas esenciales para entender OpenKeel.

¿Qué es OpenKeel?

La solución Cloud soberana, francesa y de alcance europeo, del grupo inherent. Reescribe los servicios de OpenStack en Go sobre tecnologías Cloud Native (Kubernetes, OVN, KubeVirt, CSI). Sus API REST son compatibles con las de OpenStack y se despliega en Kubernetes con la CLI okadm.

¿Quién está detrás de OpenKeel?

El grupo inherent, un grupo informático francés experto en IA, cloud, ciberseguridad y conectividad para empresas y organismos públicos.

¿Bajo qué licencia se distribuye OpenKeel?

La licencia Apache 2.0, la de OpenStack: el código puede usarse, modificarse y redistribuirse, también comercialmente, con una concesión explícita de patentes; la licencia y los avisos de copyright acompañan cada copia, y los cambios se señalan como tales.

¿Está OpenKeel cualificado SecNumCloud?

SecNumCloud (ANSSI) cualifica un servicio y a su proveedor, no un software. OpenKeel está diseñado para ser SecNumCloud-ready: cada flujo interno en TLS, una pista de auditoría CADF en cada API, el RBAC de OpenStack, Barbican con un HSM, aislamiento Kata para los contenedores, imágenes firmadas con un SBOM en un registro controlado. Lo que hoy es conforme y lo que queda por evolucionar, requisito por requisito, está en SecNumCloud-ready.

¿Siguen funcionando mis herramientas de OpenStack?

Sí: cada componente conserva las rutas, parámetros, códigos HTTP, cuerpos de error, microversiones y políticas del original. Los clientes, SDK, Terraform, Tempest y Skyline no ven ninguna diferencia. Las diferencias conocidas se enumeran en el archivo docs/CONFORMANCE.md de cada módulo.

¿Cómo es OpenKeel multi-tenant?

Los tenants son los de Keystone (dominios, proyectos, roles, cuotas). No tienen acceso a Kubernetes. Las VM no tienen interfaz en la red de Pods: sus NIC son puertos Neutron en OVN, protegidos por port_security y una protección CNI. Manila y Zun también aíslan a cada tenant (un gateway NFS dentro de la red del tenant, una microVM Kata por contenedor).

¿Por qué reescribir en Go?

Go es el lenguaje de Kubernetes, etcd, containerd, Helm, Prometheus y KubeVirt. Proporciona binarios estáticos, imágenes distroless sin shell y acceso nativo a client-go, al SDK de Helm y a OVSDB.

¿Cómo se despliega OpenKeel?

Con okadm: okadm plan comprueba el clúster, okadm install instala en orden los operadores, los servicios de datos y los componentes, y okadm upgrade actualiza un componente cada vez. En laboratorio, okadm puede crear un clúster kind.

¿Qué cabinas de almacenamiento se admiten?

Cualquier cabina o software de almacenamiento con un driver CSI de bloque: Rook-Ceph (RBD), Longhorn, NetApp (Trident), Huawei Dorado y Pure Storage FlashArray mediante el driver CSI propio de OpenKeel. Cada uno es un backend de Cinder definido por una StorageClass; los tenants lo eligen mediante los tipos de volumen. Consulte Almacenamiento en bloque para el estado de validación de cada driver.

¿Qué ocurre con el plano de datos?

No se reescribe: KubeVirt ejecuta las VM, OVN y Open vSwitch conmutan las redes, CSI (Longhorn, Pure Storage) proporciona los volúmenes, Rook-Ceph el almacenamiento de objetos, ExternalDNS el DNS y Medik8s la remediación de nodos.

¿Se reescriben Ironic y Heat?

Todavía no. Ironic sigue siendo Python upstream, empaquetado en un chart de OpenKeel. Heat tiene su reverse-spec; solo sus comandos de stack y orquestación se reescriben en el cliente ok.

¿Cómo se comprueba la compatibilidad?

Mediante cinco niveles de pruebas: unitarias, integración con Galera, e2e replay de los intercambios grabados frente al servicio Python, CLI diferencial entre ok y openstack, y Tempest con sus plugins.

¿De dónde proceden las especificaciones?

De la skill generate-reverse-spec, que lee el código Python upstream de una rama (stable/2026.2) y produce una especificación documentada con fuentes y un rewrite pack. Las 38 reverse-specs se publican en la sección Recursos.