大盘点： KubeCon EU 2019 应用管理领域的新看点！

摘要： KubeCon EU 2019 刚刚在巴塞罗那拉下帷幕，来自阿里巴巴经济体的讲师团，在大会上分享了互联网场景下规模化 Kubernetes 集群的各项落地经验和教训。所谓“独行速而众行远”，从不断发展壮大的社区中，咱们看到愈来愈多的人拥抱开源，往标准演进，搭上了这趟开往云原生的高速列车。

众所周知，云原生架构的中心项目是 Kubernetes，而 Kubernetes 则围绕着“应用”来展开。让应用部署得更好，让开发者更高效，才能给团队和组织带来切实的利益，才能让云原生技术变革发挥更大的做用。变革的势头既如洪水般吞没着老旧封闭的内部系统，又如春雨般孕育出更多的新开发者工具。在本次 KubeCon 中，就出现了许多有关应用管理与部署的新知识。这些知识中有哪些想法和思路值得借鉴，让咱们少走弯路？在它们背后，又预示着什么样的技术演进方向？

在本文中，咱们邀请到了阿里云容器平台技术专家、原 CoreOS 公司工程师、 K8s Operator 项目的核心做者之一邓洪超，为读者精选了这次会议“应用管理”领域的精华内容来一一进行分析与点评。

The Config Changed

Kubernetes 上部署的应用通常会把配置存放到 ConfigMap 里，而后挂载到 Pod 文件系统中去。当 ConfigMap 发生更改时，只有 Pod 里挂载的文件会被自动更新。这种作法对某些会自动作热更新的应用（好比 nginx）来讲是 OK 的。可是，对于大多数应用开发者来讲，他们更倾向于认为更改配置要作一次新的灰度发布、跟 ConfigMap 相关联的容器应该作一次灰度升级。

灰度升级不只简化了用户代码，加强了安全稳定性，更是体现了不可变基础架构的思想。应用一旦部署，就再也不作变动。须要升级时，只要部署一个新版系统，验证 OK 后再摧毁旧版就行了；验证不经过时也容易回滚到旧版。正是基于这样的思路，来自 Pusher 的工程师们研发了 Wave，一款自动监听 Deployment 相关联的 ConfigMap/Secret 并随之改动而触发 Deployment 升级的工具。这款工具的独特之处在于它会自动搜索该 Deployment PodTemplate 里面的 ConfigMap/Secret，而后把里面全部数据计算一次 hash 放到 PodTemplate annotations 里面；当有变更时，会从新计算一次 hash 并更新 PodTemplate annotations，从而触发 Deployment 升级。无独有偶，开源社区里还有另外一款工具 Reloader 也作了相似的功能——不一样的是，Reloader 还能让用户本身选择填写监听哪几个 ConfigMap/Secret。

分析与点评

升级不灰度，背锅两行泪。不管是升级应用镜像仍是更改配置，都要记得作一次新的灰度发布和验证。

另外咱们也看到，不可变基础架构给构建云计算应用带来了崭新的视角。朝着这个方向发展，不只能让架构更安全更可靠，更是能跟其余主要工具结合好，充分发挥云原生社区的做用，对传统应用服务实现“弯道超车”。举个例子，充分结合上面的 wave 项目和 Istio 中 weighted routing 功能，网站就能达到小部分流量对新版配置进行验证的效果。

Server-side Apply

Kubernetes 是一个声明式的资源管理系统。用户在本地定义指望的状态，而后经过 kubectl apply 去跟更新当前集群状态中被用户指定的那一部分。然而它远没有听起来那么简单…

原来的 kubectl apply 是基于客户端实现的。Apply 的时候不能简单地替换掉单个资源的总体状态，由于还有其余人也会去更改资源，好比 controllers、admissions、webhooks。那么怎样保证在改一个资源的同时，不会覆盖掉别人的改动呢？因而就有了现有的 3 way merge：用户把 last applied state 存在 Pod annotations 里，在下次 apply 的时候根据 (最新状态，last applied，用户指定状态) 作 3 way diff，而后生成 patch 发送到 APIServer。可是这样作仍是有问题！Apply 的初衷是让个体去指定哪些资源字段归他管理。可是原有实现既不能阻止不一样个体之间互相篡改字段，也没有在冲突发生时告知用户和解决。举个例子，笔者原来在 CoreOS 工做时，产品里自带的 controller 和用户都会去更改 Node 对象的一些特殊 labels，结果出现冲突，致使集群出故障了只能派人去修。

这种克苏鲁式的恐惧笼罩着每个 k8s 用户，而如今咱们终于迎来了胜利的曙光——那就是服务器端 apply。APIServer 会作 diff 和 merge 操做，不少本来易碎的现象都获得了解决。更重要的是，相比于原来用 last-applied annotations，服务器端 apply 新提供了一种声明式 API (叫 ManagedFields) 来明确指定谁管理哪些资源字段。而当发生冲突时，好比 kubectl 和 controller 都改同一个字段时，非 Admin（管理员）的请求会返回错误而且提示去解决。

分析与点评

