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

众所周知，云原生架构的中心项目是 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 这样的公司开始加入到云原生阵营。拥抱开源生态和技术标准，俨然成为当前互联网企业的一个重要机遇和挑战。构建面向云原生的应用与架构，借助云以及开源的力量，才能做好充分准备在这场上云的变革中扬帆远航。

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