Kubernetes--Docker网络实现

一、Docker网络模式

• host模式：使用--net=host指定
• container模式：使用--net=container:NAME_or_ID指定
• none模式：使用--net=none指定
• bridge模式：使用--net=bridge指定，为默认设置

    在kubernetes管理模式下通常只会使用brige模式，Docker Daemon第一次启动时会创建一张虚拟的网桥，默认名称为docker0，然后按照RPC1918的网络模型在私有 网络空间给这个网桥分配一个子网。针对由Docker创建的每一个容器，都会创建一个虚拟的以太网设备(Veth设备对)，其中一端关联到网桥上，另一端使用Linux的网络命名空间技术，映射到容器内的eth0设备，然后从网桥的地址段内给eth0接口分配一个IP地址。Docker默认桥接网络模型。

    其中ip1是网桥的IP地址，Docker Daemon会在几个备选地址段里面给给它选一个地址，通常是以172开头的一个地址。这个地址和主机的IP地址是不重叠的。ip2是Docker在启动容器时，在这个地址段选择的一个没有使用的IP地址分配容器相应的MAC地址也会根据这个IP地址在02:42:ac:11:00:00和02:42:ac:11:ff:ff范围内生成，这样可以确保ARP不冲突。

    启动后，Docker还将Veth对的名称映射到eth0网络接口。ip3是主机网卡地址。 

    一般情况下，ip1、ip2和ip3是不同的IP段，所以默认不做任何特殊配置情况下，外部有看不到ip1和ip2。这样做的结果是同一台机器内的容器之间可以相互通信，不同主机上的容器不能相互通信，实际上他们有可能在相同的网络地址范围内(不同主机上的docker0地址段可能是一样的)。

二、Docker跨主机通信缺点

    为了使不同主机上的container可以跨节点通信，就必须在主机的地址上分配端口，然后通过这个端口路由器代理到容器上。这种做法意味着一定要在容器之间小心谨慎的协调好端口的分配，或者使用动态端口的分配技术。在不同应用之间协调好端口分配是一个非常困难事情，特别是集群水平扩展时。而动态的端口分配会带来高度复杂性，例如：每个应用程序只能将端口看作一个符号(因为动态分配，所以无法提前设置)。而且API Server在分配完成后，将动态端口插入配置的合适位置，服务也必须能相互找到对方等。这些都是Docker跨主机访问时面临的问题。

三、Docker启动网络情况

    Docker网络在bridge模式下Docker Daemon启动时创建docker0网桥，并在网桥使用的网络地址和为容器分配IP。

    Docker Daemon启动后网络协议栈配置情况：

 

 Docker 创建docker0网桥，并添加了iptables规则。docker0网桥和iptables规则都处于root命名空间。

四、Docker网络局限

 Docker一开始没有考虑多主机互联的网络解决方案。针对目前Docker的网络实现，Docker使用libnetwork组件只是将Docker平台中的网络子系统模块化为一个独立库的简单尝试。