《Cloud Native Data Center Network》读书笔记-6

最新推荐文章于 2024-09-27 00:12:52 发布

竹林子的摩卡

最新推荐文章于 2024-09-27 00:12:52 发布

阅读量110

点赞数

分类专栏：会敲键盘的喵文章标签： tcp/ip

本文链接：https://blog.csdn.net/zxmgl2007/article/details/120132349

版权

会敲键盘的喵专栏收录该内容

24 篇文章 4 订阅

订阅专栏

第七章容器网络

第七章第一小节容器介绍

容器定义了几种不同的方式，一种侧重于包装，另一种侧重于执行环境。作为打包模型，容器将应用程序代码及其依赖关系、配置和数据捆绑在一起，以便运行时运行的环境不再关心或提供这些东西。作为一个执行模型，容器是一个隔离单元，它对它使用的许多资源-CPU、内存等执行限制。

容器比进程更重，但比虚拟机轻。与进程一样，并且与VM不同，该容器与运行在同一台主机上的其他容器共享操作系统。但与进程不同的是，并且类似于虚拟机，每个容器都有自己的网络专用视图，包括主机名和域名、进程、用户、文件项和进程间通信。

容器执行模型是构建在命名空间和控制组/cgroup的双Linux内核构造上的用户空间构造。群组是一个Linux内核特性，它对进程集合所消耗的资源实施限制。命名空间提供了隔离功能。我们从讨论网络名称空间开始讨论容器网络。

第七章第二小节命名空间

命名空间是一种类似于网络和服务器虚拟化的Linux内核虚拟化结构。命名空间虚拟化特定资源被内核管理，从而允许虚拟资源的多个独立实例。一个进程与该资源的一个这样的虚拟实例相关联。多个进程可以属于该资源的一个公共虚拟实例。从流程的角度来看，它们似乎完全拥有该资源。

自内核3.8版本以来，命名空间完全可以作为虚拟化结构使用。内核支持以下六个资源的虚拟化：

Cgroup

通过/proc/pip/cgroup和/proc/pid/pid/mountinfo虚拟化流程的Cgroup视图，其中pid是进程的进程ID。这样做的一个原因是防止容器应用程序识别它们在容器中运行。

进程间通信(IPC)

虚拟化IPC的各种结构，如POSIX消息队列、共享内存、信号量等。这也可以防止进程跨其隔离单元干扰另一个进程的状态。

网络

虚拟化所有的网络资源，如接口、套接字、路由表、MAC表等。

Mount

虚拟化文件系统挂载点。这允许每一组独立的进程认为自己拥有根文件系统，而实际上，它们的根文件系统通常只是一个更大的文件系统的一个受约束的视图。

PID

虚拟化进程ID空间。这也可以用于防止进程发现其被容器化的技术。每个容器都有一个PID为1(Init进程)的进程，就像在裸金属服务器上一样。

用户

虚拟化用户、用户和组ID。每个孤立的进程组都有一个根用户，它只在该虚拟实例中充当根用户。

UTS

将主机名和域名虚拟化，以便每个独立的单元都可以设置自己的主机名和域名，而不影响其他主机名或父设备。

使用命名空间，可以构建一个逻辑路由器。

7.2.1 网络命名空间

网络名称空间(又名netns)的概念类似于网络虚拟化，但它是一个更重量级的虚拟化结构，因为它包括整个网络堆栈，一直包括网络堆栈的传输层。

第七章第三小节虚拟以太网接口

Linux为虚拟以太网提供了一个称为veth的虚拟接口构造，以允许在网络之外进行通信。

因此，为了允许从网内部到外部的通信，你将网络的一端放入网，另一端放入你想要外部通信的地方。例如，当您通过Docker命令创建一个容器时，将创建一个veth对，一端位于所创建的容器的网内，另一端位于默认网或主机网内。这样，您就可以在容器和外部世界之间设置通信。图7-1说明了在Linux中对veth的使用。NS1和NS2是独立的网络名称空间，具有一个veth接口，支持它们之间的通信。
在这里插入图片描述
图7-1 Linux中的veth接口
在Docker中，在容器内创建的最常见的网络接口是一个veth接口，特别是当与默认的Docker桥接网络一起使用时。

第七章第四小节容器网络：深度解析

容器网络有四种操作模式：

无网络

主机网络

单主机网络

多主机网络

当容器不希望与外部世界通信，因此没有任何类型的网络连接时，将使用第一种模式。

在第二种模式下，容器与主机操作系统共享网络命名空间。

单主机网络是Docker提供的默认网络。在这种模式下，运行在同一台主机上的容器除了与外部世界进行通信外，还可以相互通信。

