Kubernetes has become the de facto standard for container orchestration, offering a powerful platform for deploying, scaling, and managing containerized applications. At the heart of Kubernetes are controllers, which play a crucial role in ensuring that the desired state of your application is maintained and that your resources are managed efficiently. In this article, we’ll explore the concept of Kubernetes controllers in detail, and understand their significance. Each of these Controllers will be discussed with Examples in the later articles.

What are Kubernetes Controllers?

Kubernetes controllers are control loops that continuously watch the state of your cluster’s resources and take action to bring the actual state closer to the desired state specified in your configuration. They are responsible for managing the lifecycle of various Kubernetes resources, such as Pods, ReplicaSets, Deployments, StatefulSets, DaemonSets, Jobs, and CronJobs. Controllers monitor changes to these resources, reconcile any discrepancies between the current state and the desired state, and ensure that the system remains in the desired configuration.

Why are Kubernetes Controllers Important?

Kubernetes controllers are essential for ensuring the reliability, scalability, and resilience of your applications running on Kubernetes. By automating the management of resources, controllers help eliminate manual intervention, reduce human error, and maintain system stability. Controllers also enable key features such as auto-scaling, self-healing, rolling updates, and rollback, making Kubernetes an ideal platform for deploying and managing cloud-native applications.

You should never deploy a static pod, instead wrap it in a Controller.

What is Resources in Kubernetes:

In Kubernetes, a resource refers to any entity that the system is capable of managing or manipulating, such as Pods, Services, Deployments, ConfigMaps, Secrets, and more. Resources are the building blocks of Kubernetes applications and represent the various components that make up an application or system.

  • Objects with State: Resources in Kubernetes are objects that have a state and configuration associated with them. For example, a Pod resource defines a single instance of a running application, while a Service resource defines a set of Pods and a policy for accessing them.
  • Managed by the Kubernetes API Server: All resources in Kubernetes are managed by the Kubernetes API server, which provides a RESTful interface for interacting with the cluster. Users can create, update, delete, and query resources using kubectl commands or by making API requests directly.
  • Declared in YAML or JSON Manifests: Resources in Kubernetes are typically declared using YAML or JSON manifests, which specify the desired state and configuration of the resource. These manifests define attributes such as the resource’s name, labels, annotations, specifications, and more.
  • Controlled by Controllers: Many resources in Kubernetes are controlled by controllers, which are responsible for ensuring that the desired state specified in the resource manifests is achieved and maintained. For example, a Deployment resource is controlled by a Deployment controller, which manages the creation, scaling, and updating of Pods according to the Deployment’s specifications.
  • Namespaced or Cluster-wide: Resources in Kubernetes can be namespaced or cluster-wide. Namespaced resources are scoped to a specific namespace within the cluster and are only visible and accessible within that namespace. Cluster-wide resources, on the other hand, are accessible from any namespace within the cluster.

Types of Controllers in Kubernetes:

Following Controllers you would use to manage the workload.

  1. ReplicationController(deprecated):
    • Manages the lifecycle of replicated Pods.
    • Ensures that a specified number of Pod replicas are running at all times.
    • If a Pod fails or gets deleted, the ReplicationController replaces it to maintain the desired number of replicas.
  2. ReplicaSet:
    • An evolution of the ReplicationController with more powerful selector options.
    • Supports set-based selector requirements, enabling more flexible Pod matching.
    • It’s recommended to use ReplicaSets instead of ReplicationControllers for newer deployments.
    • Recommended to use it in the Deployments Controller.
  3. DaemonSet:
    • Ensures that a copy of a Pod runs on each node in the cluster.
    • Typically used for system daemons or background services that should run on every node, such as log collectors or monitoring agents.
    • Automatically adds or removes Pods as nodes are added or removed from the cluster.
  4. Deployments:
    • Provides declarative updates to Pods and ReplicaSets, enabling easy rollouts and rollbacks.
    • Allows you to define the desired state and automatically manages the creation and scaling of ReplicaSets.
    • Supports strategies like rolling updates and blue-green deployments.
  5. StatefulSets:
    • Manages stateful applications by providing stable, unique network identifiers and persistent storage for each Pod.
    • Ensures predictable, ordered deployment and scaling of Pods.
    • Useful for applications like databases, message brokers, or key-value stores that require stable network identities and storage.
  6. Jobs:
    • Runs a batch job to completion, terminating once the job completes successfully.
    • Creates one or more Pods to perform a task and ensures that the task is completed before terminating the Pods.
    • Suitable for short-lived, parallelizable workloads like data processing, batch jobs, or backups.
  7. CronJobs:
    • Runs Jobs on a recurring schedule specified using cron syntax.
    • Automatically creates Jobs based on a schedule and ensures that they are executed at specified intervals.
    • Useful for automating repetitive tasks like periodic backups, data synchronization, or report generation.
  8. Horizontal Pod Autoscaler (HPA):
    • An HPA controller automatically scales the number of Pods in a ReplicaSet or Deployment based on observed CPU utilization or other select performance metrics.

