Notes
Notes
details with respectto these components in the cluster we'regoing to use an analogy
of ships tounderstand the architecture of kubernetes the purpose of kubernetesis 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 thispossible so let's take a ,
10,000 feet look and be covered entities architecture we have
in this example cargo ships that does the actual work of carrying containers
across the sea and control ships that are responsible for monitoring and
managing the cargo ships the current
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.
The master node does all of these using a set of components together known as the
CONTROL PLANE COMPONENTs.
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 HDD cluster actually is what data is stored in it and how it
stores the data in one of the upcoming lectures.
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.
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.
Controller-Manager:
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 .
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.
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.
The CUBE API SERVER periodically FETCHES STATUS REPORTS from the CUBELET to
monitor the status of nodes and containers on them.
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.
Woker 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.