Introduction⌗

Controllers in kubernetes are the building blocks behind orchestration. They maintain the desired state of the cluster by continously monitoring the current state of the cluster and making the required changes to align the two states.

Controllers reconcile the current state of the cluster continously with the the desired state defined in the kubernetes manifest files defined in the Kubernetes manifests.

Kubernetes architecture with controller

Components of a Kubernetes controller⌗

Control loop: core component of the controller that continously checks the current state of the cluster and reconciles it with the desired state.
Desired state: the state of the cluster as defined in a kubernetes manifest file.
Current state: the state of the cluster at the given time.
Reconcialition: the process of comparing and ensuring the current state of the cluster is the same as the desired state.

Types of Kubernetes controllers⌗

Thes are some of the built-in kubernetes controllers:

ReplicaSet Controller: Ensures that the specified number of pod replicas are running at all times.
Deployment Controller: Manages the deployment and scaling of applications by creating and updating ReplicaSets.
StatefulSet Controller: Maintains the state of stateful applications by managing the creation, scaling, and deletion of pods with unique identities.
DaemonSet Controller: Ensures that a specific pod runs on all or certain nodes in the cluster, typically used for system daemons or logging agents.
Job Controller: Manages the execution of short-lived tasks or batch jobs, ensuring completion and optionally, parallelism.
Service Controller: Maintains a stable network endpoint for services by dynamically updating the corresponding Kubernetes service objects.

Built-in controllers manage state by interacting with the cluster API server. They run inside the kube-controller-manager.

Simple implementation of a Deployment controller⌗

This implementation will define a deployment called hello-nginx and deploy three replicas of an Nginx pod:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

Controller patterns⌗

A controller will typically track at least one Kubernetes resource. In the Deployment example above, we have the spec field that represents the desired state. Built in controllers will typically carry out the action by themselves. This brings about 2 ways that actions can be carried out by a controller:

Control by API Server⌗

This is where the controller interacts with the API Server component in the control plane to give instructions on what is needed to complete an action. For example; a Job controller will instruct the API Server to ensure that there are a sufficient number of Pods to execute an action.

If the Pods are less than the required amount, the Job controller will instruct that more Pods be created. This information will eventually get to other components in the control plane that will act on it and the job will be completed.

Direct control⌗

This happens with controllers that need to make changes to things outside your cluster. For example, if a controller requires a to set up things and there are few nodes, it can communicate with an external system to ensure that a new node is created to enable completing the action.

What this means is that the controller will get it’s desired state from the API Server, then communicate with the external system to ensure that there is a current state that matches the desired state.

You can comment on this article by clicking on this link.

Kubernetes Controllers