By making containerized applications dramatically easier to manage at scale, Kubernetes has become a key part of the container revolution. Here’s the latest.Kubernetes 1.22, released August 5, 2022, contains the following new and updated features:
Server-side Apply is now generally available. This previously beta-only feature allows objects on Kubernetes servers to be created and modified declaratively, by having the developer describe their intent. Changes to an object are tracked on a field-by-field basis, so that any attempts to change a field modified and “owned” by someone else will be rejected. Server-side Apply is intended eventually to replace the original kubectl apply function because it provides a simpler mechanism for controllers to make changes to their configurations.
External credential providers, available by way of plug-ins, are now out of beta.
Etcd, the default back-end storage for Kubernetes has been updated to a new release (3.5.0) with bug fixes and new features around log management.
QoS for memory resources is available as a beta feature. The cgroups v2 API can now be used to designate how memory is allocated and isolated for pods, making it easier to deploy multiple applications that might fight each other for memory usage.
Better support for developing and running on Microsoft Windows. Some Kubernetes features for Windows are still alpha—e.g., privileged containers—but it’s now possible to run more of the early-support Kubernetes features on Windows by manually building the Windows kubelet and kube-proxy binaries.
Other changes in Kubernetes 1.22:
Nodes can now run on systems where swap memory is activated if needed. Kubernetes admins used to have to disable swap space before setting up Kubernetes. (Alpha feature.)
Support for default, cluster-wide seccomp profiles is now available. (Alpha.)
kubeadm can now be run as non-root if needed, by running the control plane with lower privileges. (Alpha.) All other Kubernetes node components can be run experimentally as a non-root user as well.
Some APIs have been deprecated and changed, in particular the API for Ephemeral Containers (which was an alpha feature to begin with and did not have a stable API).
Kubernetes 1.20, released in December 2020, introduced these major changes:
The Docker runtime is being deprecated. However, this doesn’t mean Docker images or Dockerfiles don’t work in Kubernetes anymore. It just means Kubernetes will now use its own Container Runtime Interface (CRI) product to execute containers instead of the Docker runtime. For most users this will have no significant impact—e.g., any existing Docker images will work fine. But some issues might result when dealing with runtime resource limits, logging configurations, or how GPUs and other special hardware interact with the runtime (something to note for those using Kubernetes for machine learning). The previous link provides details on how to migrate workloads, if needed, and what issues to be aware of.
Volume snapshot operations are now stable. This allows volume snapshots—images of the state of a storage volume—to be used in production. Kubernetes applications that depend on highly specific state, such as images of database files, will be easier to build and maintain with this feature active.
Kubectl Debug is now in beta, allowing common debug workflows to be conducted from within the kubectl command-line environment.
API Priority and Fairness (APF) is now enabled by default, although still in beta. Incoming requests to kube-apiserver can be sorted by priority levels, so that the administrator can specify which requests should be satisfied most immediately.
Process PID Limiting is now in general availability. This feature ensures that pods cannot exhaust the number of process IDs available on a Linux host, or interfere with other pods by using up too many processes.
Kubernetes 1.17, released in December 2019, introduced the following key new features and revisions:
Volume snapshots, introduced in alpha in Kubernetes 1.12, are now promoted to beta. This feature allows a volume in a cluster to be snapshotted at a given moment in time. Snapshots can be used to provision a new volume with data from the snapshot, or to roll back an existing volume to an earlier snapshotted version. Volume snapshots make it possible to perform elaborate data-versioned or code-versioning operations inside a cluster that weren’t previously possible.
More of the “in-tree” (included by default) storage plug-ins are now being moved to the Container Storage Interface (CSI) infrastructure. This means less direct dependencies on those drivers for the core version of Kubernetes. However, a cluster has to be explicitly updated to support migrating the in-tree storage plug-ins, but a successful migration shouldn’t have any ill effects for a cluster.
The cloud provider labels feature, originally introduced in beta back in Kubernetes 1.2, is now generally available. Nodes and volumes are labeled based on the cloud provider where the Kubernetes cluster runs, as a way to describe to the rest of Kubernetes how those nodes and volumes should be handled (e.g., by the scheduler). If you are using the earlier beta versions of the labels yourself, you should upgrade them to their new counterparts to avoid problems.
Where to download KubernetesYou can download the Kubernetes source code from the releases page of its official GitHub repository. Kubernetes is also available by way of the upgrade process provided by the numerous vendors that supply Kubernetes distributions. What’s new in Kubernetes 1.16Kubernetes 1.16, released in September 2019, contains the following new and revised features:
Custom resource definitions (CRDs), the long-recommended mechanism for extending Kubernetes functionality introduced in Kubernetes 1.7, are now officially a generally available feature. CRDs have already been widely used by third parties. With the move to GA, many optional-but-recommended behaviors are now required by default to keep the APIs stable.
Many changes have been made to how volumes are handled. Chief among them is moving the volume resizing API, found in the Container Storage Interface (CSI), to beta.
Kubeadm now has alpha support for joining Windows worker nodes to an existing cluster. The long-term goal here is to make Windows and Linux nodes both first-class citizens in a cluster, instead of having only a partial set of behaviors for Windows.
CSI plug-in support is now available in alpha for Windows nodes, so those systems can start using the same range of storage plug-ins as Linux nodes.
A new feature, Endpoint Slices, allows for greater scaling of clusters and more flexibility in handling network addresses. Endpoint Slices are now available as an alpha test feature.
The way metrics are handled continues a major overhaul with Kubernetes 1.16. Some metrics are being renamed or deprecated to bring them more in line with Prometheus. The plan is to remove all deprecated metrics by Kubernetes 1.17.
Finally, Kubernetes 1.16 removes a number of deprecated API versions.
What’s new in Kubernetes 1.15Kubernetes 1.15, released in late June 2019, provides the following new features and improvements:
More features (currently in alpha and beta) for Custom Resource Definitions, or CRDs. CRDs in Kubernetes are the foundation of its extensibility technology, allowing Kubernetes instances to be customized without falling out of conformance with upstream Kubernetes standards. The new features include the ability to convert CRDs between versions (something long available for native resources), OpenAPI publishing for CRDs, default values for fields in OpenAPI-validated schemas for CRDs, and more.
Native high availability (HA) in Kubernetes is now in beta. Setting up a cluster for HA still requires planning and forethought, but the long-term goal is to make HA possible without any third-party software.
More plug-ins that manage volumes have been migrated to use the Container Storage Interface (CSI), a consistent way to manage storage for hosted containers. Among the new features introduced in alpha for CSI are volume cloning, so that new persistent volumes can be based on an existing one.
Other changes in Kubernetes 1.15 include:
Certificate management now automatically rotates certificates before expiration.
A new framework for plug-ins that perform scheduling operations has entered alpha.
What’s new in Kubernetes 1.14
Version 1.14 of Kubernetes, released in March 2019, contains the following changes:
Microsoft Windows Server 2019 is now officially supported as a platform for running both Kubernetes worker nodes and container scheduling. This means entire Kubernetes clusters can run on Windows exclusively, rather than having a mix of Windows and Linux systems.
The plugin mechanism for Kubectl, the default Kubernetes command-line tool, is now a stable feature, letting developers implement their own Kubectl subcommands as standalone binaries.
Persistent local volumes are now a stable feature. This lets locally attached storage be used by Kubernetes for persistent volumes. Aside from offering better performance than using network-attached storage, it also makes it easier (and potentially cheaper) to stand up a cluster.
Process ID limiting for Linux hosts is now a beta feature. This prevents any one pod from using up too many process IDs and thus causing resource exhaustion on the host.
What’s new in Kubernetes 1.13
Version 1.13 of Kubernetes was released in December 2018, with the following new and upgraded features:
Kubeadm, a tool designed to make it easier to set up a Kubernetes cluster, is finally available as a fully supported feature. It walks an admin through the basics of setting up nodes for production, joining them to the cluster, and applying best practices along the way. It also provides a way for infrastructure-orchestration tools (Puppet, Chef, Salt, etc.) to automate cluster setup.
The Container Storage Interface, or CSI, is now also available as a supported feature. CSI allows extensions for Kubernetes’s volume layer, so that storage plugins can work with Kubernetes without having to be made part of Kubernetes’s core code.
Kubernetes now uses CoreDNS as its default DNS server. CoreDNS works as a drop-in replacement for other DNS servers, but was built to integrate with Kubernetes by way of plug-ins and integration with Kubernetes features such as Prometheus monitoring metrics.
What’s new in Kubernetes 1.12Released in late September 2018, Kubernetes 1.12 brings to general availability the Kubelet TLS Bootstrap. The Kubelet TLS Bootstrap allows a Kubelet, or the primary agent that runs on every Kubernetes node, to join a TLS-secured cluster automatically, by requesting a TLS client certificate through an API. By automating this process, Kubernetes allows clusters to be configured with higher security by default.Also new in Kubernetes 1.12 is support for Microsoft Azure’s virtual machine scale sets (VMSS), a way to set up a group of VMs that automatically ramp up or down on schedule or to meet demand. Kubernetes’s cluster-autoscaling feature now works with VMSS. Other new features in Kubernetes 1.12:
Snapshot and restore functionality for volumes (alpha).
Custom metrics for pod autoscaling (beta). This allows custom status conditions or other metrics to be used when scaling a pod—for instance, if resources that are specific to a given deployment of Kubernetes need to be tracked as part of the application’s management strategy.
Vertical pod scaling (beta), which allows a pod’s resource limits to be varied across its lifetime, as a way to better manage pods that have a high cost associated with disposing of them. This is a long-standing item on many wish lists for Kubernetes, because it allows for strategies to deal with pods whose behaviors aren’t easy to manage under the current scheduling strategy.
What’s new in Kubernetes 1.11Released in early July 2018, Kubernetes 1.11 adds IPVS, or IP Virtual Server, to provides high-performance cluster load balancing using an in-kernel technology that’s less complex than the iptables system normally used for such things. Eventually, Kubernetes will use IPVS as the default load balancer, but for now it’s opt-in.Custom resource definitions, billed as a way to make custom configuration changes to Kubernetes without breaking its standardizations, may now be versioned to allow for graceful transitions from one set of custom resources to another over time. Also new are ways to define “status” and “scale” subresources, which can integrate with monitoring and high-availability frameworks in a cluster.Other major changes include: