Miremos bajo el capó de OpenShift y descubramos el secreto del repositorio Origin

Si has trabajado con OpenShift o instalado su distribución gratuita OKD, seguro que te has encontrado con el repositorio openshift/origin. En la era de OpenShift 3 y las primeras versiones de 4.x, aquí era donde vivía el núcleo de toda la plataforma. Los desarrolladores clonaban una porción masiva del código de Kubernetes aquí y construían sus componentes sobre él.

Pero si visitas este repositorio hoy, no verás la estructura antigua. Ni los archivos familiares de los controladores, ni el código fuente del binario hyperkube. ¿A dónde fue todo y por qué Red Hat mantiene un proyecto con casi nueve mil estrellas?

A dónde fue el código fuente de OpenShift

En el verano de 2020, antes del lanzamiento de OpenShift 4.6, el equipo de desarrollo se reorganizó. El enfoque monolítico se había convertido en un obstáculo: sincronizar cambios con Kubernetes upstream en un solo lugar junto con sus propias pruebas se había vuelto demasiado complicado.

Como resultado, el código base se dividió:

• Todo el trabajo con el fork de Kubernetes y la construcción de binarios como hyperkube se mudó al repositorio openshift/kubernetes.
• El repositorio openshift/origin se convirtió en un centro de pruebas especializado.

Ahora el propósito principal de Origin es servir como hogar para el binario openshift-tests y un conjunto de escenarios e2e que verifican el cumplimiento del clúster con los estándares de OpenShift y Kubernetes.

Cómo funciona el testing end-to-end en openshift-tests

Construir pruebas en el proyecto no tiene nada que ver con ejecutar go test normales. Aquí se compila un binario openshift-tests completo, empaquetado en su interior con cientos de escenarios de integración y e2e.

El equipo de OpenShift tiene una regla estricta para escribir pruebas e2e. Dos pruebas diferentes no deben duplicar la funcionalidad del otro en más de un 10%. Olvídate de verificar meticulosamente cada error de validación en la API. El propósito de estas pruebas es seguir un viaje real del usuario de principio a fin: desplegar una aplicación, verificar que las políticas de red funcionan, asegurar que el enrutamiento es correcto y recopilar métricas.

Puedes compilar la herramienta de pruebas con un solo comando desde la raíz del proyecto:

make

El binario resultante puede ejecutar tanto pruebas de conformidad estándar de Kubernetes como verificaciones específicas para componentes de Red Hat.

Selectores de entorno en lugar de anotaciones

Antes, para omitir una prueba incompatible en una configuración de clúster específica, los ingenieros adjuntaban anotaciones directamente en el código Go. Esto creaba caos durante las actualizaciones.

En las ramas modernas de Origin, las anotaciones han sido eliminadas. Ahora el filtrado se controla mediante los llamados selectores de entorno (environment selectors). El framework observa los parámetros del clúster objetivo antes de ejecutar (como el tipo de proveedor de red o la plataforma en la nube) y filtra las pruebas no aptas sobre la marcha.

La lógica de exclusión se divide en dos niveles:

• Las excepciones para las pruebas estándar de Kubernetes están ubicadas en openshift/kubernetes en los archivos environment_selectors.go y disabled_tests.go.
• Las reglas para pruebas específicas de OpenShift viven directamente en Origin en el directorio pkg/test/extensions.

Si estás escribiendo tu propio operador para OpenShift, este esquema facilita entender por qué una prueba upstream particular no se ejecuta en tu entorno.

Sincronización de dependencias y problemas con la suma de verificación de Go

Dado que origin depende de un fork de openshift/kubernetes, los desarrolladores tienen que actualizar constantemente los módulos de Go. Para evitar hacer esto manualmente, se añadió un script hack/update-kube-vendor.sh al proyecto.

Puedes ejecutar actualizaciones de vendor para una rama específica o commit SHA así:

./hack/update-kube-vendor.sh master

El script puede obtener cambios incluso de pull requests no fusionados. Para hacer esto, pasa la dirección de tu fork como segundo argumento:

./hack/update-kube-vendor.sh my-feature-branch github.com/myname/kubernetes

Cuando trabajas con este script, es fácil encontrarse con un error molesto. El proxy de suma de verificación de Go (sum.golang.org) a veces devuelve 410 Gone si un commit acaba de ser creado y la base de datos de suma de verificación aún no ha tenido tiempo de indexarlo.

Se ve así:

go: k8s.io/[email protected] ... 410 Gone
        server response: not found

La solución aquí es simple: desactiva forzosamente la verificación de la base de datos de suma de verificación durante las actualizaciones de vendor:

GOSUMDB=off hack/update-kube-vendor.sh master

Ejecutar rápidamente ejemplos externos

Además de las pruebas, queda en el repositorio un script útil hack/update-external-example.sh. Descarga manifiestos de aplicaciones actualizados y quick starts de repositorios externos del ecosistema y los coloca en la carpeta examples.

Si necesitas ejemplos conocidos de Deployment, Route o StatefulSet que funcionan en OpenShift, vale la pena revisar la carpeta examples/quickstarts: contiene configuraciones verificadas.

Quién se beneficia del repositorio Origin hoy

Si solo operas un clúster de OpenShift, no necesitarás profundizar en el código de Origin todos los días. Pero el proyecto será de gran ayuda en tres casos:

• Estás escribiendo tus propios operadores o extensiones de plataforma y quieres ejecutar verificaciones e2e oficiales en tu pipeline de CI/CD.
• Estás contribuyendo al desarrollo de OKD o depurando una construcción personalizada de Kubernetes para hardware específico.
• Quieres ver cómo se implementa la arquitectura de testing de sistemas distribuidos en Go en proyectos comerciales a gran escala.

El repositorio es abierto bajo la licencia Apache 2.0, y una comunidad activa mantiene ramas para todas las versiones actuales de la plataforma.