kubectl get 时 指定 -- v8，可以打印出整个API的调用过程，可以看到是 metrics server 访问失败导致的，
打开 metrics server log 发现该 pod 访问跨节点的 kubelet endpoint 不通，所以导致有三次重试，每次延迟 5s
解决方式
- 把 metrics server 部署为 hostnetwork 模式，可以避免 cni 挂掉对 metrics server 的影响，某种意义上来说，cni 出问题，导致该 服务出问题，api 接口变慢，会影响排错定位效率。
Metrics Server 部署为 HostNetwork 模式
可以部署为 HostNetwork 模式，Metrics Server 可以在 Kubernetes 中以 HostNetwork 模式运行。这种模式允许 Pod 直接使用宿主机的网络堆栈，而不是使用 Kubernetes 提供的网络命名空间。
HostNetwork 模式的优点
- 性能：通过直接访问宿主机的网络，可以减少网络地址转换（NAT）的开销，理论上可能提高网络性能。
- 端口使用：如果您需要在特定端口提供服务，可以直接使用宿主机的端口，而不必担心 Kubernetes 的网络路由。
HostNetwork 模式的缺点
尽管可以以 HostNetwork 模式运行，控制器（如 Metrics Server）通常不建议以此模式运行，原因包括：
-
安全性：
- 使用 HostNetwork 会增加安全风险，因为容器与宿主机共享网络堆栈，恶意容器可能会发生网络入侵，影响整个宿主机及其他运行在同一宿主机上的容器。
-
端口冲突：
- 如果多个 Pod 尝试在宿主机上使用相同的端口，会导致冲突。在 Kubernetes 集群中，Pod 的网络通常是完全隔离的，这使得在同一端口上运行多个服务变得更安全和可管理。
-
可移植性和灵活性：
- 在传统的 Kubernetes 网络模型中，服务的发现和通信是通过服务的 DNS 名称和 ClusterIP 实现的，使用 HostNetwork 会导致这种灵活性减少，从而使负载均衡器和其他服务发现机制变得复杂。
-
复杂性：
- 在使用 HostNetwork 时，您需要手动管理 IP 地址和端口，增加了配置和排错的复杂性。
总结
虽然可以将 Metrics Server 部署为 HostNetwork 模式，但通常推荐在标准的网络模式下运行，以保证安全性、可管理性和集群的整体健壮性。对于大多数用例，标准的 Pod 网络设置已足够高效，并且更符合 Kubernetes 的设计哲学。如果您在特定环境中有特殊需求，可以权衡其优缺点，以决定是否应使用 HostNetwork 模式。
