Replication Controller、ReplicaSet和Deployment（Kubernetes调度系列，结合操作命令讲解）

对于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》专栏，后续会继续输出相关内容文章。如果有帮助到大家，欢迎大家点赞+关注+收藏，有疑问也欢迎大家评论留言！

标签：kubectl,操作命令,ReplicaSet,Kubernetes,Deployment,nginx,deployment,Pod
From： https://blog.csdn.net/qq_25409421/article/details/137410167