Test where you look at an existing cluster and are asked to identify where is details with respect to

these components in the cluster.

we'regoing to use an analogy of ships to understand the architecture of kubernetes.

The purpose of kubernetes is to host your applications in the form of containers in an automated
fashion.

So that you can easily deploy as many instances of your application as required and easily enable
communication between different services within your application.

So there are many things involved that work together to make this possible.

So let's take a , 10,000 feet look and be covered entire architecture we have

Two kinds of ships:

CARGO SHIPS:

In this example CARGO SHIPS that does the actual work of carrying containers across the sea.

CONTROL SHIPS:

CONTROL SHIPS that are responsible for monitoring and managing the cargo ships.

KUBERNETES CLUSTER:

The current KUBERNETES CLUSTER consists of a set of nodes which may be physical or virtual on
premise or on cloud that hosts applications in the form of containers these relate to the cargo
ships in this analogy.

CARGO SHIPS (alias KUBERNETES CLUSTER ) responsibilities:

a) carrying containers across the sea.

CONTROL SHIPS responsibilities (alias Master node):

a) Monitoring and managing the cargo ships

WOKER NODES:

The WORKER NODES in the cluster are ships that can load containers.

But somebody needs to load the containers on the ships and not just load plan how to load
identify the right ships, store information about the ships, monitor and track the location of
containers on the ships, manage the whole loading process etc this is done by the CONTROL SHIPS.
That hosts different offices and departments monitoring equipment communication, equipments
cranes for moving containers between ships etc.

The Control ships relate to the Master node in the kubernetes cluster .

The Master node is responsible for managing the kubernetes cluster storing information
regarding the different nodes, planning which containers cause we're.

Monitoring the nodes and containers on them etc.

The Master node does all of these using a set of components together known as the CONTROL
PLANE COMPONENTS.

Control Plane components :

MPSM

a)Manage (managing Kubernetes cluster by storing information regarding the different nodes)

b)Plan (which container cause we’re)

c)Schedule

d)Monitor nodes (monitoring nodes and containers)

we will look at each of these components now. Now there are many containers being loaded and
unloaded from the ships on a daily basis and so you need to maintain information about the
different ships what container is on which ship and what time it was loaded etc all of these are
stored in a highly available key value store known as ETCD.

ETCD is a DATABASE that stores information in a key value format we will look more into what
ETCD cluster actually is what data is stored in it and how it stores the data in one of the
upcoming lectures.
KUBE SCHEDULERS:

when ships arrive you load containers on them using cranes the cranes identify the containers
that need to be placed on ships it identifies the right ship based on its size its capacity the
number of containers already on the ship and any other conditions such as the destination of
the ship, the type of containers it is allowed to carry etc so those are SCHEDULERS in a
KUBERNETES CLUSTER.

A SCHEDULER identifies the right node to place a container on based on the containers
resource requirements the worker nodes capacity or any other policies or constraints such as
taints in toleration x' or no affinity rules that are on them we will look at these in much more
detail with examples and practice tests later in this course we have a whole section on scheduling
alone.
CONTROLLER-MANAGER:

There are different offices in the dock that are assigned to special tasks or departments for
example the OPERATIONS TEAM takes care of ship handling, traffic control etc they deal with
issues related to damages the routes the different ships take etc

The CARGO TEAM takes care of containers when containers are damaged or destroyed they
make sure new containers are made available.

we have these SERVICES OFFICE that takes care of the IT and communications between
different ships.

a)NODE CONTROLLER

Similarly in kubernetes we have CONTROLLERS available that take care of different areas
the NODE CONTROLLER takes care of nodes they're responsible for onboarding new nodes to
the cluster, handling situations where nodes become unavailable or get gets destroyed.

NODE CONTROLLER responsibilities:

a) onboarding new nodes to the cluster.

b) Handling situations where nodes become unavailable or gets destroyed.

REPLICATION CONTROLLER ensures that the desired number of containers are running at
all times in your repetitions rope.

REPLICATION CONTROLLER responsibilities:

