docker流量（容器网络：盘点，解释与分析）

本文目录

• 容器网络：盘点，解释与分析
• 怎么在docker容器里模拟产生很大的流量
• Docker macvlan

容器网络：盘点，解释与分析

虽然许多人倾向用Overlays作为解决跨主机容器网络的实现方法，但是如果您想根据您的环境做出正确的网络选型，容器网络的功能和类型差异还是很大的，值得更深入的理解。 有些类型的网络是容器引擎不可知的，有些类型的网络被锁定到特定的平台供应商或引擎。 一些类型主要关注组网的简单性，另一些类型可能关注功能的广度或IPv6支持以及组播能力。 哪一个适合您取决于您的应用程序需求，性能要求，工作负载布局（私有或公共云）等。让我们回顾一下目前比较常见的容器网络。

本文主要关注当前容器网络类型的细分，包括：

•None

•Overlay

•Underlay

随着容器技术的进步与发展。 下面两种模式的网络方案经消失。

Links and Ambassadors

在使用Swarm实现多主机网络支持和编排之前，Docker从单主机网络开始，通过links促成网络连接，作为允许容器通过环境变量或/ etc / hosts文件条目发现彼此的机制，并传输容器之间的信息。 links的能力通常与 ambassador pattern 相结合，以便于跨主机连接容器，并降低被写死links的脆弱性。 这种方法的最大的问题是太静态了。 一旦创建了容器并定义了环境变量，如果相关的容器或服务移动到新的IP地址，则不可能更新这些变量的值。

Container-Mapped Networking

在这种网络模式下，一个容器重用（映射到）另一个容器的网络命名空间。这种联网模式只能用以下运行Docker容器的方式使用：-net：container：some_container_name_or_id。

这个运行命令标志告诉Docker将这个容器的进程放在已经在另一个容器中创建的网络栈中。当与第一个容器共享相同的IP和MAC地址和端口号时，新容器的进程仍然局限于自己的文件系统，进程列表和资源限制。这两个容器上的进程将能够通过loopback接口相互连接。

这种联网方式对正在运行的容器执行诊断有用，并且容器缺少必要的诊断工具（例如curl或dig）。可以创建具有必要诊断工具的临时容器并将其附加到第一容器的网络。

容器映射网络可以用于模拟pod式联网，其中多个容器共享相同的网络命名空间。诸如共享本地主机通信和共享同一IP地址的优点是容器在同一个pod中运行的概念所固有的，这是rkt容器的行为。

None

None 是比较直接的容器接收一个网络堆栈，但是缺少外部网络接口。 然而，它会接收一个loopback接口。 当使用无网络或空网络时，rkt和Docker容器项目均提供类似的行为。 这种容器网络的模式具有许多用途，包括测试容器，为稍后的网络连接分配容器，并且分配给不需要外部通信的容器。

Bridge

Linux网桥提供了主机内部网络，其中同一主机上的容器可以通信，但是分配给每个容器的IP地址不能从主机外部访问。 Bridge网络利用iptables进行NAT和端口映射，从而提供单主机网络。桥接网络是默认的Docker网络类型（即，docker0），其中虚拟网络接口对的一端连接在网桥和容器之间。

这里有一个创建流程的例子：

1.在主机上设置网桥。

2.每个容器的命名空间都在该网桥中提供。

3.容器的ethX被映射到私有网桥接口。

4.使用带有NAT的iptables来映射每个私有容器和主机的公共接口。

NAT用于提供主机之外的通信。虽然桥接网络解决端口冲突问题并为在一台主机上运行的容器提供网络隔离，但是会带来一些NAT相关的性能成本。

Host

在这种方法中，新创建的容器与主机共享其网络命名空间，提供更高的性能（接近裸机），并且消除对NAT的需要; 然而，它确实遭受端口冲突问题。 虽然容器可以访问所有主机的网络接口，但除非在特权模式下部署，容器可能不会重新配置主机的网络堆栈。

