This page is under regular updates. Please check back later for more content.
Kubernetes
Kubernetes Architecture

Kubernetes Architecture

Kubernetes is built on a distributed architecture that follows a master-worker (formerly known as master-slave) model. It is designed to efficiently manage containerized applications at scale. This document breaks down the core components of Kubernetes, providing an understanding of how the system orchestrates containers.

image

Working with Kubernetes

  • We create manifest (.yml file)
  • Apply this to cluster (to master) to bring into ddesired state.
  • Pod run on board, which is controlled by master.

Role of Master Node

  • Kubernetes cluster contain containers running on bare metal/VM Instances/cloud instances.
  • K8s designates one or more of these are master and all other as worker.
  • The Master is now going to run setups K8s processes. These processes will ensure smooth functioning and cluster. These processes are called 'control plane'
  • Master run control plane to run cluster smoothly

Control Plane components

Mainly there are four components -

Kube-api-server

  • For all communication
  • Directly interaction with user (using manifest)
  • meant to scale automatically as per load
  • Act as front end of control plane

kube scheduler

  • When user make req. for creation of pod, its management it going to take action
  • Handles pod creation & management
  • It match/assign any node to create and run pods.
  • A scheduler watches for newly created pods that have no node assigned.
  • For every pod that the scheduler discovers, the scheduler become responsible for finding best node for that pod to run on.
  • Scheduler get the information for hardware config from config files and schedule the pod on node accordingly.

controller manager

  • Make sure that actual state of cluster matches to desired State.
  • Two possibility choices for controller-manager
  1. If K8s on cloud then it will be the cloud-controller-manager
  2. If not on cloud then it will be Kube-controller-manager

Components on master that runs controller

Node controller: for checking the cloud provider to determine if a node is detected in cloud after it stop responding.

Service Controller: responsible for load balancers on your cloud against services of types of load balancers.

Route-controller: Responsible for setting up network, routes on your cloud.

Volume controller: For creating, attaching, mounting volumes & interacting with cloud provider to orchestrate volume.

etcd

  • Store metadata and status of cluster
  • Consistent and highly available
  • Contain info about state of cluster.

Features

  • Fully replicated: The entire state is available on every - node.
  • Secure: Implement automatic LS
  • Fast: Benchmark @10,000 write/second.

Nodes (Kubelet & container engine)

Node is going to run 3 important piece of software processes.

Kubelet

  • Agent running on node
  • listen to Kubernetes master
  • USePOt 10255
  • send success/fail report to master.

Container Engine

  • works with Kubernetes
  • pulling images
  • Start/stop containers
  • Exposing containers on pods. specified in manifest.

Kube-proxy

  • Assign IP address to peds (dynamically)
  • Runs on each node & this make sure that each pod has its own IP address.

Pods

  • Smallest unit in K&s
  • Group of one or more containers that are deployed together on the same host.
  • A cluster is a group of nodes
  • A cluster has at least one node. and one master.
  • In K8s the control unit is the POD, not containers.
  • consist of one or more tightly coupled containers.
  • Pods runs on a node which is control by master.
  • K8s doesn't know about container (only know about pod)
  • Container cannot be started without pod.
  • One pod usually contain one container.

Fundamentals of pods

  • When a pod get created, it is scheduled to run on a node in the cluster.
  • The pod remains on that node until the process is terminated, the pod is evicted for lack of resources, or the node fails.
  • If a node fail, or if the scheduling operation itself fails, the pod will be deleted.
  • If a node dies, the pods scheduled to that node are scheduled for deletion after a timeout period.
  • A given pod (UID) is not "rescheduled" to a new node, instead it will be replaced by an identical pod with even the same name if desired, but with a new UID.
  • Volume in a pod will exist as long as that pod (with that UID) exist if that pod is deleted for any reason, volume is also destroyed and created as new on pod.

Multicentainer pod -

  • Share access to memory space.
  • Connect to each other using lecalhost
  • Share access to same volume
  • Containers within pod are deployed in an all-or-nothing manner
  • Entire ped is hosted on single

Pod limitations

  • No autoscaling or load balancing
  • Pod crashes

In order to overcome limitation we use something called High level K&s object

High level K8s objects

  1. Replication Set: Enabling autoscaling and auto healing
  2. Deployment: versioning & rollback.
  3. Service Static IP / Networking
  4. volume Persistant storage

Reference

Find more about -

Pods

Kubernetes vs Docker SwarmKubernetes Objects