目录

一、概述

二、Replication Controller

2.1 Replication Controller 说明

2.2 Replication Controller 举例

三、ReplicaSet

3.1 ReplicaSet说明

3.2 ReplicaSet 举例

四、无状态应用管理Deployment

4.1 概述

4.2 创建Deployment

4.2.1 Deployment 标签内容解析

4.2.2 kubectl create创建语句

4.2.3 查看Deployment的状态

4.3.4 使用rollout查看Deployment创建的状态

4.3.5 查看Deployment对应的ReplicaSet

4.3.6 查看Deployment创建的Pod

4.3 更新Deployment

4.3.1 说明

4.3.2 使用set 命令更新

4.3.3 使用edit命令编辑Deployment

4.3.4 使用rollout查看Deployment查看更新过程

4.3.5 查看ReplicaSet

4.3.6 describe查看Deployment的详细信息

4.4 回滚Deployment

4.4.1 多更新几次Deployment

4.4.2 查看更新历史

4.4.3 查看某次更新

4.4.4 回滚版本

4.5 扩容Deployment

4.5.1 扩容操作

4.6 暂停和恢复Deployment更新

4.6.1 说明

4.6.2 暂停更新

4.6.3 修改内容

4.6.4 rollout history 查看历史

4.6.5 恢复Deployment更新

4.7 更新Deployment的注意事项

4.7.1 历史版本清理策略

4.7.2 更新策略

4.7.3 Ready策略

---

一、概述

对于Kubernetes的应用部署，我们之前提到过Pod就是用来配置容器的，容器就是用来运行应用的。也提到过，在实际使用时，不会创建单独的Pod运行应用，而是使用更高级的资源进行调度，比如Deployment等。本文的内容就是讲解Kubernetes原生的调度资源，在讲解高级资源Deployment、StatefulSet之前，首先会介绍什么是Replication Controller和ReplicaSet。

二、Replication Controller

2.1 Replication Controller 说明

Replication Controller可以确保Pod副本数达到期望值，也就是RC定义的数量。换句话说，Replication Controller可以确保一个Pod或一组同类Pod总是可用的。

如果存在的Pod大于设定的值，则Replication Controller将终止额外的Pod。如果太小，Replication Controller将启动更多的Pod用于保证达到期望值。

与手动创建Pod不同的是，用Replication Controller维护的Pod在失败、删除或终止时会自动替换。因此，即使应用程序只需要一个Pod，也应该使用Replication Controller或其他方式管理。

Replication Controller类似于进程管理程序，但是Replication Controller不是监视单个节点上的各个进程，而是监视多个节点上的多个Pod。

2.2 Replication Controller 举例

定义一个Replication Controller的示例如下：

三、ReplicaSet

3.1 ReplicaSet说明

ReplicaSet是支持基于集合的标签选择器的下一代Replication Controller，它主要用作Deployment协调创建、删除和更新Pod，和Replication Controller唯一的区别是，ReplicaSet支持标签选择器。

在实际应用中，虽然ReplicaSet可以单独使用，但是一般建议使用Deployment来自动管理ReplicaSet，除非自定义的Pod不需要更新或有其他编排等。

3.2 ReplicaSet 举例

Replication Controller和ReplicaSet的创建、删除和Pod并无太大区别，Replication Controller目前几乎已经不在生产环境中使用，ReplicaSet也很少单独被使用，都是使用更高级的资源Deployment、DaemonSet、StatefulSet管理Pod。

四、无状态应用管理Deployment

4.1 概述

前文提到的ReplicaSet可以确保在任何给定时间运行的Pod副本达到指定的数量，但是Deployment是一个更高级的概念，它管理ReplicaSet并为Pod和ReplicaSet提供声明性更新以及许多其他有用的功能，所以建议在生产环境下使用Deployment代替ReplicaSet。

Deployment一般用于部署公司的无状态服务，这个也是最常用的控制器，因为企业内部现在都是以微服务为主，而微服务实现无状态化也是最佳实践，可以利用Deployment的高级功能做到无缝迁移、自动扩容缩容、自动灾难恢复、一键回滚等功能。

4.2 创建Deployment

创建一个Deployment也很简单，将前面章节创建Pod的YAML文件稍微更改一下即可变成Deployment的资源文件，比如创建一个有3个Nginx副本（实例）的Deployment，可以看到只是apiVersion和Kind有所变化，如下所示：

