一、ingress-nginx是否本身会在集群每个可以调度的节点都跑一个pod？

ingress-nginx 默认部署为 DaemonSet，其设计意图就是在集群的每个可调度节点上都运行一个 Pod。

为什么它是这样设计的？

这源于 Ingress Controller 作为 流量入口 的职责：

1. 流量接入点：每个节点都运行一个 Nginx Pod，意味着无论外部请求打到集群的哪一个节点，都能被本地的 Ingress Pod 立即处理，无需跨节点转发，延迟更低。
2. 高可用性：如果某个节点宕机，该节点上的 Ingress Pod 会消失，但其他所有节点的 Ingress Pod 依然正常工作，保障了服务不中断。
3. 负载均衡：配合 Service（Type: ClusterIP）或直接通过 hostNetwork 暴露端口，外部负载均衡器可以将流量均匀分散到所有节点，实现入口层面的负载均衡。

二、ingress-nginx是否需要在每个可调度的节点上都部署？

不一定需要在每个可调度的节点上都部署。

关于这一点，行业里有成熟的共识：将 Ingress Controller 部署为 DaemonSet 以确保每个节点上都有一个 Pod，这只是一种可选方案，而不是强制要求。这背后主要涉及对流量入口方案的不同选择-4-7。

为什么它不一定需要“全覆盖”？

因为 Ingress Controller 的核心职责是作为集群流量的统一入口，只要流量能被正确地转发到它所在的 Pod 上，服务就能正常工作。即使它只运行在少数几个节点上，通过以下方式，流量也可以到达它：

1. 通过 Service 进行转发：这是最常见的方式。Ingress Controller 通常会对应一个 Service（类型为 NodePort 或 LoadBalancer）。集群外部的流量会先到达这个 Service，再由 Service 将请求转发到后端的 Ingress Controller Pod 上-2-7-9。
2. 流量转发与 Pod 位置无关：在这种模式下，即使 Ingress Pod 只运行在少数几个节点上，外部流量访问任意一个节点的 NodePort，Service 的负载均衡机制都能将请求正确转发到正在运行的 Pod 上-2-7。

为什么你的配置会选择“全覆盖”？

[root@iv-yet8omgwsgcva4fi8fvv kbcloud]# kubectl get pod -n kb-cloud
NAME                             READY   STATUS    RESTARTS   AGE
ingress-nginx-controller-4p9kd   1/1     Running   0          22s
ingress-nginx-controller-hj7wr   1/1     Running   0          22s
ingress-nginx-controller-jg8qt   1/1     Running   0          22s
ingress-nginx-controller-l7wfg   1/1     Running   0          22s
ingress-nginx-controller-rmmjp   1/1     Running   0          22s
ingress-nginx-controller-sg87x   1/1     Running   0          22s

在云服务商的生产环境实践中，当需要追求极致性能时，工程师会采用“DaemonSet + hostNetwork”的模式，这也是你当前配置采用的方案。

这种方案的核心考量是：跳过 NodePort 和 Service 的转发层，让流量直接穿透到 Pod，从而获得更低的延迟和更高的性能-4-7-10。

结合你的“六节点集群，六个 Pod 分别运行在每个节点上”的情况，你当前的配置正是这种方案的典型体现，它被用来实现一个高性能的“边缘节点”流量入口层-10。

部署方式	核心配置	流量路径	是否需要每个节点一个 Pod
标准模式 (Deployment)	kind: Deployment + Service (NodePort/LoadBalancer)	外部流量 → Service → Pod	不需要，Pod 可只运行在少数节点-2-7。
高性能模式 (DaemonSet)	kind: DaemonSet + hostNetwork: true + nodeSelector	外部流量 → 直接连接节点 IP → Pod	按需选择，通常用于指定一批高性能节点-4-7-10。