Introduction

Kubernetes is driven by controllers, which are reconciliation loops that keep actual cluster state aligned with desired state. When you want to understand why resources keep getting recreated or updated, one of the first useful steps is to inventory the controllers active in the cluster.

What “Controllers” Means in Practice

There is no single kubectl command that prints every controller in one perfect list. In a real cluster, controllers come from three places:

• built-in workload controllers such as Deployments and Jobs
• control-plane components such as kube-controller-manager
• custom operators that watch custom resources

Because of that, a practical inventory is a combination of API object listing and control-plane inspection.

List the Main Workload Controllers

The simplest starting point is to list the controller-backed resource types you normally work with:

kubectl get deployments,statefulsets,daemonsets,replicasets,jobs,cronjobs -A

This shows the most visible application-level controllers across all namespaces. It answers questions such as which Deployments are present, which DaemonSets are scheduling agents onto every node, and which CronJobs are creating Jobs on a schedule.

If you prefer a namespace-by-namespace view during troubleshooting, narrow the scope:

kubectl get deployments,statefulsets,daemonsets,replicasets,jobs,cronjobs -n payments

That is often easier to read when you are focused on one service rather than the whole cluster.

Inspect the Control Plane

The Kubernetes control plane also runs controllers. In self-managed clusters, you can usually see them in the kube-system namespace:

kubectl get pods -n kube-system -o wide
kubectl get pods -n kube-system | grep controller

You may see kube-controller-manager, cloud controller manager components, or operator pods installed by the platform team. On managed offerings, parts of the control plane can be hidden, so you will not always get a full pod-level view. That does not mean those controllers are absent. It only means the provider manages them outside your namespace-level visibility.

Find Custom Controllers and Operators

Many production clusters run far more custom controllers than built-in ones. Common examples include cert-manager, Argo CD, external-dns, service mesh controllers, and database operators.

A useful discovery pattern is:

kubectl get crd
kubectl get deployments -A | grep -Ei 'operator|controller'
kubectl get pods -A | grep -Ei 'operator|controller'

Custom Resource Definitions tell you which APIs may be backed by operators. Deployment and pod searches help you locate the actual controller processes running those loops.

If you identify a likely operator, inspect it directly:

kubectl describe deployment -n cert-manager cert-manager

That gives you image names, labels, and event history, which are useful when you need to confirm which controller version is active.

Trace Ownership from Resources

Sometimes the real question is not “what controllers exist” but “what controller owns this object”. Kubernetes records that through ownerReferences.

kubectl get pod web-6d9d7fdb4b-7r4pv -n frontend -o yaml

In the output, look for the ownerReferences section. A pod is often owned by a ReplicaSet, which is in turn owned by a Deployment. That ownership chain explains why deleting a pod does not make it stay gone.

You can also summarize ownership quickly:

kubectl get pods -n frontend \
  -o jsonpath='{range .items[*]}{.metadata.name}{" -> "}{.metadata.ownerReferences[0].kind}{"\n"}{end}'

This is useful during incidents where you need to identify the controller recreating resources after manual intervention.

Build a Repeatable Inventory

If you need the same inspection often, a short shell loop is enough:

1#!/usr/bin/env bash
2set -euo pipefail
3
4for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
5  echo "=== $ns ==="
6  kubectl get deployments,statefulsets,daemonsets,replicasets,jobs,cronjobs -n "$ns" --ignore-not-found
7  echo
8done

Save it as list-controllers.sh, make it executable with chmod +x list-controllers.sh, and run it when you need a snapshot. This is still a manual inspection aid, not a replacement for understanding what each controller does.

Know the Limits of the Output

A controller is not always represented by a resource named “controller”. For example, a Deployment is itself a controlled object whose actual reconciliation loop lives in the control plane. An operator might also expose a friendly Deployment name that does not include the word “operator”.

That means your inventory should combine several signals:

• controller-backed workload objects
• control-plane pods you can see
• operator deployments and pods
• CRDs that imply a controller exists

Relying on only one of those often produces an incomplete picture.

Common Pitfalls

• Expecting one kubectl command to list every controller in every cluster configuration.
• Looking only in the current namespace and missing cluster-wide controllers.
• Forgetting that managed Kubernetes providers may hide control-plane components.
• Treating every pod in kube-system as a controller without checking what it actually runs.
• Ignoring CRDs and operators, which is where many important production controllers live.

Summary

• There is no single built-in command that shows every Kubernetes controller.
• Start by listing Deployments, StatefulSets, DaemonSets, ReplicaSets, Jobs, and CronJobs across namespaces.
• Inspect kube-system for visible control-plane controllers when your platform exposes them.
• Use CRDs, operator deployments, and owner references to find custom reconciliation loops.
• Build a repeatable inventory process, but interpret the results with an understanding of how Kubernetes ownership works.