kubernetes pod定义中重复的env变量名,确定最终值的优先级规则是什么?

liwlm1x9  于 2024-01-06  发布在  Kubernetes
关注(0)|答案(1)|浏览(159)

使用Kubernetes 1.19.3,我使用3种不同的方法初始化env变量值:

  • pod定义中带有显式键/值的env字段
  • envFrom使用configMapRefsecretRef

当键名重复时,如下面的示例所示,DUPLIK1DUPLIK2被多次定义为不同的值。
Kubernetes使用什么优先级规则将最终值分配给变量?

  1. # create some test Key/Value configs and Key/Value secrets
  2. kubectl create configmap myconfigmap --from-literal=DUPLIK1=myConfig1 --from-literal=CMKEY1=CMval1 --from-literal=DUPLIK2=FromConfigMap -n mydebugns
  3. kubectl create secret generic mysecret --from-literal=SECRETKEY1=SECval1 --from-literal=SECRETKEY2=SECval2 --from-literal=DUPLIK2=FromSecret -n mydebugns
  4. # create a test pod
  5. cat <<EOF | kubectl apply -n mydebugns -f -
  6. apiVersion: v1
  7. kind: Pod
  8. metadata:
  9. name: pod1
  10. spec:
  11. containers:
  12. - name: container1
  13. image: busybox
  14. command: [ "/bin/sh", "-c", "env" ]
  15. env:
  16. - name: DUPLIK1
  17. value: "Key/Value defined in field env"
  18. envFrom:
  19. - configMapRef:
  20. name: myconfigmap
  21. - secretRef:
  22. name: mysecret
  23. restartPolicy: Never
  24. EOF

字符串
显示元素变量值。结果是确定性的。删除资源+重新创建总是以相同的结果结束。

  1. kubectl logs pod/pod1 -n mydebugns
  2. CMKEY1=CMval1
  3. DUPLIK1=Key/Value defined in field env
  4. DUPLIK2=FromSecret
  5. SECRETKEY1=SECval1
  6. SECRETKEY2=SECval2


最佳资源

  1. kubectl delete pod/pod1 -n mydebugns
  2. kubectl delete cm/myconfigmap -n mydebugns
  3. kubectl delete secret/mysecret -n mydebugns

1hdlvixo

1hdlvixo1#

来自Kubernetes文档:
envVar:要在容器中设置的环境变量列表。无法更新。
envFrom:要在容器中填充环境变量的源列表。源中定义的键必须是C_IDENTIFIER。当容器启动时,所有无效键都将作为事件报告。当键存在于多个源中时,与最后一个源关联的值将优先。由具有重复键的Env定义的值将优先。无法更新。
上面的链接明确指出env将优先于envFrom,并且无法更新。
此外,当引用的键存在于多个资源中时,与最后一个源关联的值将覆盖所有以前的值。
基于以上所述,您看到的结果是预期的行为:

  1. DUPLIK1作为env字段添加,因此无法更新
  2. DUPLIK2被添加为envFrom,因此来自秘密的那个优先,因为它是在最后定义的

相关问题