如何使用Helm和Kubernetes管理10+团队环境？
我正在寻找关于如何改进我们的团队环境和分阶段部署过程的反馈。我们目前有10个敏捷团队，并通过Helm建立了Kubernetes部署，如下所示：
我们所有的舵机图表都是在一个git回购中。在回购的顶层，我们有一个bash脚本集合(deploy.sh、buildSecrets.sh和buildConfigMaps.sh)和一些json配置文件。(namespaceCharts.json、secrets.json、configmaps.json)
这两个主要配置文件是加密的秘密列表和配置映射环境变量的长列表，其中80%是在舵机图表之间共享的。namespaceCharts.json定义了需要部署到每个命名空间分组中的图表。
对于部署到的每个环境，我们克隆repo，更改secrets.json和configmaps.json的值，然后运行传入基本命名空间名称的脚本。(例如，团队名称)
这导致我们基本上创建了一系列名称空间，如teamA-frontend和TeamA-backend，每个名称空间都包含具有指向正确DB的连接字符串的正确的微服务，等等。
我们目前遇到了几个主要的障碍。
- 很难部署到多个集群或新集群。
- 这是很难得到一个单一的真实来源的配置。
- 很难建立一个全新的团队环境，因为我们必须遍历整个配置文件来查看需要更改或保存的内容。
我想出了三种前进的方法，所有这些都让我“觉得不对”。
- 将所有环境配置存储在单独的“配置”git中。
- 使用DB表创建一个配置服务，定义每个环境，并创建一个pub/sub特性，以便在运行时动态获取配置，以及在.sh脚本中动态抓取配置。
- 使用ansible或类似的方法来存储每个环境的脚本和配置。
我们做错了吗？我们是不是缺少一些明显的最佳做法来更好地做到这一点？这三种想法之一实际上是正确的方法吗？
回答 4
DevOps用户
发布于 2019-03-17 22:49:26
我的2美分。我们和你们有类似的要求。我们最终会有多个values-<namespace>.yaml形式的值文件，它应该以默认设置为values.yaml。
我们还有一些shell脚本要部署到名称空间中。就像这个deploy.sh --命名空间应用。
这不是没有问题的，文件的数量在稳步增长。但到目前为止我们还好。
DevOps用户
发布于 2019-03-19 02:41:02
结帐通量(https://github.com/weaveworks/flux/)，它引入了一个名为HelmRelease的新的kubernetes crd，您可以在其中包含您的头盔发布信息(比如图表回购、名称、版本、命名空间和值)。你甚至可以从git回购中提取图表)。
磁通控制器监视您选择的git回购(您也可以监视回购内部的路径，我认为这可能最适合您的需求)。并定期应用该路径中的所有yaml/json文件(包括HelmRelease定义)。
当创建一个新的HelmRelease定义时，称为helm-operator的另一个通量组件将接管并尝试创建/更新您的舵机发布到所需的状态。
这方面的好处是，您可以使用各种yaml/json文件定义所需的集群状态，通量将设法保持它的同步。如果您想要缓存一个新集群，只需将文件复制到一个新文件夹，部署您的集群，使用新文件夹路径在其上配置流量，它将为您完成剩下的工作。请注意，通量不是一个完整的ci/cd解决方案，因此您不能在其中运行shell脚本，您必须找到一种不同的方式将这些信息编码到yaml文件中。
看看这里(https://github.com/stefanprodan/gitops-helm)的最小git。
DevOps用户
发布于 2019-03-23 22:51:17
我已经制作了脚本和工具，我们用它来解决这些问题--在GitHub上开源--称之为强迫症。你提到你认为以下感觉是不对的：
- 将所有环境配置存储在单独的“配置”git repo中。
- 使用ansible或类似的方法来存储每个环境的脚本和配置。
使用OCD时，我们使用赫尔姆文件，这使得管理少量简单的yaml文件中的任何一个文件中的许多helm发行版变得容易。如果您熟悉Ansible，那么它提供了该工具的所有优点，但它只管理舵机发布。将helmfile.yml配置放到Git中是完全有意义的。这些作为游戏手册来设置您的环境。他们不应该生活在应用程序的回复中，而应该生活在一个或多个“环境回购(S)”中。
我们创建了一个通用图表来安装机密，另一个用来安装configmap。您的文件夹结构看起来可能如下：
|____config
| |____nexmo.yaml.secret // <- gpg encrypted secret
| |____reepay.yaml.secret
| |____backoffice-db.yaml.secret
| |____helmfile.yaml // <- hemlfile manages 3 secret releases and inline configmaps
|____backoffice-app
| |____helmfile.yaml // <- hemlfile manages 1 app
|____frontoffice-app
| |____helmfile.yaml // <- hemlfile manages 1 app在上面的例子中，我们有三个helmfile。有一个用于管理共享配置，另一个用于管理使用共享配置的应用程序。由于共享配置将是multipe秘密和configmap，所以它只使用两个通用图表。它使用通用秘密图使用不同的值文件来消除许多单独的加密秘密。同样，一个通用结构图被用来通过输入不同的值来消除多个configmap。
使用OCD，您可以在配置回购上安装webhooks，以指向adnanh/web钩子。当您将更改推送到配置回购时，web钩子就会触发。Web钩子运行一个脚本来签出配置回购，解密秘密，然后在每个有一个helmfile apply的文件夹中执行helmfile.yaml。这将对每个helmfile中的每个版本执行一个helmfile，因此将升级yaml已更改的所有机密、configmap或应用程序部署。
我们有一个向导脚本将web钩子安装到一个新的环境中。这意味着团队可以使用git中的配置快速创建一个新的环境。因为它是从git加载配置，所以它是一个准确的过程。这是一个六分钟内建立一个新的环境的视频，如果我不制作视频的话会更快。
Helmfile减少了必须遍历所有文件以尝试为新的团队环境找到要更改的所有设置的负担。helmfile.yaml捕获您要覆盖的图表默认值的任何内容。所有的配置图和秘密都是组织起来的，很容易在一个地方找到。Helmfile拥有相当多的功能，使得管理配置和管理许多helm发行版变得更容易。
我们碰巧使用openshift kubernetes，所以我们的微服务应用程序部署图使用openshift特定的yaml。然而，秘密和配置图都是普通的k8s。因此，OCD管理配置的方法和脚本应该与任何k8s发行版一起工作。我们计划在未来几周内发布1.0版本的强迫症。我正在考虑在普通的k8s上运行OCD来管理配置。所以我会对你的想法感兴趣，也许我们可以合作。只需在上提出一个问题，询问如何在您正在使用的k8s版本上运行它。
https://devops.stackexchange.com/questions/6641
复制相似问题
腾讯云开发者
