怎么在网站上放广告,免费装修效果图网站,深圳品牌衣服店名称,网站建设规模众所周知#xff0c;云原生架构的中心项目是 Kubernetes#xff0c;而 Kubernetes 则围绕着“应用”来展开。让应用部署得更好#xff0c;让开发者更高效#xff0c;才能给团队和组织带来切实的利益#xff0c;才能让云原生技术变革发挥更大的作用。变革的势头既如洪水般吞…众所周知云原生架构的中心项目是 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 这样的公司开始加入到云原生阵营。拥抱开源生态和技术标准俨然成为当前互联网企业的一个重要机遇和挑战。构建面向云原生的应用与架构借助云以及开源的力量才能做好充分准备在这场上云的变革中扬帆远航。
原文链接 本文为云栖社区原创内容未经允许不得转载。