妈妈不再用担忧我 kubectl apply 了。虽然仍是 Alpha 阶段，可是服务器端 apply 替代客户端只是时间问题。这样一来，不一样组件同时更改同一资源将会变得更加安全可靠。

另外咱们也看到，随着系统的发展，尤为是声明式 API 的普遍使用，在本地的逻辑将会变少，而在服务器端的则会变多。在服务器端有诸多好处：许多操做，好比 kubectl dry-run、diff，在服务器端实现会更简单；提供 HTTP endpoint，这样会更容易把 apply 这样的功能构建到其余工具中；把复杂逻辑放到服务器端实现和发布，可以更容易作好管控，让用户享受到安全、一致、高质量的服务。

Gitops

会议中有一个座谈小组讨论了 Gitops 的好处，下面给你们总结一下。

第一，Gitops 让整个团队内部更“民主”了。全部东西都写下来了，想看就看。任何变动在发布前都须要走 pull request，不只让你知道得清清楚楚，还能让你参与评审输入意见。全部改动、讨论通通都记录在 Github 等工具上，随时能够翻看历史。这些种种让团队协做更流畅和专业化。

第二，Gitops 让发布更安全稳定了。代码再也不可以随意发布，须要相关负责人、甚至多人评审。须要回滚时，原来的版本就存在 Git 里面。谁在何时发布了什么代码，有审计历史。这些种种发布流程更专业化，让发布结果更稳定可靠。

分析与点评

Gitops 不只仅是解决一个技术问题，更主要的利用 Github 等工具的版本、历史、审计、权限让，让团队协做和发布流程更专业化和流程化。

Gitops 若是可以普遍推广，对整个业界的影响将是巨大的。比方说，不论去任何公司，任何人均可以快速上手发布代码。

Gitops 里面体现的 Configuration as code 和 Git as the source of truth 的思想，仍是很是值得咱们学习和实践的。

Automated Canary Rollout

金丝雀发布 (Canary rollout)，是指在发布过程当中，先将一小部分流量导入到新版本，并分析和验证上线行为是否正常。一切正常的话继续将流量逐渐切换到新版本中，直到旧版没有流量并被摧毁。咱们知道，在 Spinnaker 等工具中，会有一个手工验证和经过的步骤。这个步骤其实能够用自动化工具替代掉，毕竟每次检查的东西都挺机械式的，例如检查下成功率和 p99 延时。

基于上述思想，来自 Amadeus 和 Datadog 的工程师分享了如何利用 Kubernetes、Operator、Istio、Prometheus 等工具来作金丝雀发布。思路是整个金丝雀发布被抽象成一个 CRD，而后作一次金丝雀发布的过程就变成了编写一个声明式的 YAML 文件就够了，Operator 收到用户建立的 YAML 文件后会自动完成复杂的运维操做。这里主要步骤分为:

部署新版本服务 (Deployment + Service)

更改 Istio VirtualService 配置切换一部分流量到新版本 ;
检验 Istio metrics 中新版本服务的成功率和 p99 响应时间是否均知足条件 ;
若是知足则整个应用升级到新版本；不然就回滚。

无独有偶，Weave 也开源了自动化金丝雀发布工具 Flagger。不一样的是，Flagger 会按部就班地切流到新版本，好比每次新切 5% 流量过去，等到流量都切过去直接摧毁旧版。

分析与点评

使用金丝雀发布一时爽，一直使用一直爽。金丝雀发布有助于提升发布成功率和系统稳定性，是应用管理的重要流程。

另外咱们也看到，云原生时代这些复杂的运维流程将被简化和标准化。经过 CRD 抽象，里面复杂的过程步骤将变成几个短短的 API 对象提供给用户。使用 Operator 作自动化运维，只要在 Kubernetes 标准平台上用户就能够用上这些功能。而 Istio 和 Kubernetes 做为顶级的标准化平台，提供了强大的基础能力让用户更容易上手。

写在最后

在这篇文章里，咱们盘点了本次 KubeCon 中有关应用管理与部署的一些新知识：

当配置文件改动时，作一个新的应用发布的缘由和方法。

客户端 kubectl apply 有诸多问题，其中重要一点就是互相篡改资源字段。这些在服务器端 apply 的实现中解决了。

Gitops 不只仅是解决一个技术问题，更主要的让团队协做和发布流程更专业化和流程化。

利用 Kubernetes、Operator、Istio、Prometheus 这些顶级标准化平台，咱们能简化金丝雀发布的运维操做，下降了开发者的使用门槛。

这些新的思想，也让咱们感慨万千：从前，咱们总在羡慕“别人家的基础架构”，它们老是这么优秀而高不可攀。而如今，开源项目和技术标准，正在将这些技术下降门槛，让每个开发者都使用上。而另外一方面，一个微妙的变化也正在发生着——“自研”的基础软件不得不面临着边际效应递减规律，致使愈来愈多的像 Twitter 这样的公司开始加入到云原生阵营。拥抱开源生态和技术标准，俨然成为当前互联网企业的一个重要机遇和挑战。构建面向云原生的应用与架构，借助云以及开源的力量，才能作好充分准备在这场上云的变革中扬帆远航。

---

本文做者：木环

阅读原文

本文为云栖社区原创内容，未经容许不得转载。