导语
容器跑起来了，怎么联网？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输出：
NAME | IP | NODE |
nginx-1 | 10.244.1.5 | node1 |
nginx-2 | 10.244.2.7 | node2 |
两个 Pod 在不同节点，却可以直接 curl 10.244.x.x 通信，这就是“跨主机扁平网络”。
三、CNI 插件：Pod 网络的幕后英雄
Pod 的 IP 是怎么来的？答案是 —— CNI 插件（Container Network Interface）
K8s 并不自己管理网络，而是通过 CNI 调用网络插件完成如下操作：
- 分配 IP 给 Pod
- 配置网络命名空间
- 配置路由和防火墙规则
常见 CNI 插件：
插件 | 特点 |
Flannel | 简单易用，采用 overlay 网络 |
Calico | 支持 BGP，性能好，安全控制强 |
Cilium | 基于 eBPF，支持 L7 网络策略 |
推荐中小集群使用 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 网络类型对比
类型 | IP 来源 | 是否 NAT | 通信特征 |
Pod IP | CNI 插件分配 | 否 | 扁平互通 |
Cluster IP (Service) | kube-proxy 管理 | 是（SNAT） | 集群内访问服务 |
NodePort | 映射宿主机端口 | 是 | 外部访问集群服务 |
LoadBalancer | 云厂商分配 | 否 | 对外暴露公网入口 |
Ingress | Nginx/TCP代理 | 否 | 多路径统一入口控制 |
六、实际排查思路案例
场景：Service IP 能 ping 通，但 curl 不通
排查步骤：
- kubectl get endpoints → 查看 Service 是否正确绑定 Pod
- iptables-save | grep <svc-ip> → 确认 kube-proxy 是否配置规则
- 检查 Pod 容器端口是否监听
- 检查防火墙、CNI 是否正常工作
总结
Kubernetes 网络听起来复杂，拆解后其实很清晰：
- Pod IP：由 CNI 分配，支持跨节点直接通信
- Service IP：实现 IP 屏蔽与负载均衡
- CNI 插件：实现网络连通的幕后技术
掌握容器网络原理，是你理解 K8s 网络策略、ServiceMesh、流量治理等技术的第一步。