在最后一种模式下，多主机容器网络允许运行在不同服务器上的容器相互通信。

7.4.1 单主机网络

桥接

当第一次实例化Docker服务时，它将创建一个Docker0设备，这是一个Linux桥。
在这里插入图片描述
图7-2 Docker0桥接器作为容器的默认网络
Docker使用172.17.0.0/16的默认子网。它将地址172.17.0.1分配给桥接本身。当容器启用-时，具有与Docker0桥关联的网络接口时，Docker会自动从Docker0子网172.17.0.0/16将未使用的IP地址分配给容器。Docker还在容器的命名空间中添加了一个默认路由，它将下一跳指定为Docker0的IP地址172.17.0.1.默认情况下，Docker还配置从桥到外部世界的任何包进行NAT，以便多个容器可以共享一个主机IP地址以与主机以外的实体通信。

图7-3显示了容器1希望与外部Web服务器进行通信的操作序列。运行Docker容器的主机和web服务器都在192.168.0.0/24网络上，Docker在192.168.0.23上，web服务器在192.168.1.2.上
在这里插入图片描述
图7-3 通过Docker程序0进行外部通信
MACVLAN

作为使用桥接进行单主机容器通信的替代方案，您可以使用Macvlan，一个与物理接口相关联的L2虚拟网络接口。内核驱动程序分配每个Macvlan接口一个唯一的MAC地址。内核将传入的包传递到Macvlan接口，其MAC地址与包的目标MAC地址匹配，从而到达正确的容器。

图7-4(a)显示了容器连接到的Macvlan网络，而Macvlan网络本身直接连接到一个物理接口上。与Macvlan网络关联的容器需要在与上游接口关联的子网中分配IP地址。在图中，上游路由器假设该接口是在192.168.0.0/24中的子网，其自己的接口被分配给地址192.168.0.1.主机分配地址为192.168.0.101/24，容器分配地址为192.168.0.128和192.168.0.129。如图7-4(b)所示，即使是连接到同一Macvlan设备的容器也不能相互直接地连接。这被称为Macvlan驱动程序的VEPA模式。默认情况下，Docker以另一种称为桥接模式的模式创建一个Macvlan网络，如图7-4©所示。在桥模式下，连接到同一Macvlan的容器可以直接交谈，而无需7-4(b）那样。然而，与宿主本身的交流仍然需要7-4(b）。
在这里插入图片描述
图7-4 使用Linux内核查看的Macvlan的容器
图7-5比较了常规桥上的包转发和VEPA模式下的Macvlan转发。

VEPA模式下的Macvlan网络的主要好处是更好的性能。
在这里插入图片描述
图7-5 桥中的包流与MACVLAN
在使用MACVLAN设备时，有一个警告。大多数网卡只接受512个左右的MAC地址作为他们自己的地址。

7.4.2 多主机容器网络

多主机容器通信时，需要解决以下问题：

这些容器是否连接在L2或L3处？

当容器跨多个主机传播时，如何处理地址管理？

可用的选择的各种含义是什么？

Overlay网络

Docker定义了一种称为多主机连接的Overlay的网络类型。VxLAN

图7-6显示了数据平面是如何连接的；也就是说，从包转发的角度。两个不同服务器中的容器都属于同一个子网，172.17.0.0/24.Server1的VTEP IP地址为192.168.0.23，而Server2的VTEP IP地址为192.168.10.41.路由器将交换路由信息，以便所有路由器都知道如何到达192.168.0.0/24和192.168.10.0/24个子网。因此，从服务器1到服务器2的VXLAN封装包将通过所示网络路由。
在这里插入图片描述
图7-6 用于容器的Overlay网络
当使用Overlay网络时，Docker会在一个容器内设置两个接口。一种是用来使用Overlay层在同一子网中的容器之间的通信。另一个是与外部世界交流的。这个新的接口也是一个版本，但它连接到另一个名为docker_gwbridge的桥。它也有自己的IP子网。

直连路由

Overlay解决方案的一个替代方案是使用路由，一个L3解决方案。此解决方案使用单主机容器网络驱动程序，通常是桥接驱动程序，来构建多个主机容器，然后通过路由进行连接。必须关闭桥接子网的NAT才能使用此解决方案。运行在单个服务器上的路由守护进程（例如来自FRR的ospf或bgp）宣布单个容器地址或桥接子网。

图7-7显示了此解决方案
在这里插入图片描述
图7-7 多主机容器网络的路由
该解决方案的一个缺点是无法跨多个节点从同一子网分配IP地址。