大盘点: KubeCon EU 2019 应用管理领域的新看点!

阅读数:7373 2019 年 5 月 31 日 08:00

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

收藏

评论

微博

用户头像
发表评论

注册/登录 InfoQ 发表评论