pod网络并非kubernetes系统内置的功能，而是有第三方项目以CNI插件方式来完成。进一步来说，除了pod网络管理，有相当一部分CNI网络插件还实现了网络策略，这些插件赋予管理员和用户通过自定义NetworkPolicy资源来管控pod通信能力
容器网络模型
Network、IPC和UTS名称空间隔离技术是容器能否使用独立网络栈的根本，而操作系统的网络设备虚拟化技术是打通各容器间通信并构建起多样化网络拓扑的至关重要因素，在linux系统上，这类的虚拟化设备类型有VETH、Bridge、VLAN、MACVLAN、IPVLAN、MACTV、和TAP/IPVTAP等。这些网络虚拟化相关技术是支撑容器与容器编排系统网络的基础。
Bridge是指linux内核支持的虚拟网桥设备，它模拟的是物理网桥设备，工作于数据链路层，根据习得的MAC地址表向设备端口转发数据帧。虚拟以太网接口设备对（veth pair）是连接虚拟网桥和容器的网络媒介：一端插入到容器的网络栈中，表现为通信接口（例如eth0），另一端则于宿主机上关联虚拟网桥并被降级为当前网桥的“从设备”，失去调用网络协议栈处理数据包的资格，从而表现为桥设备的一个接口
linux网桥提供的是宿主机内部网络，同一主机上的各容器可基于网桥和ARP协议完成本地通信。而在宿主机上，网桥表现为一个网络接口并可拥有IP地址。于是有宿主机发出的网络包可通过此桥接接口送往连接至同一个桥上的其他容器，如上图所示。这些容器通常需要某种地址分配组件自动配置一个相关网络。
但此私有网络中的容器却无法直接与宿主机之外的其他主机或容器进行通信，通常作为请求方，这些容器需要由宿主机上的iptables借助SNAT机制实现报文转发，而作为服务方时，它们的服务需要宿主机借助于iptables的DNAT规则进行服务暴露。因而，总结起来，配置容器使用Bridge网络的步骤大体有以下几个：
- 若补不存在，则需要向在宿主机上添加一个虚拟网桥
- 为每个容器配置一个独占的网络名称空间
#查询名称空间
[root@244-master-83 ]# ln -s /var/run/docker/netns /var/run/netns
[root@244-master-83 ]# ip netns list
RTNETLINK answers: Invalid argument
RTNETLINK answers: Invalid argument
RTNETLINK answers: Invalid argument
RTNETLINK answers: Invalid argument
RTNETLINK answers: Invalid argument
a47169a2f2ec
RTNETLINK answers: Invalid argument
1038387f7bab
RTNETLINK answers: Invalid argument
4ba484157927
RTNETLINK answers: Invalid argument
fe4d51dd66e8
RTNETLINK answers: Invalid argument
b4df31a131ed
RTNETLINK answers: Invalid argument
a6cac8d04bde
0e808309e387 (id: 25)
343c20af3d16 (id: 26)
a985624429bc (id: 20)
4b9daa8247ba (id: 14)
a8f7f8a9b01d (id: 21)
78f006606e92 (id: 24)
812cb5d80adc (id: 23)
b86ac085b07c (id: 22)
ea2da144ce1a (id: 18)
96fc1dc40ffb (id: 19)
a3ad72c1cd52 (id: 15)
287a6228c7fc (id: 16)
81b17a74a214 (id: 17)
1449d48b5f0c (id: 12)
626d6e1b80d1 (id: 13)
276c6689eb5d (id: 11)
06e9ea7d4ffc (id: 10)
d6281ce2f002 (id: 7)
772eeae4e488 (id: 8)
38cc315f71c8 (id: 9)
51d549a70d4f (id: 4)
default
c00297063c35 (id: 2)
872b030c4246 (id: 6)
0bccd8a61c4e (id: 5)
61ff627ccb6e (id: 3)
e707947f096e (id: 1)
a8563cd93b65 (id: 0)
#要获取Docker容器的PID，可以运行：
docker inspect --format '{{.State.Pid}}' <container_name_or_Id>
#要在容器的网络名称空间内获取命令：
nsenter -t <contanier_pid> -n <command>
#查看容器名称空间
ls /proc/<contanier_pid>/ns -la
- 生成一堆对虚拟以太网接口（如veth pair），将一端插入容器网络名称空间，一端关联至宿主机上的网桥
- 为容器分配IP地址，并按需生成必要的NAT
尽管Bridge模型下各容器使用独立且隔离的网络名称空间，且彼此间能够互联互通，但跨主机的容器通信时，请求报文会首先有源宿主机进行一次SNAT（源地址转换）处理，而后由目标宿主机进行一次DNAT（目标地主转换）处理方可送到目标容器，这种发展的NAT机制将会使得网络通信管理的复杂度随容器规模增呈几何倍数上升，而且基于iptables实现的NAT规则，先限制了解决方案的规模和性能。
kubernetes系统依然面临着类似的问题，只不过，跨节点的容器通信问题编程了更抽象的pod资源问题。我们知道，kubernetes将具有亲密关系的容器整合成pod作为基础单元并设计了专用网络模型来支撑kubernetes组件间及其他应用程序的通信。这种网络模型基于扁平网络结构，无需将主机端口映射到容器端口便能完成分布式环境中的容器间通信，并负责解决4类通信需求：同一pod 内容器间通信、pod间通信、service到pod间的通信以及集群外部与service之间的通信。
