What's new in Kubernetes 1.27

Kubernetes 1.27, codename Chill Vibes, is out in the wild. The release team posits this as a “calm” release, but it’s not without some important changes and enhancements. Here are some of the headlines as well as smaller or more experimental changes.

We’ve been talking about this for a year, but the time has come: the Kubernetes image registry changed from k8s.gcr.io to registry.k8s.io. Tell your friends. The old registry is frozen, and 1.27 isn’t available there at all—you’ll need to be using the new registry for this release and going forward.

With 1.27, seccomp profile defaulting graduated to stable, and can be enabled by running the kubelet with the --seccomp-default command line flag. 

This instructs the kubelet to use the container runtime’s seccomp profile, which should lead to more consistency and predictability and some generally improved security baselines, with fewer system calls readily available to container workloads. 

If you’re looking to enable this across nodes, you’ll want to take a look at the discussion of upgrade strategy on the Kubernetes Enhancement Proposal (KEP) on the Kubernetes GitHub.

This feature, now graduated to GA, allows for updates to a Job's scheduling directives before it starts. While it’s currently limited to a specific set of fields for suspended Jobs, this is part of a broader effort to enable more granular influence over pod placement without foregoing the kube-scheduler.

Fields that may be updated are:

• Annotations

• Labels

• Node affinity

• Node selector

• Tolerations

• Scheduling gates

With 1.27, Kubernetes moves to v3 of the OpenAPI specification. Limitations in v2 forced some workarounds in Custom Resource Definition representations, which were ahead of the game in using a v3 schema. Now the rest of the system has caught up, and CRDs are represented losslessly.

Server-side field validation has likewise moved to stable, and can validate objects more accurately than before (especially on the client-side) with the shift to OpenAPI v3. The Kubernetes team recommends using server-side field validation, which by default warns of problems but can be set to strict to raise an error on validation failure (or ignore to forego server-side validation entirely).

Previously, timezones for cronjobs were derived directly from the kube-controller-manager’s native timezone. Now you can set it directly and schedule things across regions much more cleanly. 

With a new schedulingGates field in the spec, you can define whena pod is actually rather than nominally ready for scheduling, so you don’t get a lot of wasted effort with the system trying to schedule pods that look ready to go but are actually missing essential resources. 

ReadWriteOncePod lets you give read-write volume access to just one pod, so you can be sure that only a single pod writes to a volume at a given time and avoid write skew or other problems. This mode has been around for a while, but it’s a really useful tool in the toolbelt for stateful apps so it’s good to see it progressing toward wider availability.

Moving on to some enhancements at earlier stages, we have an alpha feature that lets you access service logs for a given node via the Kubernetes API, grabbing data from either journald on Linux or the application log provider on Windows. If you want to try it out, you can enable the NodeLogQuery feature gate. Make sure that enableSystemLogHandler and enableSystemLogQuery are both set to true for the kubelet configuration.

You can read more about changes in Kubernetes 1.27 on the Kubernetes blog.

This story is excerpted from Radio Cloud Native, a biweekly news podcast from Mirantis. Listen to the full episode below.