Workload Conformance de Kubernetes: prepara tu checklist

El anuncio de Kubernetes del 27 de octubre de 2026 responde a una escena conocida: antes de drenar nodos o actualizar el clúster, alguien vuelve a preguntar si cada aplicación tolera la interrupción, usa APIs que siguen disponibles y pide recursos razonables. Workload Conformance pretende convertir parte de esa revisión repetida en un estándar común y verificable.

La palabra importante es pretende. Hoy no hay un binario que descargar, un CRD que aplicar, una versión que fijar ni una puntuación que reportar. Lo que existe es un Working Group que está escribiendo la propuesta y un charter que delimita su alcance. La forma útil de actuar ahora es preparar evidencia propia sin presentarla como conformidad oficial.

Qué se está definiendo

El charter describe tres entregables futuros:

• una especificación del comportamiento de un workload para cada versión menor de Kubernetes;
• un método para probar cada requisito contra un workload en ejecución;
• tooling upstream que implemente esas pruebas.

El alcance previsto incluye postura de seguridad, resiliencia frente a interrupciones, huella de recursos, red, almacenamiento, uso de APIs y observabilidad. La prueba debe describir cómo se ejecuta el workload, no si su lógica de negocio calcula correctamente un pedido o una factura. Además, cada requisito tendrá que ser objetivo y verificable programáticamente; una opinión sobre si una aplicación “se siente” saludable no basta.

El trabajo es un foro entre SIGs mientras se escribe la especificación. SIG Architecture será responsable del subproyecto y del tooling cuando se propongan los primeros artefactos; su revisión y aprobación final llegarán cuando la especificación y el tooling sean estables. SIG Apps aporta la perspectiva de aplicaciones. El propio grupo no posee código. El charter estima estabilidad en dos o tres ciclos de releases de Kubernetes, pero esa estimación no es una fecha de disponibilidad ni fija la primera versión objetivo.

Lo que no puedes afirmar todavía

Workload Conformance no es una nueva capacidad de Kubernetes que se habilite en una versión concreta. Tampoco es el programa Certified Kubernetes Conformance, que comprueba la capa de infraestructura del clúster, ni una certificación que opere este Working Group. El charter deja cualquier programa de certificación fuera de su alcance y condiciona el respaldo de Kubernetes a una futura aprobación de SIG Architecture.

Tampoco sustituirá las pruebas de funcionalidad, carga, seguridad, recuperación o negocio. Un futuro resultado positivo describirá el comportamiento observado del workload en un entorno y una versión menor determinados; no demostrará que el código de negocio sea correcto ni que el mismo resultado se traslade sin cambios a otro proveedor, runtime, CNI, CSI o política de clúster.

Por eso no conviene publicar hoy una receta con comandos del grupo, nombres de CRD, umbrales, puntuaciones o requisitos atribuidos a Kubernetes 1.37. El issue de incorporación comunitaria #9217 muestra la creación de canales y artefactos de organización; no es un repositorio estable de tests ni una release del tooling.

Un checklist local inspirado en el anuncio

Mientras llega la especificación, una ficha interna puede reunir la información que normalmente se pierde entre una aplicación y la plataforma. Debe quedar marcada como “checklist del equipo” y llevar el entorno exacto. No debe llamarse conformance ni producir un “aprobado” que parezca oficial.

Área	Observación local	Evidencia que conviene guardar	Límite de la conclusión
Identidad y APIs	Tipo de workload, namespace, versión menor del clúster y APIs que usan sus manifiestos y controladores	Manifiestos, dependencias, versión del servidor y fecha	No implica que una futura lista oficial sea igual
Interrupciones	Réplicas disponibles, readiness, terminación cooperativa, periodo de gracia y política de disponibilidad durante una evacuación controlada	Eventos, estados antes/durante/después y configuración efectiva	Depende de scheduler, proveedor y políticas del clúster
Seguridad	Cuenta de servicio, permisos, securityContext y privilegios realmente requeridos	Manifiestos y revisión de permisos con el alcance autorizado	No es un certificado de seguridad
Recursos	requests, limits, reinicios y señales de presión que el equipo ya observe	Configuración, métricas y ventana temporal	No inventar umbrales universales
Red y almacenamiento	Dependencias de red, montajes, reconexión y comportamiento ante una interrupción del servicio	Configuración de CNI/CSI relevante y observaciones del laboratorio	Cambia con la implementación y la topología
Observabilidad	Logs, eventos, métricas y señales de arranque y apagado que permitan explicar el comportamiento	Consultas, capturas y versiones de los consumidores	La futura especificación aún no fija nombres o señales

