Everyone is talking about Kubernetes, the orchestration tool that is becoming an increasingly important part of container deployments (even though data suggests that Kubernetes still trails Docker Swarm in market share). In the midst of all the excitement about Kubernetes, it can be easy to lose track of what Kubernetes actually does and doesn't do. Read on to get the most out of what Kubernetes can do--and ensure you don't assume it is going to handle a task that it can't support.
Let's start by discussing what Kubernetes was actually designed to do and is good at doing: orchestrating containers.
What Kubernetes Doesn't Do
Orchestration is a fancy way of saying that Kubernetes automates many of the processes required to run containerized applications. Specifically, Kubernetes automatically does the following:
- Distributes containers across multiple host servers (called nodes, in Kubernetes-speak), without requiring human admins to manage which containers are running on which servers at which time.
- Allocates compute, memory and other resources to containerized workloads in a way that keeps the workloads available without wastefully assigning more resources to them than they need at a given time.
- Manages IP addresses and network mappings so that containers and workloads can communicate with each other.
You'll notice that that's a relatively short list, which brings us to ...
What Kubernetes Doesn't Do
While Kubernetes is great at performing the core functions described above, there are many other parts of a container-based application stack that Kubernetes does not support or supports only to a limited extent.
- Container runtime
A container runtime is a program that executes containers. Kubernetes doesn't do this; it simply manages the containers once they are running.
Kubernetes supports a range of container runtimes. Docker's is the most popular, but by no means the only one.
(For the sake of clarity, let me mention that you sometimes hear folks talk about "Docker vs. Kubernetes." You might think they're implying that Kubernetes is an alternative to the Docker runtime, but what they're actually talking about are the differences between Kubernetes and Docker Swarm. Swarm is a container orchestrator that was created by Docker; it's not a container runtime, and talk about "Kubernetes vs. Docker" is deeply misleading for this reason.)
- Containerizing applications
If you want to run an application using Kubernetes, you typically have to "containerize" it first. Containerization means packaging the application in such a way that it can be deployed inside a container (or a set of containers).
Kubernetes doesn't do this for you. You have to package the application into containers yourself, then give Kubernetes the container images you've built so that it can deploy them.
- Container image management
Speaking of container images, Kubernetes also does not automate storage or management of the images themselves. That's something that you need a container registry to do.
Kubernetes natively integrates with several third-party registries, but Kubernetes itself does not function as a registry.
- Infrastructure provisioning
For Kubernetes to do anything, you need to give it servers to manage. Kubernetes doesn't set up or manage those servers itself; it only manages the workloads that run on top of them. Nor can Kubernetes magically generate more server resources in the event that the servers you are using are maxed out.
- Security
It wouldn't be right to say that Kubernetes does nothing on the security front. Kubernetes supports role-based access control. It also offers pod security policies, which help to mitigate unauthorized access to resources in a Kubernetes environment.
But these protections cover only a fraction of the security risks that could appear in a containerized environment. Kubernetes can't detect malware inside container images or alert you to anomalous behavior within a Kubernetes environment that could signal a breach. You need external tools to achieve these tasks.
Conclusion
The bottom line is that Kubernetes does one thing well: It orchestrates containers. However, it relies on other tools and processes to provide the infrastructure that hosts those containers, the runtime that executes them, the container registry that stores their images and the security tools that help keep them safe from intruders.
