0% found this document useful (0 votes)
0 views

Lecture 00 Understand-Kubernetes

The document provides an overview of Kubernetes, using analogies like cargo ships to explain its architecture and components, including master and worker nodes, controllers, and pods. It covers the roles of various components such as the Kubelet, Kube-proxy, and the API server, as well as concepts like ReplicaSets, Deployments, and Services. Additionally, it discusses the lifecycle of pods, scaling, and communication within the Kubernetes ecosystem.

Uploaded by

8650340
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
0 views

Lecture 00 Understand-Kubernetes

The document provides an overview of Kubernetes, using analogies like cargo ships to explain its architecture and components, including master and worker nodes, controllers, and pods. It covers the roles of various components such as the Kubelet, Kube-proxy, and the API server, as well as concepts like ReplicaSets, Deployments, and Services. Additionally, it discusses the lifecycle of pods, scaling, and communication within the Kubernetes ecosystem.

Uploaded by

8650340
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 94

Demystifying

Kubernetes
Let’s start with an analogy…
A Cargo Ship…
Carries containers across the sea
A Cargo Ship…
Host Application as Containers ~ Worker Nodes
Overview
Worker Node-1
Control Ships…
Managing & Monitoring of the cargo ships
Control Ships…
Manage, Plan, Schedule, Monitor ~ Master
Overview
Master Worker Node-1
Let’s talk about
Master Components..
Ship Cranes…
Identifies the placement of containers
Ship Cranes…
Identifies the right node to place a containers ~ Kube-Scheduler
Overview
Master Worker Node-1
Scheduler
Cargo Ship Profiles…
HA database ~ Which containers on which ships? When was it loaded?
Cargo Ship Profiles…
HA database ~ Which containers on which ships? When was it loaded? ~ The ETCD Cluster
Overview
Master Worker Node-1
Scheduler

ETCD
Offices in Dock…
● Operation Team Office ~ Ship Handling, Control
● Cargo Team Office ~ verify if containers are damaged, ensure that new
containers are rebuilt
● IT & Communication Office – Communication in between various ships
Controllers
● Node Controllers – Takes care of Nodes | Responsible for onboarding new nodes
in a cluster | Availability of Nodes
● Replicas Controller – Ensures that desired number of containers are running at all
times
● Controller Manager - Manages all these controllers in place
Overview
Master Worker Node-1
Scheduler

Controller
ETCD
Manager
How does each of these services communicate with each other?
Kube API Server
● A primary management component of k8s
● Responsible for orchestrating all operations within a cluster
● Exposes K8s API ,used by external users to perform management operation in the
cluster and number of controller to monitor the state of the cluster

API Server
Overview

kubectl
Scheduler

API API Server

UI Controller
ETCD
Manager

Master Worker Nodes

21
Overview
Scheduler

kubectl

API API Server

UI
Controller
ETCD
Manager

Master Worker Node-1


In nutshell…
$kubectl get componentstatus

[node1 install]$ kubectl get nodes -o wide

NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME

node1 Ready master 92s v1.14.2 192.168.0.18 <none> CentOS Linux 7 (Core) 4.4.0-141-generic docker://18.9.6
node2 Ready <none> 57s v1.14.2 192.168.0.17 <none> CentOS Linux 7 (Core) 4.4.0-141-generic docker://18.9.6
node3 NotReady <none> 39s v1.14.2 192.168.0.16 <none> CentOS Linux 7 (Core) 4.4.0-141-generic docker://18.9.6
node4 NotReady <none> 32s v1.14.2 192.168.0.15 <none> CentOS Linux 7 (Core) 4.4.0-141-generic docker://18.9.6

[node1 install]$ kubectl get componentstatus

NAME STATUS MESSAGE ERROR


scheduler Healthy ok
controller-manager Healthy ok
etcd-0 Healthy {"health":"true"}
Let’s talk about
Worker Components..
Overview
Scheduler

kubectl

API API Server

UI
Controller
ETCD
Manager

Master Worker Node-1


Captain of the Ship
● Manages all sort of activity on the ship
● Let master ship knows they are interested to join
● Sending reports back to master about the status of the ship
● Sending reports about the status of the containers API Server
Captain of the Ship ~ Kubelet
Agent which runs on each nodes of the container

API Server
Overview
Scheduler Kubelet

kubectl

API API Server

UI
Controller
ETCD
Manager

Master Worker Node-1


Communication between Cargo Ships
How does two cargo ships communicate with each other?
Communication between Cargo Ships
How will web server running on one worker node reach out to DB
server on another worker node?

