我有一个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起，香草Kubernetes中没有所需的功能。
然而，这是可以做到的。Helm和Kustomize可能是实现这一目标的两种最佳方法，但也可以使用sed或awk。Helm是Kubernetes清单的模板引擎。也就是说，您创建通用清单，通过变量将所需清单与通用清单之间的增量模板化，然后提供一个变量文件。然后，在运行时，变量文件中的变量会自动注入到模板中。
另一种实现这一点的方法是为什么Kustomize。这是我个人的建议。Kustoize与Helm类似，它处理从通用清单生成自定义清单的问题，但它不是通过模板来实现的。Kustoize的独特之处在于它在运行时执行YAML或JSON文件之间的合并补丁。这些补丁程序被称为overlay，因此它通常被称为覆盖引擎，以区别于传统的模板引擎。原因是Kustoize可以与基和覆盖的递归目录树一起使用。这使得它在可能需要从样板通用示例生成数十、数百或数千个清单的环境中更具可扩展性。
那么我们该怎么做呢？使用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的Kustoize功能，而不是为单个文本key:value对手动创建configMap文件。
既然我们已经做到了，我们必须真正制作我们的第一个补丁！由于入口中的delta非常小，所以没有那么难。创建./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生成结果清单，以应用于Kubernetes API服务器。
- Kuectl内部版本：
kubectl kustomize ./example/overlays/domain_a - Kustomize内部版本：
kustomize build ./example/overlays/domain_a
运行上面的Build命令之一，并查看终端中生成的STDOUT。注意它是如何包含两个文件myingress和config的吗？myingress是否包含覆盖补丁中的域配置？
所以，在这一点上，你可能在问。如果Kuectl默认支持这些功能，为什么Kustomize会存在？Kustoize最初是作为一个外部项目启动的，Kustoize二进制文件通常运行的版本比Kuectl中的版本更新。
下一步是创建第二个覆盖。所以继续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的开始。在看到每个覆盖的kustomization.yml文件中的configMapGenerator字段后，你可能已经猜到了，Kustoize有很多功能。它可以为所有资源添加标签，可以覆盖它们的名称空间或容器图像信息，等等。
我希望这能有所帮助。如果你还有其他问题，请告诉我。