众所周知，云原生架构的中心项目是 Kubernetes，而 Kubernetes 则围绕着“应用”来展开。让应用部署得更好，让开发者更高效，才能给团队和组织带来切实的利益，才能让云原生技术变革发挥更大的作用。
变革的势头既如洪水般吞没着老旧封闭的内部系统，又如春雨般孕育出更多的新开发者工具。在本次 KubeCon 中，就出现了许多有关应用管理与部署的新知识。这些知识中有哪些想法和思路值得借鉴，让我们少走弯路？在它们背后，又预示着什么样的技术演进方向？
在本文中，我们邀请到了阿里云容器平台技术专家、原 CoreOS 公司工程师、 K8s Operator 项目的核心作者之一邓洪超，为读者精选了此次会议“应用管理”领域的精华内容来一一进行分析与点评。
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 功能，网站就能达到小部分流量对新版配置进行验证的效果。
Kubernetes 是一个声明式的资源管理系统。用户在本地定义期望的状态，然后通过 kubectl apply 去跟更新当前集群状态中被用户指定的那一部分。然而它远没有听起来那么简单...null