Communication between worker nodes


Kube-proxy
Overview Internet

Scheduler Kubelet Kube-proxy

kubectl

API API Server

UI
Controller
ETCD
Manager

Master Worker Node-1


Let’s talk about
Pods..
Overview Internet

Scheduler Kubelet Kube-proxy

kubectl

API API Server

UI pod
Controller container
ETCD
Manager

Master Worker Node-1


Docker Containers
A popular Container Runtime
Overview Internet

Scheduler Kubelet Kube-proxy

kubectl

API API Server

UI pod
Controller container
ETCD
Manager

Master Worker Node-1


Demo
● Setting up a single Node K8s cluster on Docker Desktop for Mac / Windows

● Setting up 5 Node Kubernetes Cluster on PWK

● Setting up 3 Nodes K8s Cluster on Bare Metal or VM


Let’s Deep Dive
into Pods..
Pod - Concepts
● What is Pod?

● Pod Deployment

● Multi-Container

● Pod Networking

● Inter-Pod & Intra-Pod Networking

● Pod Lifecycle

● Pod Manifest File


Atomic Unit of Scheduling

Virtualization Docker Kubernetes

VM Container Pod
How Pods are deployed?

Scheduler

API Server

Pod

Container

Master
Cluster
Scaling the Pods to accommodate
increasing traffic
Scheduler

Scheduler

API Server

Pod

Container

Master
Worker Node
What if node resources is getting
insufficient?
Worker-2

Scheduler

API Server
Worker-1
Pod

Container

Master
Cluster
What if node resources is getting
insufficient?
Worker-2

Scheduler

API Server
Worker-1
Pod

Container

Master
Cluster
2 Containers in a same Pod

Worker-2

Scheduler

API Server
Worker-1
Pod

Container

Master
Cluster
Pod Networking
Pod 1 Pod 2

Main Supporting Supporting


Controller Controller Controller
:8080 :3000
:7777

10.0.30.50 10.0.30.60
How does these containers
inside Pods communicate with
External World?
Network Namespace
Pod 1 Pod 2

Main Supporting Supporting


Controller Controller Controller
:8080 :3000
:7777

10.0.30.50 10.0.30.60

10.0.30.50:8080 10.0.30.50:3000
How does one Pod talk to
another Pod?

Welcome to Inter-Pod Communication..


Pod Networking
Pod 1 Pod 2

Main Supporting Supporting


Controller Controller Controller
:8080 :3000
:7777

10.0.30.50 10.0.30.60

Pod Network
How does Intra-Pod
communication take place?
Intra-Pod Communication
Pod 1

Supporting
Main Container
Container
:8080 :3000

Localhost

10.0.30.50

:8080 :3000
A Look at Pod Manifest
Get a shell to a running Container

Verifying the Operating System


Stages of Life Cycle of Pod
Lifecycle of a Pod

Pod Pod Pod

Manifest API Server Pending Running Succeeding

Pod

Failed
How can you ensure that there
are 3 Pods instances which are
always available and running
at point in time?

ReplicaSet
What is ReplicaSet all about?
Maintain a stable set of replica Pods running at any given time.

● Ensures that a specified number of Pods are running at any time

a. If there are access Pods, they get killed and vice versa
b. New Pods are launched when they get failed, get deleted and terminated

● ReplicaSet & Pods are associated with “labels”


Replication Controller Vs ReplicaSets
● ReplicaSet is the next generation of Replication Controller
● Both serve the same purpose

ReplicaSet Replication Controller

Set-based Selectors Equality-based Selectors


Labels & Selectors
When Pods are scaled, how are these Pods Managed at such large scale?

Pods Controllers & Services

Labels
Selectors
#Pod-Spec
apiVersion: v1
kind: pod
metadata:
name: nginx-Pod
labels:
app: guestbook
tier: frontend
env: dev
spec:
replicas: 5..
Labels & Selectors
When Pods are scaled, how are these Pods Managed at such large scale?

Pods Controllers & Services

Labels
Selectors
#Pod-Spec
apiVersion: v1
kind: pod
metadata:
name: nginx-Pod
labels:
app: guestbook
tier: frontend
env: dev
spec:
replicas: 5..
Equality-based Selectors Set-based Selectors
Operators: Operators:

= and in notin exists


==
Examples: Examples:

