In production you almost never create a ReplicaSet. You create a Deployment, and it creates ReplicaSets for you.

The chain

learner@shallows:~$ kubectl create deployment web --image=nginx:1.27 --replicas=3
deployment.apps/web created
learner@shallows:~$ kubectl get deploy,rs,pods
NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/web   3/3     3            3           5s

NAME                             DESIRED   CURRENT   READY   AGE
replicaset.apps/web-7676f9f845   3         3         3       5s

NAME                           READY   STATUS    RESTARTS   AGE
pod/web-7676f9f845-2426w       1/1     Running   0          5s
pod/web-7676f9f845-97gjb       1/1     Running   0          5s
pod/web-7676f9f845-hwcqp       1/1     Running   0          5s

deploy is the short name. The ReplicaSet is named after the Deployment plus a hash of the Pod template; its Pods add a second suffix.

Why the extra layer

A ReplicaSet's template cannot change. A Deployment's can. When you change the image, the Deployment makes a new ReplicaSet with the new template and moves Pods from the old one to the new one, a few at a time. That is a rollout, and the next lessons are about it.

Reading the columns

A healthy Deployment has all three equal to replicas. describe deploy adds the conditions, the current and old ReplicaSets, and Events like Scaled up replica set web-7676f9f845 from 0 to 3.