Balance innovation and agility with security and compliance
risks using a 3-step process across all cloud infrastructure.
Step up business agility without compromising
security or compliance
Everything you need to become a Kubernetes expert.
Always for free!
Everything you need to know about Magalix
culture and much more
The latest release boasts 43 enhancements (up from 34 in version 1.D19), including 15 that are entirely new, 11 graduating to Stable, and 17 improvements on existing features.
This suggests that these enhancements are smaller in scope. For example, some changes were made to kube-apiserver to make it more user-friendly and perform better in HA clusters. It also reboots more efficiently after an upgrade.
These small improvements and new features pave the way for the significant changes that lie ahead. However, one major change (although long expected) was already made to the latest release.
Starting with version 1.20, Kubernetes will deprecate Docker as a container runtime in favor of the Container Runtime Interface (CRI).
But don't panic!
This doesn't mean that Docker is dead. You don't have to abandon the containerization tool. For the end-user of Kubernetes, not much will change as you can still build containers using Docker. The images produced will also continue to run in a Kubernetes cluster.
However, Kubernetes plans to remove Docker Engine support in the kubelet and dockershim in a future release, most likely late next year. But you can continue to use it by swapping a built-in dockershim to an external one.
Docker and Mirantis also agreed to partner and maintain the shim code outside Kubernetes as a conformant CRI interface for Docker Engine. This ensures that it passes all the conformance tests and works seamlessly like the previous built-in version.
To maintain excellent developer experiences, Docker plans to continue to ship this shim into Docker Desktop, while Mirantis will leverage this in the Mirantis Kubernetes Engine. Further, net/net support for your container images built with Docker tools won't be deprecated and will work as before.
Docker, although a leading container solution, wasn't developed to be embedded inside Kubernetes. It's more than a container runtime as it's equipped with multiple UX enhancements that enable developers to interact with it seamlessly.
Docker is a complete tech stack (and not just a containerization platform). But it does provide high-level container runtime called "containerd," and this will be your container runtime option from now on.
These updates and enhancements aren't necessarily focused on Kubernetes. Instead, they're designed to work around obstacles to allow developers to get the most out of it. For example, at present, the Kubernetes cluster requires a tool called Dockershim, which is containerd. It's used to add a level of complexity to another tool that the team must maintain. However, it's a source that often produces bugs and other problems. So, the Kubernetes Project plans to remove Dockershim in version 1.23 and terminate Docker support.
This means that the issue just boils down to swapping Docker for CRI runtimes. But for now, Docker development remains the same without any noticeable differences. Images built-in Docker aren't Docker-specific and are Open Container Initiative (OCI) images.
The OCI was setup by Docker in 2015 to support interoperable container standards (to ensure that containers can run in any environment). Over the last five years, it has proved to be a huge hit promoting innovation while maintaining interoperability. To pull and work with these images, leverage containerd or CRI-O.
CronJobs was introduced in version 1.4 and had CRI support from version 1.5. However, although widely used, neither was considered stable. So, it's good to see features developers depend on to run production clusters aren't considered alphas anymore.
This update improves security considerably by enhancing the authentication and the handling of tokens. Now you can access volumes that demand authentication (including secret vaults) more securely. It's also much easier (now) to set up and deploy.
More metrics are now available to better plan the capacity of the cluster. It also helps the troubleshooting process when encountering eviction problems.
While it's a small feature, it makes the developer's life so much easier. By properly releasing resources as nodes shut down, you can now avoid odd behaviors.
Unique identifiers for each kube-apiserver instance often goes unnoticed. But it's essential as knowing it will help ensure high availability features in future Kubernetes releases.
Kubernetes system vulnerabilities recently came to light, especially credentials leaked into the log output. Keeping the bigger picture in mind, you can now identify the leaks' potential sources and place a redacting mechanism to eliminate those leaks.
Feature group: cluster-lifecycle
The node-role.kubernetes.io/master is now called the node-role.kubernetes.io/control-plane.
Stage: Graduating to Beta
Feature group: api-machinery
The SelfLink field in every Kubernetes object contains a URL representing the given object but doesn't offer any new information. At the same time, its creation and maintenance impacts performance.
Kubernetes 1.16 was the beginning of the deprecation process. From now on, the feature gate is disabled by default and scheduled for removal in Kubernetes 1.21.
Feature group: node
Marked for deprecation in version 1.18, both StreamingProxyRedirects and the --redirect-container-streaming flag won't be enabled. It will also be disabled by default in version 1.22 and entirely removed in version 1.24.
As you can see from the above, Kubernetes developers and administrators don't have anything to worry about. It's essentially business as usual when they leverage docker commands and kubectl commands to manage Kubernetes clusters.
However, as significant changes to the way we work with containers are still some releases away, it'll be wise to keep an eye on our blog for future updates.
At Magalix, we're all about Kubernetes. If you need help working securely and efficiently with containers.
Self-service developer platform is all about creating a frictionless development process, boosting developer velocity, and increasing developer autonomy. Learn more about self-service platforms and why it’s important.
More and more businesses are adopting GitOps. Learn about the 5 reasons why GitOps is important for businesses.