In this era of technical challenges and frequent Kubernetes cluster upgrades, my biggest concern as a member of the maintenance team was that the upgrade might cause the server to crash. We've found that it's not uncommon for Kubernetes to update too fast and enterprises to keep up. Restrictions such as customer contracts, regulatory, and technical risk policies have put enterprises in an insurmountable pace of upgrading. In the past, developers reported that the GKE upgrade solution caused service interruptions for weeks and was extremely difficult to maintain, which was a headache for us.
How hard is it really to keep up with the pace of releases?
Kubernetes follows an "N-2" support policy and a 15-week release cycle, which is almost a shackle compared to the Debian support cycle that is common in enterprises. Businesses struggle to follow such an urgent time window, and stability is considered more important than upgrades, making it difficult for companies to keep up with the pace of K8s releases.
Upgrading a K8s cluster is a more difficult task than building a new one. Upgrading involves multiple steps, and automation inevitably requires skill. While it's easier to create a new cluster, it involves a lot of duplication and wasted resources for our team.
The cluster seems to be lagging behind, and we are stuck in a dilemma where it is difficult to decide on the right course of action.
Is there a safer way to navigate this quagmire of upgrades? Why doesn't Kubernetes launch an LTS release? The question seems to challenge the general perception of the entire industry. The LTS version is proposed in the hope of providing a stable foundation that users can use for a long time without frequent upgrades.
However, we can't expect too much from the LTS release. While it brings the benefits of a stable foundation and reduced frequent upgrades, it can also lead to a number of problems, such as the complexity and cost of backporting security fixes.
At this point, a compromise seems to be an option worth considering.
Our offer to leave LTS to K8s distributors is perhaps a compromise. Commercial products may offer longer support periods, while Kubernetes is primarily focused on innovation and growth. This allows for a better balance between stability and update speed.
Overall, Kubernetes is widely used in the container space, but the problem of frequent version upgrades does need to be addressed. Different opinions exist, including whether or not to offer an LTS version.
Some argue that K8s is a complex collection of software that makes it difficult to test as-is, while others worry that LTS will add complexity to backporting security fixes and lead to high costs. Personally, I think that perhaps LTS should be left to distributors, commercial products can provide longer-term support, and Kubernetes can be more focused on innovation and growth.
In this era of technological challenges, we need to strike a balance between stability and innovation to keep technology moving forward. Perhaps, this is what we are pursuing on the road to Kubernetes upgrades.