Kubernetes Unleashed: Exploring the Core Architecture and the Magic of PODS for Beginners!!

Kubernetes Unleashed: Exploring the Core Architecture and the Magic of PODS for Beginners!!

Kubernetes (K8s)

  • Kubernetes also known as K8s, is an open-source Container Management tool.

  • It provides container runtime, container orchestration, container-centric infrastructure orchestration, self-healing mechanisms, service discovery, load balancing and container (de)scaling.

  • Initially developed by Google, for managing containerized applications in a clustered environment but later donated to CNCF.

  • Written in Golang

  • It is a platform designed to completely manage the life cycle of containerized applications and services using methods that provide predictability, scalability, and high availability.

A Kubernetes cluster is a set of physical or virtual machines and other infrastructure resources that are needed to run your containerized applications. Each machine in a Kubernetes cluster is called a node. There are two types of nodes in each Kubernetes cluster:

Master node(s): hosts the Kubernetes control plane components and manages the cluster.

Worker node(s): runs your containerized applications.

Kubernetes Architecture

Kubernetes Master

  • Master is responsible for managing the complete cluster. • You can access master node via the CLI, GUI, or API

  • The master watches over the nodes in the cluster and is responsible for the actual orchestration of containers on the worker nodes

  • For achieving fault tolerance, there can be more than one master node in the cluster.

  • It is the access point from which administrators and other users interact with the cluster to manage the scheduling and deployment of containers.

  • It has four components: ETCD, Scheduler, Controller and API Server

ETCD

  • ETCD is a distributed reliable key-value store used by Kubernetes to store all data used to manage the cluster.

  • When you have multiple nodes and multiple masters in your cluster, etcd stores all that information on all the nodes in the cluster in a distributed manner.

  • ETCD is responsible for implementing locks within the cluster to ensure there are no conflicts between the Masters

Scheduler

  • The scheduler is responsible for distributing work or containers across multiple nodes.

  • It looks for newly created containers and assigns them to Nodes.

API server manager

  • Masters communicate with the rest of the cluster through the API-server, the main access point to the control plane.

  • It validates and executes user’s REST commands

  • API-server also makes sure that configurations in etcd match with configurations of containers deployed in the cluster.

Controller manager

  • The controllers are the brain behind orchestration.

  • They are responsible for noticing and responding when nodes, containers or endpoints go down. The controllers make decisions to bring up new containers in such cases.

  • The controller-manager runs control loops that manage the state of the cluster by checking if the required deployments, replicas, and nodes are running in the cluster.

Kubernetes Worker

Kubelet

  • Worker nodes have the kubelet agent that is responsible for interacting with the master to provide health information about the worker node.

  • To carry out actions requested by the master on the worker nodes.

Kube proxy

  • The kube-proxy is responsible for ensuring network traffic is routed properly to internal and external services as required and is based on the rules defined by network policies in kube-controller-manager and other custom controllers.

Unlocking the Power of Kubernetes: Dive into the World of Pods!!

  • Basic scheduling unit in Kubernetes. Pods are often ephemeral.

  • Kubernetes doesn’t run containers directly; instead, it wraps one or more containers into a higher-level structure called a pod

  • It is also the smallest deployable unit that can be created, scheduled, and managed on a Kubernetes cluster. Each pod is assigned a unique IP address within the cluster.

  • Pods can hold multiple containers as well, but you should limit yourself when possible. Because pods are scaled up and down as a unit, all containers in a pod must scale together, regardless of their individual needs. This leads to wasted resources.

  • Any containers in the same pod will share the same storage volumes and network resources and communicate using localhost

  • K8s uses YAML to describe the desired state of the containers in a pod. This is also called a Pod Spec. These objects are passed to the kubelet through the API server.

  • Pods are used as the unit of replication in Kubernetes. If your application becomes too popular and a single pod instance can’t carry the load, Kubernetes can be configured to deploy new replicas of your pod to the cluster as necessary.

Scaling Pods

  • All containers within the pod get scaled together.

  • You cannot scale individual containers within the pods. The pod is the unit of scale in K8s.

  • Recommended way is to have only one container per pod. Multi container pods are very rare.

  • In K8s, initcontainer is sometimes used as a second container inside pod.

Imperative vs Declarative commands

  • Kubernetes API defines a lot of objects/resources, such as namespaces, pods, deployments, services, secrets, config maps etc.

  • There are two basic ways to deploy objects in Kubernetes: Imperatively and Declaratively

Imperatively

  • Involves using any of the verb-based commands like kubectl run, kubectl create, kubectl expose, kubectl delete, kubectl scale and kubectl edit.

  • Suitable for testing and interactive experimentation.

Declaratively

  • Objects are written in YAML files and deployed using kubectl create or kubectl apply.

  • Best suited for production environments.

Manifest /Spec file

  • K8s object configuration files — Written in YAML or JSON

  • They describe the desired state of your application in terms of Kubernetes API objects. A file can include one or more API object descriptions (manifests).

Creating Pods

Imperative way:

kubectl run test --image nginx --port 80 #Also exposes port 80 of container

Then run this command to see the details of your pod

kubectl describe pod test

Declarative way:

Create YAML file with any name and paste this code in it:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: webapp
spec:
  containers:
  - name: nginx-container
    image: nginx
    ports:
    - containerPort: 80

Now Run this command with your exact file name:

kubectl create –f <file_name>.yml #To create new pod
kubectl apply –f <file_name>.yml #If the manifest file is changed/updated after deployment and need to re-deploy the pod again
kubectl delete pod <pod-name> #To delete the pod

In the ever-evolving world of Kubernetes, your learning journey has just begun! 🚀 Keep exploring, keep sharing, and stay on the cutting edge of this dynamic technology. Until next time, may your pods be ever scalable and your clusters always resilient! 🌟💡