Kubernetes 1.27: las novedades que importan a los operadores

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

SeccompDefault llega a estable

Una de las mejoras de seguridad más importantes: 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 — superficie enorme. Con SeccompDefault, la mayoría de syscalls peligrosos quedan bloqueados a menos que el pod declare explícitamente que los necesita.

Activación recomendada para la mayoría de clusters, tras probar que tus workloads no usan syscalls bloqueados por RuntimeDefault.

KMS v2 en beta

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

KMS v2 (beta en 1.27, GA esperado en 1.29) resuelve esto:

• Múltiples claves por cluster, rotables.
• Cifrado de data keys locales con DEK caching (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 KMS externo (AWS KMS, GCP KMS, HashiCorp Vault) es un paso relevante.

Mejoras del scheduler

1.27 introduce scheduling gates como feature estable. Permiten retrasar el scheduling de un pod hasta que un operador externo levante el “gate”. Útil para:

• Esperar recursos externos (aprovisionamiento de volúmenes, claims dinámicos).
• Coordinar con sistemas externos antes del startup.
• Implementar quota systems custom.

También llega pod topology spread constraints con mejoras: la propiedad minDomains evita el caso degenerado donde tienes un único dominio y el spread no aporta nada.

Deprecations importantes

1.27 completa la deprecation iniciada en versiones anteriores:

• PodSecurityPolicy ha sido removido. Si tu cluster aún tenía PSP, debes haber migrado a Pod Security Admission. No actualizarás a 1.27 si PSP aún está activo en 1.26.
• Flags deprecadas en kubelet y kube-apiserver: varios flags legacy se eliminan. Revisa tu configuración con la changelog.
• In-tree cloud providers siguen en proceso de migración a CSI + CCM. Los últimos (OpenStack, vSphere) en deprecation activa.

Cambios en APIs

Versiones de API removidas en 1.27:

• networking.k8s.io/v1beta1 (IngressClass, Ingress): ya removidas antes, solo recordatorio.
• Varias APIs alpha y beta han avanzado de versión: revisa manifests con kubectl deprecations o Pluto para detectar.

Upgrade checklist práctico

Para operadores que planifiquen el upgrade 1.26 → 1.27:

1. Audita Pod Security Policies. Cualquier PSP existente debe haberse migrado a Pod Security Admission antes de tocar el upgrade.
2. Verifica versiones de API en manifests. Ejecuta pluto detect-files -d . sobre tu repo GitOps.
3. Prueba SeccompDefault en staging. Si lo activas, prueba que workloads críticos sobreviven. Algunos (runtimes JVM antiguos, binarios nativos) usan syscalls que están bloqueados.
4. Plan de rollback. Upgrade en menor número posible de nodos primero, observación 24-48h, luego resto.

Relacionado, ver nuestra cobertura de Kubernetes 1.28 y contenedores sidecar nativos como próxima parada.

Conclusión

Kubernetes 1.27 es una release de consolidación: estabilización de features útiles (SeccompDefault, scheduling gates), avance de KMS v2, limpieza de deprecations. Sin cambios drásticos, pero con suficientes mejoras de seguridad y operación para justificar planificar el upgrade en los próximos 2-3 meses tras su release.

Síguenos en jacar.es para más sobre Kubernetes, plataformas cloud-native y operaciones.