Kubernetes 1.27: las novedades que importan a los operadores

Actualizado: 2026-05-03

Kubernetes 1.27 (“Chill Vibes”), publicada en abril de 2023, no es una release revolucionaria pero trae mejoras operativas concretas y varias deprecations que conviene atender antes del upgrade. Este artículo resume lo que importa desde la perspectiva de operadores de clusters.

Puntos clave

• SeccompDefault alcanza GA: todos los pods sin perfil explícito reciben RuntimeDefault automáticamente.
• KMS v2 llega a beta con soporte para múltiples claves rotables y DEK caching.
• Los scheduling gates son ya estables, permitiendo coordinar pods con sistemas externos.
• PodSecurityPolicy ha sido eliminado definitivamente — sin migración a PSA, el upgrade no es posible.
• Pluto o kubectl deprecations son esenciales para detectar manifests que usan APIs ya removidas.

SeccompDefault llega a estable

Una de las mejoras de seguridad más importantes de esta release: el feature gate SeccompDefault alcanza GA. Cuando se activa a nivel de nodo (--seccomp-default en kubelet), todos los pods sin perfil seccomp explícito reciben automáticamente el perfil RuntimeDefault del runtime.

Esto reduce la superficie de ataque del syscall interface. Sin activar, un pod sin perfil seccomp tiene acceso a todos los syscalls Linux. Con SeccompDefault, los syscalls más peligrosos quedan bloqueados salvo declaración explícita del pod.

Activación recomendada para la mayoría de clusters, tras verificar que los workloads no usan syscalls bloqueados por RuntimeDefault. Algunos runtimes JVM antiguos o binarios nativos pueden necesitar perfiles personalizados.

KMS v2 en beta

El cifrado de datos en etcd (para secrets y configmaps sensibles) se hacía históricamente con KMS v1, que tenía limitaciones importantes: una sola clave por cluster y sin rotación automática.

KMS v2, en beta en 1.27 y previsto para GA en 1.29, resuelve estos problemas:

• Múltiples claves por cluster, rotables de forma independiente.
• Cifrado de data keys locales con DEK caching (significativamente más rápido).
• Audit events para toda operación KMS.

Para clusters con requisitos de compliance (FIPS 140-2, SOC 2, ISO 27001), activar KMS v2 con un proveedor externo como AWS KMS, GCP KMS o HashiCorp Vault es un paso prioritario.

Scheduling gates y mejoras del scheduler

1.27 estabiliza los scheduling gates. Permiten retrasar el scheduling de un pod hasta que un controlador externo levante el gate. Son útiles en tres escenarios principales:

• Esperar recursos externos antes del startup (aprovisionamiento de volúmenes, claims dinámicos).
• Coordinar pods con sistemas de quota externos.
• Implementar lógica de admisión personalizada sin modificar el scheduler.

También se mejoran las pod topology spread constraints: la propiedad minDomains evita el caso degenerado donde un único dominio hace que el spread no aporte nada.

Deprecations importantes

Dos elementos clave eliminados o en proceso de eliminación:

• PodSecurityPolicy ha sido removido. Si el cluster aún tenía PSP activo, la migración a Pod Security Admission^[1] debía haberse completado antes. Sin ella, la actualización a 1.27 no es posible.
• In-tree cloud providers continúan su migración a CSI + CCM. OpenStack y vSphere están en deprecation activa.

Para detectar APIs removidas en manifests, ejecutar Pluto^[2] sobre el repo GitOps antes del upgrade es el paso más fiable.

Checklist de upgrade práctico

Antes de actualizar de 1.26 a 1.27:

1. Auditar Pod Security Policies. Toda PSP debe haberse migrado a Pod Security Admission.
2. Verificar versiones de API en manifests. pluto detect-files -d . sobre el repositorio GitOps.
3. Probar SeccompDefault en staging. Activarlo y validar que los workloads críticos no usan syscalls bloqueados.
4. Planificar rollback. Upgrade en el menor número de nodos posible primero, con observación de 24-48h antes de extender.

Para el contexto del siguiente salto, ver la cobertura de Kubernetes 1.28 y contenedores sidecar nativos — la feature más relevante de la siguiente release. También relacionado con la gestión de seguridad: Trivy y Grype para escaneo de imágenes en CI y SLSA nivel 3 para la cadena de suministro.

Conclusión

Kubernetes 1.27 es una release de consolidación: SeccompDefault GA, scheduling gates estables, KMS v2 avanzando y limpieza de deprecations históricas. Sin cambios drásticos, pero con suficientes mejoras de seguridad y operación para justificar planificar el upgrade en los dos meses posteriores a la release.

1. Pod Security Admission
2. Pluto