假设我需要创建环境变量或 ConfigMap 条目，如下所示:
- name: JDBC_URL
value: "jdbc:db2://alice-service-a:50000/db1"
- name: KEYCLOAK_BASE_URL
value: "http://alice-keycloak:8080/auth"
其中 alice- 是 namePrefix。如何使用 Kustomize 执行此操作？
我实际上使用的容器确实需要引用其他容器，这些容器是像上面那样的“变量”的字符串连接。
Kustomize 的 vars 似乎无法做到这一点。文档条目Unstructured Edits似乎描述了这一点，并且在名为“回避功能”的标题下，所以我想这不会发生。类似的功能请求，#775 Support envsubst style variable expansion已关闭。
来自 Helm，这很容易。
如果我想从 Helm 迁移到 Kustomize，但需要创建一个 env 或 ConfigMap 条目，例如jdbc:db2://${namePrefix}-service-b:${dbPort}/${dbName}(诚然是一个人为的示例)？
我猜我必须求助于 Kustomize 外部的功能，例如 envsubst。是否有任何将其拼凑在一起的最佳实践，或者我是否编写自己的 custom-deploy-script.sh？
最佳答案
恐怕我遇到了 Kustomize 的局限性之一。
The State of Kubernetes Configuration Management: An Unsolved Problem | by Jesse Suen | Argo Project在“Kustomize:坏处”下面有这样的说法:
No parameters & templates. The same property that makes kustomize applications so readable, can also make it very limiting. For example, I was recently trying to get the kustomize CLI to set an image tag for a custom resource instead of a Deployment, but was unable to. Kustomize does have a concept of “vars,” which look a lot like parameters, but somehow aren’t, and can only be used in Kustomize’s sanctioned whitelist of field paths. I feel like this is one of those times when the solution, despite making the hard things easy, ends up making the easy things hard.
相反，我开始使用 gomplate: A flexible commandline tool for template rendering除了 Kustomize 之外，还可以解决上述挑战，但必须使用两个不能协同工作的工具并不理想。
编辑:我们最终使用了 ytt为此，而不是 gomplate。
我强烈推荐这篇文章:The State of Kubernetes Configuration Management: An Unsolved Problem 。很高兴知道我不是唯一遇到这个障碍的人。
关于kubernetes - 如何使用 Kustomize 并创建类似 : "http://${namePrefix}service-a/some-path" or "jdbc:db2://${namePrefix}service-b:${dbPort}/${dbName}" 的环境，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/65815660/