Understanding Kubernetes Versions

Kubernetes is a popular open-source platform for deploying, scaling, and managing containerized applications. To maintain a secure and up to date infrastructure, Kubernetes follows a versioning system for its upgrade strategy. This system is based on Semantic Versioning (SemVer), which is a widely recognized standard for versioning software in a way that conveys meaning about the underlying changes.

Understanding Kubernetes versions is very important for Cloud Architects working with Kubernetes based Cloud-Native infrastructure, whether it is based on private cloud (Red Hat OpenShift, VMware Tanzu, etc) or public cloud (AWS EKS, GCP GKE, and Azure AKS, etc). It helps them plan and implement Kubernetes versions upgrades effectively, ensuring that the infrastructure remains stable and secure. By understanding the meaning behind each version number, Cloud Architects can make informed decisions about when to upgrade the infrastructure and what changes to expect after the upgrade. Let’s look at the types of Kubernetes releases:

Kubernetes Versions

Major Releases:

These are indicated by the first digit in the Kubernetes versions number (e.g., 1.x.x to 2.x.x). Major releases can introduce backward-incompatible changes. This means that the new Kubernetes versions may not work seamlessly with the existing system and applications. It requires careful planning and testing before an upgrade to the production sites. Major releases might introduce fundamental changes to Kubernetes’ architecture, significant improvements, or entirely new features. In Telco Cloud, where the infrastructure solutions are complex, and downtime can have significant consequences, upgrades to major releases are typically handled with extreme caution. They often involve extensive testing and gradual rollouts.

Minor Releases:

Represented by the second digit in the Kubernetes versions number (e.g., 1.1.x and 1.2.x), Minor Releases add new features to Kubernetes while maintaining backward compatibility with the Major Release. These are usually safer to implement than Major upgrades and are usually focused on adding functionality or enhancing existing features. For Cloud infrastructures, these upgrades are very important as they can bring improvements that enhance the efficiency and capability of the network without the risks associated with major Kubernetes versions changes. However, they still require thorough testing, especially in environments where Kubernetes is used to manage critical network functions (CNFs).

Patch Releases:

These are indicated by the third digit in the Kubernetes versions number (e.g., 1.1.1 and 1.1.2) and typically include bug fixes and security patches. Patch releases are important for maintaining the security and stability of the Kubernetes environment. They do not introduce new features but generally focus on correcting existing issues. Given the critical nature of Telco Cloud infrastructure, staying up-to-date with patch releases is non-negotiable. These upgrades are generally considered low-risk and are implemented regularly to ensure the security and reliability of the system.

Kubernetes Release Cadence

Kubernetes project keeps three release branches for its most recent minor releases: 1.n, 1.(n-1), 1.(n-2), where ‘n’ is the latest Minor release (for example, 1.28, 1.27, and 1.26.). Security and maintenance fixes can be added to those three release branches, based on severity and feasibility. Regular patch releases are made from these branches, and urgent releases are released as needed.

According to the yearly support KEP (Kubernetes Enhancement Proposal), the Kubernetes Community provides active patch release series support for approximately 14 months. The standard support period is 12 months. At the end of the 12-month period, Release Managers create a new release, and the patch release series moves into maintenance mode. After a two-month maintenance mode period, the patch release series is then considered EOL (end of life), and cherry picks to the linked branch are closed soon after.

Recent Release History ( 2023 December)

1.28

Latest Release: 1.28.4 (released: 2023-11-14)
End of Life: 2024-10-28
Patch Releases: 1.28.0, 1.28.1, 1.28.2, 1.28.3, 1.28.4
Complete 1.28 Schedule and Changelog

1.27

Latest Release: 1.27.8 (released: 2023-11-14)
End of Life: 2024-06-28
Patch Releases: 1.27.0, 1.27.1, 1.27.2, 1.27.3, 1.27.4, 1.27.5, 1.27.6, 1.27.7, 1.27.8
Complete 1.27 Schedule and Changelog

1.26

Latest Release: 1.26.11 (released: 2023-11-14)
End of Life: 2024-02-28
Patch Releases: 1.26.0, 1.26.1, 1.26.2, 1.26.3, 1.26.4, 1.26.5, 1.26.6, 1.26.7, 1.26.8, 1.26.9, 1.26.10, 1.26.11
Complete 1.26 Schedule and Changelog

What is Version Skew?

Version skew refers to a situation where two or more components or services in a distributed system are running different versions of the same software or have a mismatch in their versions. This can lead to various issues, including compatibility problems and communication failures between these components.

In Kubernetes, Version Skew can also apply to the Kubernetes components themselves. Kubernetes has a defined maximum version skew policy that specifies the maximum allowed difference in versions between various Kubernetes components. The specific maximum version skew may vary depending on the cluster deployment tools used.

Things to be considered before upgrade planning

kube-apiserver: In highly-available (HA) clusters, the newest and oldest kube-apiserver instances should be within one minor version. This means if the newest kube-apiserver is at version 1.28, then other instances must be at version 1.28 or 1.27.

kubelet: It needs to be remembered that the kubelet version must not be newer than the kube-apiserver. kubelet can be a maximum of three minor versions older than kube-apiserver. However, the kubelet versions older than 1.25 can only be up to two minor versions older than kube-apiserver.

kube-proxy: Very similar to kubelet, The kube-proxy must not be newer than the kube-apiserver. The difference between the two must be no more than three minor versions, except for versions older than 1.25. For those versions, the difference can be up to two minor versions.
Kube-proxy can work with kubelet as long as they are no more than three minor versions apart. For versions older than 1.25, the difference should be no more than two minor versions.

kube-controller-manager, kube-scheduler, and cloud-controller-manager: As other Kubernetes components, kube-controller-manager, kube-scheduler, and cloud-controller-manager must not have a newer version than the kube-apiserver version. They can be up to one minor version than kube-apiserver. In the case of HA, up to one miner version of the lowest version of kube-apiserver. For example, if kube-apiservers are running in HA with v1.28 and 1.27, kube-controller-manager, kube-scheduler, and cloud-controller-manager are supported at 1.27.

kubectl: the version of kubectl could be newer than the kube-apiserver version. kubectl version can be up to one minor version newer or older than kube-apiserver. For example, if the kube-apiserver version is 1.28, the kubectl version can be 1.29, 1.28, or 1.27.

Conclusion

In the Telco Cloud, where stability, security, and uptime are at the highest priority, understanding the Kubernetes versions is very important. Upgrading to the latest major release requires careful consideration and planning, while minor and patch upgrades are more routine but still critical for maintaining the operational integrity of the system. Each type of release serves a different purpose, and CSPs must consider the benefits of new features and improvements against the potential risks and challenges of implementing these changes in a complex production environment.

Check out some more blogs:

• OpenShift 101: An Overview of the Red Hat OpenShift
• The ABC of SDN (Software-Defined Networking)
• Deploying AWS Greengrass on VMware vSphere
• VNF Manager vs NFV Orchestrator (VNFM vs NFVO)
• Network Functions Virtualization (NFV)
• What is Hyper-Threading?
• Data Center 101: Choosing The Right One For Your Business
• OpenStack Stein ready for 5G, NFV and MEC