Kubernetes 1.27: The Changes That Matter to Operators

Actualizado: 2026-05-03

Kubernetes 1.27 (“Chill Vibes”), released in April 2023, isn’t a revolutionary release but brings concrete operational improvements and several deprecations worth addressing before upgrading. This article summarises what matters from the cluster operator’s perspective.

Key takeaways

• SeccompDefault reaches GA: all pods without an explicit profile automatically receive RuntimeDefault.
• KMS v2 enters beta with support for multiple rotatable keys and DEK caching.
• Scheduling gates are now stable, enabling coordination of pods with external systems.
• PodSecurityPolicy has been permanently removed — without migration to PSA, the upgrade is blocked.
• Pluto or kubectl deprecations are essential for detecting manifests using already-removed APIs.

SeccompDefault Reaches Stable

One of the most important security improvements in this release: the SeccompDefault feature gate reaches GA. When enabled at the node level (--seccomp-default on kubelet), all pods without an explicit seccomp profile automatically receive the runtime’s RuntimeDefault profile.

This reduces the syscall-interface attack surface. Without it, a pod without a seccomp profile has access to all Linux syscalls. With SeccompDefault, the most dangerous syscalls are blocked unless the pod explicitly declares it needs them.

Recommended for most clusters, after verifying that workloads don’t use syscalls blocked by RuntimeDefault. Some older JVM runtimes or native binaries may need custom profiles.

KMS v2 in Beta

Encrypting data in etcd (for secrets and sensitive configmaps) was historically done with KMS v1, which had key limitations: a single key per cluster and no automatic rotation.

KMS v2, in beta in 1.27 and targeted for GA in 1.29, solves these problems:

• Multiple keys per cluster, independently rotatable.
• Local data-key encryption with DEK caching (significantly faster).
• Audit events for every KMS operation.

For clusters with compliance requirements (FIPS 140-2, SOC 2, ISO 27001), enabling KMS v2 with an external provider such as AWS KMS, GCP KMS, or HashiCorp Vault is a priority step.

Scheduling Gates and Scheduler Improvements

1.27 stabilises scheduling gates. They allow delaying pod scheduling until an external controller lifts the gate. Three main use cases:

• Waiting on external resources before startup (volume provisioning, dynamic claims).
• Coordinating pods with external quota systems.
• Implementing custom admission logic without modifying the scheduler.

Pod topology spread constraints also improve: the minDomains property avoids the degenerate case where a single domain makes spread meaningless.

Important Deprecations

Two key items removed or in active removal:

• PodSecurityPolicy has been removed. If the cluster still had PSP active, migration to Pod Security Admission^[1] must have been completed beforehand. Without it, upgrading to 1.27 is blocked.
• In-tree cloud providers continue migrating to CSI + CCM. OpenStack and vSphere are in active deprecation.

To detect removed APIs in manifests, running Pluto^[2] on the GitOps repo before the upgrade is the most reliable step.

Practical Upgrade Checklist

Before upgrading from 1.26 to 1.27:

1. Audit Pod Security Policies. All PSPs must have been migrated to Pod Security Admission.
2. Verify API versions in manifests. Run pluto detect-files -d . on the GitOps repository.
3. Test SeccompDefault in staging. Enable it and validate that critical workloads don’t use blocked syscalls.
4. Plan rollback. Upgrade on the fewest nodes possible first, observe for 24-48h before extending.

For context on the next jump, see coverage of Kubernetes 1.28 and native sidecar containers — the most relevant feature in the following release. Also related to security management: Trivy and Grype for CI image scanning and SLSA Level 3 for the supply chain.

Conclusion

Kubernetes 1.27 is a consolidation release: SeccompDefault GA, stable scheduling gates, advancing KMS v2, and cleanup of historical deprecations. No drastic changes, but enough security and operational improvements to justify planning the upgrade in the two months following the release.

1. Pod Security Admission
2. Pluto