深入剖析Kubernetes之控制器模式的实现-Deployment

文章目录

- Deployment

Deployment

Deployment 实现了 Kubernetes 项目中一个非常重要的功能：Pod 的“水平扩展 / 收缩”（horizontal scaling out/in）。这个功能，是从 PaaS 时代开始，一个平台级项目就必须具备的编排能力。
如果你更新了 Deployment 的 Pod 模板（比如，修改了容器的镜像），那么 Deployment 就需要遵循一种叫作“滚动更新”（rolling update）的方式，来升级现有的容器。而这个能力的实现，依赖的是 Kubernetes 项目中的一个非常重要的概念（API 对象）：ReplicaSet。
ReplicaSet 的结构非常简单，可以通过YAML 文件查看一下：

apiVersion: apps/v1
kind: ReplicaSet
metadata:name: nginx-setlabels:app: nginx
spec:replicas: 3selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.7.9

一个 ReplicaSet 对象，其实就是由副本数目的定义和一个 Pod 模板组成的。它的定义其实是 Deployment 的一个子集。Deployment 控制器实际操纵的，正是这样的 ReplicaSet 对象，而不是 Pod 对象。

在具体的实现上，这个 Deployment，与 ReplicaSet，以及 Pod 的关系是怎样的呢？
在这里插入图片描述

将一个集群中正在运行的多个 Pod 版本，交替地逐一升级的过程，就是“滚动更新”。

**“滚动更新”的好处是显而易见的。**比如，在升级刚开始的时候，集群里只有 1 个新版本的 Pod。如果这时，新版本 Pod 有问题启动不起来，那么“滚动更新”就会停止，从而允许开发和运维人员介入。而在这个过程中，由于应用本身还有两个旧版本的 Pod 在线，所以服务并不会受到太大的影响。当然，这也就要求你一定要使用 Pod 的 Health Check 机制检查应用的运行状态，而不是简单地依赖于容器的 Running 状态。要不然的话，虽然容器已经变成 Running 了，但服务很有可能尚未启动，“滚动更新”的效果也就达不到了。而为了进一步保证服务的连续性，Deployment Controller 还会确保，在任何时间窗口内，只有指定比例的 Pod 处于离线状态。同时，它也会确保，在任何时间窗口内，只有指定比例的新 Pod 被创建出来。这两个比例的值都是可以配置的，默认都是 DESIRED 值的 25%。
这个策略，是 Deployment 对象的一个字段，名叫 RollingUpdateStrategy:

...
spec:
...strategy:type: RollingUpdaterollingUpdate:maxSurge: 1maxUnavailable: 1

在上面这个 RollingUpdateStrategy 的配置中，maxSurge 指定的是除了 DESIRED 数量之外，在一次“滚动”中，Deployment 控制器还可以创建多少个新 Pod；而 maxUnavailable 指的是，在一次“滚动”中，Deployment 控制器可以删除多少个旧 Pod。
同时，这两个配置还可以用前面我们介绍的百分比形式来表示，比如：maxUnavailable=50%，指的是我们最多可以一次删除“50%*DESIRED 数量”个 Pod。

Deployment、ReplicaSet 和 Pod 的关系图
在这里插入图片描述

Deployment 的控制器，实际上控制的是 ReplicaSet 的数目，以及每个 ReplicaSet 的属性。而一个应用的版本，对应的正是一个 ReplicaSet；这个版本应用的 Pod 数量，则由 ReplicaSet 通过它自己的控制器（ReplicaSet Controller）来保证。通过这样的多个 ReplicaSet 对象，Kubernetes 项目就实现了对多个“应用版本”的描述。
kubectl rollout undo 命令，就能把整个 Deployment 回滚到上一个版本：kubectl rollout undo deployment/nginx-deployment

如果我想回滚到更早之前的版本，要怎么办呢？

首先，需要使用 kubectl rollout history 命令，查看每次 Deployment 变更对应的版本。
还可以通过这个 kubectl rollout history 指令，看到每个版本对应的 Deployment 的 API 对象的细节，命令：kubectl rollout history deployment/nginx-deployment --revision=1
在 kubectl rollout undo 命令行最后，加上要回滚到的指定版本的版本号，就可以回滚到指定版本了。命令：kubectl rollout undo deployment/nginx-deployment --to-revision=1

金丝雀发布（Canary Deployment）和蓝绿发布（Blue-Green Deployment）