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

Question

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

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

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

似乎存在很多潜在的变化，并且所有这些变化都有缺点。构建这样一个存储库的可接受方法是什么？

Answer 1

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

两个关键想法：

1. 将kubernetes配置存储在具有的kbynetes配置中 其他构建工具。例如：与微服务源代码一起，其具有用于构建/释放该特定微服务的工具。
2. 使用类似jinja的kubernetes配置模板，并根据您要定位的环境渲染模板。

通过组合一些bash脚本或与Makefile等集成，可以非常直接地弄清楚工具。

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

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

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

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

Answer 2

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

Answer 3

在我看来，Helm是kubernetes，因为Docker-compose是docker

没有理由担心掌舵，因为它是最基本的功能，所有它都与V3 = V2; V3(~V1) = NaN; 类似。

熟悉helm后，您可以开始使用kubectl apply -f templates并在kubernetes模板中添加值，以获得最大的灵活性。

values.yaml

values.yaml

inside templates / deployment.yaml

name: my-name

https://helm.sh/

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

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

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工具，这可能是一个不错的选择。

Answer 5

使用单独的存储库来存储配置。

如果您要协调多个微服务，则它们都不对配置具有权威性-尤其是当您并行运行多个配置时，例如用于金丝雀测试。

Helm（https://helm.sh/）帮助您通过多个微服务的配置传播常量。同样，这表明这些常量/参数与任何单个代码库无关。