Kubernetes-每个环境的不同设置 [英] Kubernetes - different settings per environment

问题描述

我们有一个在GKE Kubernetes上运行的应用程序，它希望将身份验证URL(用户将通过其浏览器重定向到该URL)作为环境变量传递.

We have an app that runs on GKE Kubernetes and which expects an auth url (to which user will be redirected via his browser) to be passed as environment variable.

我们在每个环境中使用不同的名称空间

We are using different namespaces per environment

所以我们当前的pod配置看起来像这样:

So our current pod config looks something like this:

  env:
    - name: ENV
      valueFrom:
        fieldRef:
          fieldPath: metadata.namespace
    - name: AUTH_URL
      value: https://auth.$(ENV).example.org 

所有功能都令人惊讶，我们可以拥有任意数量的动态环境，只需应用-f config.yaml，它就可以完美运行而无需更改单个配置文件和任何第三方脚本.

And all works amazingly, we can have as many dynamic environments as we want, we just do apply -f config.yaml and it works flawlessly without changing a single config file and without any third party scripts.

现在用于生产的我们有点想使用不同的域，因此常规模式https://auth.$(ENV).example.org不再起作用.

Now for production we kind of want to use different domain, so the general pattern https://auth.$(ENV).example.org does not work anymore.

我们有什么选择?

1. 由于配置位于git repo中，请为prod环境创建一个单独的分支
2. 具有针对产品环境的默认ConfigMap和特定的ConfigMap，并通过某些脚本运行(如果存在prod-config.yaml然后使用它，否则使用config.yaml)-但是使用这种方法，我们不能再直接使用kubectl
3. 将此配置移到应用程序级别，并具有用于prod env的单独配置文件-但这与12factor应用程序背道而驰吗?
4. 其他...?

1. Since configs are in git repo, create a separate branch for prod environment
2. Have a default ConfigMap and a specific one for prod environment, and run it via some script (if exists prod-config.yaml then use that, else use config.yaml) - but with this approach we cannot use kubectl directly anymore
3. Move this config to application level, and have separate config file for prod env - but this kind of goes against 12factor app?
4. Other...?

推荐答案

这似乎是使用 helm 的理想机会！

This seems like an ideal opportunity to use helm!

开始非常简单，只需将分er安装到群集中即可.

It's really easy to get started, simply install tiller into your cluster.

Helm使您能够创建可以安装到集群中的图表"(类似于软件包).您可以非常轻松地对它们进行模板化.例如，您可能会让config.yaml看起来像这样:

Helm gives you the ability to create "charts" (which are like packages) which can be installed into your cluster. You can template these really easily. As an example, you might have you config.yaml look like this:

env:
  - name: AUTH_URL
    value: {{ .Values.auth.url }} 

然后，在掌舵图中，您有一个values.yaml，其中包含url的默认值，例如:

Then, within the helm chart you have a values.yaml which contains defaults for the url, for example:

auth:
  url: https://auth.namespace.example.org

您可以对头盔使用--values选项，以指定每个环境values.yaml文件，甚至在使用helm install时甚至可以使用头盔上的--set标志覆盖它们.

You can use the --values option with helm to specify per environment values.yaml files, or even use the --set flag on helm to override them when using helm install.

在此处查看文档>有关值和模板如何掌舵的信息.对于您的用例来说似乎很完美

Take a look at the documentation here for information about how values and templating works in helm. It seems perfect for your use case

这篇关于Kubernetes-每个环境的不同设置的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！