Understanding Kubernetes Controllers: What Actually Makes Kubernetes Work

Why this matters#

Most people start learning Kubernetes through pods, services, and YAML.

That works up to a point. But if you want to understand what actually makes Kubernetes behave like a living system rather than a pile of configuration, there is one concept you cannot skip:

Controllers.

What is a controller?#

Kubernetes is a declarative system.

You do not tell it how to do things step by step. You tell it what state you want the system to reach.

replicas: 3

What you are really saying is:

I want 3 pods running.

That declaration matters, but the declaration alone does not create or repair anything. Kubernetes needs a component that notices the gap between what you asked for and what is actually happening.

That component is a controller.

The controller loop#

Every controller follows the same basic pattern:

Observe -> Compare -> Act -> Repeat

• Observe the current state of the system.
• Compare it with the desired state defined in the API.
• Act to close any gap.
• Repeat continuously.

This loop is why Kubernetes feels automated instead of static.

If a pod disappears, a controller notices. If the replica count drifts, a controller notices. If an Ingress appears and an external load balancer should exist, a controller notices.

Kubernetes keeps working because controllers keep reconciling.

Why controllers matter#

Without controllers, YAML would mostly just sit in etcd.

The API would store your intent, but nothing would keep pushing the system toward that intent in the real world. No restart behavior. No self-healing. No automatic scaling. No traffic setup. No certificate renewal. No GitOps sync. No DNS automation.

Controllers are what turn Kubernetes into a continuously self-correcting system.

• Desired state
• Actual state
• Reconciliation

Core workload controllers#

These are the controllers almost everyone meets first.

Deployment controller#

The Deployment controller manages application rollout behavior.

It does not run pods directly. Instead, it manages ReplicaSets and uses them to handle rollout transitions such as:

• rolling updates
• rollback paths
• scaling changes
• replacement of old versions with new ones

When people say "I deployed an app with a Deployment," this is usually the controller doing the ongoing operational work behind the scenes.

ReplicaSet controller#

The ReplicaSet controller ensures the right number of pod replicas exist.

If you asked for 3 and only 2 are running, it creates another one. If 4 are running when only 3 should exist, it removes the extra one.

This is one of the clearest examples of the reconciliation loop in action.

Scaling controllers#

Scaling in Kubernetes is really a controller story.

Horizontal Pod Autoscaler#

The HPA watches metrics such as CPU, memory, or custom signals and adjusts replica count based on those signals.

That means scaling is not a one-time event. It is continuous feedback:

• load increases
• metrics cross a threshold
• desired replicas change
• the workload controller and ReplicaSet react

Karpenter#

Karpenter focuses on the node side rather than the pod side.

When the cluster does not have enough capacity to schedule workloads efficiently, Karpenter provisions nodes dynamically. In AWS environments, that often means creating EC2 capacity faster and more intelligently than older autoscaling patterns.

Together, HPA and Karpenter show how multiple controllers can cooperate:

• one increases pod demand
• another creates the compute capacity needed to satisfy that demand

Traffic controllers#

Traffic flow in Kubernetes is also controller-driven.

AWS Load Balancer Controller#

This controller watches resources like Ingress and turns them into real AWS load balancer infrastructure.

That can include:

• ALBs or NLBs
• listeners
• target groups
• target registration
• routing rules

The important idea is that Kubernetes intent gets translated into cloud infrastructure through a controller loop.

NGINX Ingress Controller#

The NGINX Ingress Controller handles HTTP routing inside the cluster based on Ingress configuration.

You define routing intent. The controller configures the proxy layer that makes that routing real.

Deployment and platform controllers#

Once teams move beyond basic workloads, platform controllers become much more visible.

Argo CD#

Argo CD watches Git and cluster state and continuously reconciles the cluster toward what is declared in the repository.

That is GitOps in practice:

• Git defines desired state
• Argo CD compares Git to the cluster
• differences are reconciled

ExternalDNS#

ExternalDNS watches Kubernetes resources and creates or updates DNS records automatically.

Instead of manually editing DNS every time an endpoint changes, the controller keeps DNS aligned with cluster resources.

cert-manager#

cert-manager handles certificate issuance and renewal.

Rather than manually requesting and rotating TLS certificates, you define the certificate intent and the controller keeps that lifecycle moving.

Observability controllers#

Controllers also show up in monitoring and platform visibility.

Prometheus Operator#

The Prometheus Operator manages the lifecycle around Prometheus-based monitoring resources.

It turns higher-level custom resources into the Prometheus configuration and operational behavior needed to collect metrics at scale.

Grafana Operator#

The Grafana Operator manages dashboards and related Grafana resources declaratively.

This is a good reminder that controllers are not limited to core Kubernetes objects. They can also power higher-level platform APIs built on top of the Kubernetes control plane.

Niche and situational controllers#

As systems grow more complex, more specialized controllers start to matter.

• OPA Gatekeeper for policy enforcement and compliance guardrails
• Velero for backup and restore workflows
• Istio or Linkerd for advanced traffic and service mesh behavior
• External Secrets Operator for pulling secrets from systems like AWS Secrets Manager or SSM

You do not need all of these on day one, but understanding that they are controller-driven helps the ecosystem feel much less random.

Honourable mentions#

These are worth knowing even if you do not use them every day:

• Crossplane for managing cloud infrastructure through Kubernetes APIs
• ACK for provisioning AWS resources directly from Kubernetes
• KEDA for event-driven autoscaling
• Vertical Pod Autoscaler for adjusting resource requests automatically
• Cilium for advanced networking and security
• Falco for runtime security monitoring
• Kubecost for cost visibility
• Tekton for Kubernetes-native CI/CD workflows

Real-world example: AWS Load Balancer Controller#

Let us make the controller model practical.

You create an Ingress:

apiVersion: networking.k8s.io/v1kind: Ingressmetadata:  name: appspec:  rules:    - host: app.example.com

What you are really saying is:

Expose my app through a managed traffic entry point.

The AWS Load Balancer Controller then does the operational work:

1. It detects the Ingress.
2. It creates or updates an ALB in AWS.
3. It configures listeners and target groups.
4. It connects traffic flow to the right Kubernetes backends.

All of that happens because a controller is continuously translating desired state into real infrastructure behavior.

The key mental model#

Everything comes back to the same idea:

• you define desired state
• controllers observe actual state
• controllers keep making changes until the two align

Once this clicks, many Kubernetes behaviors stop feeling magical.

You can better explain:

• why pods restart
• how rollouts happen
• how scaling decisions propagate
• how traffic gets wired up
• how cloud resources appear

What to explore next#

If you want to go deeper, these are great follow-on topics:

• Ingress and end-to-end traffic flow
• ExternalDNS and domain automation
• cert-manager and HTTPS automation
• HPA plus Karpenter for scaling systems
• Prometheus plus Grafana for observability
• Argo CD for GitOps reconciliation

Final takeaway#

Kubernetes does not "do things" on its own.

Controllers do.

Once you understand controllers, Kubernetes starts to look less like a container launcher and more like a framework for designing self-healing systems.