置信在座的大家应该都据说过云原生了，这是近三四年始终热门的一个货色。什么是云原生呢？当初的云原生是个很宽泛的定义，能够简略了解为你的服务是为云而生，或者说因为当初云原生都是以 Kubernetes 容器技术作为基础设施，那只有你的服务运行在 Kubernetes 上，它们就能够算云原生。
而明天我跟大家分享的主题是 Luffy3 利用云原生技术，实现的灰度更新，次要从以下 4 个方面进行介绍：
什么是灰度更新
灰度更新的现状
云原⽣实际
总结与瞻望
什么是灰度更新
为了让大家更好的了解，我通过一个简略的例子和大家说一下什么是灰度更新。
假如你有⼀个对于酒店预约的项⽬，须要对外提供⼀个 Web 网站，供用户预约房间。为了保障业务的⾼可⽤，该项⽬研发的服务端是⽀持分布式的。因而，你在⽣产环境，组了⼀个酒店预约 Web 集群，⼀共起了 3 个服务端，通过 Nginx 反向代理的形式对外提供服务。
左图是传统意义上的灰度更新，即先将局部流量导到新版本上进行测试，如果能够就全面推广，如果不行就退回上一个版本。具体举例来说的话，有三台机器别离部署了服务端，IP 地址别离为 0.2、0.3、0.4。日常更新的话，抉择先在 0.4 服务端更新并看一下是否有问题呈现，在确定没有问题后才进行 0.3 和 0.2 的更新。
右图则是应用容器技术，它会比物理机部署的形式更加灵便。它用到的概念是 instance，也就是实例，同一台机器上能够起多个实例。拜访流量会如图从左往右的方向，先通过网关，通过在网关上增加一些策略，让 95% 的流量走下面的原服务，5% 的流量走上面的灰度服务。通过观察灰度服务是否有异样，如果没有异样，则能够把原服务的容器镜像版本更新到最新，并删掉上面的灰度服务。这和左图是不一样的，它不是滚动式一台接一台的更新，而是借助一个弹性资源平台间接把原服务全副更新掉。
灰度更新现状
上图是灰度更新在 Luffy2 下面的现状，次要问题呈现在 API 解决这一块，因为之前的状态是靠数据库来保护的，容易呈现状态不对立的问题。
左图是一个简略的解决流程。当一个 API 申请服务过去要求进行服务灰度更新时，第一步会学生成一个带灰度名称的 App。
第二步这里给大家细说，首先要将生成的 App 放入数据库，同时在 Kubernetes 创立无状态服务，这通常须要 10 分钟左右的工夫。这期间会通过一个 Go 语言程序对 App 表进行不间断扫描以确认服务是否实现创立。同时还须要应用 Kubernetes 创立转发规定等，期待所有需要都创立实现后就返回原版 ok 给调用方。
这里波及到性能问题，因为数据库内有很多条要解决的货色，这些要期待挨个解决，而这其中有很多都是无用数据，在扫到 App 前的这 10 分钟里，就算去 Kubernetes 那边调用，也是在做无用操作。
另外还有一个调用链很长的问题，在 Kubernetes 里创立的很多货色都会蕴含在同一次 API 申请里，这就导致随时可能呈现在一步实现后，下一步解体的状况。这种时候可能要思考是否回滚的问题，而如果回滚就要删掉相干服务和数据库。这种状况在调用内部组件越多时，越容易呈现。比拟直观的解决办法是简化 API 流程，针对这个办法 Kubernetes 提供了 CRD。
云原生实际
CRD
上图是从 Kubernetes 官网上摘抄下来的对于 CRD 的阐明。这个大家应该都比拟相熟了。Kubernetes 里最重要的概念就是资源，它外面所有的货色都是一个资源或者对象。右图是相干的无状态服务的例子，外面蕴含了服务的版本、类型、标签以及镜像版本和容器对外提供的端口。在 Kubernetes 里创立无状态服务，你只须要实现定义即可，而 CRD 则能够帮忙咱们自定义 spec 内的内容。
须要留神的是，定制资源自身只能⽤来存取结构化的数据。只有与定制控制器（Custom Controller）相结合时，能力提供真正的申明式 API（Declarative API）。通过应用申明式 API，你能够申明或者设定资源的冀望状态，并让 Kubernetes 对象的以后状态同步到其冀望状态。也就是控制器负责将结构化的数据解释为⽤户所冀望状态的记录，并继续地保护该状态。
上图是对于申明式 API 的相干实际，采纳程度触发的形式。简略举例，电视应用的遥控器是边缘触发，只有你按了更改频道就会立刻触发更改。而闹钟则是程度触发，无论在闹钟响动之前更改了多少次，它只会在你最初定好的工夫点触发。总结来说就是边缘触发更重视时效性，在更改时会立刻反馈。而程度触发则只关注最终的一致性，无论后面如何，只保障最初状态和咱们设置的一样就好。
Luffy3.0 CRD
上图是又拍云应用 luffy3.0 做的整体构造，它是架在 Kubernetes 上的，其中和 Kubernetes 的服务相干交互都由 apiserver 实现。
图中右下角的是关系式数据库，关系相干比方用户关系、从属关系，都在这外面。它下面带一层 redis 缓存，来进步热点数据查问效率。左图是咱们实现的几个本人的 CRD。第二个 projects 就是相干我的项目。当年在创建我的项目时，就是背靠 CRD 的。首先在数据库里写了，而后在 Kubernetes 创立了 projects 这个 CRD 对象。
Kubernetes client-go informer 机制
接下来和，大家谈一下 informer 的实现逻辑，informer 是 Kubernetes 官网提供的，不便大家和 Apiserver 做交互的一套 SDK，它比拟依赖程度触发的机制。
上图右边是咱们的 apiserver，所有的数据都存在 Key-value 的数据库 ETCD 里。在存储时它应用以下构造：
/registry/{kind}/{namespace}/{name}
复制代码
这之中前缀 registry 是能够批改的，用于避免抵触，kind 是类型，namespace 为命名空间或者说我的项目名，对应 Luffy3。再前面的 name 是服务名称。在通过 apiserver 对这个对象进行了创立、更新、删除等操作时，ETCD 都会将这个事件反馈给 apiserver。而后 apiserver 会将更改对象凋谢给 informer。而 informer 是基于单个类型 {kind} 的，这也就说如果你有多个类型，那么你必须对应每一个类型起一个对应的 informer，当然这个能够通过代码来生成。
https://zhuanlan.zhihu.com/p/…
https://zhuanlan.zhihu.com/p/…
https://zhuanlan.zhihu.com/p/…
https://zhuanlan.zhihu.com/p/…
https://zhuanlan.zhihu.com/p/…
https://zhuanlan.zhihu.com/p/…
https://zhuanlan.zhihu.com/p/…
https://zhuanlan.zhihu.com/p/…
https://zhuanlan.zhihu.com/p/…
https://zhuanlan.zhihu.com/p/…
回到 informer 实现逻辑，当 informer 运行起来后，它会先去 Kubernetes 中获取全量数据，比方以后 informer 对应的类型是无状态服务，那它会获取全副的无状态服务。而后继续 watch apiserver，一旦 apiserver 有新的无状态服务，它都会收到对应事件。收到新事件后，informer 会将工夫放入先进先出的队列，让 controller 进行生产。而 controller 会将事件交递给模块 Processer 进行非凡解决。在模块 Processer 上有很多监听器，这些监听器是对特定类型设置的回调函数。
而后来看一下为什么 controller 中的 lister 和 indexer 关联。因为 namespace 和目录很像，在这个目录下会有很多的无状态服务，如果想依据某一规定进行解决，在原生服务上解决必定是最差的抉择，而这就是 lister 所要做的。它会将这部分进行缓存，并做一个索引，也就是 inderxer，这个索引和数据库很像，是由一些 key 组成的。
而对于 CRD 来说，要实现的就是 contorller，以及 informer 和 controller 交互的局部。其余的局部由代码本人生成。
如果代码没有生成，那就会用到上图了。前三条是写代码相干，其中 API type 须要咱们填写 CRD 的定义、灰度更新定义等，实现定义后要将定义注册到 Kubernetes 上，不然就不会起效。接着，代码会生成下方的 4 项，包含 deepcopy 深度拷贝函数，应用 CRD 的 client，informer 和 lister。
第三块是自定义控制器相干的 controller，包含和 Apiserver 打交道的 Kubernetes rest client，工夫控制器或工夫函数 eventhandler 和 handlerfuncs 等。这其中须要写的是调和函数 reconciliation，因为其余官网都曾经为咱们封装好了，只须要定义好调和函数就能够。
全副封装实现后须要把这些货色串起来，以后支流的抉择有两个，OperatorSDK 和 Kubebuilder。
OperatorSDK vs Kubebuilder
接下来来看一下代码是如何生成的
以 OperatorSDK 为例看一下是如何生成代码的。当然大家也能够抉择应用 Kubebuilder，这两者的生成形式差异不大。在上图的“初始化我的项目”里能够看到仓库的名称，它定义了一个版本的版本号，以及类型 canaryDeployment，即灰度的无服务状态。之后生成对应的资源和控制器。实现后写刚刚讲到的调和函数和 API 定义。全副实现后就能够执行了，非常简单。
灰度更新的设计
在聊了下面的这些常识后，来看一下灰度更新。上图是灰度更新的繁难示例图，流程是从左开始到左边完结。
第一步是创立灰度服务，创立后能够更新灰度。比方方才的 Nginx 的例子，咱们创立的版本号是 1.19。然而在灰度过程中发现以后版本有 bug，而在对这个 bug 进行修复后，确认无误就能够将原服务更新到版本号 1.20，而后删除灰度服务。如果发现 1.20 版本仍然有 bug，也能够抉择删除灰度服务，让你原服务接管所有流量。这就是 CRD 对开发步骤的简化。
灰度更新一共有以下 4 个阶段：
创立
更新
替换
删除
创立
因为 Kubernetes 是程度触发的，所有它创立和更新的解决逻辑是雷同的，只看最终状态即可。
这张图比拟重要，大家能够认真看一下。图中右上局部是原服务，原服务蕴含 Kubernetes 无状态服务、Service 外部域名、ApisixRoute、Apisix 路由规定、ApisixUpstrean，以及 Apisix 上游的一些配置。原服务下方是灰度服务，右边的 controller 是之前提到的 CRD 控制器。
原服务创立好后，创立无状态服务，配置对应的 http 转发规定后转到 ApisixRoute 服务站中进行对应路由的配置，之后只有转到容器网关就会主动定位到指定服务。而后大家能够看到，咱们自定义的 CRD 类型名是 CanaryDeployment，是灰度的无状态服务。创立这个无状态服务的流程和原服务是雷同的。
CRD 的定义是如何设计的？下图是一个简略示例：
apiVersion 咱们先不讲，具体看一下上面的局部：
kind：类型，上图类型为 CanaryDeployment（无状态服务）
name：名称
namespace：地位，在 mohb-test 这个测试空间下
version：版本
replicas：灰度实例个数，这个个数是可配的
weight：权重，影响了灰度服务接管多少流量
apisix：服务对应的 hb 转化规定
apisixRouteMatches：相干性能
parentDeployment：原无状态服务名称
template：这里定义了刚刚讲的镜像、其余命令、凋谢端口等配置
在定义 CRD 的时候可能会遇到几个问题。第一个问题是如果删除了原服务，那灰度服务不会主动删除，会被遗留。呈现这个问题是因为没有做 Kubernetes 的回收技术，而解决这个问题须要 Kubernetes 的 ownerReferences。它能够帮忙你把灰度服务的 CRD 指到原服务的无状态服务中，也就是灰度服务的 owner 由原服务负责。
这样当删除原服务的时候，owner 会负责删除灰度服务。而删除 CanaryDeployment 的时候，只会删除它左边的 Deployment。
ownerReferences 的具体设置如下图：
咱们在定义 CRD 时退出红框局部的字段，这个字段会指定它是谁的 owner，以及它的指向。到这里创立阶段根本就实现了。
替换
接下来看第二阶段——替换。
我通过退出字段 replace 进行管制，默认状况下它是 false，如果值是 true 那控制器就会晓得要用 deployment 的进行替换。这里有个问题是什么时候进行替换？也就是什么时候把流量切过去。尽管间接切也能够，然而等原服务齐全运行起来后再切无疑是更好的。
那具体要怎么做呢？
这就波及到 informer 的局部逻辑了。这须要控制器可能感知到灰度服务的 parentDeployment 是否产生变更。这部分 operator-sdk 和 Kubebuilder 就很好，它能够把不是 CRD 事件的变动也导入到调和函数内，让控制器能够监听无状态服务。
具体能够看一下代码。首先注册一些 watch 来监听无状态服务，而后写一个函数让无状态服务对应到 CanaryDeployment，比方在 text back 内对无状态服务进行了标记，这样当感知到事件后能够看一下是哪个无状态服务进行了替换，并推算出对应的 CanaryDeployment，而后通过调用调和函数比照和预期是否有差距。
勾销
接下来看最初一个阶段——勾销阶段。
如果间接把 CanaryDeployment 对应的对象删掉，就会发现它的左边多了一个 deletionTimestamp 的字段，这是 Kubernetes 打的删除工夫标记。而对于控制器来讲，就是晓得这个曾经是删除状态了，须要调整对应内容。
这有个问题，删除是霎时的操作，可能等不到控制器运行起来，删除就曾经实现了。因而 Kubernetes 提供了 Finalizer，Finalizer 决定了最终由谁来做开释。
Finalizer 是自定义的，对应咱们本人写的 controller。当 Kubernetes 看到 Finalizer 不为空时，就不会立刻删除，而是出于删除中的状态，这就让 controller 有工夫去做一些对应解决。
压力测试 wrk
一套货色做完后，验证它是否正确的办法就是进行压力测试。
我用了一个更加通用的工具来做压力测试，能够设置更多的货色。比方能够做一些逻辑上的解决。如上图例子一样，假如有一个服务，申请原服务会返回“helloword”，而申请灰度版本则会返回“hello Hongbo”。而后定义回来的包，让每一个申请完结后都会调用函数判断是否等于 200，如果不是，那可能是切的过程中呈现了异样，如果等于 200，则能够看一下外面是否有“Hongbo”。如果有，那证实申请的是灰度版本。这样房门定一个档（summary），对申请到原服务、灰度服务、失败申请的次数进行统计了。
另外还能够进行一下头部设置：
-c：多少个链接，比方 20
-d：放低多长时间，比方 3 分钟
-s：脚本对应的地址
上图是压测的后果，大家能够简略看一下。
总结和布局
接下来和大家谈一下引入 CRD 后的总结。在引⼊ CRD 后，基于 Kubernetes 事件驱动以及⽔平触发的理念，简化了实现的复杂性。而且因为采纳了 OperatorSDK 的成熟框架，不再须要关怀底层的实现，能够更加聚焦于业务的逻辑实现。缩小了开发成本，进步了开发效率。