Apart from the discussed Workload management Controllers, there are several internal Control Plane Controllers used to manage Nodes, and Kubernetes cluster.

  • Node Controller: The guardian of worker nodes, responsible for detecting and responding to node failures or restarts. It attempts to cordon and drain unhealthy nodes and replenish the cluster with new healthy nodes.
  • Route Controller (cloud-specific): These controllers, managed by your cloud provider (e.g., GKE, EKS), handle cloud-specific networking aspects like creating and managing routes for Services exposed through NodePorts or LoadBalancers.
  • Custom controllers extend Kubernetes functionality by defining custom resources and their controllers. These controllers manage custom resources specific to your applications or infrastructure needs. Popular use cases include database management, certificate management, and monitoring tools.

A Business Case Study:

Let us say Shopify, is using Kubernetes to manage its online store application. The company faces the challenge of efficiently managing the workload of its application, ensuring high availability, scalability, and resilience to handle varying levels of customer traffic. Shopify’s online store experiences fluctuating levels of customer traffic throughout the day, with peak loads during promotional events or holiday seasons. The company needs a robust solution to automatically scale its application resources up or down based on demand, ensuring optimal performance and cost-effectiveness.

Solution:

To address this challenge, Shopify decides to leverage Kubernetes controllers to manage its workload dynamically. Specifically, it employs the Horizontal Pod Autoscaler (HPA) controller to automatically adjust the number of application Pods based on CPU utilization metrics.

Sample Deployment example:

Shopify’s online store application is deployed as a set of microservices, including frontend, backend, and database components. Each microservice is deployed as a Deployment resource managed by Kubernetes. This is an over simplified example.

YAML
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
      - name: frontend
        image: shopify/frontend:latest
        ports:
        - containerPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: backend
  template:
    metadata:
      labels:
        app: backend
    spec:
      containers:
      - name: backend
        image: shopify/backend:latest
        ports:
        - containerPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: database
spec:
  replicas: 1
  selector:
    matchLabels:
      app: database
  template:
    metadata:
      labels:
        app: database
    spec:
      containers:
      - name: database
        image: shopify/database:latest
        ports:
        - containerPort: 3306

Now we will configure HPA:

To automatically scale the frontend Deployment based on CPU utilization, Shopify configures an HPA resource as follows:

YAML
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: frontend-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: frontend
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      targetAverageUtilization: 50

You can use similar configs for other services:

  • The HPA resource named frontend-hpa is configured to monitor the CPU utilization of the Pods in the frontend Deployment.
  • It maintains a target average CPU utilization of 50%.
  • The minimum number of replicas is set to 3, and the maximum is set to 10.
  • Based on CPU utilization metrics, the HPA controller dynamically adjusts the number of frontend Pods within the specified range.

By leveraging the HPA controller, Shopify achieves the following benefits:

  • Automatic Scaling: The frontend Pods scale up or down automatically based on CPU utilization, ensuring optimal performance during peak traffic periods and cost savings during off-peak periods.
  • High Availability: The HPA controller maintains a minimum number of frontend Pods to ensure high availability and resilience to sudden spikes in traffic.
  • Cost Efficiency: By scaling resources dynamically, Shopify optimizes resource utilization and reduces cloud infrastructure costs.

Conclusion:

By understanding these core Kubernetes controllers and how they work together, you gain a deeper appreciation for the orchestration magic happening behind the scenes.

These controllers are essential for managing and maintaining the desired state of a Kubernetes cluster. They provide a way to declaratively manage resources and ensure that the cluster is running as expected.

Kubernetes controllers are fundamental building blocks for managing your applications on Kubernetes. By understanding how controllers work and leveraging them effectively, you can automate the management of your resources, ensure system reliability, and streamline your application deployment and management processes. We will learn each of these controllers in the subsequent Articles.

By |Last Updated: April 16th, 2024|Categories: Kubernetes|

Table of Contents