写在前面：

deployment和replicateSet都是管理pod的工具，那么他们是如何工作呢？先上图

 

deploy控制RS，RS控制Pod，这一整套，向外提供稳定可靠的Service

 

实战：

我们先创建一个deployment。

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx-deployment
  #指定域
  namespace: nginx
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.14.0
        name: nginx
        volumeMounts:
        - name: conf
          mountPath: /etc/nginx/nginx.conf
        - name: log
          mountPath: /var/log/nginx/
        - name: html
          mountPath: /etc/nginx/html
      #标签选择器（集群状态下，可以指定服务部署在特定node节点上，这就是标签的作用）
      #nodeSelector:
        #type: nginx
      #设置污点可以调度到对应服务器
      tolerations:
      - key: "key"
        operator: "Equal"
        value: "nginx"
        effect: "NoSchedule"
      volumes:
      - name: conf
        hostPath:
          path: /usr/local/nginx/conf/nginx.conf
      - name: log
        hostPath:
          path: /usr/local/nginx/logs
          type: Directory
      - name: html
        hostPath:
          path: /usr/local/nginx/html
          type: Directory

接下来，看看我们生成的pod,deploy.,rs

可以看到，在生成一个nginx-deployment 的同时生成了一个rs(nginx-deployment-5d7975b79c)。同时还包含资源最小单位POD。在他的历史版本中也出现了这一个版本记录。

一，修改replicas

 

可以看到修改replicas之后，无论是deploy, rs, history 都不会变，只会增加pod的数量，而且原来的pod并不会改变。在注意一下版本历史，也没有改变。

二，修改image

这里面涉及的东西就很多了。慢慢来

第一个变化：肯定是 rs无缘无故多了一个。其实想想也很简单。因为出现版本的变化，pod肯定是要更新的，最前面我们也说了，deploy是通过 rs去管理pod的。当我们更新时，肯定会多一个副本集，注意TAG那一列。

第二个变化：pod由原来的nginx-deployment-5d7975b79c-* 变成 nginx-deployment-77fcbbfc7b-*系列。前缀时rs的名字。这个变化很简单，自己想想喽，这里想说的时另外一个 处于Terminating状态，最后消失的pod。为什么呢？ 还记得之前我们说过strategy这个标签吗，当type为rollingUpdate时，它定义了最大不可用和最大不可超两个含义。在replicas=3， maxSure=25%的时候，也就是说最大pod的数量为4个(大约)。当我们三个新的pod全部更新成功的时候，这一个 也会最终消失。如果更新失败呢，比如镜像not found?这里给出答案，三个旧的pod不变，多出一个新的containercreatinferror 的pod。

第三个变化：历史版本多了一个。看他的change-cause 可以看明白为什么。

 

讲到这里，你应该可以明白deploy, rs,的关系了吧。

 

接下来，我们看看 另外一组命令 kubectl rollout pause/resume/undo deploy/nginx-deployment -n nginx

 pause 暂停功能
resume恢复功能(用于启动被pause的deploy服务)
undo取消功能 (可以指定版本回归（kubectl rollout history deploy/nginx-deployment -n nginx）)

经过pause之后，修改镜像，pod并不会变化，尽管deploy的镜像版本已经变化。接下来我们 恢复deploy的功能。

 

第一次，我们使用错误的镜像，多了一个errimagepull 的pod,旧的pod并没有改变。在我们使用resume之后，自动更新了pod。

更多操作见（K8S 进阶 -3 (金丝雀发布、滚动更新、蓝绿部署) ）

更多可参考 http://docs.kubernetes.org.cn/645.html。