裸金属K8s中DNS/Ingress/MetalLB/Kube-proxy协作流程咨询

以下流程基于标准裸金属K8s集群部署，默认已部署MetalLB、Nginx Ingress Controller、kube-proxy正常运行，无云厂商负载均衡服务介入。

各阶段流转逻辑与组件职责 #

1. DNS解析阶段 #

客户端发起访问的第一步是解析域名mytestsite.com，这个阶段的逻辑：

• 你提前创建Ingress资源，配置host为mytestsite.com的路由规则，指向对应后端业务Service。Ingress Controller启动时会自动创建一个LoadBalancer类型的Service，用来承接所有外部入站流量。
• MetalLB持续监听集群内LoadBalancer类型的Service资源，发现这个Ingress对应的LB Service没有分配外部IP，就会从自身预配置的地址池中，选一个和客户端/网关二层可达（或BGP路由可达）的空闲IP（例如192.168.3.100），绑定到这个LB Service上。
• DNS侧需要将mytestsite.com的A记录指向上述MetalLB分配的IP：你可以手动在DNS服务商/内部DNS服务器上添加这条记录，也可以部署ExternalDNS组件，自动监听Service/Ingress的IP变化同步DNS记录。

  DNS和MetalLB没有直接的接口交互，两者完全通过K8s的资源状态做关联，不存在DNS直接请求MetalLB拿IP的逻辑

• 客户端向DNS服务器发起查询后，最终拿到mytestsite.com对应的IP就是MetalLB分配给Ingress LB Service的地址，解析完成。

2. MetalLB流量接入阶段 #

客户端拿到IP后，直接向192.168.3.100:443发起HTTPS连接：

• MetalLB的核心作用是让这个原本只在集群内有效的LB IP，能被集群外的设备访问到：如果是二层部署模式，集群节点上运行的MetalLB Speaker会通过ARP广播，告诉同网段的客户端/上游网关“192.168.3.100的MAC地址是我所在节点的MAC”，把流量引导到集群节点上；如果是BGP模式，MetalLB会和上游路由器交换路由表，告知路由器访问192.168.3.100的流量下一跳为集群节点。
• MetalLB本身不做七层路由判断，也不识别域名、路径这类七层信息，它只负责把发往这个LB IP的流量，丢给集群内的Service转发链路处理。

3. kube-proxy转发阶段 #

kube-proxy不直接处理流量，它的核心职责是在所有集群节点上实时配置iptables/ipvs转发规则，所有访问Service的流量（不管来自集群外还是集群内）都靠这些规则完成转发，在整个链路里它会在两个节点生效：

• 第一个生效点：MetalLB把流量引到集群节点后，节点上的kube-proxy规则匹配到目标是Ingress对应的LB Service，就会按照预设的负载均衡策略（轮询、随机等），把流量转发到后端健康的Ingress Controller Pod的实际IP+端口上，自动剔除异常的Ingress Pod。
• 第二个生效点：后续Ingress Controller匹配完路由，把请求转发给后端业务Service的时候，节点上的kube-proxy规则会再次匹配，把流量转发到对应业务Service下健康的业务Pod上。

  简单说：只要你访问的是K8s的Service（不管是ClusterIP、NodePort还是LoadBalancer类型），底层的转发规则全是kube-proxy维护的，没有它Service网络根本通不了。

4. Ingress Controller七层路由阶段 #

流量到达Ingress Controller Pod后：

• 首先完成HTTPS的TLS证书校验与卸载，读取请求的Host头，确认是mytestsite.com，再匹配你提前创建的Ingress规则中对应域名的路由表。
• 根据请求路径、请求头、Cookie等七层规则，匹配到对应的后端业务Service，将请求转发给这个Service的ClusterIP。
• 后续经过kube-proxy的规则转发，请求最终到达运行业务的Pod上，业务处理完成后，响应包按原路径返回给客户端，整个请求流程结束。

常见认知误区澄清 #

• 误区1：必须部署ExternalDNS才能让DNS和MetalLB配合
  错。ExternalDNS只是个自动化同步工具，你手动把域名A记录指向MetalLB分配的LB IP，效果完全一致，DNS和MetalLB本身没有强绑定依赖。
• 误区2：MetalLB会直接把流量转发给后端业务Pod
  错。MetalLB只负责把流量引到对应LoadBalancer Service的转发链路，这个Service的后端是Ingress Controller Pod还是业务Pod，完全取决于你创建的LB Service对应的端点列表，默认Ingress场景下它的转发目标只有Ingress Controller Pod。
• 误区3：Ingress Controller可以代替kube-proxy做转发
  错。Ingress Controller只做七层路由匹配，它把请求转给后端Service之后，还是要靠kube-proxy的规则才能找到实际的业务Pod，两者职责完全不重叠。

内容的提问来源于stack exchange，提问作者Chel MS