我们已经就这个主题进行了非正式的聊天，以下是用于跟踪目的的正式bug。

我明白你的观点，在我第一次阅读这个问题时，我认为这是一个非常好的想法，几乎是不费吹灰之力的。但是随着我对这个问题的思考，我意识到这并不像看起来那么无害，如果我们提议进行这样的更改，可能会遇到一些问题：

1. 我们必须意识到这里有两个角色在起作用：负责集群配置的系统管理员/集群操作员和部署工作负载的最终用户。在这里，系统管理员/集群操作员负责配置kubelet选项，并必须向最终用户传达配置的路径，以确保将正确的路径挂载到pod规范中。这种额外的沟通可能是一个负担，可能导致意外的行为。

2. 有了这个选项，系统管理员/集群操作员可以为集群中的不同节点配置不同的路径，而用户必须确保客户端应用程序中挂载的Unix套接字与节点上配置的路径一致。但如果Pod被调度到一个路径与配置路径不一致的节点上呢？唯一能让它正常工作的方法是确保集群中的所有节点都使用相同的、定义明确的路径进行配置。

3. 此外，我能理解想要有能力在选项为空/nil时禁用此功能的愿望，但我担心这可能导致一些惊讶/不满意的最终用户，仅仅因为系统管理员忘记更新kubelet配置的新选项，然后由于缺乏podresource API支持而导致工作负载出现问题。因此，如果选项既未指定也为空，最好将其默认设置为当前硬编码值，以确保向后兼容性。我认为禁用稳定功能的能力应该经过更仔细的评估和与更广泛的群体讨论，因为它违背了作为功能毕业过程的一部分的默认假设和期望。

显而易见的是，因为我们将引入一个新的kubelet选项，所以这将需要一个KEP(Kubernetes增强点)以及来自社区的非平凡的努力。问题是：我们是否从这次变化中获得足够的收益来证明额外的努力以及我上面提到的风险是值得的？我倾向于说“不”，但我愿意听取支持这个更改的论点。

感谢您的反馈！您提出了很好的观点。让我们看看我们是否可以解决这些问题。

1. We have to be conscious that we have two personas at play here: sys-admin/cluster operator that takes of cluster configuration and the end user who deploys the workload. The sys-admin/cluster operator here is responsible for configuring the kubelet option and would have to communicate to the end user the configured path in order to ensure that the right path is volume mounted into the pod spec. This additional communication can be an overhead and can lead to unexpected behavior.

这是非常正确的。然而，从目前的情况来看，实际的podresources套接字路径是不可发现的。podspec所有者必须通过侧通道(阅读代码？)发现它，并必须在他们的podspec中硬编码。最终，这是由于podresources API的不常见性质所带来的副产品，无论是节点本地还是以这种方式公开，在生态系统中都是非常独特的。也许更好的方法是，一般来说，在节点状态中公开podresources套接字路径(和可用性)?这个值不会改变，除非kubelet重启，因此对节点对象和apiserver的开销将是最小化的。

2. With this option, the sys-admin/cluster operator CAN configure different paths for different nodes in the cluster and the user HAS to ensure that the unix socket mounted in the client application is consistent with that configured on the node. But what if the pod is scheduled on a node where the path does not align with the configured path?? The only way this would work is if we ensure that all the nodes in the cluster is configured with the same well defined path.

再次非常正确，并且通过在节点状态中公开API可用性和路径部分解决了这个问题。关于不一致的配置，这是完全可能的，而且我担心这是一个更普遍(且复杂)的问题需要解决。

3. Also, I can understand the desire to have the ability to disable this feature if the option is empty/nil but I am concerned that this could result in some surprised/unhappy end-users just because the sys-admin forgot to update the kubelet configuration with the new option and then the workload ran into issues due to lack of the podresource API support. Because of this, it might be better to default to the current hardcoded value in case the option is either not specified or empty to ensure backward compatibility. I think the ability to disable a stable feature deserves more careful evaluation  and a discussion with the wider group because it goes against the default assumptions and expectation we have as part of the graduation process of a feature.

