加强心理咨询网站的建设,牛商网建设的食品网站,太原百度关键词推广,网站建设实践总结1. Docker引擎
Docker引擎是用来运行和管理容器的核心软件。通常人们会简单的将其指代为Docker或Docker平台。
基于开放容器计划#xff08;OCI#xff09;相关的标准要求#xff0c;Docker引擎采用了模块化的设计原则#xff0c;其组件是可替换的。
Docker引擎由如下主…1. Docker引擎
Docker引擎是用来运行和管理容器的核心软件。通常人们会简单的将其指代为Docker或Docker平台。
基于开放容器计划OCI相关的标准要求Docker引擎采用了模块化的设计原则其组件是可替换的。
Docker引擎由如下主要的组件构成Docker客户端Docker Client、Docker守护进程Docker daemon、containerd以及runc。
Docker引擎的架构示意图如下 1.1 runc
runc是OCI容器运行时规范的参考实现。去粗取精会发现runc实质上是一个轻量级的、针对Libcontainer进行了包装的命令行交互工具Libcontainer取代了早期Docker架构中的LXCLXC提供了对诸如命令空间namespace和控制组CGroup等基础工具的操作能力
runc生来只有一个作用 — 创建容器它是一个CLI包装器实质上就是一个独立的容器运行时工具。因此直接下载它或者基于源码编译二进制文件即可拥有一个全功能的runc。但它只是一个基础工具并不提供类似Docker引擎所拥有的丰富功能。
1.2 containerd
在对Docker daemon的功能拆解后所有的容器执行逻辑被重构到一个新的名为containerd的工具中。它的主要任务是容器的生命周期管理 — start|stop|pause|rm...
在Docker引擎技术栈中containerd位于daemon和runc所在的OCI层之间。Kubernetes也可以通过cri-containerd使用containerd。
1.3 启动一个新的容器流程
现在我们对Docker引擎已经有了一个总体认识也了解了一些历史下面介绍一下创建新容器的过程。
常用的启动容器的方法就是使用Docker命令行工具。下面的docker container run命令会基于alpine:latest镜像启动一个新容器。
docker container run --name ctr1 -it alpine:latest sh当使用Docker命令行工具执行如上命令时Docker客户端会将其转换为合适的API格式并发送到正确的API端点。
API是在daemon中实现的。这套功能丰富、基于版本的REST API已经成为Docker的标志并且被行业接受成为事实上的容器API。
一旦daemon接收到创建新容器的命令它就会向containerd发出调用。daemon已经不再包含任何创建容器的代码了
daemon使用一种CRUD风格的API通过gRPC与containerd进行通信。
虽然名叫containerd但是它并不负责创建容器而是指挥runc去做。containerd将Docker镜像转换为OCI bundle并让runc基于此创建一个新的容器。
然后runc与操作系统内核接口进行通信基于所有必要的工具Namespace、CGroup等来创建容器。容器进程作为runc的子进程启动启动完毕后runc将会退出。
现在容器启动完毕了。整个过程如下图。 1.4 shim
shim是实现无daemon的容器不可或缺的工具。
前面提到containerd指挥runc来创建新容器。事实上每次创建容器时它都会fork一个新的runc实例。不过一旦容器创建完毕对应的runc进程就会退出。
一旦容器进程的父进程runc退出相关联的containerd-shim进程就会成为容器的父进程。
作为容器的父进程shim的部分职责如下。
保持所有STDIN和STDOUT流是开启窗台从而当daemon重启的时候容器不回因为管道pipe的关闭而终止。将容器的退出状态反馈给daemon。
1.5 daemon的作用
当所有的执行逻辑和运行时代码都从daemon中剥离出来之后daemon的主要功能包括镜像管理、镜像构建、REST API、身份验证、安全、核心网络以及编排。 2. Docker镜像
Docker镜像就是停止运行的容器。如果读者是一名研发人员可以将镜像理解为类Class。
读者需要先从镜像仓库服务中拉取镜像。常见的镜像仓库服务是Docker Hub但是也存在其他镜像仓库服务。
镜像由多个层租场每层叠加之后从外部看起来就如一个独立的对象。镜像内部是一个精简的操作系统OS同时还包含应用运行所必须的文件和依赖包。
镜像中不包含内核容器都是共享所在Docker主机的内核。 3. Docker容器
容器是镜像的运行时实例。虚拟机和容器最大的区别是容器更快并且更轻量级与虚拟机运行在完整的操作系统之上相比容器会共享其所在主机的操作系统/内核。
3.1 容器 vs 虚拟机
从更高层面上讲Hypervisor是硬件虚拟化Hypervisor将硬件物理资源划分为虚拟资源容器是操作系统虚拟化容器将系统资源划分为虚拟资源。
虚拟机模型
在虚拟机模型中首先要开启物理机并启动Hypervisor引导程序一旦Hypervisor启动就会占有机器上的全部物理资源如CPU、RAM、存储以及NIC。Hypervisor接下来就会将这些物理资源划分为虚拟资源并且看起来与真实物理资源完全一致。
然后Hypervisor会将这些资源打包进一个叫做虚拟机VM的软件结构当中。这样用户就可以使用这些虚拟机并在其中安装操作系统和应用。
容器模型
与操作系统模型相同的是OS也占用了全部硬件资源。
在OS层之上需要安装容器引擎如Docker。容器引擎可以获取系统资源如进程树、文件系统以及网络栈接着将资源分割为安全的相互隔离的资源结构称之为容器。每个容器看起来就像一个真实的操作系统在其内部可以运行应用。
虚拟机的额外开销
虚拟机模型通过Hypervisor将底层硬件资源划分为虚拟机当中。每个虚拟机都是包含了虚拟CPU、虚拟RAM、虚拟磁盘等资源的一种软件结构。因此每个虚拟机都需要有自己的操作系统来声明、初始化并管理这些虚拟资源。但不幸的是操作系统本身是有额外开销的。
容器模型具有宿主机操作系统中运行的单个内核。这意味着只有一个操作系统消耗CPU、RAM和存储资源。简而言之就是只有一份OS损耗 4. 应用容器化
容器是为应用而生具体来说容器能够简化应用的构建、部署和运行过程。
完整的应用容器化过程主要分为以下几个步骤。
1编写应用代码。 2创建一个Dockerfile其中包括当前应用的描述、依赖以及该如何运行这个应用。 3对该Dockerfile执行docker image build命令。 4等待Docker将应用程序构建到Docker镜像中。 5. 容器网络
Docker对于容器之间、容器与外部网络和VLAN之间的连接均有相应的解决方案。
Docker网络架构源自一种叫做容器网络模型CNM的方案该方案是开源的并且支持插接式连接。Libnetwork是Docker对CNM的一种实现提供了Docker核心网络架构的全部功能。不同的驱动可以通过插拔的方式接入Libnetwork来提供定制化的网络拓扑。
为了实现开箱即用的效果Docker封装了一系列本地驱动覆盖了大部分常见的网络需求。其中包括单机桥接网络Single-Host Bridge Network、多机覆盖网络Multi-Host Overlay并且支持接入现有VLAN。
最后要说的是Libnetwork提供了本地服务发现和基础的容器负载均衡解决方案。
基础理论
在顶层设计中Docker网络架构由3个主要部分构成CNM、Libnetwork、驱动。
CNM是设计标准。Libnetwork是CNM的具体实现。驱动通过实现特定网络拓扑的方式来扩展该模型的能力。
5.1 CNM
Docker网络架构的设计规范是CNM。CNM中规定了Docker网络的基础组成要素。
CNM定义了3个基本要素沙盒Sandbox、终端Endpoint和网络Network。 沙盒是一个独立的网络栈。其中包括以太网接口、端口、路由表以及DNS配置。 终端就是虚拟网络接口。在CNM中终端负责将沙盒连接到网络。 网络是802.1d网桥类似于大家熟知的交换机的软件实现。因此网络就是需要交换的终端的集合并且终端之间相互独立。 Docker环境中最小的调度单位就是容器图11.3展示了CNM组件是如何与容器进行关联的 — 沙盒被放置在容器内部为容器提供网络连接。 容器A只有一个网络接口终端并连接到了网络A。容器B有两个接口终端并且分别接入了网络A和网络B。容器A和容器B之间是可以相互通信的因为都接入了网络A。但是如果没有三层路由器的支持容器B的两个终端之间是不能通信的。
5.2 Libnetwork
CNM是设计规范文档Libnetwork是标准的实现。
Docker将网络部分从daemon中拆分并重构为一个叫作Libnetwork的外部类库。Libnetwork实现了CNM中定义的全部3个组件。此外它还实现了本地服务发现Service Discovery、基于ingress的容器负载均衡以及网络控制层和管理层功能。
5.3 驱动
如果说Libnetwork实现了控制层和管理层功能那么驱动就负责实现数据层。
Docker封装了若干内置驱动通常被称为原生驱动或者本地驱动。在Linux上包括Bridge、Overlay以及Macvlan。第三方也可以编写Docker网络驱动这些驱动叫作远程驱动例如Calico、Contiv、Kuryr以及Weave。 每个驱动都负责其上所有网络资源的创建和管理。 6. Docker覆盖网络Overlay
容器间通信的可靠性和安全性相当重要即使容器分属于不同网络中的不同主机。这也是覆盖网络大展拳脚的地方它允许读者创建扁平、安全的二层网络来连接多个主机容器可以连接到覆盖网络并直接通信。
创建overlay网络命令
docker network create -d overlay uber-net6.1 工作原理VXLAN
首先必须知道Docker使用VXLAN隧道技术创建了虚拟二层覆盖网络。
在VXLAN的设计中允许用户基于已经存在的三层网络结构创建虚拟二层网络。VXLAN的美妙之处在于它是一种封装技术能使现存的路由器和网络架构看起来就像普通的IP/UDP包一样并且处理起来毫无问题。
为了创建二层覆盖网络VXLAN基于现有的三层IP网络创建了隧道VXLAN隧道终端VXLAN Tunnel Endpoint VTEP。VTEP完成了封装和解压的步骤以及一些功能实现所必须的操作。
6.2 网络联通举例
假设当前有2个网络172.31.1.0/24192.168.1.0/24每个网络下有一台主机。通过IP网络将两台主机连接起来。每个主机运行了一个容器之后又为容器连接创建一个VXLAN覆盖网络。
为了实现上述场景在每台主机上都新建了一个Sandbox网络命名空间。Sandbox就像一个容器但其中运行的不是应用而是当前主机上独立的网络栈。
在Sandbox内部创建了一个名为Br0的虚拟交换机又称虚拟网桥。同时Sandbox内部还创建了一个VTEP其中一端接入到名为Br0的虚拟交换机当中另一端接入主机网络栈VTEP。在主机网络栈中的终端从主机所连接的基础网络中获取到IP地址并以UDP Socket的方式绑定到4789端口。不同主机上的两个VTEP通过VXLAN隧道创建了一个覆盖网络如下图所示。 这是VXLAN上层网络创建和使用所必需的。
接下来每个容器都会有自己的虚拟以太网veth适配器并接入本地Br0虚拟交换机。目前拓扑结果如图12.7所示虽然是在主机所属网络互相独立的情况下但这样能更容器看出两个分别位于不同主机上的容器之间是如何通过VXLAN上层网络进行通信的。 6.3 通信示例
在本例中将node1上的容器称为C1node2上的容器称为C2如图12.8所示。假设C1希望ping通C2。 C1发送ping请求目标IP为C2的地址10.0.0.4。该请求的流量通过连接到Br0虚拟交换机的veth接口发出。虚拟交换机并不知道将包发送在哪里因为在虚拟交换机的MAC地址映射表ARP映射表中并没有与当前目的IP对应的MAC地址。所以虚拟交换机会将该包发送到其上的全部端口。连接到Br0的VTEP接口知道如何转发这个数据帧所以会将自己的MAC地址返回。这就是一个代理ARP响应并且虚拟交换机Br0根据返回结果学会了如何转发该包。接下来虚拟交换机会更新自己的ARP映射表叫10.0.0.4映射到本地VTEP的MAC地址上。
现在Br0交换机已经学会如何转发目标C2的流量接下来所有发送到C2的包都会被直接转发到VTEP接口。VTEP接口知道C2是因为所有新启动的容器都会将自己的网络详情采用网络内置Gossip协议发送给相同Swarm集群内的其他节点。
交换机会将包转发到VTEP接口VTEP完成数据帧的封装这样就能在底层网络传输。具体来说封装操作就是把VXLAN Header信息添加到以太帧当中。
VXLAN Header信息包含了VXLAN网络IDVNID其作用是记录VLAN到VXLAN的映射关系。每个VLAN都对应一个VNID以便可以在解析后被转发到正确的VLAN。封装的时候会将数据帧放到UDP包中并设置UDP的目的IP字段为node2节点的VTEP的IP地址同时设置UDP Socket端口为4789。这种封装方式保证了底层网络即使不知道任何关于VXLAN的信息也可以完成数据传输。
当包达到node2之后内核发现目的端口为UDP端口4789同时还知道存在VTEP接口绑定到该Socket。所以内核将包发给VTEP由VTEP读取VNID解压包信息并根据VNID发送到本地名为Br0的连接到VLAN的交换机上。在该交换机上包被发送给容器C2。
以上大体介绍了Docker覆盖网络是如何利用VXLAN技术的。
