What is Kubernates and why do we care about it? It starts with containers, says Hossam Barakat (@hossambarakat_).
We used to run multiple applications directly on the host server. Then we started using virtual machines for isolation. Containers allow us to further isolate the application and its dependencies on the host server(s).
Containers illustration from Hossam Barakat’s “Kubernetes for Developers” presentation.
We can run more containers on the same host with less overhead from the guest OS that comes with virtual machines.
Scaling With Growth
Kubernetes helps to automate deploying, scaling, and managing many containers. It’s not needed for a few containers. But it’s the most popular container orchestration system. Kubernetes is architected as shown in this diagram.
Kubernetes architecture from Hossam Barakat’s “Kubernetes for Developers” presentation.
As you can see, Kubernetes is made up of several components.
An application lives in a pod. To scale an application, we simply scale the pod. Pods are declared using a YAML doc and deployed using the CLI command: kubectl.
Pod example from Hossam Barakat’s “Kubernetes for Developers” presentation.
This pod definition is relatively simple. It contains a single container definition. The entire application can consist of several container definitions with more complex parameters than what you see here.
Pods are contained within replica sets for stability. If a pod is unhealthy, other pods in the replica set keep the application alive. Replica sets are also declared using YAML. A deployed replica set looks like the following:
Representation of the Kubernetes dashboard from Hossam Barakat’s “Kubernetes for Developers” presentation.
Kubernetes assures that there will be three pods in the replica set shown above. You can easily scale the replica set up and down by changing the desired number of pods.
A deployment contains one or many replica sets. The replica sets are versioned. It’s this versioning that allows us to do rolling deployments and easy rollbacks. Deployments are defined in, you guessed it, YAML documents! And the deployment defines how you will roll out the new version of your application.
It takes a bit of a shift in your mental model. Releasing an application is a bit different using Kubernetes. There’s no need to take the application offline. But it takes some planning to design the application changes in order to use this capability.
A service connects pods using labels. This is important because pods are ephemeral, meaning that they might go away at any time. And when they do, the new pod that will replace it won’t have the same IP address. So we can’t connect pods using IP addresses. This is the importance of using a service!
Illustration of service from Hossam Barakat’s “Kubernetes for Developers” presentation.
A service with a static IP and DNS sits between each pod layer.
Volumes are persistent storage devices that live beyond the life of a container. They can be used for the persistence of databases and other types of files that should live longer than any given pod. These volumes can be detached from one pod and mounted to another pod. Should the original pod go down, the volume can just be moved to the new one. This is how the data stored in volumes outlives any given pod or container.
Getting Started in the Cloud
There are several components to install and manage. If you start with a managed Kubernetes service, you won’t have to spend the extra effort creating your own from scratch. Azure, GCP, and AWS each offer managed Kubernetes services, as do several other cloud providers.
Whether you’re outgrowing your existing container environment or just curious, it’s definitely worth checking out Kubernetes!
This post was written by Phil Vuollet. Phil uses software to automate processes to improve efficiency and repeatability. He writes about topics relevant to technology and business, occasionally gives talks on the same topics, and is a family man who enjoys playing soccer and board games with his children.
Photo by Tom Fisk