Workload Conformance: prepara las preguntas de operación

Un estándar en preparación

El anuncio del 27 de octubre presenta un grupo que prepara especificación por versión menor, método y herramientas verificables. Los requisitos siguen abiertos; el alcance propuesto incluye seguridad, interrupciones, recursos, red, almacenamiento, APIs y observabilidad. Esa fecha corresponde a la publicación, no necesariamente a la creación del grupo. (Kubernetes project / Nabarun Pal)

El charter sitúa los futuros artefactos bajo SIG Architecture. Excluye lógica de negocio, formatos obligatorios de empaquetado y herramientas de proveedor impuestas. El grupo no ejecutará certificaciones: una posible oferta de CNCF dependería de aprobar el estándar. No se presenta aquí un test oficial listo para usar. (Kubernetes community)

El programa existente Certified Kubernetes comprueba las APIs requeridas de distribuciones y plataformas. Ese objeto es distinto del comportamiento de tus aplicaciones. (CNCF)

Para quien mantiene una aplicación, conviene separar esas capas en sus acuerdos: características de la plataforma, comportamiento operativo de la carga y resultado funcional del producto. Cada capa requiere evidencia propia y puede tener un responsable diferente.

Preguntas que puedes plantear a tu equipo

Esta matriz es una propuesta editorial de KIURO para equipos que ya usan Kubernetes. No reproduce una lista oficial de conformidad, no asigna una certificación y no recoge pruebas realizadas. Úsala para identificar evidencias disponibles y huecos antes de programar una intervención.

Añade a cada fila una fecha, el entorno y el estado de la evidencia: disponible, pendiente o no aplicable con motivo. Si alguien responde «eso lo cubre el proveedor», pide la referencia y comprueba exactamente qué cubre. Conserva los desacuerdos como decisiones pendientes con una persona responsable.

Ejemplo hipotético: una ventana de mantenimiento

Imagina un equipo con una aplicación interna de gestión de pedidos. Antes de renovar nodos, acuerda qué operaciones deben seguir disponibles y durante cuánto tiempo admite una interrupción. Esa tolerancia la decide el negocio; este artículo no propone un umbral universal.

En un entorno de ensayo autorizado, el equipo puede observar el comportamiento al retirar un nodo y después comprobar una operación representativa. Debe registrar qué ocurrió con las peticiones en curso, cuánto tardó en recuperar el servicio y si los datos esperados siguen accesibles. Son preguntas para diseñar el ensayo, no resultados obtenidos por KIURO.

Si el contenedor vuelve a arrancar pero una operación de pedido falla, conserva ambas observaciones. Separarlas ayuda a localizar la dependencia que falta. No cierres la incidencia únicamente porque la plataforma muestre recursos en ejecución; establece quién valida la función que necesita la persona usuaria.

Convierte las respuestas en un acuerdo mantenible

Para cada hueco, decide si falta documentación, una configuración que revisar o un ensayo que autorizar. Estima el esfuerzo según tu arquitectura y el entorno necesario. No hay un coste de certificación nuevo que este anuncio permita presupuestar.

Versiona la ficha junto a la aplicación. Cuando cambien sus dependencias, permisos o necesidades de almacenamiento, revisa las filas afectadas. Cuando el grupo publique artefactos verificables, podrás comparar su alcance con tu ficha y señalar qué queda fuera; no atribuyas hoy a esos artefactos propiedades todavía sin definir.

El siguiente paso útil es elegir una aplicación, una intervención prevista y una persona que coordine las respuestas. Esta propuesta se dirige a equipos que ya utilizan Kubernetes: el anuncio no demuestra que adoptar esa plataforma resuelva las necesidades de una organización.