"Getting Started with Kubernetes: A Beginner's Guide to Container Orchestration"
K8s is an open-source container management tool which automate Container Deployment, Container Scaling & Load Balancing.
It schedules, runs and manage isolated containers which are running on Virtual/Physical/Cloud Machine.
All top cloud providers support Kubernetes.
One popular name for Kubernetes is K8s.
History
Google developed an internal system called 'borg' (later named as omega) to deploy and manage thousands google application and services on this cluster.
In 2014 google introduced k8s on open-source platform written in 'Go lang' and later donated to CNCF (Cloud Native Computing Foundation).
Cloud base k8s services
GKE -> Google K8s services
AKS -> Azure K8s services
Amazon EKS (Elastic k8s services)
K8S installation tools:-
kubeadm
minicube
Features of Kubernetes
Orchestration (clustering of any number of containers running on a different network).
Autoscaling (Vertical & Horizontal)
Auto Healing
Load Balancing
Platform Independent (Cloud/Virtual/Physical)
Fault Tolerance (Node/POD/Failure)
Rollback (Going back to the previous version)
Health monitoring of containers
Batch Execution (One time, Sequential, Parallel)
Architecture of Kubernetes
Working with Kubernetes
We create a Manifest (.yml) file.
Apply those to cluster (to master) to bring it into the desired state.
POD runs on a node, which is controlled by the master.
Role of Master Node
Kubernetes cluster contains containers running or Bare Metal / VM instances/cloud instances/ all mix.
Kubernetes designates one or more of these as masters and all others as workers.
The master is now going to run a set of K8s processes. These processes will ensure the smooth functioning of the cluster. These processes are called the ‘Control Plane.
Can be Multi-Master for high availability.
Master runs control plane to run cluster smoothly.
Components of Control Plane
🖇️Kube-api-server (For all communications)
This api-server interacts directly with the user (i.e we apply .yml or .json manifest to kube-api-server).
This kube-api-server is meant to scale automatically as per load.
Kube-api-server is the front end of the control plane.
🖇️etcd
Stores metadata and status of the cluster.
etcd is a consistent and high-available store (key-value-store).
Source of touch for cluster state (info about the state of the cluster).
✅etcd has the following features
Fully Replicated -> The entire state is available on every node in the cluster.
Secure -> Implements automatic TLS with optional client-certificate authentication.
Fast -> Benchmarked at 10,000 writes per second.
🖇️Kube-schedular (action)
When users request the creation & management of Pods, Kube scheduler is going to take action on these requests.
Handles POD creation and Management.
Kube-scheduler match/assigns 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 becomes responsible for finding the best node for that pod to run.
The scheduler gets the information for hardware configuration from configuration files and schedules the Pods on nodes accordingly.
🖇️Controller-Manager
Make sure the actual state of the cluster matches the desired state.
📌Two possible choices for controller manager
If K8s is on the cloud, then it will be a cloud controller manager.
If K8s is on non-cloud, then it will be kube-controller-manager.
🖇️Components on the master that runs the controller
Node Controller:- For checking the cloud provider to determine if a node has been detected in the cloud after it stops responding.
Route Controller:- Responsible for setting up a network, and routes on your cloud.
Service Controller:- Responsible for load Balancers on your cloud against services of type Load Balancer.
Volume Controller:- For creating, attaching, and mounting volumes and interacting with the cloud provider to orchestrate volume.
🖇️Nodes (Kubelet and Container Engine)
Node is going to run 3 important pieces of software/process.
Kubelet
The agent running on the node.
Listens to Kubernetes master (e.g- Pod creation request).
Use port 10255.
Send success/Fail reports to master.
Container Engine
Works with kubelet
Pulling images
Start/Stop Containers
Exposing containers on ports specified in the manifest.
Kube-Proxy
Assign IP to each pod.
It is required to assign IP addresses to Pods (dynamic)
Kube-proxy runs on each node & this makes sure that each pod will get its unique IP Address.
These 3 components collectively consist of ‘node’.
POD
The smallest unit in Kubernetes.
POD is a 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 worker node and a master node.
In Kubernetes, the control unit is the POD, not the containers.
Consist of one or more tightly coupled containers.
POD runs on a node, which is controlled by the master.
Kubernetes only knows about PODs (Does not know about individual containers).
Cannot start containers without a POD.
One POD usually contains One Container.
🖇️Multi Container PODs
Share access to memory space.
Connect to each other using Localhost (container - port)
Share access to the Same Volume.
Containers within POD are deployed in an all-or-nothing manner.
The entire POD is hosted on the same node (Scheduler will decide which node).
There is no auto-healing or scaling by default.
Pod crashes.
Higher-level Kubernetes Objects
Replication Set:- Auto scaling and auto-healing.
Deployment:- Versioning and Rollback.
Service:- Static (Non-ephemeral) IP and Networking.
Volume:- Non-ephemeral storage [Ephemeral Storage outside the node].
Working of Kubernetes
🖇️Pods
Pods can have one or more containers coupled together. They are the basic unit of Kubernetes. To increase High Availability, we always prefer pods to be in replicas.
🖇️Service
Services are used to load balance the traffic among the pods. It follows round robin distribution among the healthy pods.
🖇️Ingress
An Ingress is an object that allows access to your Kubernetes services from outside the Kubernetes cluster. You configure access by creating a collection of rules that define which inbound connections reach which services.
Deployments in Kubernetes
Deployment in Kubernetes is a controller which helps your applications reach the desired state, the desired state is defined inside the deployment file.
🖇️Creating a Deployment
📌kubectl create -f nginx.yaml
🖇️Creating a Service
A Service is basically a round-robin load balancer for all the pods, which match with it’s name or selector. It constantly monitors the pods, in case a pod gets unhealthy, the service will start deploying the traffic to the other healthy pods.
Service Types:
ClusterIP: Exposes the service on cluster-internal IP
NodePort: Exposes the service on each Node’s IP at a static port
LoadBalancer: Exposes the service externally using a cloud provider’s load balancer.
ExternalName: Maps the service to the contents of the ExternalName
🖇️Creating an Ingress:
Kubernetes ingress is a collection of routing rules that govern how external users access services running in a Kubernetes cluster.
Kubernetes Objects
Kubernetes uses objects to represent the state of your cluster.
What Containerized applications are running (and Which node)?
The policies around how those applications behave such as restart policies, upgrades, and fault tolerance.
Once You create the object, the Kubernetes system will constantly work to ensure that the object exists and maintains cluster's desired state.
Every Kubernetes object includes two nested fields that govern the object Config. The object spec and object status.
The spec, Which We provide, describes your desired state for the object and the characteristics that you want the object to have.
The status describes the actual state of the object and is supplied and updated by the Kubernetes system.
All objects are identified by a unique name and a UID.
The basic k8s objects include:-
Pod
Service
Volume
Namespace
Replicasets
Secrets
Config Maps
Deployment
Jobs
Daemon sets
Relationship b/w these Objects
Pod manages Containers.
Replica set manage Pods.
services expose- Pod Processes to the outside world.
Config maps and secrets help you configure Pods.
🖇️Kubernetes Object
It represents as JSON or YAML files.
You create these and then push them to the Kubernetes API with Kubectl.
Labels and Selectors
Labels are the mechanism you use to organize Kubernetes Objects.
A Label is a Key-value Pair without any predefined meaning that Can be attached to the objects.
Labels are Similar to tags in AWs or git where you use a name for a quick reference.
So you are to Chase labels it as You need it to refer to an environment that is used for dev or testing or Production, refer a Product group like Department A, Department B.
Multiple labels can be added to a single object.
Labels-Selectors
Unlike name/UIDs, labels do not provide Uniqueness, as in general, We can expect many objects to carry the same label.
Once labels are attached to an object, we would need filters to narrow down and these are called label selectors.
Node Selector
One use case for selecting labels is to Constrain the set of nodes onto which a pod can schedule i.e. you can tell a pod to only be able to run on particular nodes.
Generally, such Constraints are Unnecessary, as the Scheduler will automatically do a reasonable placement, but in certain circumstances, we might need it.
We can use labels to tag nodes.
You the nodes are tagged, so you can use the label selectors to specify the pods run only on specific moves.
First, we give a label to the node.
Then use the node selector to the Pod Configuration.
Scaling and Replication
Kubernetes was designed to Orchestrate multiple constraints and replication.
Need multiple containers/ replication helps us with these.
🖇️Reliability
By having multiple versions of an application, you prevent problems if one or more falls.
🖇️Load Balancing
Having multiple versions of a container enables you to easily send traffic to different instances to prevent overloading of a single instance or node.
🖇️Scaling
When the load does become too much for the number of existing instances, Kubernetes enables you to easily scale up your application, adding additional Instances as needed.
🖇️Rolling Updates
Updates to a service by replacing pods one by one.
Replication Controller
A replication controller is an object that enables you to easily create multiple Pods, then make sure that number of Pods always exists.
If a pad is created using an RC-replication controller will be automatically replaced if they do crash, failed, or is terminated.
RC is recommended if you just want to make sure 1 Pod is always running, even after the system reboots.
You can run the RC with 1 replica & the RC Will make sure the Pod is always running.
Replica Set
A replica set is a next-generation Replication controller.
The replication controller only supports equality-based selectors whereas the replica set supports set-based selectors i.e. filtering according to set of values.
The replica set rather than the replication controller is used by other objects like deployment.
Deployment & Rollback
The replication controller & replica set is not able to do updates & rollback apps in the cluster.
A deployment object act as a supervisor for pods, giving you fine grained control over how and when a new pod is rolled out, updated, or rolled back to a previous state.
When using a deployment object, we first define the state of the app, then the K8s cluster schedules mentioned app instance onto specific individual nodes.
K8s then monitors, if the node hosting an instance goes down or the pod is deleted the deployment controller replaces it.
The following are typical use cases of Deployments
create a deployment to roll out a Replicaset– The replica set creates pods in the background. check the status of the rollout to see if it succeeds or not.
Declare the new state of the Pods– By updating the PodTemplateSpec of the deployment. A new replica set is created and the deployment manages to move the pods from the old replica set to the new one at a controlled rate. Each new replica set updates the revision of the Deployment.
Rollback to an earlier deployment revision– If the current state of the deployment is not stable. Each rollback updates the revision of the Deployment.
Scale up the deployment to facilitate more load.
Pause the deployment to apply multiple fixes to its PodTemplateSpec and then resume it to start a new rollout.
Clean up older Replicaset that You don't need anymore.
Happy learning, and welcome to the world of Kubernetes!
Thank you🙏
Keep Learning..