Forem: Lakshya Gupta

Kubernetes Architecture Simplified #2

Lakshya Gupta — Fri, 06 Aug 2021 22:49:28 +0000

So by now, I have heard a lot about Kubernetes and how people are finding it so cool. This really intrigued me and I wanted to get a deeper look at the architecture.

Here is my attempt to put down my learnings in a simple language.

As we know, Kubernetes is a container orchestration tool that has revolutionized the deployment process. Everyone is talking about it and day by day, more and more companies are adopting it. Let's understand its structure.

If you have any doubt while going through the blog, feel free to refer to the Kubernetes Official Documentation. You can also refer to this blog to get a brief Introduction to Kubernetes.

Before diving deep into the architecture let's first understand few concepts that will help understand the workflow of K8s(Kubernetes) better.

Basic Concepts Behind Kubernetes

1. Declarative vs Imperative

Let's understand this with an example, suppose you were asked to drive a car at exactly 60km/hr. To attain this, you would probably try to speed up the car till you reach 60km/hr and if the car was over 60km/hr, you would try to slow it down.

This is a declarative model where you describe the desired state without actually stating the actions required to reach there.

On the other hand, if you were simply told to slow down or to speed up the car, that would be an imperative model where you were provided the list of actions that will create the desired state.

So it is important to understand that Kubernetes runs on a declarative model that saves us a lot of time and energy. We can just say "make sure that there are four pods running" instead of telling it spicifically "run this pod, run that pod". K8s will take care of everything else for us.

2. Control loop

The control loops are one of the core features that make Kubernetes so special. Almost every structure in Kubernetes uses some sort of a control loop, where you describe the state of the objects you want and not the actual steps to get there.

This is a loop that is constantly running and it includes the following processes:

observe: it observes the current state of the Kubernetes cluster.
diff: compares the current state of the cluster to the desired state.
act: makes sure that the current state meets the desired state.

3. Reconciliation

If you understood the control loop and declarative statements, this is basically the implementation of the two. Reconciliation is a simple process that makes sure that the actual state is looking like the desired state via the observe, diff, and act control loop.

Kubernetes Architecture

Now that we have understood about states and control loops in Kubernetes, this would be the right time to get introduced to the actual architecture of Kubernetes.

Learning K8s can be overwhelming so I will try to provide a very high-level view of how it is structured. Do check out the Official documentation for referencing.

1. Master Node

On the left, we have the Master node, and connected to it are several worker nodes. The master node runs several important processes that are important to run Kubernetes. It also controls and manages the worker nodes.

The master node is where the plan of action required to align the current state to the desired state is formed. Master node mainly consists of the following component:

kube-apiserver: This is the most important component responsible for handling all the internal and external requests.
Kube-apiserver allows communication between the master node and the worker nodes.
kube-schedular: It basically creates new pods and decides which worker node to deploy it on.
It also consists of all the resources to create and deploy pods on the worker nodes if an old pod dies.
kube-controller-manager: This runs controller processes in the background that take care of the cluster. One of the controllers' function is to communicate to the kube-schedular when a pod dies and makes sure the desired state that we talked about, is reached.
etcd: It is a key-value store database that stores the state of the Kubernetes cluster like the number of pods, their state, etc.

2. Worker Node

On the right, we have the worker node. While the master node runs the tasks that are important for Kubernetes to function, it is the worker node that runs the tasks given by the user.

There can be more than one worker nodes attached to a master node but at least one worker node is needed to run the cluster.

Before looking at the components of the worker node, let's first understand what pods are.

Pods are the smallest unit in Kubernetes. They are made up of one or many containers and act as a single instance of an application.

Now coming back to the worker nodes, they consists of:

Container runtime engine: This is an engine that runs the containers inside the pod. For example, we have Docker in the figure above. You can read more about Docker here
kubelet: It interacts with the container runtime engine(Docker) and makes sure that the required containers are running inside the pods. It also facilitates communication between the worker node and the master node.
kube-proxy: This enables internal as well as external networking among the pods.

Conclusion

Yaay you reached the end! This was a brief overview of the Kubernetes Architecture. I hope you now have a clearer picture of the concepts behind it.

There are few details that I have omitted in order to keep the explanation simple, but feel free to check out the Documentation. I really hope you liked the blog and do let me know in the comments if you did.

Feel free to connect with me on Twitter and say hi, I'll be more than happy to have a conversation. :)

This blog is a part of my #100DaysOfKubernetes challenge. Do check out my journey on Twitter when you drop by. :D

Thanks for reading! :)

Introduction To Cloud Native Chaos Engineering

Lakshya Gupta — Thu, 29 Jul 2021 16:00:25 +0000

In this blog, I will be sharing my learning from a Live stream about chaos engineering. the link to which can be found [here].

https://www.youtube.com/watch?v=LK0oDLQE4S8

The problems before Chaos Engineering

Before Chaos Engineering was adopted there was no way to tackle problems that were unpredictable. For example, high traffic on the app would cause a system outage. This outage, even for a small time would cost millions to companies and their reputation as well. This is where we felt that normal streamlined testing is not enough.

