New Kubernetes 1.26 release boosts security, storage, teases dynamic resource allocation (UPDATED)
In the cloud-native space, where applications are purpose built and delivered to run in the cloud, one technology in particular rises above all others — Kubernetes.
Kubernetes is an open-source container orchestration system, originally developed by Google in 2014. Since 2015, Kubernetes has been developed under the governance of the Cloud Native Computing Foundation (CNCF), which is part of the Linux Foundation and benefits from the support of thousands of developers and hundreds supporting organizations.
In 2022, all the major public cloud providers use Kubernetes, including Microsoft Azure’s Managed Kubernetes Service (AKS), Google Kubernetes Engine (GKE) service and the Amazon Elastic Kubernetes Service (EKS).
Kubernetes also benefits from the support of numerous vendor distributions, including Red Hat’s OpenShift, Canonical Kubernetes and the SUSE Rancher Kubernetes Engine (RKE). Sitting upstream from all the cloud and software vendors’ efforts is the open-source project that is being updated today to version 1.26.
UPDATE
Now it is official:
-
Kubernetes v1.26: Electrifying | Kubernetes
It's with immense joy that we announce the release of Kubernetes v1.26!
This release includes a total of 37 enhancements: eleven of them are graduating to Stable, ten are graduating to Beta, and sixteen of them are entering Alpha. We also have twelve features being deprecated or removed, three of which we better detail in this announcement.
Also new:
-
Kubernetes 1.26: We're now signing our binary release artifacts! | Kubernetes
The Kubernetes Special Interest Group (SIG) Release is proud to announce that we are digitally signing all release artifacts, and that this aspect of Kubernetes has now reached beta.
Signing artifacts provides end users a chance to verify the integrity of the downloaded resource. It allows to mitigate man-in-the-middle attacks directly on the client side and therefore ensures the trustfulness of the remote serving the artifacts. The overall goal of out past work was to define the used tooling for signing all Kubernetes related artifacts as well as providing a standard signing process for related projects (for example for those in kubernetes-sigs).
We already signed all officially released container images (from Kubernetes v1.24 onwards). Image signing was alpha for v1.24 and v1.25. For v1.26, we've added all binary artifacts to the signing process as well! This means that now all client, server and source tarballs, binary artifacts, Software Bills of Material (SBOMs) as well as the build provenance will be signed using cosign. Technically speaking, we now ship additional *.sig (signature) and *.cert (certificate) files side by side to the artifacts for verifying their integrity.
Now (Monday) from Canonical:
-
Canonical Kubernetes 1.26 is now generally available
Canonical Kubernetes 1.26 is now generally available for both distributions, Charmed Kubernetes and MicroK8s, following the release of upstream Kubernetes on the 8th of December.We consistently follow the upstream release cadence to provide our users and customers with the latest improvements and fixes, together with security maintenance and enterprise support for Kubernetes on Ubuntu.� This blog is a quick overview of the latest development highlights available in Canonical Kubernetes 1.26 as well as a look at our favourite upstream enhancements.
Some more details a week later:
-
Kubernetes 1.26: Introducing Validating Admission Policies | Kubernetes
In Kubernetes 1.26, the 1st alpha release of validating admission policies is available!
Validating admission policies use the Common Expression Language (CEL) to offer a declarative, in-process alternative to validating admission webhooks.
CEL was first introduced to Kubernetes for the Validation rules for CustomResourceDefinitions. This enhancement expands the use of CEL in Kubernetes to support a far wider range of admission use cases.
Admission webhooks can be burdensome to develop and operate. Webhook developers must implement and maintain a webhook binary to handle admission requests. Also, admission webhooks are complex to operate. Each webhook must be deployed, monitored and have a well defined upgrade and rollback plan. To make matters worse, if a webhook times out or becomes unavailable, the Kubernetes control plane can become unavailable. This enhancement avoids much of this complexity of admission webhooks by embedding CEL expressions into Kubernetes resources instead of calling out to a remote webhook binary.