时间戳

首页 > 解决方案 > 为什么必须为某些 Kubernetes 入口控制器提供 POD_NAME 和 POD_NAMESPACE？

nginx - 为什么必须为某些 Kubernetes 入口控制器提供 POD_NAME 和 POD_NAMESPACE？

问题描述

对于那里的至少一些入口控制器，必须提供 2 个变量：POD_NAME和POD_NAMESPACE. nginx 入口控制器确保将这 2 个变量注入容器中，如此处所示（ Azure 部署模板的链接），HAProxy 正在使用它（如此处所示），可能其他人也在这样做。

我明白为什么需要这两个值。对于 nginx 入口控制器，POD_NAMESPACE变量的值用于潜在地通过--watch-namespace 参数将控制器将要注意的入口资源对象限制为它部署的命名空间（Helm 图表显示了这一点）。至于POD_NAME，没有这个会导致入口内部代码（这里的函数）出现一些错误，这反过来可能会阻止入口在没有设置变量的情况下运行。

入口控制器是否不能根据它必须运行的权限自动获取此信息（毕竟它可以在 Kubernetes 级别监视更改，所以人们会假设它“强大”到足以看到自己的 pod 名称和命名空间它部署在哪里）？换句话说，入口控制器不能做某种“whoami”并获取自己的数据吗？或者这可能是 Kubernetes 中使用的一种常见模式？

标签： nginxkubernetesingress-controller

解决方案

它是通过设计完成的，一个在接近主题时开发此功能的社区。

当环境变量启动时，变量是已知的。Kubernetes 提供了这些变量，pod 可以在运行时使用它们。

当然，如果你有更好的解决方法，可以在github的官方线程中提出建议。

但是，请记住，这种潜在的解决方案：

入口控制器不能根据它必须运行的权限自动获取此信息（毕竟它可以在 Kubernetes 级别监视更改，因此人们会假设它“强大”到足以看到自己的 pod 名称和命名空间它部署在哪里）？换句话说，入口控制器不能做某种“whoami”并获取自己的数据吗？或者这可能是 Kubernetes 中使用的一种常见模式？

将需要一个额外的步骤。首先，pod 必须有额外的权限，其次，当它启动时，它还没有这些变量。

推荐阅读