Separar aplicación y plataforma evita mezclar preguntas. La primera columna debe responder qué necesita el servicio para ejecutarse; la segunda, qué ofrece el clúster y cómo se comporta durante una operación. Una política del proveedor puede explicar un resultado local sin convertirse en requisito de Workload Conformance.

Procedimiento seguro para un laboratorio

El objetivo no es “pasar” una prueba inexistente, sino dejar una ficha que otra persona pueda repetir.

1. Elige un entorno aislado. Usa un clúster efímero o un entorno de laboratorio con datos sintéticos, sin credenciales de producción ni tráfico real. Anota la versión menor de Kubernetes, runtime, CNI, CSI, ingress y políticas que puedan alterar el resultado.
2. Delimita el workload. Selecciona el Deployment, StatefulSet o Job que revisarás y registra su manifiesto, imagen, namespace, dependencias de API y configuración efectiva. No extiendas el resultado a otros workloads por similitud de nombre.
3. Define cada observación antes de ejecutarla. Para cada control escribe qué se observará, qué procedimiento autorizado se usará, qué condición considera el equipo satisfactoria y qué evidencia se conservará. Si el equipo ya cuenta con una rutina aprobada de evacuación, úsala solo en el laboratorio y documenta sus pasos reales; el Working Group aún no ha publicado un comando equivalente.
4. Observa el cambio de estado. Captura disponibilidad, terminación, eventos, recursos, red, almacenamiento y telemetría antes, durante y después de la operación. Si un paso puede afectar datos, usa una copia desechable y una política de restauración conocida.
5. Guarda el contexto. Junto al resultado conserva versiones, hashes de manifiestos, configuración y fecha. Un registro sin ese contexto no permite distinguir un cambio de la aplicación de un cambio del clúster.
6. Etiqueta el resultado correctamente. El encabezado de la ficha debe decir “evaluación interna inspirada en Workload Conformance”. No uses nombres de requisitos, puntuaciones o estados que sugieran una herramienta upstream; espera a que el proyecto publique sus artefactos y su método.

Este procedimiento puede revelar una dependencia de una API retirada, un privilegio innecesario o una terminación defectuosa. Es una razón para corregir el workload, no evidencia de que la iniciativa ya lo haya certificado.

Un manifiesto ilustrativo, no un requisito

Un Deployment mínimo puede servir para que el equipo decida qué quiere observar. El siguiente fragmento solo reúne campos conocidos de Kubernetes; los valores son ilustrativos y no forman parte de una lista oficial de Workload Conformance:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: servicio-ejemplo
spec:
  replicas: 2
  template:
    spec:
      terminationGracePeriodSeconds: 30
      containers:
        - name: servicio
          image: ejemplo/servicio:local
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
          livenessProbe:
            httpGet:
              path: /health
              port: 8080
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop:
                - ALL

La ficha debe explicar qué se observa con cada campo: cuándo pasa a estar listo, cómo deja de recibir tráfico, cuánto tarda en terminar y qué ocurre al acercarse a los límites. No debe convertir esos valores en umbrales normativos ni afirmar que un servicio con este manifiesto cumple un estándar futuro. La verificación estática de APIs usadas por los manifiestos es una revisión propia hasta que exista un método oficial.

Cómo distinguir la ficha propia del futuro estándar

Mantén dos columnas desde el primer día:

Ficha del equipo	Futura conformance oficial
Define la observación, el procedimiento autorizado y la evidencia para tu entorno	Definirá requisitos por versión menor y un método común cuando SIG Architecture los apruebe
Puede usar herramientas ya aprobadas por tu plataforma	Implementará tooling upstream que todavía no está disponible
Sirve para comparar tus cambios bajo el mismo contexto	No se puede anticipar con comandos, CRD, puntuaciones o nombres inventados
Su resultado es una decisión interna con límites explícitos	Su semántica dependerá de la especificación y las pruebas publicadas

Revisar el anuncio, el charter y los artefactos del subproyecto cuando aparezcan será más fiable que adaptar una plantilla comunitaria no oficial. Hasta entonces, conserva la trazabilidad de tus propias observaciones y evita venderlas como interoperabilidad automática.

Fuentes primarias

• Announcing the Workload Conformance Working Group — Kubernetes Blog, 27/10/2026
• WG Workload Conformance Charter — Kubernetes community
• WG Workload Conformance: Bootstrap community artifacts, issue #9217