The world’s leading publication for data science, AI, and ML professionals.

What exactly is Kubernetes?

I had a very good journey into deploying a web application on Azure Kubernetes and I want to share with you all the secrets about this fun!

My roadmap to Kubernetes

Since I discovered Docker in late 2015 I was impressed by the fact that deployment could have been processed like source code. Yes, I think this was the gap that containers fill: make source code and serve the same thing. As you commit your changes on the order controller, you can commit the new server that hosts the order controller. That was a revolution, thinking to the time when developer manually uploads file to production or move with DevOps tool if they were lucky. This opens to new scenarios, where also the infrastructure is deployed by DevOps tools. Honestly speaking, not all the applications need an infrastructure that can be replicated by a click. It is a requirement for Saas software, but an expensive plus for most of simples business use case. However, coming back to Docker, there still was some effort to deploy it and scale. I used it on dev, test, and production environment, no blame on docker. I love it. But, it needed to convert old way developers to use container also in development to gain all benefits of a lean process to the production environment. We did it so that, more or less, most of the developers have docker in their PC, can run a container or run "docker-compose up" and use a cluster of servers.

That was great, a lot of the issue by developing in different environment or setup costs for developers was cutoff. Deployment to production was still completely managed by DevOps process, so what else? In my deep, I found something was missing. There still be some parts that stuck me… pulling container, running containers, exposing volumes it’s great and docker itself give us the solution, but I missing something. I didn’t know exactly what at that moment but there was for sure. Then a day I discovered Kubernetes. The payload is "Production-Grade Container Orchestrator". I can’t remember what it was at that time, but trust me… the Orchestrator word opened my mind. I needed something to orchestrate container, coordinate their work: Kubernetes was what I miss. Since that time I tested it into production environments, friction during development reduced, setup time fall, DevOps effort was reduced.

Kubernets is the revolution in containers!
Kubernets is the revolution in containers!

What is Kubernetes

I already spoke very positively about containers. I hope it’s clear for all those containers are a good way to ship and run our applications. In a production environment, we have also many requirements, first of all, you would like to deploy with no downtime or scale when load increase. Maybe you would that, if a container goes down, another will start. Think to Kubernetes as a framework to run distributed systems resiliently. It takes care of your scaling requirements, failover, deployment patterns, and more.

The features that Kubernetes provides out of the box:

  • Service discovery and load balancing: Kubernetes provides a swiss tool called "ingress controller". It can be managed by different add-ons but, basically, expose a container using the DNS or IP address. That’s cool because, if traffic is high, Kubernetes will balance it and distribute it. Moreover, this can implement HTTPS to HTTP mechanism, so that internal containers communicate in HTTP without bothering about shipping certificates on each container. If you want, you can also make a sort of URL rewrite to host much application into a single domain, i.e. you can have an angular SPA on www.mysite.com and a REST API app on www.mysite.com/api/
  • Storage orchestration: if you remember something about Docker volumes… the concept is the same but a little bit more evolved. You can link storage to the Kubernetes cluster, then blame the volumes from the containers. The very cool thing is that "storage" may mean a local drive as a cloud-based service.
  • Automated rollouts and rollbacks: You can automate the creation of containers just by add some YAML files somewhere. You just have to describe how your platform has to scale and how your container interacts with each other.
  • Automatic bin packing: In the end also Kubernetes need physical resources to work. That means that you still will need to put CPU, RAM, and disk to let container works. The good news is that you can specify the resource need for each container. This will help Kubernetes to take better decisions about scaling.
  • Self-healing: Kubernetes is the container babysitter. He takes care of everything. If a container fails, it will try to replace it. If the container doesn’t respond, it kills him, and so on.
  • Secret and configuration management: the very nice thing about Kubernetes is that is possible to decouple configuration from containers. That’s something like the environment variables, but cooler. each configuration can be managed globally, the attached to one or more containers. Moreover, some variable, called "secrets" are encrypted to ensure security. This is very useful for sensitive information, such as password, authentication tokens or ssh keys.

What Kubernetes is not

Kubernetes is a lot of good things, I hope to have been clear exposing all Kubernetes benefits. The main problem from Kubernetes newbie is that they discover it is not a PaaS (Platform as a Service) system like they suppose. Kubernetes is a lot of things but not an "all included" service. It is great and reduces the amount of work, especially on the sysadmin side, but doesn’t offer you any apart from the infrastructure.

Said that most of the things you are looking for in a fully-managed system are there: simplified deployments, scaling, load balancing, logging, and monitoring. Usually, you get a standard configuration from your hosting but you can theoretically customize it if you really need it.

