Image credit: turbosquid
I know there are a lot of these out there, but I’m going to add yet another to the pile — a Kubernetes for dummies piece!
Before I begin, I want to point out that there are some really excellent treatments of this topic out there and you might be better served checking those out:
- “The Illustrated Children’s Guide to Kubernetes”: https://www.cncf.io/the-childrens-illustrated-guide-to-kubernetes/
- Organization-formerly-known-as-CoreOS’s “What is Kubernetes? An Intro for Beginners”: https://coreos.com/blog/what-is-kubernetes.html
- Kubernetes.io website: https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/
Still here?
History
I like starting with history lessons. Where did an idea come from? Why? Who should we blame for it?
Let’s rewind to before Kubernetes was around. In the beginning there was metal. Physical servers. In many cases these servers were running an application each, which became prohibitively expensive as application footprints grew.
Then came virtualization. Virtualization helped make infrastructure a lot more efficient by allowing multiple applications to run on a single server. Same apps as before, but now packed on physical servers with friends. A virtualized application stack looked much the same as before, but with the insertion of a hypervisor layer.
Then came a shift both on the infrastructure and application layer — containers. Containers are lightweight constructs that have filesystem and resources, but share some OS components with other containers. They encapsulate not just an application but those parts of the environment that are needed for the application to run. This means that they have lighter footprints and are fundamentally more portable between environments, a huge benefit. Also, containers are immutable, meaning that operations can be dramatically simplified as you do away with incremental change management on images that you deploy.
Container technology was also a key enabler for microservice based application architectures. Developers could more easily decouple their application components, increasing overall velocity of their efforts.
Great — now you have these more efficient and compact portable units running around. And there might be a lot of them if you embraced microservices. So… how do you manage them?
That’s where Kubernetes came in. Kubernetes was announced in 2014 by Google and v1.0 was released approximately a year later. Based on Google’s Borg system, Kubernetes is a technology to manage lots of containers.
Kubernetes — tell me more
To understand how Kubernetes works the single best thing to do, in my opinion, is just get a handle on the vocabulary.
- Clusters: these are a set of machines (or nodes) that run applications. Clusters have at least one worker node and one master node.
- Containers: we already discussed this briefly but we can summarize a container by saying it is an encapsulation of an application and its environment.
- Pods: these are a collection of containers that are tightly coupled. An overlay network connects the pod to the environment it should be running in.
- Master nodes manage worker nodes and pods.
- Worker nodes host application pods.
- Deployments and Replica Sets: these are a way of managing lots of pods. They replicate pods and manage their lifecycles, from deployment to scaling (both up or down), and ensure that a specific number of pods is always available.
- StatefulSets: these are similar to deployments but focused on applications that need persistence, whether in storage, stable network IDs, etc. Like deployments, StatefulSets manage deployment and scaling of pods, but also manages uniqueness and ordering of those pods that are spun up.
- Services and service discovery: Applications provide services. A service registry captures what the services are that are offered by the application in the environment.
- Namespaces: these provide an isolation mechanism within a cluster. Namespaces are groups that include pods, replication controllers, volumes, and services.
Kubernetes provides a means by which to automate the deployment, management, and autoscaling of application containers across infrastructure. It is declarative by nature, meaning that you describe what you want to have happen in your container deployment and Kubernetes makes it happen, reconciling state when it deviates from your stated intention. As an example, if a container crashes then Kubernetes would just spin up a new one and figures out where to put it. It strips out the distributed computing tools from PaaS and brings it to the infrastructure directly.
In addition to managing the application from the compute side, Kubernetes also handles the plumbing within the infrastructure. Kubernetes handles getting pods IP addresses and DNS names, manages load balancing between them, and handles service discovery and plumbing.
There is a lot more to Kubernetes, but this should provide at least a little foundation for understanding what Kubernetes is. If you need to learn more than spend some time on kubernetes.io. It’ll be time well spent.