Hi let us understand about various components of kubernetes. Within kubernetes
the working hours is a pod. So pod is going to be the working hour where the pod can have
n number of containers, as we discussed
earlier container is nothing but a entity
which is going to encapsulate an image from
any repository. Let's assume I do have a
repository and it may have n number of
images within it, let's assume I do have an
image http, a web server I can use this
particular image as a part of this particular
pod and pod can have n number of other
containers as well along with this particular
container. Say if I have http I may need some
other containers to manage this particular
container mostly we will be using a mesh
mostly we will be using some sort of a proxy
For now assume there may or there may not
be another container and a pod can have
n number of containers. Kubernetes is all
about managing or orchestrating this
particular pod. I may want to start n number
of pods and manage them within the
infrastructure. So we call that as an
orchestrator for that I am going to use a
client code kubectl. How this particular pod
should get created, so declaratively I will be
defining the structure of the pod that will be
using a yaml file. So this will have the details
on what should be the image and what port
of this particular container should get exposed
and what type of pod should get created all
this informations will be available as a part of
this particular xyz.yaml file. Now I can use this
particular kubectl and use this yaml file and
create the pod. So the pod will get created
using the kubernetes cluster and cluster
it's going to have master and worker and
there are n number of components available
as a part of master worker architecture to
manage this particular pods. Assume I do
have a master and n number of workers. As
we discussed earlier the worker needs to
report to the master. The workers will have
a component called kubelet, a small
process or a daemon which will continue to run in
each worker machine and to manage all this
worker or this kubelet I am going to have a
controller within the master. There are n
number of controllers available like node
controller, replication controller, router, volume
and many more. So this controller will be
controlling how this particular node should
behave, what are all the availability of the
resources and what work currently it is doing
all will be controlled by this particular
controller and I'm going to start a pod within
this worker machines and pod going to have
a container. So I need a runtime to run the
containers, so I need a container runtime
in each worker machine. Container run time it
could be of docker racket rkt or even containerd
predominantly we will be using docker and
depending on the type of runtime that
corresponding containers would get created
within the pod. So each worker machine will
have a run time to start the containers and to
interact with this particular cluster I need to
have a component that is called API server.
So the user will be interacting with this API
server and provide the yaml file and say I
wanted this type of infrastructure or this
many number of pods to get created and
depending on the availability of the resources
the kube scheduler will schedule there is
another component called kube scheduler
where the pod should get created, what type
of pod should get created, how it should get
created. So correspondingly the pod would
get created. So all these pods will be
managed by kube scheduler and within the pod
I am going to have the containers and I can
consolidate and group all these containers
together and I will be calling that as a service
say I may deploy an application and that
should have three web servers and a load
balancer and all this will be consolidated and
managed together as a service like this we
have n number of components involved
within kubernetes we will be seeing all of them
one after the other and basically the core
building block of kubernetes is a pod and the
pod going to have n number of containers
most of the time it is recommended to have
just one containers but it can have other
containers we call them as sidecar or the
container that's going to work closely with
the core container. Now I can go ahead and
add n number of workers or remove the
worker for any other maintenance purpose
and do the configuration within the cluster all
this needs to be stored and I'm going to use
a database called etcd and this is a key
value pair database and the configurations
will be stored within the etcd database and
for high availability I can go for multiple
masters as well. Now we do have all the
components put in a single place, now let's
explore the components available as a part
of the master as well as the workers. So
within master I'm going to have API server
that will be used for the users to interact with
and I am going to have a kube scheduler to
manage the pods and which node should do
that particular work of the pod in
which node the pod should get started and where it should not get started, how the load
is within the nodes all will be managed by the kube scheduler and what are all the nodes
available and how the replication can happen
where it can happen all will be controlled by
this controllers and there are n number of
controllers available, as of now assume I do
have a controller to do different type of
controls like replications routing volumes and
other activities. In the same way I do have a
key value pair database called etcd database. The similar
way if I get into the worker machines each
worker machine it's going to have a
component called kubelet and it's going to
have a container runtime environment it
could be of docker rkt or containerd
Containerd is open sourced by docker and rkt
is another type of container provided by red
hat and I will be having another small
component called kube proxy to take care of
the networking. All the pods and the
containers across the nodes needs to be
communicated within each other and that
will be facilitated by the kube proxy. So just to
recall how the workflow will happen the user
will be having a yaml file that is declarative
way of defining how the services or the pod
should exist and that will be provided to the
API server and that is done using a
component called kubectl and API server will
process this yml file with the help of
kube scheduler and the controller it will
define which are all the worker machine
should have the pods and how many pods
and where it should get created. So the pods
will be assigned, so that's going to have X
amount of capacity of memory processing
capacity within that the containers can get
started. So the worker machines will be
communicating with the registry or the
repository to get the image of the container
get the container started and the proxy
available will facilitate the networking within
the worker machines and the kubelet it's also
called as an agent. So that's going to keep
providing the report to the controller how
much amount of resources available and
where the future pods can be started that
can be controlled and managed by the
controller. So in a quick summary we had
seen what are all the different type of
components available within a kubernetes
cluster and this is a high-level overview on
how all this components going to come
together we will be discussing each and
every component in detail this is just a quick introduction on various
terminologies and the components involved within kubernetes.