这里就需要说一下ReplicationSet（RS：副本组）和ReplicationController（RC：副本控制器），RS是在RC基础上发展来的，在新版的Kubernetes中，已经将RC替换为RS 了，它们两者没有本质的区别，都是用于Pod副本数量的维护与更新的，使得副本数量始终维持在用户定义范围内，即如果存在容器异常退出，此时会自动创建新的Pod进行替代；而且异常多出来的容器也会自动回收。

1.5 Deployment、RS、Pod它们三者之间的关系：

RS负责控制副本数量，由Deployment来创建具体的Pod。

第2章 Deployment的镜像更新策略

pods镜像的更新是Deployment一个非常重要的功能，是支持敏捷开发和DevOps的一个必不可少的能力。

2.1 更新策略

（1）镜像更新的方向

升级
降级（回退）

（2）镜像更新的策略

Deployment控制器支持两种镜像版本更新策略：滚动更新（rolling update）和重新创建（recreate），默认为滚动更新。可以通过strategy选项进行配置。

重建更新：

先删除所有pod，然后在一个个创建新pod，这种方式先删除所有需要更新的pod，然后再创建新的pod，如果新pod创建有问题，就会有系统有较大的影响。

滚动更新（默认）：

创建-》删除-》创建-》删除-》....., 这种方式是，先创建一部分，删除一部分，然后再创建一部分，再删除一部分，对系统的影响非常小，因此滚动更新是默认更新方式，缺点更新的速度较慢，过程复杂。在更新的过程中，同一时间有两个版本。

滚动更新又分为：滚动升级与滚动回退。

2.2 滚动升级

滚动升级是默认的更新策略，它在删除一部分旧版本Pod资源的同时，补充创建一部分新版本的Pod对象进行应用升级，其优势是升级期间，容器中应用提供的服务不会中断，但要求应用程序能够应对新旧版本同时工作的情形，例如新旧版本兼容同一个数据库方案等。不过，更新操作期间，不同客户端得到的响应内容可能会来自不同版本的应用。
Deployment控制器的滚动更新操作并非在同一个ReplicaSet控制器对象下删除并创建Pod资源，而是将它们分置于两个不同的控制器之下：旧控制器的Pod对象数量不断减少的同时，新控制器的Pod对象数量不断增加，直到旧控制器不再拥有Pod对象，而新控制器的副本数量变得完全符合期望值为止，如图所示：

滚动更新时，应用升级期间还要确保可用的Pod对象总数量不低于某阈值，以确保可以持续处理客户端的服务请求，变动的方式和Pod对象的数量范围将通过spec.strategy.rollingUpdate.maxSurge和spec.strategy.rollingUpdate.maxUnavailable两个属性协同进行定义，它们的功用如图所示：

上述案例中，删除一个V1版本的Pod，然后创建2个V2版本的Pod。

maxSurge：指定升级期间存在的总Pod对象数量最多可超出期望值的个数，其值可以是0或正整数，也可以是一个期望值的百分比；例如，如果期望值为3，当前的属性值为1，则表示Pod对象的总数不能超过4个。
maxUnavailable：升级期间正常可用的Pod副本数（包括新旧版本）最多不能低于期望数值的个数，其值可以是0或正整数，也可以是一个期望值的百分比；默认值为1，该值意味着如果期望值是3，则升级期间至少要有两个Pod对象处于正常提供服务的状态。

maxSurge和maxUnavailable属性的值不可同时为0，否则Pod对象的副本数量在符合用户期望的数量后无法做出合理变动以进行滚动更新操作。

2.3 滚动回退（回滚）

Deployment也支持用户保留其滚动更新历史中的旧ReplicaSet对象版本，这赋予了Deployment进行应用回滚的能力：用户可按需回滚到指定的历史版本。

Deployment可保存的历史版本数量由“spec.revisionHistoryLimit”属性进行定义。当然，也只有保存于revision历史中的ReplicaSet版本可用于回滚，因此，用户要习惯性地在更新操作时指定保留旧版本。

2.4 金丝雀发布，也叫做灰度发布

所谓的金丝雀发布，也叫做灰度发布，就是并非一次性全部更新完所有pods。

