可以引用当前命名空间的ConfigMap

我正在使用一个Pod(Shiny Proxy(，它与Kubernetes API对话以启动其他Pod。我想让它通用，所以不想硬编码命名空间(因为我打算有多个这样的命名空间，可能部署为OpenShift模板或类似的模板(。

我使用Kustoize来设置所有对象的名称空间。以下是我的kustomization.yaml在我的叠加中的样子：

bases:
- ../../base
namespace: shiny
commonAnnotations:
technical_contact: A Local Developer <somedev@example.invalid>

运行Shiny Proxy并让它启动我需要的pod(我有服务帐户和RBAC已经排序(是可行的，只要在Shiny Proxy的配置中我指定(硬代码(应该在其中生成新pod的命名空间。Shiny Proxy将使用的默认命名空间是(不幸的("default"，这不适合我的需求。

目前，对于配置，我正在使用ConfigMap(也许我应该转到Kustomize ConfigMapGenerator(

当前有问题的ConfigMap如下所示：

apiVersion: v1
kind: ConfigMap
metadata:
name: shiny-proxy
data:
application_yml: |
...
container-backend: kubernetes
kubernetes:
url: https://kubernetes.default.svc.cluster.local:443
namespace: shiny
...

上面的作品，但"闪亮"是硬编码的；我希望能够做以下事情：

namespace: { .metadata.namespace }

但这似乎在ConfigMap中不起作用，我在文档中看不到任何东西会让人相信它会起作用，或者在ConfigMap机制中可能会出现类似的事情。

查看Kustoize文档也不清楚，尤其是配置文件基本上是纯文本(就ConfigMap而言，不是YAML文档(。我见过Vars的一些用法，但是https://github.com/kubernetes-sigs/kustomize/issues/741让人相信这不是一个开始。

有没有一种很好的声明方式来处理这个问题？或者我应该在容器中实现模板智能，这对我来说似乎有点错误，但我对Kubernetes(和OpenShift(还是个新手

我使用的是CodeReady Containers 1.24(OpenShift 4.7.2(，它本质上是Kubernetes 1.20(IIRC(。我更愿意在不太依赖OpenShift的情况下与Kubernetes保持一致，但这还为时过早。

谢谢，Cameron

如果您不想在清单文件中硬编码特定数据，可以考虑使用Kustoize插件。在这种情况下，sedtransformer插件可能很有用。这是一个示例插件，由kustoize维护人员维护和测试，但不是kustoize内置的
如您在Kustoize插件指南中所见：

Kustoize提供了一个插件框架，允许人们编写自己的资源生成器和转换器。

有关创建和使用Kustoize插件的更多信息，请参阅扩展Kustoize。

我将创建一个示例来说明如何在您的案例中使用sedtransformer插件。

假设我有一个shiny-proxyConfigMap:
注意：我没有指定名称空间，而是使用namespace: NAMESPACE。

$ cat cm.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: shiny-proxy
data:
application_yml: |
container-backend: kubernetes
kubernetes:
url: https://kubernetes.default.svc.cluster.local:443
namespace: NAMESPACE
something_else:
something: something

要使用sedtransformer插件，我们首先需要创建插件的配置文件，该文件包含一个YAML配置对象：
注意：在argsOneLiner:中，我指定NAMESPACE应替换为shiny。

$ cat sedTransformer.yaml
apiVersion: someteam.example.com/v1
kind: SedTransformer
metadata:
name: sedtransformer
argsOneLiner: s/NAMESPACE/shiny/g

接下来，我们需要将SedTransformer Bash脚本放在正确的位置。

加载时，kustosize将首先查找一个名为$XDG_CONFIG_HOME/kustomize/plugin/${apiVersion}/LOWERCASE(${kind})/${kind}

我创建了必要的目录，并从Github下载了SedTransformer脚本：
注意：下载的脚本需要是可执行的。

$ mkdir -p $HOME/.config/kustomize/plugin/someteam.example.com/v1/sedtransformer
$ cd $HOME/.config/kustomize/plugin/someteam.example.com/v1/sedtransformer
$ wget https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/plugin/someteam.example.com/v1/sedtransformer/SedTransformer
$ chmod a+x SedTransformer

最后，我们可以检查它是否按预期工作：
注意：要使用此插件，您需要提供--enable-alpha-plugins标志。

$ tree
.
├── cm.yaml
├── kustomization.yaml
└── sedTransformer.yaml
0 directories, 3 files
$ cat kustomization.yaml
resources:
- cm.yaml
transformers:
- sedTransformer.yaml

$ kustomize build --enable-alpha-plugins .
apiVersion: v1
data:
application_yml: |
container-backend: kubernetes
kubernetes:
url: https://kubernetes.default.svc.cluster.local:443
namespace: shiny
something_else:
something: something
kind: ConfigMap
metadata:
name: shiny-proxy

如果您想在许多地方替换NAMESPACE，那么使用sedtransformer插件可能特别有用。

我发现最简单的方法是在容器中使用入口点脚本，该脚本获取装载在容器中的向下API(？(服务凭据(特别是命名空间机密(，并将其作为环境变量公开。

export SHINY_K8S_NAMESPACE=`cat /run/secrets/kubernetes.io/serviceaccount/namespace`
cd /opt/shiny-proxy/working
exec java ${JVM_OPTIONS} -jar /opt/shiny-proxy/shiny-proxy.jar

在应用程序配置(闪亮代理(中，它支持在其配置文件中使用环境变量，因此我可以使用${shiny_K8S_namespace}引用pod的命名空间

不过，我刚刚看到了fieldRef(来自https://docs.openshift.com/enterprise/3.2/dev_guide/downward_api.html)，并且可以推广到命名空间之外的其他事物。

apiVersion: v1
kind: Pod
metadata:
name: dapi-env-test-pod
spec:
containers:
- name: env-test-container
image: gcr.io/google_containers/busybox
command: ["/bin/sh", "-c", "env"]
env:
- name: MY_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
restartPolicy: Never

相关内容

最新更新

热门标签：