Kubernetes: A Brief History
Kubernetes evolved from the Borg System, which was created by Google in 2003. Borg was an internal cluster management system. It was briefly replaced by the Omega cluster management system in 2013, and then finally by k8s in 2014.
In 2015, Kubernetes v1.0 was released and project ownership was handed to the Cloud Native Computing Foundation (CNCF). The CNCF holds k8s under the unpatentable Apache License 2.0. This license ensures that the platform remains open-source.
New minor versions of Kubernetes are released roughly every three months. There are also patch releases that do not follow a predetermined schedule. Version releases follow a numbering scheme of 1.X. Patch releases follow a numbering scheme of 1.X.Y.
There is currently no criteria for a 2.X release. There is also no Long Term Support (LTS) version of Kubernetes. Only the most recent three minor releases receive support. This means that, at most, you can defer upgrading for roughly nine months before your version is deprecated.
Kubernetes is currently in version 1.16, released in September 2019. The most notable changes to v1.16 include:
- Custom resources and admission webhooks features are now standard
- Overhauled metrics are more transparent and now fall under stability requirements
- Volume extension enhancements were added, including resizing support in Container Storage Interface (CSI) spec plugins
- Topology Manager, a new Kubelet component, was added to enable coordination of resource assignment decisions
- You can now use both IPv4 and IPv6 addresses with Pods and Services
How to Manage Updates
Updating requires time and effort but it is necessary to ensure cluster security and functioning. Vulnerability patches and improved features can only be obtained through updates. How you manage updates depends on how your clusters are hosted.
Managed Cloud Services
If you are using managed cloud services, like GKE, AKS, or EKS, you handle updating through the provider. Some providers automatically push updates and perform the process for you. Others require you to initiate the process. Each provider has a specific process for updating that you can find in the provider documentation.
Managed services can simplify the process of updating since you aren’t required to manually roll-out the updates yourself. However, managed services also put you at the mercy of the provider. You must rely on them to make compatible updates available and uphold service level agreements for availability.
Manually Upgrading Your Clusters
Self-hosting, or hosting in the cloud without using a managed service, requires you to perform upgrades manually. To upgrade manually, you need to adjust your Kubernetes cluster and possibly your etcd cluster. Your etcd cluster is the cluster used to control and direct your deployment.
You can perform incremental upgrades on live clusters or you can transfer workloads from old clusters to newly created ones with the updated version. When performing upgrades, make sure to follow the upgrade path.
Skipping versions can lead to serious issues and is not recommended. You also need to be aware of any breaking changes before proceeding. These changes are typically highlighted in the version release notes.
Before performing any upgrades to etcd, be sure to take a snapshot for backup purposes. You should also check that your cluster is healthy to ensure minimal downtime. Check out this tutorial for a step-by-step on how to upgrade Kubernetes.
Another option, for internal-facing clusters, is to defer maintenance. Internal clusters don’t face the same threats as external clusters, so theoretically are at less risk if out-of-date. This option is generally not recommended as it is unlikely that you won’t need to upgrade at a future date. When that time comes, the older your version is, the longer the update process takes. You’re also more likely to have to manage breaking changes.
Despite this downside, deferral can be a good short term option. For example, if you are planning to move to a managed platform or restructure your deployment in the near future. In these cases, deferring updates can help you condense downtime and avoid unnecessary effort.
If you do choose this option, restrict it to internal-facing clusters, those without external network access. Internal clusters don’t face the same threats as external clusters, so theoretically are at less risk if out-of-date.
How to Manage Features
When new versions of k8s are released, you need to carefully look at what feature changes were made. You also need to pay attention to API changes. These changes dictate feature capabilities and how you access features.
If you ignore feature changes, you can lose access to functionality you’re currently using before you implement an alternative. You can also unknowingly introduce unintended functionality into your system, which can be misused by attackers.
Features in Kubernetes fall into one of three categories:
- Alpha features—disabled by default as they may contain bugs. Support for these features can be dropped at any time.
- Beta features—enabled by default. Support for these features is guaranteed but it is not recommended to use them for business-critical uses.
- General Availability (GA)—features cannot be disabled. These features are stable and unlikely to change.
You can control which alpha and beta features are active using feature gates, which enables you to activate or deactivate features. When features are moved to GA, feature gates are deprecated or removed.
Managing Kubernetes can be a challenge and updating your clusters can be one of the most difficult aspects. If you are unsure how to interpret or implement the information that is in the version notes, pause before updating.
The Kubernetes community is a good source for clarification. They can help you identify how version changes can affect you and highlight best practices. When it comes time to upgrade, work methodically and make sure to test changes before applying. With patience and a little effort, you can update your clusters with minimum downtime.