Kubernetes : Automated Orchestration

To understand what Kubernetes does, you should know what a Container is. If you’re not familiar with it, I recommend you to read my docker post first, then come back to this thread.

What, why is Kubernetes

Kubernetes is a Container Orchestration Application which supports any Microservice architecture that requires multiple containers to run a full service. Then why kubernetes? Because it automates every manual operation that have stolen millions of engineers’ sleep in charge of maintenance.

The main concept of whole orchestration is ‘how to reduce repetitive, manual works’. Engineers usually traced and monitored server’s status and loads over server, and predict next incident to prevent before it happens. But any application might fail due to unchecked bug, (and worse, not find any clue even after incident) or hardware mal-function.

Kubernetes creates an environment that has certain ammount of CPU, Memory and disk resources. With presets and policies defined by user, it creates a container and balance whole loads over the network between other containers. If the container fails due to uncertainty, it simply retreats resources from the container, and recreate new one with same image, and re-balance the network. This whole process is fully automated with kubernetes configuration.

If you’re any kind of server engineer, you understand the nightmare of server replacement, or load balancing instances and networks. You might think Cloud environment eased your job, but hold your beer until you get into kubernetes.

Most brief terminology

This image sums up what you have to understand. Let’s check every name one by one, but you can check more information at official website:

Master

It is a API Server that commands every Nodes. Master is in charge of every nodes that contains pods (that has resources such as containers, volumes and etc;), and when user makes a call with an API using command line tool like kubectl, master executes it giving commands to Nodes kubelet with its own API.

It also has key-value storage(Etcd), which helps to store informations that child Node might need it. Controller manager, and Scheduler gives whole variety of control over every nodes.

Most important thing is: Master is not a substantial object for Nodes. Which means, you can set a Master away and remote cluster with nodes in different server. Which automatically allows Kubernetes to take a control over numerous servers and orchestrate it freely.

Nodes

We now know that Master is like a conductor in Orchestra. Nodes are like every instruments watching his Baton, waiting for the command. It is a worker virtual machine, but it does not work as a single Container. It is consist of a logical group that can have multiple pods, and each pod can has multiple containers.

All the magic happens with an Kubernetes agent kubelet, which allows you to orchestrate resources.

Pods

Finally we’re at Smallest unit. It can have multiple containers, volume disk shared by containers(Which is AWESOME THING), and Network router to communicate with other instance.

With these 3 main concept, you can broadly imagine what Kubernetes is capable of. From Master API, you can manage multiple Nodes in different physical clusters using controller API. You can launch thousands of containers with a configuration and few commands.

What makes Kubernetes special

While Docker made popular the Container technology, Kubernetes allowed microservice architecture to spread his wing over Cloud environments. To maintain the application, Kubernetes Controller(in Master) gives specific options that you might find useful.

Deployment

Blue and green deployment, Canary, Rollback, Versioning, and etc; These were just a name of technics that engineer needed to execute manually, until orchestration tools came out and automated it.

Main factor is desired state. When configurations are determined, Master gives a command to each Nodes’ kubelet to maintain pods in desired condition: quantity of containers, volume attachment, network interfaces and load balancing, and others. If you need to deploy newer version, all you have to do is declare a deployment so kubernetes controller will command to nodes and automatically launch newer containers and replace it.

Ingress & Service

Service is the logical group of Pods, which load balance access, and has proper (internal) DNS name to communicate each other. But what makes layer 7 load balancing available is Ingress. It support TLS communication and distribute access to each services included.

ConfigMap, Secret and PodPreset

ConfigMap and Secret are both key/value storage for variables that can be called in configuration. It allows you to store confidential data such as API Keys, password, and let The only difference that secret has is that value should be stored in BASE64.

While both ConfigMap and secrets are pure data that can be used freely, PodPreset is more like a rule that applies automatically. Such as attaching volume, replica’s quantity can be predetermined in PodPreset and not copy-paste same configuration over and over. (And also, not forget to add it)

Security

If you’re familiar with AWS, kubernetes has a similar interface like IAM. You can create an user account, service account, and roleBinding (which I found very similar to IAM role). So basically, you create any roles to allow or deny, and bind that role to any account you want to.

Technically, Network policy, authentication and authorization system are quite similar to other cloud environment system, so If you’re keen on any system or cloud engineering, it is very easy to do similar thing.

Resource management

What I was astonished for a first time was the resource management. As you can create multiple containers and distribute cluster’s CPU, memory, and disk resource to each of them, what you can do is designate Request and Limit ammount of each resource so they don’t overuse it. And what really blew my mind was the approaches to overcome OverCommitted resources by relimit resources and if the case is not claused, destroy resource to protect form whole cluster going down.

helm

the npm of kubernetes that makes third party applications way much easier to deploy. If you want to install any monitoring agent over thousands of clusters, you don’t have to do repetitive jobs over and over, but with helm, you just describe a chart configuration and let kubernetes controller do the repetitive job over whole clusters.

And others

Things such as StatefulSet, Pod Distribution Budget, or Monitoring clusters needs more specific knowledge over kubernetes to understand it why this thing is convenient. If my time allows, I will try to write more specific post about each one with some practical examples to follow.

Closing

I tried to summarize what I have learned during this first quarter, fortunately having experience with deploying docker images and let kubernetes to use it. I will try to do some small projects with microservice architecture and get more used to it.