Why Kubernetes Works for Infrastructure Abstraction
KubeCon + CloudNativeCon sponsored this post, in anticipation of KubeCon + CloudNativeCon NA, Nov. 18-21 in San Diego.
Kublr’s CEO Slava Koltovich and CTO Oleg Chunikhin are certainly well-placed to discuss the role of Kubernetes, both as a container orchestrator, its role in operations management and what the future may hold. Also among the main topics of this Q&A, Koltovich and Chunikhin explore each other’s areas of expertise about Kubernetes and how Kublr helps automate the platform’s management.
Kubernetes: Beyond Container Orchestration
Koltovich: You’ve said that the industry needs to shift from seeing Kubernetes purely as a container orchestrator to leveraging it as an infrastructure abstraction layer. But what does that mean?
Chunikhin: Yes, Kubernetes is a container orchestrator, but it can do a lot more than that. Inherently infrastructure agnostic, you can use Kubernetes to abstract the infrastructure away from higher-level services and applications. Not only does this make your apps a lot more portable, but it also adds flexibility and builds a much-needed, future-ready architecture.
Koltovich: How does that impact daily operations?
Chunikhin: You want to enable teams to focus on what they do best and abstracting at an infrastructure level does make it a lot easier. Ops teams can provide developers with a platform to run their stacks and apps on in an infrastructure-independent manner while still fine-tuning infrastructures based on their department’s requirements. Dev teams, on the other hand, can focus on writing software while still retaining a lot of control over how infrastructure is set up.
Resource abstractions and a pluggable architecture give you a very flexible framework that can be plugged into any infrastructure. Operator frameworks allow you to encapsulate knowledge and experience that pertain to managing specific components of your applications and middleware. They do this by automating a lot of operational tasks, which comes especially handy when it relates to the management of data storage systems. This also makes it feasible for smaller organizations to use hosted storage.
Koltovich: How does this affect future-readiness?
Chunikhin: Architecture will ultimately determine the longevity of any solution. The more flexible and pluggable, the more likely it’ll be able to adapt to market demands. Keeping the container orchestration layer separate from the middleware and cloud-native or managed services ensures that your system architecture stays modular and open. As soon as you start tying layers together, you compromise flexibility. Beware of opinionated open-source, a new type of technology becoming increasingly prevalent, which negates one of the core benefits of open source!
In short, the same good old architecture best practice of a clear separation of layers apply here just as they did a decade ago. The difference is that Kubernetes brings it all to a whole new level — it would be foolish not to take advantage of its power.
Self-Healing Does Not Equal Self-Healing
Chunikhin: You’ve highlighted before that there seems to be some confusion around Kubernetes and self-healing, how so?
Koltovich: You hear a lot about self-healing and Kubernetes. Yet there are multiple layers to it and to ensure truly self-healing apps, you need to hit all of them.
Kubernetes’ self-healing ability only applies to pods. If a pod goes down, Kubernetes will restart a new one. However, if an entire node goes down, Kubernetes generally isn’t able to spin a new one up. From a self-healing point of view, that means infrastructure could turn into the weakest link in the chain, jeopardizing the reliability of your applications — your clusters are only as reliable as the underlying infrastructure.
Chunikhin: Which are these self-healing layers?
Koltovich: To ensure application reliability, you’ll need (1) a self-healing infrastructure which includes worker and master nodes; (2) self-healing clusters achieved through self-healing masters (not necessarily workers); (3) self-healing pods; and (4) self-healing Kubernetes which, while contingent on a self-healing infrastructure, requires specific configuration.
Additionally, a self-healing infrastructure does not guarantee self-healing Kubernetes. The infrastructure must be provisioned for Kubernetes before it can install, configure and connect a component to create a cluster. This is basically what Kelsey Hightower described in his Kubernetes the hard way tutorial. Some of the complexity deals with automating infrastructure provisioning. Since Kubernetes doesn’t do it, it’s either left to you or your provider. But beware, infrastructure provisioning is not yet a standard feature (though we strongly believe it should be).
Chunikhin: Why is infrastructure provisioning so important?
Koltovich: If the platform doesn’t provision the infrastructure, it cannot ensure the infrastructure was set up and initialized correctly. Who or what will guarantee that the right packages and versions of the operating system and software components are installed on the nodes? Those things really matter as your Kubernetes cluster will only be as reliable as the infrastructure it runs on. That’s why Kublr provisions infrastructure automatically. This approach automates the process whenever possible leveraging native infrastructure automation tools such as AWS’ Cloud Formation or VMware’s vSphere.
Chunikhin: What are the implications of not having a self-healing infrastructure?
Koltovich: If you don’t have a self-healing infrastructure and a node goes down, you are facing potential downtime of minutes, possibly even hours; all depending on how quickly your Ops team reacts to the incident. That’s why infrastructure provisioning is so critical, allowing for the setup of self-healing nodes whenever the infrastructure allows. For customer-facing and mission-critical apps, node self-healing and solid infrastructure provisioning are critical. If the platform doesn’t provide that, application performance can’t possibly be guaranteed.
Chunikhin: So why isn’t this an industry standard?
Koltovich: Good questions. We believe it should be — it’s just too important. While many vendors assume Kubernetes has been already installed, we aim at eliminating any constraints and providing reliable, fully self-healing production-grade cluster deployment. Ultimately, it will likely become an industry standard as users will start demanding it when they run into some of the above-mentioned issues.
Feature image by from Pixabay.