本文主要关注当前容器网络类型的细分,包括:
•None
•Bridge
•Overlay
•Underlay
这个运行命令标志告诉Docker将这个容器的进程放在已经在另一个容器中创建的网络栈中。当与第一个容器共享相同的IP和MAC地址和端口号时,新容器的进程仍然局限于自己的文件系统,进程列表和资源限制。这两个容器上的进程将能够通过loopback接口相互连接。
这种联网方式对正在运行的容器执行诊断有用,并且容器缺少必要的诊断工具(例如curl或dig)。可以创建具有必要诊断工具的临时容器并将其附加到第一容器的网络。
容器映射网络可以用于模拟pod式联网,其中多个容器共享相同的网络命名空间。诸如共享本地主机通信和共享同一IP地址的优点是容器在同一个pod中运行的概念所固有的,这是rkt容器的行为。
这里有一个创建流程的例子:
1.在主机上设置网桥。
2.每个容器的命名空间都在该网桥中提供。
3.容器的ethX被映射到私有网桥接口。
4.使用带有NAT的iptables来映射每个私有容器和主机的公共接口。
NAT用于提供主机之外的通信。虽然桥接网络解决端口冲突问题并为在一台主机上运行的容器提供网络隔离,但是会带来一些NAT相关的性能成本。
主机网络是Mesos中使用的默认类型。 换句话说,如果框架没有指定网络类型,新的网络命名空间将不会与容器相关联,而是与主机网络相关联。 有时称为本地网络,主机网络在概念上很简单,使其更容易被理解,故障排除和使用。
VXLAN是Docker libnetwork的首选隧道技术,其多主机网络在1.9版本中作为原生功能。随着这种能力的引入,Docker选择利用HashiCorp的Serf作为gossip协议,选择它的邻居表交换和收敛时间的效率。
对于那些需要支持其他隧道技术的需求,Flannel可能是一个选择。它支持udp,vxlan,host-gw,aws-vpc或gce。每个云提供商隧道类型为您的帐户或者VPC在提供商的路由表中创建路由。对公共云的支持对于overlay驱动尤其重要,因为overlay能比较好的解决混合云场景,并提供扩展和冗余,而无需打开公共端口。
多主机网络在启动Docker守护程序以及键值存储时需要额外的参数。某些overlay依赖于分布式键值存储。如果你正在做容器编排,你已经有一个分布式的键值存储。
overlay层侧重于跨主机通信挑战。在同一主机上连接到两个不同overlay网络的容器不能通过本地网桥彼此通信 – 它们是彼此分段的。
MACVLAN每个容器使用唯一的MAC地址,这可能导致启用了防止MAC欺骗的这种安全策略(每个物理交换机接口仅允许一个MAC地址)的网络交换机出现问题。
容器流量被过滤掉,不能与底层主机通信,将主机和它上面运行的容器完全隔离。主机无法到达容器。容器与主机隔离。这对服务提供者或多租户场景有用,并且具有比网桥模型更好的隔离。
MACVLAN需要混杂模式; MACVLAN有四种工作模式,Docker 1.12只支持桥接模式。 MACvlan桥接模式和IPvlan L2模式在功能上等效。两种模式都允许广播和组播流量进入。这些底层协议的设计考虑了内部使用案例。您的公有云里程将有所不同,因为它们的虚拟机接口上大多数不支持混合模式。
注意事项:MACVLAN桥接模式为每个容器分配唯一的MAC地址或许是跟踪网络流量和端到端可见性的福音; 然而,对于具有512个唯一MAC地址的上限的典型网络接口卡(NIC),例如BR OADCOM,应该考虑这个上限。
最佳运行内核是4.2或更新版本,IPVLAN可以在L2或L3模式下运行。像MACVLAN一样,IPVLAN L2模式要求分配给子接口的IP地址与物理接口在同一子网中。然而,IPvlan L3模式要求容器网络和IP地址在与父物理接口不同的子网上。
Linux主机上的802.1q配置(使用IP Link创建时)是短暂的,因此大多数运营商使用网络启动脚本来保持配置。对于运行底层驱动程序和暴露API的程序化配置VLAN的容器引擎,自动化可以对其改进。例如,当在机架交换机顶部创建新VLAN时,这些VLAN可以通过暴露的容器引擎API.ico被推入Linux主机。
对于地址解析协议(ARP)和广播通信,无论是底层驱动程序的L2模式,就像连接到交换机的服务器那样,通过将大量使用802.1D分组学习操作。然而,在IPVLAN L3模式中,网络堆栈在容器内处理,不允许多播或广播流量。在这个意义之上,IPVLAN L3模式会按照您期望L3路由器的行为运行。
注意,上游L3路由器需要知道使用IPvlan创建的网络。网络广告和重新分配网络仍然需要完成。今天,Docker正在尝试边界网关协议(BGP)。虽然静态路 由可以在机架交换机的顶层创建,就像goBGP项目如雨后春笋般成立作为一个容器生态友好的方式来提供对等邻居和路由交换功能。
尽管在给定主机上支持多种联网模式,但是MACVLAN和IPVLAN不能同时在相同的物理接口上使用。总之,如果你习惯于在主机上运行trunks,可以用L2模式。如果你主要关注规模,L3则具有大规模的潜力。
CALICO就是一个这样的项目,使用BGP为每个网络分配路由 – 特别是对使用/ 32的工作负载,这允许它与现有的数据中心基础设施无缝集成,并且不需要Overlays。没有Overlays或封装带来的开销,结果是可以组建具有卓越的性能和规模的网络。容器的可路由IP地址将IP地址与端口暴露于外部世界。被培训并习惯于使用路由协议部署,诊断和操作网络的网络工程师可能发现直接路由更容易消化。然而,值得注意的是,CALICO不支持重叠的IP地址。
问题是这些能力是否受到支持。即使您的runtime,编排引擎或插件支持容器网络功能,您的基础架构也可能不支持该功能。虽然一些2级公有云提供商提供对IPv6的支持,但是在顶级公有云中却缺乏对IPv6的支持,这也增加了用户对其他网络类型(例如Overlays和FAN网络)的需求。
在IPAM方面,为了提高易用性,大多数容器runtime引擎默认使用host-local为容器分配地址,因为它们已连接到网络。host-local IPAM涉及定义要选择的固定IP地址块。跨容器网络项目普遍支持动态主机配置协议(DHCP)。容器网络模型(CNM)和容器网络接口(CNI)都具有用于与IPAM系统集成的IPAM内置和插件框架 – 这是在许多现有环境中采用的关键能力。
评论前必须登录!
注册