如何使用Helm和Kubernetes管理10+个团队环境

86次阅读

问题描述

在寻求关于如何改进团队环境和分阶段部署过程的反馈意见。他们目前有10个敏捷团队，并通过Helm设置了他们的Kubernetes部署。具体而言，他们的Helm chart都位于单一的git仓库中。在仓库的顶层，有一组bash脚本（deploy.sh、buildSecrets.sh、buildConfigMaps.sh）以及一些JSON配置文件（namespaceCharts.json、secrets.json、configmaps.json）。其中，两个主要的配置文件是一份包含加密的密钥的长列表，以及一份包含80%共享于Helm chart之间的配置映射环境变量的长列表。namespaceCharts.json定义了每个命名空间组中需要部署的chart。对于每个部署的环境，他们会克隆仓库，更改secrets.json和configmaps.json的值，然后运行脚本，传入基础命名空间名称（例如，团队名称）。这导致他们创建了一系列的命名空间，如teamA-frontend和TeamA-backend，每个命名空间包含了正确的微服务以及连接到正确数据库的连接字符串。目前，他们遇到了一些主要障碍：
1. 难以部署到多个集群或新集群。
2. 难以获得配置的单一真实来源。
3. 难以设置全新的团队环境，因为他们必须查看整个配置文件以确定需要更改或保留的内容。
他们提出了三种推进的方式，但都感觉不太合适：
1. 将所有环境配置存储在单独的“配置”git仓库中。
2. 创建一个配置服务，其中包含一个定义每个环境的数据库表，并创建一个发布/订阅功能，以在运行时动态获取配置，以及在.sh脚本中动态获取配置。
3. 使用ansible或类似工具来存储每个环境的脚本和配置。

解决方案

请注意以下操作注意版本差异及修改前做好备份。

方案1

首先，我们来讨论在单一git仓库中管理多个Helm chart以及配置文件的挑战。如果你希望简化配置管理并提高可维护性，以下解决方案可能会有所帮助：

将配置与代码分离: 首先，建议将密钥和配置从代码库中分离出来，以便更好地管理。可以考虑使用专门的配置管理工具或密钥管理服务来存储和管理这些敏感数据。
使用Helm Values文件: 对于80%共享的配置映射环境变量，你可以考虑使用Helm的Values文件来管理。为每个团队/命名空间创建一个单独的Values文件，其中包含特定于团队的配置。这将有助于减少重复工作，同时保持清晰的配置管理。以下是一个示例目录结构：

- helm-charts/
  - teamA/
    - values.yaml
  - teamB/
    - values.yaml
  - ...

使用Helm Chart Inheritance: 如果存在大量共享的配置，你可以考虑创建一个基础的Helm Chart，然后在各个团队的Chart中引用该基础Chart，并覆盖必要的配置值。这样，你可以将共享配置集中到基础Chart中，同时允许团队自定义其特定配置。
使用Helm Hooks: 如果部署需要在多个chart之间进行协调或某些配置需要在部署过程中进行修改，你可以使用Helm的Hooks来实现。Hooks允许你定义在不同部署阶段执行的操作，例如在部署前或部署后运行脚本等。

方案2

下面是关于使用ArgoCD来简化多个团队环境的部署和管理的解决方案：

使用ArgoCD项目: ArgoCD支持项目的概念，你可以为每个团队创建一个独立的项目。每个项目可以包含特定团队的应用程序部署。这样，每个团队都可以独立管理其自己的应用程序和配置。
配置管理: 在ArgoCD项目中，你可以将Kubernetes YAML文件存储在Git仓库中。对于共享的配置，可以将它们作为独立的Kubernetes资源存储，然后在各个团队的项目中引用这些资源。这确保了共享配置的一致性和可维护性。
多集群支持: ArgoCD支持多集群部署，你可以使用一个ArgoCD控制台来管理多个集群中的应用程序。这可以帮助你在不同集群之间部署应用程序，提供更好的灵活性。
GitOps工作流程: ArgoCD采用GitOps工作流程，即以Git仓库作为单一的配置源。这有助于确保所有环境的配置都可以跟踪，审查和版本控制。