Kubernetes for Dummies — Part 1: Introduction

Introduction

This was a topic which I was looking forward to write, because some of my colleagues heard about it as a Container Orchestration platform and its nice, but they do not want to use it. I cannot blame them, because Kubernetes, when run in a production grade setup, is a big well oiled machine with lot of moving parts. If one of them gets problematic, then for a beginner, it will be a really confusing topic.

So here I am preparing this document for everyone who would like to know about Kubernetes and work on it as a beginner.

What is Kubernetes and why?

Kubernetes is an open-source platform for running container workloads in a declarative or automated way.

In modern era, where many of the applications and workloads are being run on containers, there is a need for automation in maintaining the services. Consider the following examples for automation:

• Spin up a new container, when the service running the same container crashes
• Deploying new versions of the services by spinning up new containers without downtime
• Service discovery, when a monolithic application is split into multiple service applications, each serving its own purpose

These are the basic scenarios that we need automation. How can Kubernetes help here?

• Self healing: Kubernetes can monitor the containers running and recreate a new one when the container crashes
• Rollouts and Rollbacks: Kubernetes can ensure new versions can be released and if the new release version containers are crashing, rollback to previous version
• Loadbalancing and Service discovery: Kubernetes can expose containers with DNS names which can be accessed by another container to communicate. It can balance the load and distribute network traffic

And other features include:

• Freedom of choice to select our own storage provider, whether it may be cloud, local or host
• Easy management of secrets and configuration, so that each app can be developed in a 12-factor App model or the model desired by the users
• Can accept memory and CPU resources for each containers that is being run on the cluster.

This is just something to show its features. Lets look at some use-cases:

• A product or an application that is running on containers, require to be run as test services for customers to evaluate the product. It would be easy to run with docker and docker-compose. If there is couple of test servers, there is an overhead of using a configuration management tool liek ansible to configure the servers
• An organization running a lot of test applications in containers on their own servers using docker or docker-compose and using ansible for configuring servers.

In both cases, the issue is there is a need for a configuration management tool. Otherwise there will be a drift between configurations in the repositories or anywhere its stored and on the servers.

Introducing Kubernetes will reduce the overhead of configuring servers. This will be a one time task to configure a new cluster or adding a new server. Running the applications and services would be with YAML file resources or with package manager like helm

The real advantage here is instead of using multiple test servers for each application or customer, we can aggregate all of them into a Kubernetes cluster, and then use namespaces to differentiate each customer or test environments. This means we dont need to login to all the servers for managing all of the applications. Kind of a good choice here

Why not Kubernetes?

Many documents on the internet and what I have just written above brags about the merits of going to Kubernetes. In a fast moving world with more advanced technologies coming out, its logical to take the next step by adopting the new technologies. But are we sure about that?

Migrating docker container applications which are running fine to Kubernetes is good, but we have to make sure that these applications can be run on cluster. For ex: there is a hevay task on developers to move the apps to 12 Factor App model if its not built like that.

Learning curve is very steep. With the introduction of Kubernetes, Developers and Operations need to learn and understand how it works and how everything is connected inside the cluster. If this is not properly done, then in the event of an issue with the cluster, the troubleshooting and fix times will be longer.

Deploying applications on the cluster should be properly done. There are some values in the cluster which are set as default, and many continue to use them in production to a point of no return. After this point, any issue that occurs, will be a hell of a firefighting mission and the cluster can be unstable.

The main trouble will be, not all applications can be containerized. In such cases, it doesn’t make sense to migrate apps to Kubernetes by following the hype.

and so on…

Conclusion

In a nutshell, Kubernetes is an amazing tool to use. Before adopting it, one should weigh the pros and cons and the necessity of migrating. Its not just about the hype and moving all of the services to Kubernetes blindly. This should be considered carefully and if it makes sense to migrate, then continue. If it creates more problem if migrated, then its not worth a try.