environment = environment in (production,


production tier! = qa) tier notin(frontend,
frontend backend)
Commandline Commandline
: :
$kubectl get pods -l $kubectl get pods -l `enviornment
environment=production in(production)

In Manifest: In Manifest:

.. ..
selector: selector:
environment: matchExpressions:
production tier: -{key:environment,operator:in,values:[prod,qa]}
frontend -{key:tier,operator:Notin,values:[frontend,backend]}
.. ..
Supports: Services, Replication Controller Supports: Job, Deployment, ReplicaSet, DaemonSet
Demo - ReplicaSet
● Manifest file

● Deploy app using RS

● Display and validate RS

● Test – Node Fails

● Test – Scale Up

● Test – Scale Down


ReplicaSet Manifest File

64
ReplicaSet Manifest File
Creating Nginx-rs Pods
$kubectl create –f nginx-rs.yaml
Scaling the Nginx Service
Deployment
Deployment
A Deployment controller provides declarative updates for Pods and ReplicaSets.

You describe a desired state in a Deployment, and the Deployment controller changes
the actual state to the desired state at a controlled rate. You can define Deployments
to create new ReplicaSets, or to remove existing Deployments and adopt all their
resources with new Deployments.

● How is it different from Replicaset?


● ReplicaSet doesn’t provide features like updates & roll backs.
A Single Deployment Manifest File
Do we need to create 3 different Deployment
manifest files for each on these?
ReplicaSet

Answer is “No”. Pods

We can create all 3 different objects


using a single Deployment manifest file
Features of Deployment
● Multiple Replicas
● Upgrade
● Rollback
● Scale Up or Down
● Pause & Resume
Deployment Types - Recreate
● How it works?
○ Shutting down version A and then making sure, version A is turned off... then
bringing up version B.
● Demerits:
○ During this, there will be a downtime of the service. Easy to setup.
Deployment Type – Rolling Updates
● RollingUpdate(Ramped or Incremental)
○ Default updating strategy in Kubernetes.
○ It can take sometime for a complete update process

● How it works?
○ Slowly rollout a version of app by replacing instances one after the other
until all the instances are successfully rolled out.
○ Assume that there are 10 instances of version A which is running behind the
LB. Then update strategy starts with one instance of version B is deployed
When version B is ready to accept traffic, one instance of version A is
removed from the pool
Deployment Type - Canary
● Canary
○ Ideal deployment method for someone who want to test newer version
before it is deployed 100%.

● How it works?
○ This method is all about gradually shifting production traffic from version A
to version B.
○ Lets imagine that there are about 10 instances of app version A running
inside a cluster. You use Canary deployment when you dont want to upgrade
all of your instances. Let's say you upgraded your 2 instances of ver A to
version B then do some testing. If test results are good, then you upgrade
remaining 8 instances to version B. Say, your version B is ready, then you
completely shut down version A.
Deployment Type - Canary
● Blue Green
○ Instance roll out and roll back.

● How it works?
○ Using this method, version B(which is GREEN) is deployed along side version
A(which is BLUE) with exactly same amount of instances.
○ After testing new version with all the requirement, the traffic is switched from
version A to version B at the LB level
Deployment Manifest File

ReplicaSet

Pods
Deployment
Deployment => Pods + ReplicaSet

Deployment

ReplicaSet

Pods
3 Instances of same Nginx Apps running in the form
of Pods

79
3 Instances of same Nginx Apps
running in the form of Pods
3 Instances of same Nginx Apps
running in the form of Pods

Update deployment
3 Instances of same Nginx Apps
running in the form of Pods
Scaling up
Listing Pods by Labels
Services
Services
● Imagine that, you have been asked to deploy web app

● How does this frontend web app exposed to outside world?


● How do front end app connected to backend database?
● How do we resolve Pod IP changes, when they die?
Agenda
● Why do we need services?

● What is Service?

● Type of Services
Services User

192.168.1.1
● Frontend Services
○ A Service which stays between
Service(frontend)
user and frontend pod
● Backend Services Frontend
Pod
○ A Service which communicate
Service(backend)
between frontend Pod and
backend end app:db
Backend
Pod

Node
Types of Services

LoadBalancer
ClusterIP NodePort
Node-1 Node-1

- Reachable within the - Exposing Frontend app Node-1 Node-1 Node-1

cluster. to external world


- Equally distribute the
- Connects Frontend loads
Pods to Backend Pods
Services:
ClusterIP
Services
● Imagine you need to deploy one full fledge app which consists of
frontend app & backend app

● How can we restrict access of backend database to only within


the kubernetes cluster?
User
192.168.1.1:31000

NodePort

10.210.1.1:8080

Services ClusterIP
Services
● Frontend Web app
● Backend DB - Redis
Thank you

You might also like