kubernetes - Kubernetes 和 helm 生态系统中应用程序配置管理的最佳实践

Question

使用 Kubernetes 和 helm 已经有一段时间了，我发现在 Kubernetes 世界中仅使用 helm 来处理应用程序配置是很不自然的。

几个原因是：

• 配置在集群外部进行管理，使用 helm 客户端和额外的 yamls 进行自定义配置。额外的值 yaml 文件未经过验证，并且随着时间的推移可能会变得非常大。
• 额外的值不会被版本化或持久化，您需要想出自己的方式来跟踪上次应用的自定义配置。
• 配置更新对用户不友好：您必须更新额外的值 yaml，执行 helm 升级，等待服务重新启动（只有当您正确编写 helm 图表以在配置映射更新上重新部署工作负载时）。这只是为了更新应用程序中的阈值之类的东西。
• 使用 etcd 作为应用程序的数据库更像是一种反模式，因为 etcd 由于其顺序 IO 要求，已经对磁盘写入延迟非常敏感。
• 重用/重置值混淆helm reset 重用行为

我想知道混合解决方案是否像

• 使用 helm 只处理 kubernetes 资源配置
• 对于特定于应用程序的配置，使用集群内的集中配置服务（例如构建在 Spring Cloud Config 或类似项目之上的东西）

可能更适合这个生态系统。

您如何在 k8s 中进行应用程序级配置管理？你只对 helm 满意吗？有没有更好的解决方案你付诸实践并得到了回报？

标签： kubernetesconfigurationkubernetes-helm