在源代码管理中存储kubernetes配置的最佳实践

Question

在Kubernetes文档站点的几个位置,他们建议您将配置YAML文件存储在源代码管理中,以便于版本跟踪,回滚和部署.

我和我的同事目前正在尝试决定我们的git存储库的结构.

• 我们已经决定,由于配置可以在不对应用程序代码进行任何更改的情况下进行更改,因此我们希望将配置存储在单独的共享存储库中.
• 我们可能需要在给定环境(集群)中并行运行的某些组件的多个版本.这些版本可能具有不同的配置.

似乎存在很多潜在的变化,并且所有这些变化都有缺点.构建此类存储库的可接受方式是什么？

Answer 1

我相信还没有既定的标准.我发现helm的图表太复杂了,特别是在k8s集群上运行了另一个非托管组件.这是我们遵循的工作流程,可以很好地设置15个微服务和5种不同的环境(devx2,staging,qa,prod).

2个关键思想:

1. 将kubernetes配置存储在具有其他构建工具的相同源repo中.例如:与微服务源代码一起,其具有用于构建/释放该特定微服务的工具.
2. 使用像jinja这样的kubernetes配置模板,并根据您定位的环境渲染模板.

通过组合一些bash脚本或与Makefile等集成,可以非常直接地找到工具.

编辑:回答评论中的一些问题

应用程序源代码存储库用作单一事实来源.这意味着如果一切正常,那么永远不应该将更改从kubernetes集群移动到存储库.

我们的工作流程中禁止直接在服务器上进行更改.如果它确实发生过,我们必须手动确保它们再次进入应用程序存储库.

再次,只是想要注意,源代码中存储的配置实际上是模板并且使用secretKeyRef非常自由.这意味着一些配置从CI工具中传入,因为它们被渲染,一些配置来自仅存在于集群上的秘密(如数据库密码,API令牌等).

Answer 2

在我看来，Helm 之于 kubernetes 就像 Docker-compose 之于 docker

没有理由害怕 helm，因为在它最基本的功能中，它所做的一切都类似于kubectl apply -f templates.

熟悉 helm 后，您就可以开始使用values.yaml并将值添加到 kubernetes 模板中，以获得最大的灵活性。

值.yaml

name: my-name

在模板/deployment.yaml 中

name: {{ .Values.name }}

https://helm.sh/

我的方法是在每个项目中创建一个 helm 子目录，与包含 docker-compose.yml 文件的方式相同。

除此之外，您还可以为所有引用预构建图像的项目维护一个 helm 存储库

Answer 3

我认为helm将成为为 kubernetes 集群创建应用程序安装程序的标准化方式。我将尝试创建自己的图表来参数化我的应用程序部署。

Answer 4

Google 构建了一个工具来帮助 k8s 开发：https://github.com/GoogleContainerTools/skaffold。它提出了存储信息以供团队成员/CI 等重用的方法。

还有一个 Terraform Kubernetes 提供程序，它允许您将整个 Kubernetes 配置保留为 Terraform 配置文件：https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs。如果您已经使用 Terraform 或其他 Hashicorp 工具，这可能是一个不错的选择。