gpt4 book ai didi

kubectl - 为什么端口转发到 headless (headless)服务总是路由到同一个 pod?

转载 作者:行者123 更新时间:2023-12-05 04:24:45 27 4
gpt4 key购买 nike

我的问题是关于应用于 Kubernetes 中 headless (headless)服务的端口转发功能。

例如这个命令:

kubectl port-forward service/mongodb-headless 27017:27017 -n mongodb

端口转发到 headless (headless)服务。虽然我读到过无外设服务既不会负载平衡也不会代理请求到它的支持 pod,但我观察到它总是连接到同一个支持 pod(选择似乎是随机的)。

经过一些调查后,我发现 DNS 查找无外设服务的 FQDN 以基于循环的行为返回所有支持 pod 的 IP。无论重新端口转发到我的 headless (headless)服务总是连接到同一个 pod。此外,重新部署 headless (headless)服务不会更改选定的 pod。

有人知道端口转发到 headless (headless)服务的行为吗?

  • 为什么端口转发到 headless (headless)服务会将 pod 的端口绑定(bind)到我的本地主机端口?
  • 为此绑定(bind)选择了哪个支持 pod(假设 3 个中的 1 个)?
  • 为什么 headless (headless)服务总是坚持同一个 pod?

谢谢

最佳答案

是的,自 2022 年 11 月起,kubectl port-forward 始终将您路由到同一个 pod。
这仅仅是由于它是如何在引擎盖下实现的。
它似乎只占用服务的第一个可用 endpoint

Why does port-forwarding to a headless service bind the pod's port to my localhost port at all?

为什么不呢? kubectl port-forward 的最初目的是针对一个 pod。然后它被改进为还允许用户定位服务 - 但首先,它将该服务“翻译”成合适的 pod。这恰好此时总是同一个 pod。

Which backing pod (let's say 1 out of 3) is chosen for this binding?

我怀疑这是 kubectl get endpoints 为该服务返回的第一个。

Why does the headless service always stick to the same pod?

非 headless (headless)的普通服务的行为完全相同。
请注意,这与 headless (headless)服务无关。

资料来源:
https://github.com/kubernetes/kubectl/issues/881 https://github.com/kubernetes/kubernetes/issues/15180#issuecomment-410798267

关于kubectl - 为什么端口转发到 headless (headless)服务总是路由到同一个 pod?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/73442677/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com