[No Audio]
From a bird's eye view, the architecture of
Kubernetes cluster would look pretty simple.
We have two types of instances, Master and Nodes.
They both run Kubernetes, but serve different
purposes just like manager and worker of Swarm.
Let's have a deeper look inside Master. Master acts
as a controlling node and while working with
Kubernetes, we communicate with Master for the
most part. It runs a set of applications, which
include kube-apiserver, which serves all of the
REST requests provided by user and obtains
responses from other nodes. You can consider it as
a central serving unit or front end of the
cluster. Then we have kube-controllermanager,
which serves as a parent or managing process for a
number of controller processes. These controller
processes manage the controller objects like
ReplicaSet controller, or deployment controller,
which we will study soon enough. Next, we have
kube-scheduler, which schedules our container
under a supervisory sandbox environment called pod.
kube-scheduler also decides which of the
nodes will be serving which set of containers.
The API requests from kube-controllermanager
and kube-scheduler are served by kube-apiserver.
Finally, we have etcd, which is the
distributed key value data store. etcd stores the
data obtained from all other components in key
value pairs. This may include our cluster
configuration, input desired state, actual
cluster state, event logs, object details,
anything and everything. etcd only communicates
with kube-apiserver for security reasons. So in a
nutshell, kube-controllermanager controls
objects, kube-scheduler schedules containers and
their API's are served by kube-apiserver, which
stores all of their data as a key value pair in
etcd and fetches the data from the same place as well.
This simple yet robust architecture of
Master is one of the reasons for thriving success of Kubernetes.
Now let's talk about nodes.
They're pretty simple compared to Master, they only run
two components to be precise. One is Mr. Talk talk,
and one is Mr. Do do. kubelet is Mr. Do do as
it performs the actions suggested by Master
components like kube scheduler, apiserver,
or controllermanager. Master and nodes are virtually
or physically different machines, which means
kubelet acts as supervisory process on nodes to
allocate resources and create containers or pod processes.
kube-proxy is Mr. Talk talk. It manages
nodes communication with other nodes, Master
and the world outside the cluster.
[No Audio]
In regular case, it is kube-apiserver of Master,
which talks to kube-proxy of the node.
So kube-apiserver gets data
from etcd, it gets requests from controllermanager
and scheduler and passes it to the node via kube-proxy.
Whereas kube-proxy passes it to the
kubelet, which in return provides the response to
these requests, which are again passed to Master
by a proxy and stored on etcd.
[No Audio]
But if the cluster is hosted on
Kubernetes supported Cloud platform,
kube-controllermanager talks to kube-proxy via
Cloud VPC or other such relevant infrastructure,
since it has a component called Cloud controller manager.
Now let's focus on how we as users
interact with Kubernetes. Users talk to the Master
via commands. Let's say we command Master to
create an object, Master passes this instruction as
an API Request. Once kubelet performs its request,
it returns the state of the node as a response,
which Master stores in its etcd and pass it to us.
Objects can be of multiple types, such as
Workloads, Config objects, Connectivity objects, or Storage objects.
Whereas states are of two types,
desired state and current state.
Kubernetes always keeps on checking if the desired state and
current state match.
If they don't match, Kubernetes tries its best to
make sure that they do. And if they do match,
it keeps on checking again and again to make sure
this harmony isn't affected. This endless loop is
called Reconciliation Loop which makes sure that
our cluster is in the most desired state as much as possible.
All in all, this is how Kubernetes
infrastructure functions. Next, we will go through
the objects of Kubernetes and learn how to use them.
And while we do so, you will get a broader
sense and deeper idea of how this infrastructure
is used while creating and using objects.