4.2.1 Deployment 标签内容解析

• nginx-deployment：Deployment的名称。
• replicas：创建Pod的副本数。
• selector：定义Deployment如何找到要管理的Pod，与template的label（标签）对应，apiVersion为apps/v1必须指定该字段。
• template字段包含以下字段：
• app: nginx使用label（标签）标记Pod。
• spec：表示Pod运行一个名字为nginx的容器。
• image：运行此Pod使用的镜像。
• Port：容器用于发送和接收流量的端口。

注意：从Kubernetes 1.16版本开始，彻底废弃了其他的APIVersion，只能使用apps/v1，1.16以下的版本可以使用extension等。

4.2.2 kubectl create创建语句

使用kubectl create创建此Deployment：

kubectl create -f dp-nginx.yaml

4.2.3 查看Deployment的状态

使用kubectl get或者kubectl describe查看此Deployment的状态：

kubectl get deploy

• NAME：集群中Deployment的名称。
• DESIRED：应用程序副本数。
• CURRENT：当前正在运行的副本数。
• UP-TO-DATE：显示已达到期望状态的被更新的副本数。
• AVAILABLE：显示用户可以使用的应用程序副本数，当前为1，因为部分Pod仍在创建过程中。
• AGE：显示应用程序运行的时间。

4.3.4 使用rollout查看Deployment创建的状态

可以使用rollout命令查看整个Deployment创建的状态：

     kubectl rollout status deployment/nginx-deployment

当rollout结束时，再次查看此Deployment，可以看到AVAILABLE的数量和YAML文件中定义的replicas相同：

kubectl get deploy

4.3.5 查看Deployment对应的ReplicaSet

之前讲过Deployment通过ReplicaSet管理Pod，可以查看此Deployment当前对应的ReplicaSet：

kubectl get rs -l app=nginx

如果Deployment有过更新，对应的ReplicaSet可能不止一个，可以通过-o yaml获取当前对应的ReplicaSet是哪个，其余的ReplicaSet为保留的历史版本，用于回滚等操作。

注意：ReplicaSet的命名格式为[DEPLOYMENT-NAME]-[POD-TEMPLATE-HASH-VALUE]POD-TEMPLATE-HASH- VALUE，是自动生成的，不用手动指定。

4.3.6 查看Deployment创建的Pod

查看此Deployment创建的Pod，可以看到Pod的hash值5c689d88bb和上述Deployment对应的ReplicaSet的hash值一致：

kubectl get pods --show-labels

4.3 更新Deployment

4.3.1 说明

通过Deployment部署应用后，经常会有Deployment文件的配置更改或者镜像版本迭代的需求，更改配置后该Deployment会创建新的ReplicaSet，之后会对管理的Pod进行滚动升级。

注意：当且仅当Deployment的Pod模板（即.spec.template）更改时，才会触发Deployment更新，例如更改内存、CPU配置或者容器的image。

4.3.2 使用set 命令更新

假如更新Nginx Pod的image使用nginx:1.9.1，并使用--record记录当前更改的参数，后期回滚时可以查看到对应的信息：

     kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record

4.3.3 使用edit命令编辑Deployment

     kubectl edit deployment.v1.apps/nginx-deployment

4.3.4 使用rollout查看Deployment查看更新过程

kubectl rollout status deployment.v1.apps/nginx-deployment

可以看出更新过程为新旧交替更新，首先新建一个Pod，当Pod状态为Running时，删除一个旧的Pod，同时创建一个新的Pod。

4.3.5 查看ReplicaSet

当触发一个更新后，会有新的ReplicaSet产生，旧的ReplicaSet会被保存，查看此时的ReplicaSet，可以从AGE或READY看出新旧ReplicaSet：

kubectl get rs

4.3.6 describe查看Deployment的详细信息

kubectl describe deploy nginx-deployment

在describe中可以看出，第一次创建时，它创建了一个名为nginx-deployment-5c689d88bb的ReplicaSet，并直接将其扩展为3个副本。更新部署时，它创建了一个新的ReplicaSet，命名为nginx-deployment-6987cdb55b，并将其副本数扩展为1，然后将旧的ReplicaSet缩小为2，这样至少可以有两个Pod可用，最多创建了4个Pod。以此类推，使用相同的滚动更新策略向上和向下扩展新旧ReplicaSet，最终新的ReplicaSet可以拥有3个副本，并将旧的ReplicaSet缩小为0。