a) Ensures that the desired number of containers are running at all times in your repetitions rope
CUBE API SERVER:

So we've seen different components like the different offices the different ships, the datastore,
the cranes but how do these communicate with each other how does one office reach the other
office and who manages them all at a high level. The CUBE API server is the primary
management component of kubernetes.

The CUBE API SERVER is responsible for orchestrating all operations within the cluster it
exposes the kubernetes api which is used by external users to perform management
operations on the cluster as well as the various controllers to monitor the state of the cluster
and make necessary changes as required and by the worker nodes to communicate with the
server .

CONTAINER RUNTIME ENGINE:

Now we're working with containers here containers are everywhere so we need everything to
be container compatible.

Our applications are in the form of containers.

The different components that form the entire management system on the master node could
be hosted in the form of containers.

The DNS SERVICE NETWORKING SOLUTION can all be deployed in the form of containers so we
need these software that can run containers and that's the CONTAINER RUNTIME ENGINE a
popular one being docker so we need docker or it's supported equivalent installed on all the
nodes in the cluster including the master nodes if you wish to host the CONTROL PLANE
COMPONENTS as containers.

Kubernates supports other runtime engines like ‘Control d’ or ‘Rocket’.

Now ee doesn't always have to be docker. Kubernetes supports other runtime engines as well like
container d or rocket .

Cargo ships:

let us now turn our focus onto the CARGO ships now every ship has a CAPTAIN the captain is
RESPONSIBLE FOR MANAGING ALL ACTIVITIES ON THESE SHIPS.

The CAPTAIN IS RESPONSIBLE FOR LEASING WITH THE MASTER SHIPS STARTING WITH LETTING
tHE MASTERSHIP KNOW THAT THEY ARE INTERESTED IN JOINING THE GROUP, RECEIVING
INFORMATION ABOUT THE CONTAINERS TO BE LOADED ON THE SHIP AND LOADING THE
APPROPRIATE CONTAINERS AS REQUIRED, SENDING REPORTS BACK TO THE MASTER ABOUT
THE STATUS OF THIS SHIP AND THE STATUS OF THE CONTAINERS ON THE SHIP ETC.
Captain of the ship (CUBELET):

Now the CAPTAIN of the ship is the CUBELET IN KUBERNETES.

A CUBELET is an AGENT that runs on each node in a cluster it LISTENS for instructions from the
CUBE API SERVER and DEPLOYS OR DESTROYS CONTAINERS on the nodes as required.
CUBE PROXY servers:

The CUBELET was more of a CAPTAIN on the ship that manages containers on the ship.

But the applications running on the worker nodes need to be able to communicate with each
other for example you might have a web server running in one container on one of the nodes and
a database server running on another container on another node.

How would the web server reach a database server on the other node COMMUNICATION
BETWEEN.

WORKER NODES ARE ENABLED by another component that runs on the WORKER NODE known
as the CUBE PROXY SERVICE.

The CUBE PROXY SERVICE ensures that the necessary rules are in place on the worker NODES to
allow the containers running on them to reach each other.

Summary:

Master node:

============

So to summarize we have MASTER and WORKER NODES, on the master we have the ETCD cluster
which stores information about the cluster.

We have the cube scheduler that is responsible for scheduling applications or containers on
nodes.
We have different controllers that take care of different functions like the node controller or
replication controller etc

we have the cube API server that is responsible for orchestrating all operations within the
cluster.

Woker node summary:

======================

on the worker node we have the cubelet that listens for instructions from the cube api server and
manages containers and the cube proxy that helps in communication between services within
the cluster.

So that's a high-level overview of the various components we will drill down into each of these in
the upcoming lectures.

That's it for now and I will see you in the next lecture.

Hello where's the practice session and explore the networking set up in the existing environment
we will start with simple exercises where you will explore an existing kubernetes cluster and view
information about the interfaces, IPS host names, ports etc this will help you familiarize with the
environment and look for information in the future sections going forward we will get into
more challenging exercises for now let's start slow.