Helm模拟Linux包管理器思路却难以应对有状态应用

Helm走的是比[[Kustomize用Base Overlay分离信息但不解决应用全生命周期 管理]]更系统的路线：直接照搬Linux发行版包管理工具（apt-get/dpkg、 yum/rpm）的成熟思路——用户只要知道应用名，就能从仓库下载、安装、升级、 部署、卸载、回滚，依赖信息和版本变更由工具自己管理。对应地，Helm设计了 Chart（应用封装格式，一个目录集合，含Chart.yaml描述应用信息、 requirements.yaml声明依赖坐标、values.yaml给出可配置项默认值、 templates目录存放资源模板）和Repository（应用仓库，支持公共/私有仓库， 还能通过Hub聚合形成更大的分布式仓库）。部署时Helm把管理员设置的值覆盖 到values.yaml默认值上，再以字符串替换的形式传给模板，生成最终要部署的 资源文件。但Linux和Kubernetes部署应用有个关键差异：Linux里99%的应用只 装一份，Kubernetes里为保证可用性，同一个应用部署多份副本才是常态。Helm 为此引入了Release概念（每次安装产生一个版本，相当于该Chart的安装实例）， 对无状态服务这已经足够支撑多实例并行工作。但对有状态服务（如需要绑定 特定存储位置的数据库），多个Release之间会各自和特定资源产生依赖关系， Helm本身管不好这种依赖——这道坎正是Operator要专门解决的痛点。