How to do it...

You may run the kubectl run command to recreate my-nginx, or write a Deployments configuration file that produces the same result. This is a great opportunity to learn about the Deployment configuration file. 

This example is an equivalent of kubectl run my-nginx --image=nginx:1.11.0 --port=80 --replicas=3:

$ cat deploy.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      run: my-nginx
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx:1.11.0
        ports:
        - containerPort: 80

These parameters, sorted by key and value, are described here:

If you use this YAML file to create a Deployment, use the kubectl create command instead of kubectl run.

Note that, this time, you should also specify --save-config, which allows you to update the resource using the kubectl apply command in the future. In addition, specify --record which can store the command line history. Those two options are not mandatory to manage ReplicaSet history but help you to preserve better information:

//use -f to specify YAML file
$ kubectl create -f deploy.yaml --save-config --record
deployment.apps "my-nginx" created 


//check my-nginx Deployment
$ kubectl get deploy
NAME       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
my-nginx   3         3         3            3           5s


$ kubectl describe deploy my-nginx
Name:  my-nginx
Namespace: default
CreationTimestamp: Wed, 09 May 2018 03:40:09 +0000
Labels:  <none>
Annotations: deployment.kubernetes.io/revision=1
 kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"name":"my-nginx","namespace":"default"},"spec":{"replicas":3,"selector":{"mat...
 kubernetes.io/change-cause=kubectl create --filename=deploy.yaml --save-config=true --record=true
Selector:  run=my-nginx
Replicas:  3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:  RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
 Labels: run=my-nginx
 Containers:
 my-nginx:
 Image: nginx:1.11.0
 Port:  80/TCP
 Host Port: 0/TCP
 Environment: <none>
 Mounts:  <none>
 Volumes: <none>
Conditions:
 Type  Status Reason
 ----  ------ ------
 Available True MinimumReplicasAvailable
 Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet:  my-nginx-54bb7bbcf9 (3/3 replicas created)
Events:
 Type Reason  Age  From  Message
 ---- ------  ---- ----  -------
 Normal ScalingReplicaSet 34s  deployment-controller Scaled up replica set my-nginx-54bb7bbcf9 to 3

You can see a property OldReplicaSets and  NewReplicaSet in the preceding code, which are some association between Deployment and ReplicaSet.

Whenever you update a definition of a container template, for example, changing the nginx image version from 1.11.0 to 1.12.0, then Deployment my-nginx will create a new ReplicaSet. Then the property NewReplicaSet will point to the new ReplicaSet which has nginx version 1.12.0.

On the other hand, the OldReplicaSets property points to an old ReplicaSet which has nginx version 1.11.0 until new ReplicaSet is complete to setup new Pod.

These old/new ReplicaSet associations between Deployment, Kubernetes administrator can easy to achieve rollback operation in case new ReplicaSet has any issues.

In addition, Deployment can keep preserves the history of ReplicaSet which were associated with it before. Therefore, Deployment can anytime to change back (rollback) to any point of older ReplicaSet.