Introduction

When you create a Kubernetes Deployment, Kubernetes does not just run your containers directly. The Deployment object is created first, then the deployment controller creates a ReplicaSet, and the ReplicaSet creates the Pods. Understanding that ownership chain is the key to understanding what API objects appear after a deployment is applied.

What gets created directly

If you run:

kubectl apply -f deployment.yaml

the object you directly submit to the API server is the Deployment itself:

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: web
5spec:
6  replicas: 3
7  selector:
8    matchLabels:
9      app: web
10  template:
11    metadata:
12      labels:
13        app: web
14    spec:
15      containers:
16        - name: nginx
17          image: nginx:1.27
18          ports:
19            - containerPort: 80

That object does not directly "become pods". It describes desired state for a controller.

The object chain: Deployment to ReplicaSet to Pod

After the Deployment is accepted:

1. The deployment controller creates a ReplicaSet.
2. The ReplicaSet creates the requested number of Pods.
3. The controllers keep reconciling state if pods die or the deployment changes.

You can see that chain with:

kubectl get deployment,replicaset,pods

Typical output will show one deployment, one replica set, and the pod replicas created by that replica set.

This ownership model is why rolling updates work. A new deployment revision usually creates a new ReplicaSet, scales it up, and scales the old one down gradually.

Inspect ownership with ownerReferences

Kubernetes tracks this relationship explicitly through ownerReferences. For example, a ReplicaSet created by a Deployment points back to that Deployment, and each managed Pod points back to its owning ReplicaSet.

You can inspect this with:

kubectl get rs web-abcdef123 -o yaml
kubectl get pod web-abcdef123-xyz99 -o yaml

Look for the ownerReferences section. That is what lets Kubernetes garbage-collect dependents and reason about controller ownership.

What is not created automatically

A Deployment does not automatically create everything related to an application. In particular, it does not create:

• a Service
• an Ingress
• a ConfigMap
• a Secret
• a PersistentVolumeClaim

Those objects must be created separately if your application needs them.

This is a common point of confusion. People sometimes create a Deployment and expect network access from a stable service name to exist automatically. It does not. For stable in-cluster access, you usually create a Service alongside the deployment.

Why there can be multiple ReplicaSet objects

After updates, a deployment often owns more than one ReplicaSet. Only one is normally active at full scale, but old ones may still exist for rollout history and rollback support.

For example:

kubectl rollout history deployment/web

If you change the pod template, Kubernetes creates a new ReplicaSet for the new revision. That is why kubectl get rs sometimes shows old replica sets with zero replicas.

Common Pitfalls

The biggest mistake is saying "the deployment creates pods directly". Operationally, the deployment causes pods to exist, but the actual direct creator is the ReplicaSet.

Another common issue is expecting a Service to appear automatically. Deployments manage pod replicas, not service discovery resources.

Developers also get confused by multiple replica sets after rollouts and think stale objects are an error. Often they are just rollout history.

Finally, remember that deleting a pod created by a deployment usually does not remove the workload. The ReplicaSet sees that one replica is missing and creates another.

Summary

• The object you create directly is the Deployment.
• The deployment controller creates a ReplicaSet.
• The ReplicaSet creates and maintains the Pods.
• A Deployment does not automatically create a Service, Ingress, or other supporting resources.
• Use kubectl get deployment,replicaset,pods and inspect ownerReferences to see the ownership chain clearly.