El proyecto

Mejoras

Más allá de la isofuncionalidad: herramientas, seguridad y facilidad de uso.

Go: el lenguaje Cloud Native

El lenguaje Cloud Native

Kubernetes, etcd, containerd, Helm, Prometheus, KubeVirt: el mismo lenguaje que la plataforma

Ecosistema integrado

client-go, SDK de Helm, OVSDB, Prometheus, OIDC: bibliotecas nativas, sin pasarelas

Tipado y compilado

Tipado fuerte, errores detectados en compilación, código más rápido que Python

Compilaciones rápidas

Un binario estático por servicio, compilación rápida, multiarquitectura

Contenedores mínimos

Un ejecutable, rootless, sin shell ni código fuente, sobre distroless en lugar de Ubuntu

Ligero en ejecución

Sin intérprete ni eventlet (tiempo de arranque y memoria no medidos en el espacio de trabajo)

Herramientas: automatizar, desplegar, pilotar

Tres herramientas que OpenStack no ofrece de esta forma, escritas en Go como los servicios y entregadas con cada versión de OpenKeel.

La CLI de OpenStack, en Go

ok es el comando openstack reescrito en Go: un único binario estático, sin Python, virtualenv ni plugins que instalar.

Los 1.325 comandos de python-openstackclient 10.3.1 y sus plugins, cada uno verificado frente a la CLI de Python por reproducción diferencial
Mismos argumentos, formatos de salida, mensajes de error y códigos de salida: los scripts existentes siguen funcionando
Lee clouds.yaml, OS_* y --os-* como el original; binarios para Linux, macOS y Windows, y una imagen distroless

export OS_CLOUD=openkeel
ok server list -f json

Más información

okadm

Despliegue plug and play, en lab o en producción

okadm instala OpenKeel en un clúster de Kubernetes con un comando por etapa del ciclo de vida, en modo lab o producción.

Lab: sin clúster, crea un clúster kind, instala los operadores de lab y una réplica de cada servicio; --ingress añade el punto de entrada público
Producción: okadm plan comprueba los requisitos previos (versión, roles de los nodos, operadores, StorageClass, dominio) e indica la corrección de cada uno; tres réplicas
Instalación idempotente que se reanuda donde se detuvo, actualización componente a componente, estado, desinstalación; client-go y el SDK de Helm integrados

okadm plan --mode production
okadm install --mode lab \
  --create-kind --ingress --demo

Más información

Configurator

Pilotar el despliegue de forma gráfica

El Configurator es una consola web, instalada por defecto por okadm, para preparar el despliegue de los módulos de OpenKeel y seguirlo visualmente.

Roles de los nodos (plano de control, cómputo, red, almacenamiento, contenedores, aprovisionamiento) y ubicación de cada componente, arrastrando y soltando en una vista de topología por zona de disponibilidad
Parámetros de cada servicio: activado, réplicas, autoescalado, recursos, YAML libre; comprobaciones de quórum, antiafinidad y mínimos por rol
Seguimiento visual: la distribución de los componentes en los nodos, el estado de los pods (listos, reinicios) y los registros de cada servicio, combinados y con búsqueda
Genera los valores de okadm install -f y las etiquetas de los nodos, o etiqueta él mismo los nodos

Ver la demostración

Menos código, las mismas garantías

1,008 kLíneas de Python en los 19 módulos originales
310 kLíneas de Go en los módulos de OpenKeel
−69%código, sin contar las pruebas

Módulo	Python	Go	Cambio
Placement	10,287	10,256	0%
Nova	150,846	20,534	−86%
Zun	30,938	13,947	−55%
Masakari	10,835	9,347	−14%
Cinder	255,934	17,400	−93%
Glance	31,279	14,372	−54%
Manila	135,162	18,285	−86%
Neutron	127,623	25,947	−80%
Octavia (OVN)	5,778	9,042	+56%
Neutron-FWaaS	8,085	9,643	+19%
Neutron-VPNaaS	6,449	11,190	+74%
OVN-BGP-Agent	8,448	5,074	−40%
Keystone	50,584	21,015	−58%
Barbican	18,688	12,851	−31%
Designate	23,671	15,367	−35%
CloudKitty	15,020	12,042	−20%
API EC2	11,570	16,272	+41%
Skyline	18,723	8,590	−54%
ok (CLI)	88,122	59,156	−33%
Total	1,008,042	310,330	−69%

Líneas no vacías y sin comentarios, sin contar las pruebas, contadas al generar el sitio. En el lado de Python solo se cuenta el paquete del servicio: oslo, neutron-lib, keystonemiddleware y os-brick no se cuentan, mientras que sus equivalentes están dentro de cada módulo Go. Los drivers y agentes sustituidos por Kubernetes desaparecen; los pequeños módulos antes injertados en Neutron o Nova crecen, porque se convierten en servicios independientes.

Configuración: de oslo.config a YAML

	OpenStack (Python)	OpenKeel (Go)
Archivos	INI de oslo.config, más api-paste.ini, rootwrap.conf y sus filtros, logging.conf, policy	Un config.yaml por proceso, montado desde un ConfigMap
Secretos	Contraseñas dentro de connection y transport_url	Campos *_file leídos de Secrets montados, nunca en el YAML
Proceso	bind_host, workers, log_file, use_syslog, debug	Gestionado por Kubernetes; un único default.log_level
Drivers	Opciones de todos los drivers incluidos (libvirt, VMware, cabinas, ML2…)	Solo las opciones de los componentes elegidos (KubeVirt, CSI, OVN)
Validación	Una comprobación aparte con la herramienta oslo-config-validator	Decodificación estricta: ante una clave desconocida o un valor fuera de rango, el proceso se niega a arrancar
Cambio	Editar los archivos en cada host y reiniciar	Nuevo hash de ConfigMap, reinicio progresivo; nivel de log mediante SIGHUP

Mismos nombres: grupos, opciones y valores por defecto del original; OPENKEEL_<GROUP>_<OPTION> sobrescribe un valor para un único pod.

Menos opciones: conservar solo lo que importa

Módulo	Conservadas	Eliminadas
Placement	7	101
Nova	122	1,015
Zun	63	300
Masakari	35	235
Cinder	49	1,411
Glance	66	472
Manila	82	905
Neutron	82	443
Keystone	100	313
Barbican	72	200
Designate	84	300
CloudKitty	50	271
API EC2	16	151

828opciones conservadas de 6,945, en 13 módulos
88%de las opciones de oslo eliminadas

Cifras leídas del archivo config/dropped-options.md de cada módulo; cada opción eliminada figura allí con su motivo. Eliminadas: opciones obsoletas, drivers no incluidos, eventlet y bloqueos de archivo, opciones de proceso asumidas por Kubernetes. Conservadas: todo lo que modifica la API, los datos o los límites (cuotas, ratios de asignación, duración de los tokens, enforce_scope).

Seguridad y facilidad de uso

Skyline-OIDC

Inicio de sesión en la consola mediante un proveedor de identidad OIDC: federación, SSO, tokens validados con JWKS.

Secretos internos rotativos

Contraseñas de bases de datos, cuentas de RabbitMQ y claves de servicio gestionadas como componentes rotativos, renovables sin intervención manual.

Credenciales EC2 en Skyline

Crear y gestionar credenciales EC2 (access / secret) desde la consola para acceder al almacenamiento S3.