Kubernetes 1.30: las mejoras que de verdad agradecen los operadores

Actualizado: 2026-05-03

Kubernetes 1.30 salió en abril de 2024 y pasó con bastante discreción —sobre todo comparado con la 1.31 de agosto, que se llevó casi todos los titulares con AppArmor en GA y el reordenamiento de sidecars. Es una pena, porque para quien opera clústeres en producción esta release es precisamente la clase que marca la diferencia: pocos cambios épicos, muchas costuras apretadas. Este artículo recorre lo que de verdad vale la pena conocer y, sobre todo, lo que cambia en el día a día de un operador.

Puntos clave

• ValidatingAdmissionPolicy llega a GA: políticas de admisión declarativas en CEL sin webhooks externos.
• Pod scheduling readiness permite que los pods declaren cuando están listos para ser programados.
• Job success policy añade control granular sobre qué combinación de índices constituye éxito en Jobs indexados.
• La versión mínima de Go requerida sube a 1.22; revisar imágenes base personalizadas antes del upgrade.
• El proceso de upgrade desde 1.29 sigue siendo aconsejable release a release, sin saltar versiones.

ValidatingAdmissionPolicy llega a GA: el cambio más importante

La promoción a GA de ValidatingAdmissionPolicy es, con diferencia, la mejora con mayor impacto práctico de esta release. Durante años, cualquier regla de admisión mínimamente seria —rechazar un Deployment con más de X réplicas, forzar etiquetas obligatorias, impedir imágenes sin tag fijado— exigía desplegar un webhook externo: un servicio HTTPS con su certificado, su alta disponibilidad, su latencia añadida a cada llamada a la API y su punto de fallo propio. Si el webhook se caía o ralentizaba, el plano de control se degradaba.

Con 1.30, el modelo declarativo basado en CEL (Common Expression Language) deja de ser experimental y pasa a ser una opción seria. Defines la política como un recurso del clúster, la API server la evalúa en proceso y te ahorras todo el andamiaje del webhook. Para políticas simples —la inmensa mayoría en la práctica— sustituyes varios cientos de líneas de Go, un Deployment, un Service y un cert-manager Certificate por un YAML de veinte líneas.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: "force-tag-not-latest"
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups:   ["apps"]
      apiVersions: ["v1"]
      operations:  ["CREATE","UPDATE"]
      resources:   ["deployments"]
  validations:
  - expression: >
      object.spec.template.spec.containers.all(c,
        !c.image.endsWith(':latest'))
    message: "La etiqueta :latest no está permitida en producción"

La latencia baja, la superficie de fallo también, y los equipos de plataforma pueden revisar políticas como PRs normales sin auditar código Go. La única limitación real es la expresividad de CEL: para lógica compleja con efectos secundarios (consultar una API externa, escribir en un registro de auditoría), el webhook sigue siendo necesario.

Pod scheduling readiness: control del ciclo de vida antes del scheduling

Esta feature, que llega a GA en 1.30, resuelve un problema frecuente en arquitecturas con dependencias de inicialización. Antes de 1.30, un pod creado en Kubernetes entraba directamente en el ciclo de scheduling: el scheduler lo veía, evaluaba su viabilidad y, si encontraba un nodo adecuado, lo asignaba. No había forma de decirle al scheduler “este pod existe pero todavía no está listo para ser programado”.

El resultado práctico era que pods con dependencias externas —un secreto que aún no había llegado al clúster, un recurso de infraestructura que se estaba aprovisionando— se asignaban a nodos, fallaban en el arranque y entraban en bucles de CrashLoopBackOff innecesarios.

Con pod scheduling readiness, los pods pueden declarar scheduling gates: condiciones explícitas que deben satisfacerse antes de que el scheduler los considere. Una vez eliminada la gate por un controlador externo, el pod entra en el ciclo normal.

spec:
  schedulingGates:
  - name: "example.com/external-resource-ready"

El caso de uso más común es en operadores de infraestructura que crean pods antes de que el recurso de nube asociado esté disponible. Para gestores de clústeres que también usan observabilidad con eBPF, esto simplifica mucho el ciclo de vida de los pods de profiling.

Job success policy: qué conta como éxito en Jobs indexados

Los Jobs indexados (con completionMode: Indexed) permiten que cada índice ejecute un rol diferente dentro del mismo Job. El problema antes de 1.30 es que el éxito del Job requería que todos los índices completaran satisfactoriamente —sin matices.

Job success policy añade un campo successPolicy en la spec del Job que permite especificar qué combinación de índices exitosos constituye éxito del Job completo, aunque otros índices fallen o no completen. Esto es especialmente útil en workloads de ML distribuido, simulaciones por Monte Carlo o cualquier patrón de “suficientes índices buenos”:

spec:
  completions: 10
  completionMode: Indexed
  successPolicy:
    rules:
    - succeededIndexes: "0-2"
      succeededCount: 3

La release también incluye mejoras en el recolector de basura de pods completados y ajustes en el manejo de Jobs con reintentos, que reducen race conditions observadas en 1.29.

Otros cambios relevantes

Más allá de los tres cambios principales, algunos detalles merecen atención:

• Contextual logging estabilizado: el logging estructurado con contexto propagado llega a estable, útil para correlacionar logs de plano de control con traces de aplicación.
• VolumeAttributesClass: nueva API (alpha) para modificar atributos de volúmenes sin recrearlos; relevante para PV de alto rendimiento en cloud.
• Retirada de v1beta2 en FlowSchemas y PriorityLevelConfigurations: si tienes estos recursos en versión beta antigua, migra antes del upgrade.
• Go 1.22 requerido: para quienes compilan imágenes personalizadas del plano de control, verificar la cadena de herramientas antes.

Upgrade desde 1.29

El proceso de upgrade en 1.30 no introduce sorpresas mayores si sigues la secuencia habitual: actualizar primero el plano de control (apiserver, controller-manager, scheduler), luego los nodos trabajadores con rolling update, y finalmente los componentes de add-on como CoreDNS y kube-proxy.

Los puntos a verificar antes del upgrade:

• Comprobar que ningún webhook de admisión existente cubra reglas que vayas a migrar a ValidatingAdmissionPolicy; duplicar reglas genera comportamiento inesperado.
• Revisar si tienes FlowSchemas o PriorityLevelConfigurations en v1beta2; la API sigue presente en 1.30 pero la deprecación avanza.
• Si usas Trivy Operator para auditoría continua del clúster, actualizar el chart de Helm antes del upgrade del clúster asegura compatibilidad de API.

Para el upgrade en sí, la guía oficial de Kubernetes documenta los pasos específicos de cada componente. La recomendación general de no saltar versiones sigue vigente en 1.30.

Conclusión

Kubernetes 1.30 es una release de consolidación, no de titulares. ValidatingAdmissionPolicy en GA elimina una categoría entera de infraestructura accidental para políticas de admisión. Pod scheduling readiness y job success policy añaden matices que los operadores de cargas complejas llevaban tiempo pidiendo. El operador de clústeres que actualiza a 1.30 sale con menos webhooks, menos CrashLoops innecesarios y más control sobre qué constituye éxito en sus Jobs distribuidos.