Kubernetes 1.27: The Changes That Matter to Operators

Javier Cañete
Contenedores en arquitectura Kubernetes

Kubernetes 1.27 (“Chill Vibes”), released in April 2023, isn’t a revolutionary release but brings a useful set of operational improvements and several deprecations worth attending to before upgrade. This article summarises what matters from the operator perspective.

SeccompDefault Reaches Stable

One of the most important security improvements: 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 — a huge surface. With SeccompDefault, most dangerous syscalls are blocked unless the pod explicitly declares it needs them.

Recommended activation for most clusters, after testing that your workloads don’t use syscalls blocked by RuntimeDefault.

KMS v2 in Beta

Encryption of data in etcd (for secrets, sensitive configmaps) was historically done with KMS v1, which had limitations: one key per cluster, no automatic rotation.

KMS v2 (beta in 1.27, GA expected in 1.29) solves this:

  • Multiple keys per cluster, rotatable.
  • Local data-key encryption with DEK caching (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 KMS provider (AWS KMS, GCP KMS, HashiCorp Vault) is a relevant step.

Scheduler Improvements

1.27 introduces scheduling gates as a stable feature. They allow delaying pod scheduling until an external operator lifts the “gate”. Useful for:

  • Waiting on external resources (volume provisioning, dynamic claims).
  • Coordinating with external systems before startup.
  • Implementing custom quota systems.

Also arriving: improved pod topology spread constraints: the minDomains property avoids the degenerate case where you have a single domain and spread adds nothing.

Important Deprecations

1.27 completes the deprecation started in previous versions:

  • PodSecurityPolicy has been removed. If your cluster still had PSP, you must have migrated to Pod Security Admission. You won’t upgrade to 1.27 if PSP is still active in 1.26.
  • Deprecated kubelet and kube-apiserver flags: several legacy flags are removed. Review your config with the changelog.
  • In-tree cloud providers continue migrating to CSI + CCM. The last ones (OpenStack, vSphere) in active deprecation.

API Changes

API versions removed in 1.27:

  • networking.k8s.io/v1beta1 (IngressClass, Ingress): already removed before, just a reminder.
  • Several alpha and beta APIs have advanced versions: review manifests with kubectl deprecations or Pluto to detect.

Practical Upgrade Checklist

For operators planning the 1.26 → 1.27 upgrade:

  1. Audit Pod Security Policies. Any existing PSP must have been migrated to Pod Security Admission before touching the upgrade.
  2. Verify API versions in manifests. Run pluto detect-files -d . on your GitOps repo.
  3. Test SeccompDefault in staging. If enabled, test that critical workloads survive. Some (older JVM runtimes, native binaries) use syscalls that are blocked.
  4. Rollback plan. Upgrade on as few nodes as possible first, observe 24-48h, then the rest.

Related, see our coverage of Kubernetes 1.28 and native sidecar containers as the next stop.

Conclusion

Kubernetes 1.27 is a consolidation release: stabilising useful features (SeccompDefault, scheduling gates), KMS v2 progress, deprecation cleanup. No drastic changes, but enough security and operational improvements to justify planning the upgrade within 2-3 months after release.

Follow us on jacar.es for more on Kubernetes, cloud-native platforms, and operations.

Entradas relacionadas