主机网络是Mesos中使用的默认类型。 换句话说，如果框架没有指定网络类型，新的网络命名空间将不会与容器相关联，而是与主机网络相关联。 有时称为本地网络，主机网络在概念上很简单，使其更容易被理解，故障排除和使用。

Overlay

Overlays使用网络隧道在主机之间传递通信。这允许容器通过从一个主机到下一个主机隧道网络子网表现得好像它们在同一台机器上;实质上是一个网络跨越多个主机。目前存在许多隧道技术，例如虚拟可扩展局域网VXLAN。

VXLAN是Docker libnetwork的首选隧道技术，其多主机网络在1.9版本中作为原生功能。随着这种能力的引入，Docker选择利用HashiCorp的Serf作为gossip协议，选择它的邻居表交换和收敛时间的效率。

对于那些需要支持其他隧道技术的需求，Flannel可能是一个选择。它支持udp，vxlan，host-gw，aws-vpc或gce。每个云提供商隧道类型为您的帐户或者VPC在提供商的路由表中创建路由。对公共云的支持对于overlay驱动尤其重要，因为overlay能比较好的解决混合云场景，并提供扩展和冗余，而无需打开公共端口。

多主机网络在启动Docker守护程序以及键值存储时需要额外的参数。某些overlay依赖于分布式键值存储。如果你正在做容器编排，你已经有一个分布式的键值存储。

overlay层侧重于跨主机通信挑战。在同一主机上连接到两个不同overlay网络的容器不能通过本地网桥彼此通信 - 它们是彼此分段的。

Underlays

底层网络驱动将主机接口（即，eth0处的物理网络接口）直接暴露给在主机上运行的容器或VM。 两个这样的底层驱动就是MACVLAN和IPVLAN。 网络工程师非常熟悉MACVLAN和IPVLAN驱动的操作和功能。 这两个网络驱动在概念上比桥接网络更简单，不需要端口映射，并且更高效。 此外，IPVLAN具有与许多网络工程师比较青睐的L3模式。 考虑到大多数公共云中的限制（或缺乏能力），当您有本地工作负载，安全问题，流量优先级或合规要求时，底层特别有用。 不同于每个VLAN需要一个网桥，底层网络允许每个子接口一个VLAN。

MACVLAN

MACVLAN允许在主机的单个物理接口后面创建多个虚拟网络接口。每个虚拟接口具有唯一的MAC和IP地址分配，有一个限制：IP地址需要在与物理接口相同的广播域。虽然许多网络工程师可能更熟悉子接口这个术语（不要与辅助接口混淆），但用于描述MACVLAN虚拟接口的说法通常是上层或下层接口。 MACVLAN网络是一种消除对LINUX网桥需要的方式，NAT和端口映射，允许您直接连接到物理接口。

MACVLAN每个容器使用唯一的MAC地址，这可能导致启用了防止MAC欺骗的这种安全策略（每个物理交换机接口仅允许一个MAC地址）的网络交换机出现问题。

容器流量被过滤掉，不能与底层主机通信，将主机和它上面运行的容器完全隔离。主机无法到达容器。容器与主机隔离。这对服务提供者或多租户场景有用，并且具有比网桥模型更好的隔离。

MACVLAN需要混杂模式; MACVLAN有四种工作模式，Docker 1.12只支持桥接模式。 MACvlan桥接模式和IPvlan L2模式在功能上等效。两种模式都允许广播和组播流量进入。这些底层协议的设计考虑了内部使用案例。您的公有云里程将有所不同，因为它们的虚拟机接口上大多数不支持混合模式。

注意事项：MACVLAN桥接模式为每个容器分配唯一的MAC地址或许是跟踪网络流量和端到端可见性的福音; 然而，对于具有512个唯一MAC地址的上限的典型网络接口卡（NIC），例如BR OADCOM，应该考虑这个上限。

IPVLAN

