What is DevOps, Part III: Kubernetes

I don't know about you but I understand complex concepts through repetition and hands-on exercises. The first part can be tedious and have you on your last leg with learning if you don't find the right sources. Kubernetes is considered, for lack of a better word, diffucult, with a steep learning curve, I hold a contrary opinion. After reading multiple articles, tutorials and having played with Kubernetes for a while, I figured it would be nice to sum up all these concepts in a straightforward, easy-to-understand tutorial. This article is however not exclusively for beginers only, it can serve as a refresher of the fundementals for intermediate developers as well.

We'll start by looking at the theory part including basic Kubernetes concepts and architecture then, in a future article, we will go through a small practical session to see Kubernetes in action. This is part 3 of my What is DevOps series of articles.

Part 1 (Introduction, basic concepts in DevOps)

Part 2

(Containerization, Docker)

The assumption made here is that you're already familiar with a few concepts of software development including containerization, software development lifecycle and version control. Get yourself some coffee and let's start learning.

Throughout this article, keep two things in mind. One, the thumbnail photo. Two, to orchestrate, basically means to manage at a deeper level.

The problem

Kubernetes is one of the tools use by DevOps engineers and others alike to deploy software. Let's say you have been developing a website locally using Django, ReactJs, MySQL Database, and mobile UI running on Flutter. All these 4 components run individually and separately. If you were to work with all of these in your local development environment, you would have to configure your computer to run each of this components without the dependencies and libraries clushing with one another. If other projects are already running on your computer, this process becomes very tediouse and time consuming.

Like I mentioned in my previose article on Docker, a solution would be to use Virtual Machines, obviously not a viable option if you don't have the luxury of resources. Needless to mention, we will face the same problems on a production environment. It's also important to note that some of these components would require multiple instances of them so as to implement things like load balancing for faster communication/ API Calls, for scaling purposes and redundancy. With docker, you would package each of them as separate containers (more on containers in Part II of this series) and deploy each either on one server or on different servers.

Docker came into the picture in 2013 and revolutionized how we develop and ship code. With docker you could package your program as a container and have it run on any environment without the dependency conflicts and whatnot.

I swear this article is not about Docker, just hung on a minute

With docker you can run a single instance of the application with a simple docker run command and this case to run a NodeJs application, you would do something like;

//a single instance
docker run nodejs

But that's just one instance of your application, what happens when the number of users increases and that instance was no longer able to handle the load? You deploy additional instances of your application by running the docker run command multiple times.

//for multiple instances
docker run nodejs
docker run nodejs
docker run nodejs
docker run nodejs

That's...