Kubernetes limitations:

  • It does not limit the types of applications supported. Everything is written into the container so every container application, no matter on technology, can be run. The counterpart is that you still have to define the container by hand.
  • It doesn’t offer an automated deployment. You just have to push to a docker repository your built images, no more. This is quite easy if you already work in a process with Continuous Integration, Delivery, and Deployment (CI/CD), but consider that without it will be quite tricky.
  • It does not provide any application-level services, just infrastructure. If you need a database, you have to buy a service or run it into a dedicated container. Of course, taking charges of backups and so on.
  • Most of the interactions with the system are by a command line that wraps API. That’s very good because it allows automating each setting. Commands syntax is very simple but, if you are looking to a system that is managed fully by a UI you are looking to the worst place.

How Kubernetes works

Let’s start a little bit deeper investigation on the technical part. This is not the time for a full overview of the components and I don’t want to split hairs. My purpose is to describe the most important components and make clear all will came later into this article’s follow up. Of course, if you plan to learn Kubernetes by yourself, starting knowing where you are is a big plus.

Pods

Consider a Pod like a high-level abstraction of a container. In this abstraction, the pod can be one single container instance or a group. A Pod consists of one or more containers that share resources and are colocated on the host machine. Each pod has one unique IP address assigned which means one pod can communicate with each other like a traditional container in a docker environment. Each container inside the pod can reach all other pods into the virtual network, but cannot deep to the other container on other pods. That’s important to guarantee the pod abstraction: nobody has to know how the Pods are composed internally. Moreover, the IP assigned is volatile so you must use always the service name (resolved to the right IP directly). Like Docker containers, a POD can define volumes that can be compared to shared network drives. This is useful to persist data or share files between pods.

You can manage pods using API or just hitting commands on your shell.

Services

The name "service" in informatics science is overused. In Kubernetes scope think to a service like something you want to serve. A Kubernetes service involves a set of pods and may offer a complex feature or just expose a single Pod with a single container. So you can have a service that provides a CMS feature, with database and web server inside, or two different services, one for the database and one for the webserver. That’s up to you.

Ingress controller

The service is the component that you can expose outside. To do this there is an ingress controller that does something similar to a load balancer. It virtually forwards traffic from outside to the services. During this step, based on the ingress implementation you have chosen, you can add HTTPS encryption, route traffic based on the hostname or URL segments. The only service can be linked to the ingress controller, not Pods.

Volumes

By default Pod storage is volatile. This is important to know because at the first restart you will lose everything. Kubernetes volumes allow mapping some part of the hard drive of containers to a safe place. That space can be shared between containers. The mount point can be any part of the container, but a volume cannot be mount into another one.

Namespaces

Think to namespace like the feature that makes Kubernetes multitenant. The namespace is the tenant level. Each namespace can partitioning resources to isolate services, ingress, and many other things. This feature is good to have a strong separation between application, delegate safely to different teams, and have separated environments in a single infrastructure.

Secrets and configuration

The configuration can be made globally trough config maps. This mechanism work in this way. First of all, you have one or more config inventory, then you link environment variables of the container to the global variable. The benefits are clear. If one variable changes, you have to change it only once. Moreover, for some sensitive information, there is a cool mechanism called "secrets". Secrets variable are stored encrypted into a system that cannot be accessed by anyone. Secrets are sent only to the pods that require it

Kubernetes as a service

As every non-sysadmin, I hate to wear the sysadmin hat. Or better… all it is funny until things break. Maybe I’m overreacting, or this is just envy, but one thing is sacred don’t do the job of others. Nowadays there are so many services that give Kubernetes free to you that’s so stupid no to use it that I don’t want to speak about it. We are not speaking about hand-made marmalade, that’s software. Just buy from a better player, if you can. Google, Amazon, Microsoft, IBM … all of them have their Kubernetes service and all works with the same pricing model: came to me, all Kubernetes service will be free, you will pay just for the resources you will use. Many vendors give you a free tier or trial period with credit so it is easy to start playing with it. I chose Azure for this article because of some facilities during source code integration, but most of the things you will learn in this article series will apply to all. Another great concept on Kubernetes as a service is that this doesn’t require that your application is coupled with the cloud. As your application is just a raw container and this is orchestrated by some configuration files compliant with Kubernetes you will be able to move to azure to google and vice-versa with few efforts (at least without changing the source code).

So, Kubernetes service is free and you pay only the hardware for it, where "hardware" means a virtual machine used by Kubernetes.

What to take home

Kubernetes is a very great platform to exit safely the traditional virtual machine shield and go to the cloud. It brings dynamism, reduces the sysadmin cost and pushes to the quality level of the service that will be hard to ensure differently. Many traditional issues like networking and data protection can be overcome by the advanced configuration of Kubernetes itself.

I cant tell that Kubernetes is ok for all your projects but trust me if I told you that you have to consider the option for all your new projects.

Ready for the next step? just read how to deploy a web application with Kubernetes in practices!


Found this article useful? Follow me (Daniele Fontani) on Medium and check out my most popular articles below! Please 👏 this article to share it!


Related Articles