本文要解决的核心问题是理解节点是如何访问172.30.*.*的docker-registry地址的？
Docker在容器引擎的层面提供了不同的网络模式，以满足容器网络通信的需求。
桥接（Bridge）模式是最常用的Docker容器网络类型。在桥接模式下，Docker会为每个容器分配IP地址及创建虚拟以太网网卡对（veth）。所有的容器都被连接到Docker在主机绑定的桥接设备上。被连接到同一个桥接设备的所有容器，都可以实现互联互通。如果容器要对外提供服务，则用户需要将容器内的服务端口与宿主机的某一端口绑定。这样所有访问宿主机目标端口的请求都将通过Docker代理转发到容器的服务端，最终到达应用。
除了桥接模式，Docker也支持主机（Host）模式，让容器直接使用宿主机的网络设备。宿主机模式使得容器占用宿主机的端口资源，而且要求容器具有更高的权限，因此只有特殊需求的容器，才会使用这种模式，如OpenShift集群中的Router组件。Router主机需要监听计算节点上的端口，以接受外部的请求，因此Router组件的Pod的容器网络为主机模式。
所有OpenShift节点主机上的Docker默认网桥docker0会被Linux二层网桥lbr0替代，所有使用Docker直接启动的容器都会连接到这个网桥上。在所有节点上都会创建一个OVS网桥br0。所有通过OpenShift启动的Pod容器都会通过veth设备对连接到这个OVS网桥。OVS网桥和Docker网桥通过vovsbr和vlinuxbr对设备连接，使OpenShift创建的容器和Docker创建的容器可以直接通信。
在OpenShift中，容器应用间的调用应通过Service进行解耦，避免容器之间直接调用。OpenShift会给每个Service组件分配一个虚拟的IP地址。图10-1中的Service A分配到的地址为172.30.2.2。在集群中另外一个计算节点上运行的Pod3可以访问Service A的IP地址来访问与之相关联的容器Pod2。Service的地址是一个虚拟地址，其转发功能是通过iptables规则及Kubeproxy实现的。创建新的Service时，Kubernetes会在集群内的所有节点上为该Service创建相应的iptables规则。这些iptables的规则会将发送至该Service地址及服务端口的流量转发至本节点的KubeProxy进程，再由Kube-Proxy转发至实际的容器。
