Kubernetes & Components

What is Kubernetes? Open Source Container Orchestration Tool Developed By Google Helps you manage containerized apps in different deployment environments like a physical machine, virtual machine, cloud & hybrid.

What do we need Kubernetes(container orchestration tool)?

As the trend increases from Monolith to microservices, it caused increased usage of container technologies because the containers actually offer the perfect host for small independent applications like microservices. As the usage of containers and the microservices technology increases, this resulted in applications that are comprised of hundreds or sometimes maybe even thousands of containers. And managing those thousands of containers across multiple environments using scripts & self-made tools can be really complex and sometimes even impossible. This led to the need for having a proper way to manage these containers, i.e. container orchestration technologies.

Features of Kubernetes

High availability - No Downtime. High Scalability - High performance. Disaster Recovery - Easy Backup & Restore.

Components of Kubernetes

Node Pod

What is Node?

Simple server, a physical or virtual machine on which containers are running.

What is Pod?

Basic component or smallest unit of Kubernetes(K8s) Abstraction (handle complexity by hiding unnecessary details from the user) layer over the container as you don't need to deal with containers. You only interact with the Kubernetes layer. Usually 1 app container per pod Epithermal, they can die easily

How do Pods Communicate with each other?

K8s offers a virtual network, which means each Pod gets its own IP address(Remember, pod get IP, not container) Each pod can communicate with the other with this Internal IP Address. If the container crashed because the application crashed inside or because the nodes(server) on which container is running ran out of resources, the pod will die and a new one will get created in its place & it will get assigned a new IP address.

As Pods are getting new IP every time with creation, then how do these Pods are going to communicate?

Here, Service comes into the picture. Basically, Service has a static IP Address with a DNS name, that can be attached to Pod. SERVICE also works as a load balancer, we will discuss this later. The lifecycle of Pods & Service is not connected. So even if Pod dies, & replaced by a new Pod, it gets a new IP address, it still has the same service through which they can communicate. Here, we talk about how Pods can communicate with each other internally, but We want our app to be accessible through a browser, which we will see in the next section.

How to access Our App through a browser?

For this, we need to create an External Service External service(http://ip-of-node:port-no-of-service) is a service that opens the communication from external sources But obviously, you wouldn't want certain pods open to the world like your database pods and for that, you need to create an Internal Service which opens the communication from internal sources only, which you specify when creating one. But we want our URL don't like this (http://ip-of-node:port-no-of-service), we want our URL to look like https://my-app.com, which has secure protocol & domain name, which we can get using Ingress, which route traffic into the cluster.

SUMMARY

We have servers(NODES) on which CONTAINERS are running. These containers have an abstract layer on them called PODS, which has static IPs called SERVICES, which are connected to INGRESS.

OR

Whenever any request comes, it first goes to INGRESS, which routes it to SERVICE, which is connected to PODS, which is an abstract layer on CONTAINERS running on servers (NODES).

Consider you make any changes in the endpoint of SERVICE attached to Database Pod, but usually, we define database URLs inbuilt application, so do we need to rebuild the application, push it to repository & pull it to pod & restart it ??

For this very purpose, we use CONFIGMAP which is an external configuration to your application Usually contain configuration data like URLs of a database or some other services. Connected to Pod so that pod actually gets the data that config map contains and now if you change the name of the service(endpoint of the service), you just adjust the config map.

But what if we make changes in username & password or certificates, can we store them in ConfigMap which is a plain text file?

For this, we use SECRET. Same as ConfigMap, but used to store secret data in base 64 encoded format. The built-in security mechanism is not enabled by default. ConfigMap & Secret data can be used as an environment variable or even as a properties file.

As on restarting Pod, data on Pod is gone, so how can we persist the data?

Yes, K8s doesn't manage data persistence. So, it is our responsibility to backup, replicate & manage data. We can attach VOLUMES(physical storage on a hard drive) to our pod. VOLUMES can be on a local machine(Same NODE), or remote storage(outside of K8s cluster, maybe on the cloud, on-prem, etc.)

What if my application pod die due to restart/crash etc., how we are going to access the application?

We are replicating everything on multiple servers means we have multiple NODES, which have a replica of our app pod & all replica app pods are connected to the same SERVICE, which works a load balancer also means it forwards the request to the pod who is least busy.

How would we create a replica of the application pod?

We would define the blueprint for our application pod and specify how many replicas we want. That blueprint is called DEPLOYMENT. Also, in practice, we won't create any pod, we create DEPLOYMENT, because there you can specify how many replicas you want and you can also scale up or scale down based on the number of replicas of pods that you need. DEPLOYMENT is an Abstraction layer over PODS, which makes it more convenient to interact with the pods & replicate them and do some other configuration. Databases cannot be replicated using deployment as DB has a state which is its data meaning that if we have clones or replicas of the database they would all need to access the same shared data storage and there you would need some kind of mechanism that manages which pods are currently writing to that storage or which pods are reading from the storage to avoid data inconsistencies & also to replicate the DBs, which is offered by STATEFULSET

STATEFULSET

For Stateful apps like DBs, MySQL, MongoDB, ElasticSearch. No DBs inconsistencies But working with STATEFULSET is tedious, so generally DBs are deployed outside the K8s cluster. Like DEPLOYMENT except DEPLOYMENT is for Stateless apps & STATEFULSET is for Stateful apps or DBs.