大话云原生之灰度发布篇 - 从步行到坐缆车的自动化服务升级

看过很多关于云原生的文章，要么云山雾罩，要么曲高和寡。 所以笔者就有了写《大话云原生》系列文章的想法，期望用最通俗、简单的语言、方便记忆的场景来说明：云原生生态系统内的组成及应用关系。

一、Kubernetes 的 Pod 概念解析

说到老婆过生日了我们一起出去旅游，上了团体服务班车，小娜同学(老婆)闲聊到：“这服务还不错哈，2 个跟车导游，1 个司机”。三句不离老本行，我无聊的说到：“他们三个人就是一个 Pod，提供一天的旅游服务内容，有主有次不可分割"。

小娜同学又上套了：“什么是 Pod 啊？英文单词豌豆荚？”，让老婆增加对老公崇拜感的机会不可多得，那就开讲，反正坐车也是闲着。

• 一般来说一个 Pod 提供一种服务(微服务)，“哎？之前说容器技术的时候你也是这么说的”。是的，容器是提供服务的最小单元，那么 Pod 是什么概念？这是因为我们现在讨论的是 k8s，Pod 是 k8s 服务调度的最小单元。

• “为什么引入 Pod 的概念？”，因为有的时候你会发现：一个服务通常包含辅助它的服务。比如这个车上，一个导游长得漂亮口才好作为主导游提供核心讲解服务，还有一个辅助她的导游负责发帽子、统计人数、统计消费等。同理回到架构技术角度举个例子：一个 nginx 提供 web 服务容器作为核心服务容器，负责收集 nginx 日志的服务容器作为辅助服务和它部署在一个 Pod，这样方便日志收集与网络连接。

• 一个 Pod 存在一个基础容器 Infra，基础容器 Infra 提供了网络共享的能力，就像主导游和辅助导游必须在一辆车（基础容器 Infra）上，或者基于这辆车组成了一个组合，否则他们之间无法对话及资源共享。

• 一个 Pod 下的容器共享网络及数据卷，所以将容器服务间具有相当强的捆绑关系的服务容器放到一个 Pod 里面，通常一个容器提供核心服务，其他的容器提供辅助服务，如：日志收集、监控告警等。

二、Pod 标签与 Service 服务

聊着聊着很快车就到了旅游目的地，一下车发现 X 公司的团队还真不少。导游都统一都带上了深红色的帽子（游客带上蓝色遮阳帽），浩浩荡荡出发。深红色的帽子为导游 Pod 服务打上了标签，他们面向游客（用户）提供了统一的一种服务叫做：“导游服务”。

对于 K8s 中的服务架构也是一样的：

• 一个 Pod 通常提供一种服务，如 nginx web 访问服务

• 多个提供同样服务的 Pod 通常打上一样的标签

• 创建 Service：具备同一种标签的 Pod 组成一个 Service，对外提供服务。

三、自动化服务升级-灰度发布

我们今天的项目是爬山，提供了两种上山的方式：一是直接爬(即步行)，二是坐缆车，当然如果你中途爬不动了也可以在缆车换乘站上缆车。

• “步行服务”到“缆车服务”可以理解为一次服务升级（1.0 版本服务升级为 2.0 版本服务）。从技术角度，一次服务升级等同于新版本服务的上线部署被称为一次 Deployment。K8s 同样使用 Deployment 这个术语代表服务升级部署。

• ReplicaSet 代表一个版本的 Pod 服务组合，1.0 为步行版本的 Pod 服务组合，2.0 为缆车版本的 Pod 服务组合，这样理解是不是容易多了呢？

• 在服务容器部署 Deployment 的过程中，我们不希望面向用户的服务中断(即：不希望对步行 1.0 的用户的服务出现中断情况)，所以停掉一个 1.0 的 Pod，再启动一个 2.0 的 Pod2.0，这个过程被称为灰度发布。整个过程高度依赖 Kubernetes 提供的自动化运维能力。

上面的图每个 RS 只有 2 个 Pod，还不能那么直观的理解灰度发布，看下面这张图

• 圆形代表 Pod，分为 v1 版本和 v2 版本，虚线标识的 Pod 表示即将下线的 Pod

• v1 版本的 Pod 减一，v2 版本的 pod 加一

• 逐渐 ReplicaSet：v1 的 Pod 全部销毁，ReplicaSet：v2 的 Pod 逐渐被创建并启动提供服务

• 整个的灰度发布过程，在 k8s 中通过一个 Deployment 进行定义并执行。