当一批新的pod资源创建完成后，立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧的版本。然后，再筛选一小部分的用户请求路由到新的pod应用，继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的pod资源滚动更新，否则立即回滚更新操作。

2.5 Depolyment配置文件详解

apiVersion: apps/v1        #版本号
kind: Deployment           #Deployment类型标识
metadata:                  #元数据
  name:                    #Deployment资源名称
  namespace:               #所属命名空间
  labels:                  #标签
    controller: deploy
spec:                      #详情描述
  replicas:                #副本数量
  revisionHistoryLimit:    #保留历史版本，默认是10
  paused:                  #暂停部署，默认是false
  progressDeadlineSeconds: #部署超时时间(s)，默认是600
  strategy:                #自动编排策略
    type: RollingUpdates   #滚动更新策略
    rollingUpdate:         #滚动更新
      maxSurge:            #最大额外可以存在的副本数，可以为百分比，也可以为整数
      maxUnavaliable:      #最大不可用状态的pod的最大值，可以为百分比，也可以为整数
  selector:                #选择器，通过它指定该控制器管理哪些pod
    matchLabels:           #Labels匹配规则
       app: nginx-pod
    matchExpressions:      #Expression匹配规则
      - key: app, operator: In, values: [nginx-pod]
  template:                #模板，当副本数量不足时，会根据下面的模板创建pod副本
    metadata:
        labels:
          app: nginx-pod
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.1
        ports:
        - containerPort: 80

第3章 Depolyment常见特性与操作命令

3.1 显示当前的Depolyment

（1）命令行

$ kubectl get deploy -n dev -owide
$ kubectl get pods -n dev
$ kubectl delete pod -n dev

（2）UI

通过dashboard显示

3.2 新创建一个Depolyment

（1）命令行方式

# 创建一个部署，指定docker image镜像
$ kubectl create depolyment mynignx --image=nginx:1.17.1

（2）配置文件方式

apiVersion: apps/v1
kind: Deployment
metadata:
  name: pc-deployment
  namespace: dev
spec:
  replicas: 3
  selector:
    matchLabels:
     app: nginx-pod
  template:
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.1  # 不用最新，便于后续更新

$ kubectl create namespace dev
$ kubectl create -f pc-deployment.yaml

3.3 Depolyment多副本的能力

# 创建一个部署，指定docker image镜像，生成n份副本
$ kubectl create depolyment mynignx --image=nginx:1.17.1 --replicas=3

3.4 Depolyment的故障治愈能力

$ kubectl get pods

$ kubectl delete pod mynignx

备注：直接删除pod的操作，模拟的pod节点出出故障的情形。由于不是直接删除的depolyment，而是直接删除的pod，depolyment会检测到其管辖的pod失效，会自动重启启动pod，新的pod有可能在原有的节点上，也可能在新的节点上。

治愈能力：新创建的pod还在原有的节点上。
故障转移能力：新创建的pod在新的节点上。

3.5 Depolyment的故障转移能力

# 先通过云平台使得某台机器shutdown

$ kubectl get pods -owide

# 等待5min
# 被shutdown机器上的pod会被depolyment部署到新的节点上

3.6 删除一个Depolyment

（1）命令行方式

$ kubectl delete depolyment mynignx 

$ kubectl get pods

$ kubectl get deploy -n dev -owide

该删除操作，会删除depolyment所有的pods。

（2）通过UI方式：dashboard

第4章 Depolyment高级特性相关的命令

4.1 扩容与缩容能力：kubectl scale

（1）方式1：命令行

# 自动选择节点，自动创建pod实例
$ kubectl scale deploy pc-deployment --replicas=5 -n dev

$ kubectl get pod -n dev

（2）方式2：编辑deploy文件

$ kubectl edit deploy pc-deployment -n dev

$ kubectl get pod -n dev

4.2 pod对应的Docker镜像更新：kubectl set image

（1）修改策略

strategy：  #指定新的pod替换旧的pod的策略，支持两个属性：
    type：  #指定策略类型，支持两种策略
        Recreate：     #在创建出新的pod之前会先杀掉所有已存在的pod，这种更新较大的风险
        RollingUpdate：#滚动更新，就是杀死一部分，就启动一部分，在更新过程中，存在两个版本pod
    # 当type为RollingUpdate时生效，
    rollingUpdate：
        maxUnavailable：#用来指定在升级过程中不可用pod的最大数量，默认为25%
        maxSurge：      #用来指定在升级过程中可以超过期望的pod的最大数量，默认为25%

