Kubernetes Control Plane, How it communicates with its masters?

I have a few questions regarding Kubernetes. After reading around, I can somewhat understand what it is. I'll give a short summary on what I think it is. It manages a bunch of pods, that are micro-services/containers, which each pod provides a service. And the pod data is stored the same way as a container, so that the data is accessible by any other pods because it is containerized. I am assuming,if you want to have multiple database gateway, you can.

This all makes sense if it is hosted on a single host, and that you are using this kubernetes as a manager to maintain the health of each micro-service etc etc.

But what i cant seem to understand is how this works when you have more than 1 host. How does 1 kubernetes communicate with another kubernetes? I can just keep scaling up my VM technically, but how does multiple VM come together and have the same effect?

It feels like you need another bigger kubernetes to come in to manage them.

@prasanna kumar gave a detailed explanation. Thanks

Now Kubernetes masters communication takes place via

1. API Server
2. etcd
3. Controller manager

API Server: The API server is the central component of the Kubernetes control plane that exposes the Kubernetes API. It receives requests from users, clients, and other components and communicates with the etcd store to read and update the cluster's state. The API server on each master node connects to the etcd cluster to access and update the shared configuration data.

               +------------------------+
               |    Kubernetes Master 1  |
               |        API Server       |
               +------------------------+
                    |         ^
                    |         |
                    v         |
               +------------------------+
               |    Kubernetes Master 2  |
               |        API Server       |
               +------------------------+
                    |         ^
                    |         |
                    v         |
               +------------------------+
               |         etcd           |
               +------------------------+

etcd: etcd is a distributed key-value store used by Kubernetes to store and manage the cluster's configuration data and state. It serves as a reliable data store accessible by all the master nodes. Each master node connects to the etcd cluster to read and write information about the cluster's state.

               +------------------------+
               |    Kubernetes Master 1  |
               +------------------------+
                    |         ^
                    |         |
                    v         |
               +------------------------+
               |    Kubernetes Master 2  |
               +------------------------+
                    |         ^
                    |         |
                    v         |
               +------------------------+
               |         etcd           |
               +------------------------+

Controller Manager: The controller manager runs various controllers that monitor the state of the cluster and make necessary adjustments to ensure the desired state is maintained. The controller manager on each master node communicates with the API server to retrieve information and perform actions based on the desired state.

           +------------------------+
           |    Kubernetes Master 1  |
           |    Controller Manager   |
           +------------------------+
                |         ^
                |         |
                v         |
           +------------------------+
           |    Kubernetes Master 2  |
           |    Controller Manager   |
           +------------------------+
                |         ^
                |         |
                v         |
           +------------------------+
           |         etcd           |
           +------------------------+

These are the core components that facilitate communication and coordination between the Kubernetes masters in a cluster. The etcd store holds the cluster's configuration and state, the API server exposes the Kubernetes API and interacts with etcd, and the controller manager monitors and manages the cluster based on the desired state.

Together, these components ensure that the Kubernetes masters work together as a cohesive unit, sharing information, and coordinating actions to maintain the health and functionality of the cluster.

Now sharing of resources with in the Kubernetes master takes place as follows:

Imagine you have a Kubernetes cluster consisting of multiple nodes, which can be physical or virtual machines. Each node represents a host that can run containers. In a multi-node setup, you might have three nodes, labeled as Node A, Node B, and Node C.

       +------------------------+
       |         Node A         |
       +------------------------+
                /       \
               /         \
              /           \
+-------------------+   +-------------------+
|       Node B      |   |       Node C      |
+-------------------+   +-------------------+

On each node, there is a Kubernetes runtime environment responsible for managing containers and executing pods.

Now, let's say you have a Kubernetes cluster with multiple pods, each containing one or more containers. These pods represent your microservices or applications.

       +------------------------+
       |         Node A         |
       +------------------------+
                /       \
               /         \
              /           \
+-------------------+   +-------------------+
|     Pod 1         |   |    Pod 2          |
|                   |   |                   |
|   Container 1     |   |   Container 1     |
+-------------------+   +-------------------+

The pods are distributed across the nodes based on resource availability and constraints. The Kubernetes scheduler component decides which nodes to place the pods on.

To enable communication between pods running on different nodes, Kubernetes establishes a network overlay across the cluster. This network overlay provides each pod with its unique IP address, allowing them to communicate with each other seamlessly.

       +------------------------+
       |         Node A         |
       +------------------------+
                /       \
               /         \
              /           \
+-------------------+   +-------------------+
|     Pod 1         |   |    Pod 2          |
|   IP: 10.0.0.1    |   |   IP: 10.0.0.2    |
|                   |   |                   |
|   Container 1     |   |   Container 1     |
+-------------------+   +-------------------+

So, even though Pod 1 is running on Node A and Pod 2 is running on Node B, they can communicate with each other using their respective IP addresses.

The control plane components of Kubernetes, including the API server, scheduler, and controller manager, ensure that the desired state of the cluster is maintained. They coordinate the actions across the nodes to achieve scalability, high availability, and fault tolerance.

If you want to scale your Kubernetes cluster itself, you can set up multiple Kubernetes master nodes. These master nodes work together and communicate with each other to manage the cluster's state and ensure the desired state is maintained.

          +------------------------+
          |     Kubernetes Master 1 |
          +------------------------+
                      |
                      |
                      v
          +------------------------+
          |     Kubernetes Master 2 |
          +------------------------+

By having multiple master nodes, you ensure that if one master node fails, the other nodes can take over and maintain the cluster's operation.

This visual representation demonstrates how Kubernetes manages a multi-node setup, distributes pods, enables inter-pod communication, and ensures the cluster's health and scalability.