kubernetes - Kubectl-如何从配置变量读取入口主机？

我的域中有一个带有变量的ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: config
data:
  MY_DOMAIN: mydomain.com

我的目标是在Ingress配置中使用MY_DOMAIN变量

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: myingress
spec:
  tls:
    - hosts:
⮕       - config.MY_DOMAIN
      secretName: mytls
  rules:
⮕   - host: config.MY_DOMAIN
      http:
        paths:
          - backend:
              serviceName: myservice
              servicePort: 3000

但显然上述配置无效。那么如何实现呢？

最佳答案

envFrom和valueFrom函数的configMapRef和secretMapRef仅可用于环境变量，这意味着它们不能在此上下文中使用。从1.18.0开始，所需的功能在 Vanilla Kubernetes中不可用。

但是，可以做到。 Helm和Kustomize可能是完成此操作的两种最佳方法，但也可以使用sed或awk完成。 Helm是Kubernetes list 的模板引擎。这意味着，您将创建通用 list ，通过变量将通用 list 与所需 list 之间的差异模板化，然后提供一个变量文件。然后，在运行时，变量文件中的变量将自动注入(inject)到模板中。

实现此目的的另一种方法是为什么要使用Kustomize。这是我个人推荐的。 Kustomize就像Helm一样，它处理从通用 list 生成定制 list 的过程，但是它不是通过模板来完成的。 Kustomize的独特之处在于，它在运行时在YAML或JSON文件之间执行合并补丁。这些补丁被称为Overlays，因此通常被称为覆盖引擎，以使其自身与传统的模板引擎区分开。 Kustomize的原因可以与bases和overlays的递归目录树一起使用。对于需要从样板通用示例生成数十个，数百个或数千个 list 的环境而言，它具有更大的可伸缩性。

那么我们该怎么做呢？好吧，使用Kustomize首先定义一个kustomization.yml文件。在其中定义资源。在这种情况下，myingress:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
    - myingress.yml

因此，创建一个example目录，并在其中创建一个名为base的子目录。创建./example/base/kustomization.yml并使用上面的kustomization进行填充。现在创建一个./example/base/myingress.yml文件，并使用上面提供的示例myingress文件填充它。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: myingress
spec:
  tls:
    - hosts:
      - config.MY_DOMAIN
      secretName: mytls
  rules:
     - host: config.MY_DOMAIN
        http:
          paths:
            - backend:
                serviceName: myservice
                servicePort: 3000

现在我们需要定义第一个叠加层。我们将创建两个不同的域配置，以提供叠加层工作方式的示例。首先创建一个./example/overlays/domain-a目录，并在其中创建包含以下内容的kustomization.yml文件:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
    - ../../../base/

patchesStrategicMerge:
    - ing_patch.yml

configMapGenerator:
    - name: config_a
      literals:
        - MY_DOMAIN='domain_a'

至此，我们已经在该文件中定义了ing_patch.yml和config_a。 ing_patch.yml将用作我们的入口补丁，config_a将用作我们的configMap。但是，在这种情况下，我们将利用称为configMapGenerator的Kustomize功能，而不是为单个文字key:value对手动创建configMap文件。

现在，我们已经完成了此工作，我们必须实际制作第一个补丁!由于入口中的增量很小，因此并不难。创建./example/overlays/domain_a/ing_patch.yml并填充以下内容:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: myingress
spec:
  tls:
    - hosts:
      - domain.a.com
  rules:
     - host: domain.a.com

完美，您已经创建了第一个叠加层。现在，您可以使用kubectl或kustomize生成结果 list ，以应用于Kubernetes API Server。

Kubectl构建: kubectl kustomize ./example/overlays/domain_a

Kustomize构建: kustomize build ./example/overlays/domain_a

运行以上Build命令之一，并查看终端中生成的STDOUT。注意它如何包含两个文件myingress和config？ myingress包含叠加层补丁中存在的Domain配置吗？

因此，此时您可能会问。如果Kubectl默认支持这些功能，为什么Kustomize存在？ Kustomize最初是作为外部项目启动的，并且Kustomize二进制文件通常运行的版本比Kubectl中可用的版本新。

下一步是创建第二个叠加层。因此，继续cp您的第一个叠加层:cp -r ./example/overlays/domain_a ./example/overlays/domain_b。

现在您已经完成了，在文本编辑器中打开./example/overlays/domain_b/ing_patch.yml，然后将内容更改为如下所示:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: myingress
spec:
  tls:
    - hosts:
      - domain.b.com
  rules:
     - host: domain.b.com

保存文件，然后构建两个单独的叠加层:

kustomize build ./example/overlays/domain_a
kustomize build ./example/overlays/domain_b

请注意，每个生成的STDOUT流根据Overlay目录中存在的修补程序如何变化？您可以通过将“基础”设置为其他基础的覆盖层来继续抽象该模式。或通过使您的叠加层成为其他叠加层的基础。这样做可以使您以极其强大和高效的方式扩展该项目。如果需要，将它们应用于您的API服务器:

kubectl apply -k ./example/overlays/domain_a
kubectl apply -k ./example/overlays/domain_b

实际上，这仅仅是Kustomize的开始。您可能会在configMapGenerator文件中为每个叠加层看到kustomization.yml字段后猜到，Kustomize具有很多功能。它可以将labels添加到您的所有资源中，可以覆盖其namespaces或容器image信息等。

我希望这有帮助。如果您还有其他问题，请告诉我。

关于kubernetes - Kubectl-如何从配置变量读取入口主机？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/60903362/