Kubernetes:
Its an open-source orchestration tool
Originally developed by google
Helps to manage containerized application
It originated with the rise of microservices architecture
It offers high availability of your application and also high scalability like during the high load
on your application it scales the architecture to manage it and reduce the architecture when
load goes down.
Architecture:
Master Node: The master node controls the cluster and worker nodes host the
running applications. Each node in the Kubernetes cluster plays a specific role and
runs various components to ensure the proper functioning of the system
o API Server: It’s the entry point to Kubernetes cluster. It exposes the Kubernetes
API, which allows users and other components to interact with the cluster.
o Controller manager: Keeps an overviews what’s happening in the cluster (state
of the cluster) like if any container restart is required.
o Scheduler: Ensures pods placement on different nodes based on resource
availability and constraints. It watches for newly created pods with no assigned
node and selects an appropriate node for scheduling based on factors such as
resource requirements, node capacity.
o ETCD: it’s a key-value storage(Meta-data). It holds info of current state of
Kubernetes cluster. Backup also gets maintained by using etcd.
Worker nodes:
POD: Smallest unit of Kubernetes
Its an abstraction over container
When pod runs it create a layer over the container to run container runtime
Here in Kubernetes we only interacts with pod layers
Best case scenarios always prefers to run one container (in short your
application)
Inside single POD. Although you can have multiple containers running inside
a POD.
There’s a virtual network set-up in Kubernetes that runs and ensure each
pod do have its own IP. By using this internal IP address PODs can
communicate with each other
If a POD stops working then Kubernetes replace it with newly created POD
along with new IP address
Service:
it’s a permanent IP address that can be attached to each pod.
Lifecycle of service and POD are totally independent. Even if POD dies
service with IP address stays.
Another working is it acts as loadbalancer
Volume:
Its an external storage attached to the POD
This storage could be any remote storage, cloud storage, local storage
Lets say if you have database running inside the POD and it gets restarted
then in order to maintain replica of storage for the safer side we use
volumes.
Because Kubernetes doesn’t ensure persistent data storage
Deployments:
Here in Kubernetes in order to ensures high availability we replicate PODs
Now PODs are actually running on some servers. But in order to maintain
copies of POD we don’t actually create PODs but just BLUEPRINTS of existing
PODs architecture. And blueprints are knows as Deployment
BUT in case of a POD containing database we can’t create Deployment for it
because Databases do have states ( STATE of data). It can lead to data
consistency
So for PODs contains databases we create STATEFULSETS. Statefulsets makes
sure the database reads and writs are synchronized.
So generally its preferable to have database outside of Kubernetes
architecture where we can easily manage deployments
Kubelet: It interacts with the API server (running in Masterode) to manage the PODs
It also reports back to API server about PODs states , worker node state.
KubeProxy: It is a network proxy that runs on each Worker node and maintains
network connectivity of PODS. Also manages the routing , Loadbalancing between
the PODs.
Kubernetes Configuration:
As an user we interact via Kubernetes dashboard, Kubectl to the Kubernetes cluster .
The request we send to cluster entertained by the API server
The request format would be YAML or JSON
Kubernetes always tries to maintain a balance between Current state and Desired state (what we
have mentioned in specification file). All these info comes from etcd
Kubectl is command line tool for Kubernetes
