Kustomize用Base Overlay分离信息但不解决应用全生命周期管理

面对[[Kubernetes封装了服务集群却没有真正封装应用是复杂性的根源]]， Kubernetes官方给出的第一种方案是Kustomize——本质是”用配置文件来配置 配置文件”，一种针对YAML的模板引擎变体。核心思路是把应用不变的信息与 易变的信息分离：用Kustomization文件（YAML格式）组织应用涉及的全部资源， 再用Base（基准配置）+ Overlay（覆盖配置）的方式，针对不同模式（生产/ 调试）、不同项目（同产品不同客户定制）派生出不同的资源整合包；部署期还 能通过kubectl的补丁（Patch）机制，让运维人员在不改动原始配置的前提下 调整他们关心的属性（比如加副本数、改内存限制）。这套Base+Overlay+Patch 的思路和Docker分层镜像的思路有相似之处，既不侵入资源元数据文件本身 （不需要”字符替换”这种脏手段），也不要求用户学习额外的DSL语法（如Lua）。 但Kustomize终究只是一个轻量小工具：对开发人员，它只是简化了针对不同 情况的重复配置，该写的配置一分没少，只是不用重复写；对运维人员，应用 维护远不止安装部署，整个生命周期还有更新、回滚、卸载、多版本、多实例、 依赖项维护这些问题，Kustomize统统帮不上忙。它的价值恰恰在于这份”克制”—— 以极小成本在一定程度上分离开发和运维关注点，不需要像后续的Helm那样 建立一整套独立的应用管理体系，轻量便捷本身就是一种可贵的取舍。