Kubernetes is one of the hottest topics in IT. It is in every conversation that involves containerization or cloud-native development where any level of scale beyond a single instance is needed.
Yet for all this hype, there seems to be a misunderstanding of what Kubernetes is, and — most importantly — what it cannot do on its own. That’s a problem, because Kubernetes itself has a pretty narrow and specific scope of functionality. If you adopt the thinking that it’s going to solve problems that it was not designed to solve, you’ll learn the hard way that, despite all the buzz around Kubernetes, it doesn’t solve every container-related problem you can imagine.
With that risk in mind, let’s take a look at what Kubernetes does, and what it doesn’t do.
Kubernetes only does what?
Kubernetes is an orchestration engine and management framework. Orchestration simply means that Kubernetes will manage running containers based on their specifications across all the compute nodes it controls. Pure Kubernetes has no idea what the containers it manages do, and really does not care. If you want 10 copies of NGINX running, then Kubernetes will keep 10 running; if one dies, it will restart it. If a node dies, Kubernetes will restart the affected containers across the remaining nodes in its cluster based on capacity.
Beyond the orchestration, Kubernetes has been built with the idea that it is the core of a container’s ecosystem, so it has been architected to act as a management framework. This extensibility gives Kubernetes the ability to work with other technologies to create a full ecosystem that can support real production workloads, in even the most regulated environments.
To put it simply, Kubernetes is a blunt instrument. All the nuance that makes up container-based development and deployment is done around Kubernetes to let it do what it does so well.
Container runtime engine
Just to give an idea of how minimal Kubernetes is out of the box, Kubernetes does not ship with an engine that actually runs the containers on each host in its cluster. Instead, Kubernetes supports multiple runtimes that can do this job, like containerd (which Docker open-sourced); the Kubernetes-specific CRI-O implementation, and even Microsoft Windows containers. There is even a project called Kubevirt which allows Kubernetes to run full virtual machines under its control.
Networking beyond basic routing
Kubernetes out of the box supports a basic network structure that assigns an IP to each pod and can route traffic within its cluster between any two pods, and in and out of the cluster through exposed services at an egress/ingress point.
By complying with the AppC CNI plugin specification, Kubernetes has support for multiple open source projects and commercial vendors that offer networking solutions which go beyond the basic implementation of the Kubernetes networking model. A list of some of the projects can be found in the documentation, and a larger list of vendors can be found in the CNCF Interactive Landscape in the Cloud Networking group.
Depending on the environment, some of the features that can be found in these plugins are:
- Network policies to allow fine-grained access control lists at the individual pod level.
- Multi-tenant network support to segment at the namespace level
- Full overlay networks that use BGP to interact with networks outside the container infrastructure.
Monitoring
Kubernetes does include health checks that can be performed on individual containers and pods. Monitoring provides much, much more than simple health checks and is a vital part of any infrastructure or application platform that will be used beyond supporting development.
One of the most common open source products used to provide monitoring is Prometheus, with some assistance from Grafana to provide easy-to-read graphs and analytics for the data that is being collected.
There are many more extensive monitoring products available (which are often commercial and rarely cheap), but enterprises will often include them. The most common type of monitoring from this category falls under the Application Performance Management (APM) banner. Those that are compatible with Kubernetes can also be found on the CNCF Landscape in the Monitoring category.
Logging
Each component of Kubernetes can produce its own log, and containers also produce logs, which are destroyed when the container is restarted. Kubernetes supports exporting logs at multiple levels, the highest being at the cluster level which will export all the logs from all the sub-systems.
The ELK stack (ElasticSearch, LogStash, and Kibana) is the mostly commonly used open source based solution used to store the logs in for later analysis.
As with most complementary tools, the CNCF uses its Landscape tool to track compatible solutions in the Logging category.
Authentication and Authorization Management
In the last few recent releases, Kubernetes has integrated more and more functionality around authentication and authorization, including RBAC, as enterprises see it as a core requirement and not a nice-to-have feature. While this is a solid step forward, it still has a ways to go to support the now nearly ubiquitous feature of two-factor authentication, or even integration with external directory services like Active Directory, which don’t fully support OpenID. Active Directory is almost a guaranteed checkbox in most enterprises for adoption, and third-party libraries are needed for it to be used as a backend LDAP server for Kubernetes.
Conclusion
While the industry is focused on using Kubernetes as a kind of buzzword to suggest enterprise-grade container management, by itself, it falls far short of the needs of the average organization that wants to roll out containers. This is especially true in the world of large and regulated enterprise IT environments that have strict requirements around management and auditing to comply with. The effort required to integrate all these solutions onto the base Kubernetes installation, regardless of whether from a public cloud or locally installed, can be a substantial undertaking.
The recommended approach for most organizations is to evaluate and select an enterprise-friendly “Kubernetes distribution” that solves many of these integration issues to provide a full container ecosystem to support running bespoke applications in production.
