导语

容器跑起来了，怎么联网？K8s 能调度 Pod，那 Pod 能不能互相通信？Service 又是干嘛的？为什么明明 IP 能通，服务就是访问不了？

阅读本文你将收获：

• 容器网络与传统网络的核心区别
• Kubernetes 容器网络模型（CNI）及其背后逻辑
• Pod 网络、Service 网络如何配合工作
• 常见网络故障排查思路

一、从虚拟机到容器，网络复杂了吗？

在虚拟机时代，我们熟悉的网络拓扑长这样：

VM 通过 虚拟网卡 → 接入宿主机网桥 → 上外网

但到了容器世界，网络设计变复杂了 —— 容器生命周期短，IP 随时可能变，K8s 集群又要求容器之间可直接通信，还得让外部访问容器服务。

所以问题来了：

• 每个 Pod 有独立 IP 吗？
• Pod 重启后 IP 会变吗？
• 多个 Pod 如何统一暴露一个服务？
• CNI 是干什么的？

带着这些问题，往下看。

二、Pod 网络模型：每个 Pod 有独立 IP

Kubernetes 的核心网络理念是：

所有 Pod 之间都是“扁平网络”，IP 可达，不需要 NAT。

具体特点：

• 每个 Pod 在启动时会分配一个 IP（通过 CNI 插件）
• Pod 之间通信不需要端口映射
• Pod 所在的容器共享网络命名空间（同一个网卡、IP）

举例说明

kubectl get pods -o wide

输出：

两个 Pod 在不同节点，却可以直接 curl 10.244.x.x 通信，这就是“跨主机扁平网络”。

三、CNI 插件：Pod 网络的幕后英雄

Pod 的 IP 是怎么来的？答案是 —— CNI 插件（Container Network Interface）

K8s 并不自己管理网络，而是通过 CNI 调用网络插件完成如下操作：

• 分配 IP 给 Pod
• 配置网络命名空间
• 配置路由和防火墙规则

常见 CNI 插件：

推荐中小集群使用 Flannel，大规模生产集群用 Calico 或 Cilium。

四、Service：解决 Pod IP 易变的问题

Pod 重启 IP 就会变，客户端怎么访问？

Kubernetes 提供了 Service 机制，做了“虚拟 IP + 负载均衡”。

原理：

• Service 会分配一个 ClusterIP
• 会自动将流量转发到后端 Pod（通过 kube-proxy 实现）
• 默认是基于 IPtables 或 IPVS 的负载均衡

举个例子：

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80

这个 Service 会自动负载到所有 label 为 app=nginx 的 Pod 上，无需关心 Pod IP。

五、几种 Kubernetes 网络类型对比

六、实际排查思路案例

场景：Service IP 能 ping 通，但 curl 不通

排查步骤：

1. kubectl get endpoints → 查看 Service 是否正确绑定 Pod
2. iptables-save | grep <svc-ip> → 确认 kube-proxy 是否配置规则
3. 检查 Pod 容器端口是否监听
4. 检查防火墙、CNI 是否正常工作

总结

Kubernetes 网络听起来复杂，拆解后其实很清晰：

• Pod IP：由 CNI 分配，支持跨节点直接通信
• Service IP：实现 IP 屏蔽与负载均衡
• CNI 插件：实现网络连通的幕后技术

掌握容器网络原理，是你理解 K8s 网络策略、ServiceMesh、流量治理等技术的第一步。