Open-source container management and orchestration tool Kubernetes has just released version 1.20 on 8 December 2020 with much fanfare from the developer community.
A few months ago, we covered a refresher on Kubernetes, its importance in deploying and scaling applications and our predictions for what is in store for this tool. Weeks after that post, v1.19 was released on 26 August.
The last release for 2020 was dropped early December and has been termed ‘The Raddest.’ It saw the Kubernetes support window increased to 12 months from 9 months, the reimplementation of the IPv4/IPv6 dual-stack, the enhancement of the Topology Manager and EndpointSlices API among other major changes, and the ‘drama’ that surrounds the deprecation of Dockershim/Docker.
Today we speak to Zek Chak, our Lead Solutions Architect at our Singapore office about his take on this release.
How will the latest Kubernetes version 1.20 release impact existing developers?
I think the extension of the support window itself is significant, as now it covers a whole year which is more aligned with how most digital teams organise their planning cycle. However, that might have been eclipsed by the Docker deprecation drama.
Many developers would have been alarmed to read headlines saying that Docker runtime support would be removed from Kubernetes. Docker, after all, is still the way most developers package and ship their applications, if they’re deploying to Kubernetes or any other container orchestration service.
However, contrary to popular opinion, Docker and containers are not the same thing! Docker builds container images that comply with the OCI specification, and there are alternatives that can run those images.
The good news is this: this change is only for the container runtime used by Kubectl, which means it doesn’t affect most developers.
Images built by Docker will continue to work on Kubernetes because those images are still compliant with OCI, and Containerd is able to work with them. So, for end-users of Kubernetes, there’s really nothing to worry about.
This does affect Kubernetes administrators, however. If you’re using a managed Kubernetes service such as AWS EKS, it should be as easy as replacing nodes in the cluster with the new AMI. Those with custom node customisations will have to update them based on their requirements, and I’m sure AWS and other cloud providers will provide the guidance for this in the near future.
For Kubernetes administrators who manage their own clusters, the task is to switch from Docker to Containerd or CRI-O, and to ensure the replacement runtime supports the Docker Daemon configurations you currently use.
Zooming out to the bigger picture, I believe this evolution of the Kubernetes project is healthy for its future growth because it removes Dockershim from the list of things the team needs to maintain. Is it bad for the future of Docker? Not necessarily. For the foreseeable future, Docker will still be a very popular way to build OCI images.
Moving forward with v1.20, how can developers deploy on Kubernetes?
One thing about this release highlights is the benefit of using a managed Kubernetes service.
Taking AWS as an example – when the changes are rolled out, the AMIs will first be well tested and updated by AWS, and all the administrator needs to do would be to replace the nodes with the new AMI.
However, for those rolling their own clusters, it’s very likely that the process of testing to an equivalent level of confidence and the subsequent roll-out of changes would take significantly more time. Engaging with a managed Kubernetes service helps to take away the time and resources needed to create, connect and secure new clusters.
If you’re reading this, you’re likely either using Kubernetes or considering using it. Kubernetes has continued to change cloud computing since it went open-source 5 years ago and we look forward to the exciting things the next release will bring.
The takeaways
- Extended Kubernetes Support Window from 9 months to 12 months
- Nothing much to worry about dockershim/Docker deprecation, change is only for the container runtime used by kubectl
- Images built by Docker will continue to work on Kubernetes
- Time to switch from Docker to containerd or CRI-O if you’re a Kubernetes administrator
- A managed Kubernetes service provider would ensure your Kubernetes environment is always healthy and up-to-date
We’ve carried out complex Kubernetes projects for many clients (check out our work for Sydney Coliseum) and, as a cloud-native MSP, we’re always on the forefront of innovation.
If you’ve any questions, you can reach us here.