There are many services running in the system and the interaction between them can be unpredictable. These interactions often result in downtime of the system.

What is Chaos Engineering?

Chaos engineering can be thought of as a mechanism of running experiments on the system by exposing it to real-life scenarios to see whether the system can withstand unexpected disruptions. These include scenarios of high traffic on the system or when the system faces any sort of outage. By running these experiments on the system we try to find out its weakness and makes the system more resilient. Any event capable of disrupting steady state is a potential variable in a Chaos experiment

There are four steps in Chaos Engineering:

Steady-state
Hypothesis
Experiment
Adapt

More details on these can be found on https://principlesofchaos.org/

What is resilience

Resilience is a system's ability to stay working even when a fault is occurred. Resilience of a system can be challenged in many ways such as when the services become unhealthy or when a node in a Kubernetes cluster goes to not-ready state or when there is a memory leak in the system. Chaos engineering caters to these problems of not maintaining a resilient system.

How to build resilience

Identify steady state conditions i.e. the state that we want the system to be in ideally.
Introduce a fault related to what you want to test
Did the system regain its steady state after introducing a fault?
If yes then the system is resilient
If no then work on this weakness and again introduce a fault

How Litmus and Chaos Engineering is introduced in DevOps space?

The general idea is that we should also focus on operations and not just the development side. Instead of writing tests for all the microservices individually, we can automate the entire process using Litmus. This make everything very smooth.

Why Kubernetes?

Kubernetes is the de facto standard in the industry.
Kubernetes is highly scalable.
High availability

Cloud Native Chaos Engineering

Cloud Native leverages the idea of using cloud storage to run microservices on the system. Some principles of Cloud Native Chaos Engineering are:

Projects are mainly open source
Community support
Open observability
Open API
GitOps

Benefits:

Run services without an outage
Run services to meet the business SLAs and SLOs
Scale your services on demand
Upgrade you services without an outage

Some advantages of using Litmus:

Litmus is cross-cloud
It takes a cloud-native approach to create, manage and monitor chaos
It is a complete framework to implement Chaos Engineering within a cloud-native ecosystem
It helps both developers and SREs to automate the chaos experiment.

Useful Resources

Beginner friendly issues to contribute:

https://github.com/litmuschaos/litmus

https://github.com/litmuschaos/test-t...

https://github.com/litmuschaos/websit...

Blogs and videos to learn more about Litmus:

https://dev.to/litmus-chaos

https://medium.com/litmus-chaos

https://www.youtube.com/channel/UCa57...

https://github.com/litmusbot/katacoda...

You can join the slack community too! That is where you can ask your queries and get to learn more about chaos & contributing to Litmus! To join the slack please follow the following steps!
Step 1: Join the Kubernetes slack using the following link: https://slack.k8s.io/

Step 2: Join the #litmus channel on the Kubernetes slack or use this link after joining the Kubernetes slack: https://slack.litmuschaos.io/

Thank you! :)

Introduction to Kubernetes #1

Lakshya Gupta — Wed, 28 Jul 2021 11:36:39 +0000

What is Kubernetes?

Kubernetes is an open-source container orchestration tool powered by Google.
It helps us manage apps that are made of containers.

What problems does it solve ?

Apps moving from a monolithic app structure to microservices comprise of isolated containers, and managing these containers can be a difficult task.
Kubernetes guarantees
1. High availability
2. Scalability
3. Disaster Recovery

Basic architecture

There is one master node and connected to it are a couple of worker nodes.
Each node has a kubelet running on it that enables it to connect to other nodes.
Worker nodes are where the actual work is happening.
The master node runs several processes that are important to run Kubernetes. These processes are:
- API Server: This is a container that is an entry point to the Kubernetes cluster.
- Controller Manager: Keeps track of what is happening in the cluster.
- Scheduler: It is responsible for scheduling containers on different nodes.
- Etcd: It is key-value storage that holds the current state of a Kubernetes cluster at any given time. This is the backing store of Kubernetes
Worker nodes run heavier tasks than master nodes but the master nodes run more important tasks.

Basic Concepts

Pod: A pod is the smallest unit that a Kubernetes user can interact with.
On each worker node, there are multiple pods and on each pod, there are multiple containers.
We usually have one pod per application.
Each pod has its own self-containing server and its own internal IP addresses.
These pods connect to each other using this internal IP address.
If a pod dies a new pod is created which has a new IP address.

What is a service?

Definition: An abstract way to expose an application running on a set of Pods as a network service.

Pods get created and destroyed all the time in Kubernetes according to the need of the deployment. Every time a new pod is created it gets a new IP address and its connection with other pods gets lost. It would be inconvenient to adjust the IP addresses all the time. This is where services come to play.

A service is set in front of a pod(or replica of pods) and has its own IP address which is permanent.Clients use this IP address instead of the pods' IP addresses. So even if a pod dies and the IP address gets changed, it won't affect the communication between the the services.

Services have many functionalities, it has a permanent IP address and at the same time it is a load balancer.

More about it on the next blog :)
Stay Tuned!