IPVLAN与MACVLAN类似，它创建新的虚拟网络接口并为每个IP地址分配一个唯一的IP地址。区别在于，相同的MAC地址用于主机上的所有pod和容器 - 物理接口的相同MAC地址。对这种行为的需要主要由以下事实驱动：许多交换机的通常配置的安全状态是关闭具有来自多于一个MAC地址的业务的交换机端口。

最佳运行内核是4.2或更新版本，IPVLAN可以在L2或L3模式下运行。像MACVLAN一样，IPVLAN L2模式要求分配给子接口的IP地址与物理接口在同一子网中。然而，IPvlan L3模式要求容器网络和IP地址在与父物理接口不同的子网上。

Linux主机上的802.1q配置（使用IP Link创建时）是短暂的，因此大多数运营商使用网络启动脚本来保持配置。对于运行底层驱动程序和暴露API的程序化配置VLAN的容器引擎，自动化可以对其改进。例如，当在机架交换机顶部创建新VLAN时，这些VLAN可以通过暴露的容器引擎API.ico被推入Linux主机。

MACVLAN AND IPVLAN

当在这两种底层类型之间进行选择时，请考虑是否需要网络才能看到单个容器的MAC地址。

对于地址解析协议（ARP）和广播通信，无论是底层驱动程序的L2模式，就像连接到交换机的服务器那样，通过将大量使用802.1D分组学习操作。然而，在IPVLAN L3模式中，网络堆栈在容器内处理，不允许多播或广播流量。在这个意义之上，IPVLAN L3模式会按照您期望L3路由器的行为运行。

注意，上游L3路由器需要知道使用IPvlan创建的网络。网络广告和重新分配网络仍然需要完成。今天，Docker正在尝试边界网关协议（BGP）。虽然静态路 由可以在机架交换机的顶层创建，就像goBGP项目如雨后春笋般成立作为一个容器生态友好的方式来提供对等邻居和路由交换功能。

尽管在给定主机上支持多种联网模式，但是MACVLAN和IPVLAN不能同时在相同的物理接口上使用。总之，如果你习惯于在主机上运行trunks，可以用L2模式。如果你主要关注规模，L3则具有大规模的潜力。

DIRECT ROUTING

出于同样的原因，IPVLAN L3模式被网络工程师所青睐，他们可能选择专注于在第3层解决寻址网络复杂性。这种方法受益于利用现有的网络基础设施来管理容器网络。集中在L3的容器网络解决方案使用路由协议提供连接，这可以说更容易与现有的数据中心基础设施，连接容器，VM和裸机服务器进行相互操作。此外，L3网络扩展和提供在过滤和隔离网络流量方面的细粒度控制。

CALICO就是一个这样的项目，使用BGP为每个网络分配路由 - 特别是对使用/ 32的工作负载，这允许它与现有的数据中心基础设施无缝集成，并且不需要Overlays。没有Overlays或封装带来的开销，结果是可以组建具有卓越的性能和规模的网络。容器的可路由IP地址将IP地址与端口暴露于外部世界。被培训并习惯于使用路由协议部署，诊断和操作网络的网络工程师可能发现直接路由更容易消化。然而，值得注意的是，CALICO不支持重叠的IP地址。

FAN NETWORKING

Fan网络是实现访问更多IP地址的一种方式，从一个分配的IP地址扩展到250个IP地址。 这是一种获得更多IP而不需要重叠网络的高效方法。 当在公有云中运行容器时，这种类型的网络特别有用，其中单个IP地址被分配给主机并且启动附加网络是禁止的，或者运行另一个负载均衡实例是昂贵的。

POINT-TO-POINT

点对点可能是CoreOS rkt使用的最简单的网络类型和默认网络。 默认情况下，使用NAT或IPMASQ，它将创建一个虚拟以太网对，将一个放在主机上，另一个放在容器pod中。 点到点网络利用iptables不仅为入站流量提供端口转发，而且通过loopback接口为pod中的其他容器之间的内部通信提供端口转发。

