Skip to main content

Communication Between User and cluster

We now know what Kubernetes is, its architecure etc. Let's say there exists a Kubernetes cluster. How do you connect to and manage this cluster? How do you deploy your applications? There should be a way to do this. Come, let's see.

Users interact with the Kubernetes cluster primarily through the API Server, which serves as the central point of communication. The API Server exposes a RESTful API that users can access to manage and control the cluster.

User to API Server​

Users can communicate with the API Server using various tools and interfaces, such as:

  • kubectl: The command-line tool for Kubernetes, which allows users to interact with the cluster by sending API requests to the API Server.
  • Kubernetes Dashboard: A web-based UI that provides an interface for users to manage and monitor their Kubernetes clusters.

User to Nodes and Pods​

While users primarily interact with the API Server, there are scenarios where they may need to communicate directly with nodes or pods. For example:

  • Port Forwarding: Users can use kubectl port-forward to forward a local port to a port on a pod, allowing them to access applications running inside the pod directly from their local machine.
  • Exec into Pods: Users can use kubectl exec to execute commands inside a running pod, which allows them to interact with the applications or troubleshoot issues directly within the pod.
  • Logs Access: Users can use kubectl logs to access the logs of a specific pod, which helps in monitoring and debugging applications.

In these cases, the communication between the user and the nodes or pods is facilitated through the API Server, which acts as a proxy to route the requests to the appropriate destinations within the cluster.

kubectl​

kubectl is the most widely used command-line tool when it comes to interacting with a Kubernetes cluster. All the production clusters across the organizations, all DevOps engineers and developers use kubectl. The Kubernetes dashboard it not used widely.

So, we will only see kubectl throughout this course.

How kubectl works​

When a user executes a command using kubectl, the following process occurs:

  1. Command Execution: The user runs a command, such as kubectl get pods, which sends a request to the API Server.
  2. Authentication and Authorization: The API Server authenticates the user and checks their permissions to ensure they have the necessary access rights to perform the requested action.
  3. Request Processing: If the user is authorized, the API Server processes the request and interacts with the relevant components (e.g., etcd, kubelet) to retrieve or modify the requested resources.
  4. Response: The API Server sends a response back to the user, which may include the requested information or a confirmation of the action taken.

Declarative vs Imperative​

kubectl supports both declarative and imperative approaches to managing Kubernetes resources:

  • Declarative: In this approach, users define the desired state of the cluster using YAML or JSON files. They then apply these configurations using kubectl apply -f <file>, and Kubernetes takes care of achieving that state.
  • Imperative: In this approach, users directly execute commands to create, update, or delete resources without using configuration files. For example, kubectl create deployment my-deployment --image=nginx creates a deployment directly from the command line.

In practice, the declarative approach is often preferred for managing Kubernetes resources, as it allows for better version control and reproducibility. However, the imperative approach can be useful for quick tasks or when experimenting with new configurations.