这是一个非常公平的说法。默认情况下确实应该是向后兼容的。
允许禁用API(尽管是显式的和选择性的)仍然是我们应该允许的事情：我认为从一开始就应该这样。
只是陈述显而易见的事情，因为我们将引入一个新的kubelet选项，这将需要一个KEP和社区的非平凡努力。
我们还需要API审查
问题是：我们是否从这个变化中获得足够的收益来证明额外的努力以及我上面提到的风险是有道理的？我倾向于否决，但我愿意听取支持这个变化的论点。
如果我们作为社区决定不追求这项工作，我会没问题。
我认为我们需要进行这样的对话并记录下来，这是我提出这个问题的主要原因。

这是非常正确的。然而，在当前的情况下，实际的pod资源套接字路径是不可发现的。podspec所有者必须通过侧通道(阅读代码？)发现它，并必须在他们的podspec中硬编码。
我倾向于同意路径不可发现的说法，但简单的文档更新可以解决这个问题。我们已经有了一个关于如何使用podresource API监控资源的部分，这似乎是记录套接字路径的正确地方。
最终，这是podresources API不寻常性质的副产品，无论是节点本地还是以这种方式公开，都是生态系统中的非典型情况。也许更好的方法是，一般来说，在节点状态中公开podresources套接字路径(和可用性)?这个值不能改变，除非kubelet重启，因此对节点对象和apiserver的开销将是最小化的。
通过节点状态公开此信息只能部分解决问题。这在某种程度上已经成为了调度问题，因为我们需要匹配pod中挂载的路径卷与能够支持配置的节点，或者用户必须手动观察节点状态并确保pod被调度到“正确的”节点，可能带有nodeSelector。
再次非常正确，并且通过在节点状态中公开API可用性和路径将部分解决这个问题。关于不一致的配置，这是始终可能的，而且我担心这是一个更一般(且复杂)的问题需要解决。
同意节点状态中的路径将部分解决问题。关键是这并不像表面看起来那么简单，突然从简单的kubelet更改使套接字路径可配置，我们现在需要进行podstatus更改，也许还需要更改调度器以确保我们不会引起回归。
这是一个非常公平的陈述。默认应该是向后兼容的。具有禁用API(尽管是显式的和选择性的)的可能性仍然是我们应该允许的事情：我认为从一开始就应该这样。
当然，我理解并同意禁用此功能可能是有用的。然而，我不完全相信将此与可配置路径耦合是正确的方法。
问题是：我们是否从这次变化中获得足够的收益来证明额外的努力以及我上面提到的风险是值得的？我倾向于说不，但我愿意听取支持这一变化的论点。
如果我们作为社区决定不追求这项努力，我会没问题。我认为我们需要进行这样的对话并记录下来，这是我提出这个问题的主要原因。
同意！

/kind feature
/remove-kind bug
/triage accepted

xref: #120626

/assign

最终，这是podresources API不寻常性质的副产品，因为它是节点本地的，以这种方式公开几乎是生态系统中的独一无二的。也许更好的方法是，一般来说，在节点状态中公开podresources套接字路径(和可用性)?这个值除非kubelet重启，否则不会改变，因此对节点对象和apiserver的开销将是最小化的。
通过节点状态公开这些信息只能部分解决问题。这在某种程度上已经成为一个调度问题，因为我们需要匹配在pod中挂载的路径卷到能够支持配置的节点，或者用户必须手动观察节点状态并确保pod被调度到“正确的”节点，可能带有nodeSelector。
我在考虑如何解决这个问题。控制器可以在提交之前修补清单(例如修复守护进程集的路径),但这是与调度问题相关的次要问题。
思考一下，这是资源管理器配置的问题。我们有一个节点属性(导致扩展行为的某种配置),假设它不能被发现或请求。