$ kubectl edit deploy pc-deployment -n dev

spec:
  strategy:  #策略
    type: Recreate  #重建更新策略


$ kubectl apply -f pc-deployment.yaml 

# 查看当前镜像的版本
$ kubectl get pod -n dev

$ kubectl edit deploy pc-deployment -n dev

strategy:
  type: RollingUpdate #滚动更新策略
  rollingUpdate:
    maxUnavailable: 25%
    maxSurge: 25%


$ kubectl apply -f pc-deployment.yaml 

# 查看当前镜像的版本
$ kubectl get pod -n dev

（2）创建新镜像、更新镜像

#首先记录原本的pod名
$ kubectl get pod -n dev

# 更改pod镜像版本
$ kubectl set image deploy pc-deployment nginx=nginx:1.17.2 -n dev
$ kubectl set image deploy pc-deployment nginx=nginx:1.17.3 -n dev

#再次查看镜像
$ kubectl get pod -n dev

4.3 版本回退：kubectl rollout

（1）功能简介

所谓版本回退，就是自动把版本回退到先前更旧的版本等功能，支持的详细功能如下

status：显示当前升级状态
history：显示升级历史记录
pause：暂停版本升级过程
resume：继续已经暂停的版本升级过程
restart：重启版本升级过程
undo：回滚到上一级版本（可以使用–to-revision回滚到指定版本）

（2）在rollout的过程中，查看升级状态

$ kubectl rollout status deploy pc-deployment -n dev

（3）在rollout的过程中，查看升级历史

$ kubectl rollout history deploy pc-deployment -n dev

（4）软件版本回退：undo

#这里使用–to-revision=1回滚到1版本，如果省略这个选项，则会回退到上个版本
$ kubectl rollout undo deploy pc-deployment --to-revision=1 -n dev


#查看是否回滚成功
$ kubectl get rs -n dev
$ kubectl get pods
$ kubectl get depoly -owide

回滚的过程，也是先创建一个新的低版本的pod，然后杀掉已有的高版本的pod。

4.4 Deployment金丝雀发布（灰度发布）

灰度发布通过如下两个命令配合使用来完成：

kubectl rollout pause deploy

kubectl rollout resumedeploy

（1）启动rollout pause部署更新

$ kubectl set image deploy pc-deployment nginx=nginx:1.17.2 -n dev && kubectl rollout pause deploy pc-deployment -n dev

（2）查看rs

$ kubectl get rs -n dev

发现老版本rs没有减少，新版本rs增加一个

（3）#查看更新过程

$ kubectl rollout status deploy pc-deployment -n dev
$ kubectl get rs -n dev

发现老版本均停止，新版本已经创建好。

作者主页(文火冰糖的硅基工坊)：文火冰糖（王文兵）的博客_文火冰糖的硅基工坊_CSDN博客

本文网址：https://blog.csdn.net/HiWangWenBing/article/details/122796352

以上是关于[云原生专题-32]：K8S - 核心概念 - 工作负载资源之Depolyment（无状态应用）的概念与常见操作命令的主要内容，如果未能解决你的问题，请参考以下文章

[云原生专题-43]：K8S - 核心概念 - placeholder - 加密数据

[云原生专题-42]：K8S - 核心概念 - placeholder-有状态服务

[云原生专题-38]：K8S - 核心概念 - 存储抽象- 空间大小可配置的目录挂载PV+PVC

[云原生专题-40]：K8S - 核心概念 - 网络模型网络通信集群内负载均衡机制（重要重要重要）

[云原生专题-33]：K8S - 核心概念 - 服务Service管理服务发现负载均衡

[云原生专题-39]：K8S - 核心概念 - 存储抽象- pod配置文件的挂载ConfigMap

[云原生专题-32]：K8S - 核心概念 - 工作负载资源之Depolyment（无状态应用）的概念与常见操作命令

第1章 什么是Depolyment工作负载资源

1.1 工作负载总体概述

1.2 什么是Depolyment

1.3 Depolyment的应用场合

1.4 ReplicationSet（RS）和ReplicationController（RC）概念