4.4 回滚Deployment

4.4.1 多更新几次Deployment

当更新的版本不稳定或配置不合理时，可以对其进行回滚操作，假设我们又进行了几次更新（此处以更新镜像版本触发更新，更改配置效果类似）：

     kubectl set image deployment nginx-deployment nginx=dotbalo/canary:v1 --record
     kubectl set image deployment nginx-deployment nginx=dotbalo/canary:v2 --record

4.4.2 查看更新历史

使用kubectl rollout history查看更新历史：

kubectl rollout history deployment/nginx-deployment

4.4.3 查看某次更新

查看Deployment某次更新的详细信息，使用--revision指定某次更新的版本号：

kubectl rollout history deployment/nginx-deployment -revision=3

4.4.4 回滚版本

如果只需要回滚到上一个稳定版本，使用kubectl rollout undo即可：

     kubectl rollout undo deployment/nginx-deployment

再次查看更新历史，发现REVISION5回到了canary:v1：

kubectl rollout history deployment/nginx-deployment

如果要回滚到指定版本，使用--to-revision参数：

      kubectl rollout undo deployment/nginx-deployment --to-revision=2

4.5 扩容Deployment

4.5.1 扩容操作

当公司访问量变大，或者有预期内的活动时，3个Pod可能已无法支撑业务时，可以提前对其进行扩展。

使用kubectl scale动态调整Pod的副本数，比如增加Pod为5个：

      kubectl scale deployment.v1.apps/nginx-deployment --replicas=5

查看Pod，此时Pod已经变成了5个：

kubectl get pods

4.6 暂停和恢复Deployment更新

4.6.1 说明

上述演示的均为更改某一处的配置，更改后立即触发更新，大多数情况下可能需要针对一个资源文件更改多处地方，而并不需要多次触发更新，此时可以使用Deployment暂停功能，临时禁用更新操作，对Deployment进行多次修改后再进行更新。

4.6.2 暂停更新

使用kubectl rollout pause命令即可暂停Deployment更新：

      kubectl rollout pause deployment/nginx-deployment

4.6.3 修改内容

然后对Deployment进行相关更新操作，比如先更新镜像，然后对其资源进行限制（如果使用的是kubectl edit命令，可以直接进行多次修改，无须暂停更新，kubectl set命令一般会集成在CICD流水线中）：

kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1

kubectl set resources deployment.v1.apps/nginx-deployment -C=nginx -limits=cpu=200m,memory=512Mi

4.6.4 rollout history 查看历史

通过rollout history可以看到没有新的更新：

kubectl rollout history deployment.v1.apps/nginx-deployment

4.6.5 恢复Deployment更新

进行完最后一处配置更改后，使用kubectl rollout resume恢复Deployment更新：

     kubectl rollout resume deployment.v1.apps/nginx-deployment

可以查看到Deployment的image（镜像）已经变为nginx:1.9.1：

kubectl describe deploy nginx-deployment

4.7 更新Deployment的注意事项

4.7.1 历史版本清理策略

在默认情况下，revision保留10个旧的ReplicaSet，其余的将在后台进行垃圾回收，可以在.spec.revisionHistoryLimit设置保留ReplicaSet的个数。当设置为0时，不保留历史记录。

4.7.2 更新策略

• .spec.strategy.type==Recreate：表示重建，先删掉旧的Pod，再创建新的Pod。
• .spec.strategy.type==RollingUpdate：表示滚动更新，可以指定maxUnavailable和maxSurge来控制滚动更新过程。
• .spec.strategy.rollingUpdate.maxUnavailable：指定在回滚更新时最大不可用的Pod数量，可选字段，默认为25%，可以设置为数字或百分比，如果maxSurge为0，则该值不能为0。
• .spec.strategy.rollingUpdate.maxSurge：可以超过期望值的最大Pod数，可选字段，默认为25%，可以设置成数字或百分比，如果maxUnavailable为0，则该值不能为0。

4.7.3 Ready策略

.spec.minReadySeconds是可选参数，指定新创建的Pod应该在没有任何容器崩溃的情况下视为Ready（就绪）状态的最小秒数，默认为0，即一旦被创建就视为可用，通常和容器探针连用。

好了，本次内容就分享到这，欢迎大家关注《Kubernetes》专栏，后续会继续输出相关内容文章。如果有帮助到大家，欢迎大家点赞+关注+收藏，有疑问也欢迎大家评论留言！