How to Check the Ownership of a Pod in Kubernetes

Products

• VMware vSphere Kubernetes Service

Issue/Introduction

Administrators or users may need to identify which Kubernetes controller or resource is responsible for creating and managing a specific pod. This is crucial for troubleshooting, scaling, managing lifecycle, or understanding pod behavior in the cluster.

Environment

VMware vSphere Kubernetes Service

Cause

Pods in Kubernetes are often created and overseen by higher-level controllers such as ReplicaSets, DaemonSets, Deployments, StatefulSets, or custom controllers. The pod itself maintains metadata identifying its immediate owner via ownerReferences.

Identifying this ownership correctly helps understand how the pod is managed and how changes might propagate.

Resolution

To determine the parent resource or controller of a pod, follow these general steps:

• Inspect Pod Metadata for OwnerReferences
  • Run the command: kubectl get pod <pod-name> -n <namespace> -o yaml
  • Look under metadata.ownerReferences. This field lists the resource(s) that directly own the pod, including:
    • kind: The type of parent resource (e.g., ReplicaSet, DaemonSet, StatefulSet, Job, CronJob, etc.).
    • name: The name of the parent resource.
    • uid: Unique identifier of the owner object.

Example snippet:

ownerReferences:
- apiVersion: apps/v1
  kind: ReplicaSet
  name: example-rs
  uid: abc12345-####-####-####-####

• Trace Ownership Hierarchy Recursively (if needed)
  • Many pods are not directly created by top-level controllers but by intermediate controllers. For instance:
    • A Pod may be owned by a ReplicaSet, which in turn is owned by a Deployment.
    • A Job may own Pods, and a CronJob may own Jobs.
  • To find the root owner, query the owner resource and check its ownerReferences. Repeat the process until you find a resource without owners — this is the root controller.

Command to inspect owner resource: kubectl get <kind> <name> -n <namespace> -o yaml

Replace <kind> and <name> with the kind and name found in the pod’s ownerReferences.

• Use Quick Inspection
  • To quickly see the immediate owner kind: kubectl get pod <pod-name> -n <namespace> -o jsonpath='{.metadata.ownerReferences[0].kind}'
• Consider Workloads Controlled by Custom or Specialized Controllers
  • Pods can be managed by custom controllers or operators. The methodology remains the same — check ownership annotations in ownerReferences.

Additional Information

1. Pods without ownerReferences are typically standalone and directly created by users or scripts.
2. Understanding pod ownership is critical for safe deletion — deleting a pod managed by a controller may cause it to be recreated automatically.
3. Recursive tracing helps understand complex ownership chains in nested workloads.