In order to create Deployment objects, as usual, use the kubectl run command or prepare the YAML/JSON file that describe Deployment configuration. This example is using the kubectl run command to create a my-nginx Deployment object:
//create my-nginx Deployment (specify 3 replicas and nginx version 1.11.0)
$ kubectl run my-nginx --image=nginx:1.11.0 --port=80 --replicas=3
deployment.apps "my-nginx" created
//see status of my-nginx Deployment
$ kubectl get deploy
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
my-nginx 3 3 3 3 8s
//see status of ReplicaSet
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
my-nginx-5d69b5ff7 3 3 3 11s
//see status of Pod
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
my-nginx-5d69b5ff7-9mhbc 1/1 Running 0 14s
my-nginx-5d69b5ff7-mt6z7 1/1 Running 0 14s
my-nginx-5d69b5ff7-rdl2k 1/1 Running 0 14s
As you can see, a Deployment object my-nginx creates one ReplicaSet, which has an identifier: <Deployment name>-<hex decimal hash>. And then ReplicaSet creates three Pods which have an identifier: <ReplicaSet id>-<random id>.
For more details, look at pull request: https://github.com/kubernetes/kubernetes/pull/51538.
This diagram illustrates the Deployment, ReplicaSet, and Pod relationship:
Because of this relationship, if you perform delete on a my-nginx Deployment object, it will also attempt to delete ReplicaSet and Pods respectively:
//delete my-nginx Deployment
$ kubectl delete deploy my-nginx
deployment.extensions "my-nginx" deleted
//see status of ReplicaSet
$ kubectl get rs
No resources found.
//see status of Pod, it has been terminated
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
my-nginx-5d69b5ff7-9mhbc 0/1 Terminating 0 2m
my-nginx-5d69b5ff7-mt6z7 0/1 Terminating 0 2m
my-nginx-5d69b5ff7-rdl2k 0/1 Terminating 0 2m
This example is just a simple create and delete, that easy to understand Deployment object and ReplicaSet object 1:1 relationship at this moment. However, a Deployment object can manage many ReplicaSets to preserve as a history. So the actual relationship is 1:N, as in the following diagram:
To understand the 1:N relationship, let's recreate this Deployment object again and perform to make some changes to see how Deployment manages ReplicaSet history.