在连接性之外，需要考虑对其他网络功能和网络服务的支持。容器网络的许多模式利用NAT和端口转发或有意避免它们的使用。选择网络时，IP地址管理IPAM，组播，广播，IPv6，负载均衡，服务发现，策略，服务质量，高级过滤和性能都是需要额外考虑的。

问题是这些能力是否受到支持。即使您的runtime，编排引擎或插件支持容器网络功能，您的基础架构也可能不支持该功能。虽然一些2级公有云提供商提供对IPv6的支持，但是在顶级公有云中却缺乏对IPv6的支持，这也增加了用户对其他网络类型（例如Overlays和FAN网络）的需求。

在IPAM方面，为了提高易用性，大多数容器runtime引擎默认使用host-local为容器分配地址，因为它们已连接到网络。host-local IPAM涉及定义要选择的固定IP地址块。跨容器网络项目普遍支持动态主机配置协议（DHCP）。容器网络模型（CNM）和容器网络接口（CNI）都具有用于与IPAM系统集成的IPAM内置和插件框架 - 这是在许多现有环境中采用的关键能力。

想了解更多关于容器网络模型（CNM）和容器网络接口（CNI）的技术细节请参考忘期文章： 容器网络聚焦：CNM和CNI

文末福利：请大家关注"Wise2C"公众号并回复【进群】，睿云小助手会第一时间拉你进入【 Docker企业落地实践群】，我们分享的各个企业案例项目的技术专家与用户代表，正在敬候您的光临，期待大家就项目的更多细节与疑问与群里的大牛们进行咨询探讨。

需要了解更多有关睿云智合的客户项目细节，请在Wise2C公众号中最佳实践菜单中查看。

干货放送系列之（一）： 富德生命人寿容器技术应用实战案例

干货放送系列之（二）： 中国平安容器技术应用实战案例

干货放送系列之（三）： 民生人寿容器技术应用实战案例

干货放送系列之（四）： 某中型人寿保险公司系统架构改造规划咨询实战案例

年度盘点系列： 年度盘点 | 2016年金融行业容器技术应用 - 保险篇

年度盘点系列： 年度盘点 | 2016年金融行业容器技术应用 - 银行篇

若需要了解更多有关Wise系列PaaS产品的详情，请与我们的市场团队联系：

contact@wise2c.com

怎么在docker容器里模拟产生很大的流量

，操作命令如下： Docker会在隔离的容器中运行进程。当运行docker run命令时，Docker会启动一个进程，并为这个进程分配其独占的文件系统、网络资源和以此进程为根进程的进程组。在容器启动时，镜像可能已经定义了要运行的二进制文件、暴露的

Docker macvlan

默认情况下docker使用bridge网络，这是一个私有网络，只能在host和container之间互通，如果发布服务，需要使用端口映射的方式来解决，比如一个nginx容器要想对外提供服务则在容器启动时指定参数 -p 80:80 ，然后使用host主机的ip加端口即可访问容器。这在大部分场景下都够用了，但是总有一些需求无法满足，比如如果多个容器都需要使用80端口，或者只使用ip通信的网络应用， macvlan 可以做到。

macvlan 是可以虚拟mac地址，单独的macvlan存在意义不大，结合docker给每一个容器都虚拟一个 mac 地址，这样每个容器在局域网中都相当于一个独立的主机。

经过上面操作运行了一个nginx容器，此容器拥有一个虚拟的mac地址，在网内相当于一个真实的主机，任何网内的其他主机（非host）都可以通过为其指定的ip访问该容器。 如果使用相同的方法运行多个nginx容器，并不需要每个容器指定不同的端口，因为网络namespace是隔离的。

但是目前有个问题： host 和 container 是无法互通的，因为是macvlan的原因，同一个网口的流量是无法回传的，除非在外部有一个支持 VEPA 或者 VN-Link 的交换机。

以上命令中的网络接口、ip请根据实际情况进行调整