Kubernetes 网络与服务发现：从原理到实战避坑指南

摘要K8s 网络是很多人眼中的黑盒。本文深入剖析 Pod 通信、Service 发现、Ingress 网关的核心原理结合真实生产环境的踩坑经验带你彻底搞懂 K8s 网络模型。看完这篇你再也不会被服务找不到、跨节点通信失败这些问题困扰。一、开篇为什么 K8s 网络让人头大说实话我第一次接触 Kubernetes 网络的时候整个人都是懵的。Pod 之间怎么通信Service 到底是什么ClusterIP、NodePort、LoadBalancer 有什么区别Ingress 和 Gateway API 该选哪个CNI 插件这么多Calico、Flannel、Cilium 到底哪个香这些问题官方文档讲得云里雾里网上教程又大多是碎片化的。我踩了至少 50 个坑才慢慢把 K8s 网络的脉络理清楚。今天这篇文章我不打算照本宣科地讲概念。咱们直接上干货从实际场景出发把 K8s 网络这层窗户纸捅破。先说一个反常识的观点K8s 网络设计得其实非常优雅只是大多数人没找到正确的理解方式。二、K8s 网络模型核心就三句话Kubernetes 网络模型可以浓缩成三句话每个 Pod 都有独立的 IP 地址不需要 NAT 转换Pod 之间可以直接通信无论它们在哪个节点上Pod IP 是临时的重启后会变所以不能直接依赖 Pod IP听起来简单但实现起来可不简单。咱们一个一个拆解。2.1 Pod IP 从哪来当你创建一个 Pod 时K8s 会通过 CNIContainer Network Interface插件分配一个 IP。这个 IP 属于整个集群的网络平面不是 Docker 那种 NAT 网络。apiVersion: v1 kind:Pod metadata: name:test-pod namespace:default spec: containers: -name:nginx image:nginx:1.21 ports: -containerPort:80创建后查看 IPkubectl get pod test-pod -o wide # 输出示例 # NAME READY STATUS IP NODE # test-pod 1/1 Running 10.244.1.15 worker-node-01这个10.244.1.15就是 Pod 的 IP集群内任何 Pod 都能直接访问它。2.2 跨节点通信怎么实现这是 K8s 网络最核心的问题。假设 Pod A 在 node-01Pod B 在 node-02它们怎么通信答案取决于你用的 CNI 插件CNI 插件实现方式性能适用场景FlannelVXLAN 隧道中等小型集群简单易用CalicoBGP 路由高中大型集群生产首选CiliumeBPF极高高性能需求可观测性强Weave加密隧道较低需要网络加密的场景我生产环境用过 Calico 和 Cilium坦白讲Cilium 的 eBPF 方案真的很香性能比传统 iptables 方案提升 30%而且可观测性极强。三、Service解决 Pod IP 不稳定的问题Pod IP 是临时的重启后会变。那服务之间怎么稳定通信答案是Service。Service 本质上是一个虚拟 IP它背后可以关联多个 Pod。访问 Service 的流量会被自动转发到后端的 Pod。3.1 Service 的四种类型ClusterIP默认类型只能在集群内部访问适合内部服务apiVersion: v1 kind:Service metadata: name:backend-service namespace:default spec: type:ClusterIP selector: app:backend ports: -port:80 targetPort:8080访问方式http://backend-service.default.svc.cluster.local:80NodePort在每个节点上开放一个端口可以从外部访问apiVersion: v1 kind:Service metadata: name:web-service spec: type:NodePort selector: app:web ports: -port:80 targetPort:8080 nodePort:30080# 范围30000-32767访问方式http://任意节点 IP:30080LoadBalancer云厂商会创建一个外部负载均衡器要花钱的apiVersion: v1 kind:Service metadata: name:prod-service spec: type:LoadBalancer selector: app:prod ports: -port:80 targetPort:8080访问方式云厂商提供的公网 IPExternalName指向外部服务适合混合云场景apiVersion: v1 kind: Service metadata: name: external-db spec: type: ExternalName externalName: rds-mysql.xxxxx.rds.aliyuncs.com3.2 Service 发现的核心原理Service 背后是 kube-proxy 在干活。kube-proxy 有三种模式iptables 模式默认基于 iptables 规则转发流量IPVS 模式基于 Linux IPVS性能更好适合大集群Userspace 模式已废弃性能差别用我强烈建议在生产环境开启 IPVS 模式# 修改 kube-proxy 配置 kubectl edit cm kube-proxy -n kube-system # 添加或修改 mode: ipvs开启后可以用ipvsadm -Ln查看转发规则。四、Ingress七层流量入口Service 只能做四层负载均衡如果要基于域名、路径做路由得用 Ingress。4.1 Ingress 基础配置apiVersion: networking.k8s.io/v1 kind:Ingress metadata: name:web-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target:/ spec: ingressClassName:nginx rules: -host:api.example.com http: paths: -path:/v1 pathType:Prefix backend: service: name:api-service port: number:80 -path:/v2 pathType:Prefix backend: service: name:api-v2-service port: number:80 -host:www.example.com http: paths: -path:/ pathType:Prefix backend: service: name:web-service port: number:80这个配置实现了api.example.com/v1/*→ api-serviceapi.example.com/v2/*→ api-v2-servicewww.example.com/*→ web-service4.2 生产环境的 Ingress 实践TLS 证书配置apiVersion: networking.k8s.io/v1 kind:Ingress metadata: name:secure-ingress annotations: cert-manager.io/cluster-issuer:letsencrypt-prod spec: tls: -hosts: -api.example.com secretName:api-tls-secret rules: -host:api.example.com http: paths: -path:/ pathType:Prefix backend: service: name:api-service port: number:443配合 cert-manager 可以自动申请和续期 Lets Encrypt 证书亲测有效省去了手动管理证书的麻烦。限流和熔断apiVersion: networking.k8s.io/v1 kind:Ingress metadata: name:rate-limited-ingress annotations: nginx.ingress.kubernetes.io/limit-rps:100 nginx.ingress.kubernetes.io/limit-connections:50 nginx.ingress.kubernetes.io/proxy-connect-timeout:5 nginx.ingress.kubernetes.io/proxy-read-timeout:30 spec: # ... 其他配置这些注解可以防止突发流量打垮后端服务。4.3 Gateway APIIngress 的下一代Ingress 有一些历史局限性K8s 社区推出了 Gateway APIapiVersion: gateway.networking.k8s.io/v1 kind:Gateway metadata: name:prod-gateway spec: gatewayClassName:nginx listeners: -name:http protocol:HTTP port:80 -name:https protocol:HTTPS port:443 tls: mode:Terminate certificateRefs: -name:tls-cert --- apiVersion:gateway.networking.k8s.io/v1 kind:HTTPRoute metadata: name:api-route spec: parentRefs: -name:prod-gateway rules: -matches: -path: type:PathPrefix value:/api backendRefs: -name:api-service port:80Gateway API 更灵活支持更复杂的路由场景。但坦白讲目前生态还不如 Ingress 成熟建议等一等再上生产。五、网络策略K8s 的防火墙默认情况下K8s 集群内所有 Pod 都可以互相访问。这在生产环境是有安全风险的。NetworkPolicy 可以限制 Pod 之间的通信。5.1 基础网络策略apiVersion: networking.k8s.io/v1 kind:NetworkPolicy metadata: name:backend-policy namespace:default spec: podSelector: matchLabels: app:backend policyTypes: -Ingress -Egress ingress: -from: -podSelector: matchLabels: app:frontend ports: -protocol:TCP port:8080 egress: -to: -podSelector: matchLabels: app:database ports: -protocol:TCP port:5432这个策略的意思是backend Pod 只能被 frontend Pod 访问 8080 端口backend Pod 只能访问 database Pod 的 5432 端口其他所有流量都被拒绝5.2 生产环境的网络隔离我建议在多租户集群中强制执行网络隔离# 默认拒绝所有流量 apiVersion:networking.k8s.io/v1 kind:NetworkPolicy metadata: name:default-deny-all namespace:production spec: podSelector:{} policyTypes: -Ingress -Egress然后再根据实际需求逐个放开。这样做虽然麻烦一点但安全性提升很大。注意NetworkPolicy 需要 CNI 插件支持。Calico、Cilium、Weave 都支持但 Flannel 不支持。六、真实踩坑经验坑 1Service 找不到后端 Pod现象Service 创建成功但访问返回 503。原因Service 的 selector 和 Pod 的 label 不匹配。解决# 查看 Service 的 selector kubectl get service my-service -o jsonpath{.spec.selector} # 查看 Pod 的 label kubectl get pods -l appmyapp --show-labels # 确保两者匹配坑 2跨命名空间服务访问失败现象同一集群内不同命名空间的 Service 无法访问。原因忘记加命名空间后缀。解决# 错误写法 curl http://backend-service:80 # 正确写法跨命名空间 curl http://backend-service.other-namespace.svc.cluster.local:80坑 3Ingress 返回 404现象Ingress 配置正确但访问返回 404。原因可能是 Ingress Controller 没安装或者 ingressClassName 不匹配。解决# 检查 Ingress Controller 是否运行 kubectl get pods -n ingress-nginx # 检查 Ingress 资源 kubectl describe ingress my-ingress # 查看事件日志通常会有明确错误信息坑 4Pod 无法访问外网现象Pod 内无法 ping 通外网域名。原因节点的网络配置问题或者 CNI 插件配置错误。解决# 进入 Pod 测试 kubectl exec -it my-pod -- bash curl https://www.google.com # 检查节点的网络配置 kubectl debug node/node-name -it --imagebusybox # 检查 CNI 插件日志 kubectl logs -n kube-system -l k8s-appcalico-node七、技术选型建议场景 1小型开发集群10 节点CNIFlannel简单够用ServiceClusterIP NodePortIngressnginx-ingress网络策略可选场景 2中型生产集群10-50 节点CNICalicoBGP 模式性能好ServiceClusterIP LoadBalancer云厂商Ingressnginx-ingress cert-manager网络策略建议开启场景 3大型高并发集群50 节点CNICiliumeBPF极致性能ServiceIPVS 模式 Service Mesh可选IngressGateway API前瞻性网络策略必须开启八、性能优化技巧1. 开启 IPVS 模式前面提到了IPVS 比 iptables 性能好很多尤其是 Service 数量多的时候。2. 使用本地 Pod 优先apiVersion: v1 kind:Service metadata: name:optimized-service annotations: service.spec.externalTrafficPolicy:Local spec: type:LoadBalancer # ...externalTrafficPolicy: Local可以避免 SNAT保留客户端真实 IP同时减少跨节点流量。3. 调整 conntrack 参数高并发场景下conntrack 表可能爆满# 查看当前限制 sysctl net.netfilter.nf_conntrack_max # 调大限制 sysctl -w net.netfilter.nf_conntrack_max1000000 # 永久生效 echo net.netfilter.nf_conntrack_max1000000 /etc/sysctl.conf九、结尾K8s 网络这东西刚开始看确实复杂。但只要你理解了核心模型——Pod IP、Service 虚拟 IP、Ingress 七层路由——剩下的都是细节问题。我写这篇文章的目的不是让你背下所有配置而是帮你建立一个清晰的认知框架。有了这个框架遇到问题时你就知道从哪个方向排查了。最后送大家一句话网络问题80% 都是配置问题剩下 20%查日志基本都能解决。互动时间你在 K8s 网络方面踩过最大的坑是什么欢迎在评论区分享我挑几个典型问题在下篇文章里详细解答。如果觉得这篇文章对你有帮助点赞 在看支持一下你的鼓励是我持续创作的动力本文基于 Kubernetes 1.28 版本部分特性在旧版本中可能有差异。