zagandesign - Fotolia
Kubernetes is supposed to make container management easy, but it can be hard to manage and maintain. This is why...
so many options for Kubernetes tooling emerged in the past year. Big cloud vendors now offer Kubernetes services, OpenStack vendors like Mirantis and Red Hat shifted focus to Kubernetes and startups like Heptio formed to solve the Kubernetes management issues.
Many of these tools aim to automate the most common and time-consuming tasks in Kubernetes management. The end goal is to spend less time on management and more time on features, release cycle and performance optimizations.
The challenge of upgrades
With Kubernetes, software teams can automate builds, tests and deployments. It can also help failed nodes restore automatically and provides autoscaling to cope with traffic spikes.
However, software teams need help when it comes to Kubernetes upgrades. Upgrades often involve downtime as teams need to create new nodes, assign permissions for those nodes, move container pods from the old to the new nodes and then delete the old nodes once the process is complete. This can be a tedious, manual process.
Many of the managed Kubernetes services solve the challenge of automated upgrades. CoreOS was one of the first to introduce the automated upgrade feature. Red Hat recently acquired CoreOS for a healthy $250 million. There are many reasons for the acquisition, but the advanced features that CoreOS has developed as part of its flagship product, Tectonic, were a major attractor.
Tectonic, which is now part of Red Hat's OpenShift Container Platform, provides a one-click upgrade for its Kubernetes cluster that creates zero downtime. It deploys in a self-hosted way -- Kubernetes on Kubernetes. It does not require an external installer, and the Kubernetes compiler is built from the host machine's own compiler. Basically, it uses Kubernetes to solve its own management challenges.
This upgrade method uses Kubernetes' high availability (HA) and scaling capabilities. Tectonic also uses Kubernetes' rolling updates feature, which replaces pods one at a time rather than all at once in order to maintain availability. It only switches to the newly upgraded cluster once the right number of pods is replaced.
The underlying open source container OS that Tectonic uses -- formerly called Container Linux -- makes rolling Kubernetes updates possible. Its update operator feature handles upgrades to the system in a seamless manner. As part of the CoreOS acquisition, Red Hat renamed the OS to Red Hat CoreOS. In fact, the company scrapped its own container OS project, called Atomic Host, and will instead rely on this newly acquired OS.
Tectonic sees the Kubernetes system as a combination of three layers: the infrastructure layer, the OS layer and the business application layer. It abstracts complex operations, such as Kubernetes upgrades, to the infrastructure and OS layer in order to enable HA and scalability for the business application layer.
Kubernetes supports this approach, but many vendors have yet to adopt it. CoreOS had the early mover advantage and positioned itself as a front-runner in the managed Kubernetes tooling space prior to its acquisition.
Many other Kubernetes tooling vendors follow CoreOS' example. Azure and AWS now offer platforms that support automated Kubernetes upgrades. Google Cloud also added an automatic update feature in early 2017.
Google Cloud Platform also incorporates Pod Disruption Budgets (PDBs). In Kubernetes, pods run until they are manually disrupted by a user or stopped by a system process. A PDB is a Kubernetes feature that ensures a minimum number of pods continue to run in the case of a voluntary disruption. This is essential to maintain HA during upgrades. This process is too intricate to perform manually. Kubernetes' strength is that it enables tools like Tectonic to automate these operations.