1.docker容器网络
2.探索 Linux Namespace：Docker 隔离的神奇背后
3.深入理解 Docker 核心原理：Namespace、Cgroups 和 Rootfs
4.图文详解 | Docker 究极版入门指南，别再说 Docker 难了！
5.Docker容器网络-实现篇
6.深入学习docker -- 资源限制Cgroups

docker容器网络

       åˆ©ç”¨Net Namespace可以为Docker容器创建隔离的网络环境，容器具有完全独立的网络栈，与宿主机隔离。也可以使Docker容器共享主机或者其他容器的网络命名空间，基本可以满足开发者在各种场景下的需要。

       Docker支持 4种网络模式 ：

       1）host模式，--net=host指定，不支持多主机。

        2）container模式，--net = container : name_or_id指定，不支持多主机。

        3）none模式，--net=none指定，不支持多主机。

        4）bridge模式，--net=bridge指定，默认设置，不支持多主机。

        启动容器的时候使用Host模式，那么该容器与宿主机共用一个Network Namespace，因此容器将不会虚拟自己的网卡、配置自己的IP等，而是使用宿主机的IP和端口。

        采用Host模式的容器，可以直接使用宿主机的IP地址与外界进行通信，无需额外进行NAT转换。由于容器通信时，不再需要通过Linux Bridge等方式转发或者数据包的拆封，性能上有很大优势。当然， Host模式有利也有弊 ，主要包括以下缺点：

        1）容器没有隔离、独立的网络栈。容器因与宿主机共用网络栈而争抢网络资源，并且容器崩溃也可能导致宿主机崩溃，这在生产环境中是不允许发生的。

        2）容器不再拥有所有的端口资源，因为一些端口已经被宿主机服务、Bridge模式的容器端口绑定等其他服务占用了。

        需要补充说明的是，Host模式下的容器仅仅是网络命名空间与主机相同，但容器的文件系统、进程列表等还是和与宿主机隔离的。

       Container模式是一种特殊的网络模式。该模式下的容器使用其他容器的网络命名空间，网络隔离性会处于Bridge模式与Host模式之间。当容器与其他容器共享网络命名空间时，这两个容器间不存在网络隔离，但它们与宿主机及其他容器又存在网络隔离。

        在Kubernetes体系架构下引入Pod概念，Kubernetes为Pod创建一个基础设施容器， 同一Pod下的其他容器都以Container模式 共享这个基础设施容器的网络命名空间，相互之间以localhost访问，构成一个统一的整体。

       ä¸Žå‰ä¸¤ç§ä¸åŒï¼ŒNone模式的Docker容器拥有自己的Network Namespace，但并不为Docker容器进行网络配置。该Docker容器没有网卡、IP、路由等信息。需要用户为Docker容器添加网卡、配置IP等。

        Bridge模式是Docker默认的网络模式，也是开发者最常使用的网络模式。在这种模式下，Docker为容器创建独立的网络栈，保证容器内的进程使用独立的网络环境，实现容器之间、容器与宿主机之间的网络栈隔离。同时，通过宿主机上的Docker0网桥，容器可以与宿主机乃至外界进行网络通信。

        同一宿主机上，容器之间都是连接在Docker0这个网桥上，Docker0作为虚拟交换机使容器间相互通信 。但是， 由于宿主机的IP地址与容器veth pair的IP地址均不在同一个网段 ，故仅仅依靠 veth pair和NameSpace的技术 并不足以使宿主机以外的网络主动发现容器的存在。Docker采用了 端口绑定的方式(通过iptables的NAT) ，将宿主机上的端口流量转发到容器内的端口上，这样一来，外界就可以与容器中的进程进行通信。 iptables的介绍，请点我点我 。

       åˆ›å»ºå®¹å™¨ï¼Œå¹¶å°†å®¿ä¸»æœºçš„端口绑定到容器的端口：docker run -tid --name db -p : mysql

        在宿主机上，可以通过“iptables -t nat -L -n”，查到一条DNAT规则：DNAT tcp --0.0.0.0/0 0.0.0.0/0 tcp dpt: to:..0.5:

        Bridge模式的容器与外界通信时，必定会占用宿主机上的端口，从而与宿主机竞争端口资源，这会造成对宿主机端口管理很复杂。同时，由于容器与外界通信是基于三层上iptables NAT，性能和效率损耗是显而易见的。

       NAT将地址空间分段的做法引入了额外的复杂度。比如容器中应用所见的IP并不是对外暴露的IP， 因为网络隔离，容器中的应用实际上只能检测到容器的IP，但是需要对外宣称的则是宿主机的IP，这种信息的不对称将带来诸如破坏自注册机制等问题 。

       æ‘˜æŠ„自陆平的《基于Kubernetes的容器云平台实战》一书的第章Kubernetes网络

探索 Linux Namespace：Docker 隔离的神奇背后

       深入探索 Linux Namespace：揭秘 Docker 隔离原理

       在理解 Docker 的核心实现机制时，Linux Namespace 玩着至关重要的角色。Namespace 是modbus RTU vb源码 Linux 内核提供的，用于在操作系统级别实现资源隔离的技术。借助 Namespace，Docker 可以在宿主机上创建出独立的运行环境，这些环境之间彼此隔离，确保应用在不同的容器中运行时互不影响。

       Namespace 包括但不限于进程、网络、文件系统、用户组等，通过这些不同的 Namespace，Docker 实现了容器内的资源隔离。接下来，让我们逐一了解 Namespace 的类型、使用方法以及在 Docker 中的应用。

       一、Linux Namespace 基础概览

       Namespace 的主要作用是提供资源隔离，使得不同进程共享相同的系统资源时，不会产生冲突。Linux 内核中提供了八种不同的etc后台源码 Namespace 类型，包括但不限于：

       PID Namespace

       UTS Namespace

       IPC Namespace

       Network Namespace

       User Namespace

       这些 Namespace 共同构建了一个灵活、高效的资源隔离框架，为容器化技术提供了坚实的基础。

       二、Namespace 的使用与实现

       实现 Namespace 通常涉及以下关键函数：

       clone

       setns

       unshare

       ioctl_ns

       这些函数允许在内核级别创建、切换和管理 Namespace，确保进程在隔离的环境中运行。

       1. UTS Namespace 示例

       UTS Namespace 专门用于隔离主机名（hostname）和域名（domain name）。在 UTS Namespace 内，每个 Namespace 都可以拥有自己的 hostname。以下代码展示了如何在 Go 语言中切换 UTS Namespace，从而在新环境中修改 hostname 且不会影响到宿主机。

       2. IPC Namespace 示例

       IPC Namespace 用于隔离系统调用和 POSIX 消息队列。在不同 IPC Namespace 内的进程将拥有各自独立的系统调用和消息队列。通过在程序中调用 Cloneflags 并指定 CLONE_NEWIPC，可以成功创建和使用 IPC Namespace。

       3. PID Namespace 示例

       PID Namespace 用于隔离进程 ID，允许同一进程在不同 Namespace 中拥有不同的 PID。在 Docker 中，PID Namespace 实现了容器内的进程隔离，使容器内的进程看似独立于宿主机。

       4. Mount Namespace 示例

       Mount Namespace 用于隔离文件系统的挂载点视图。通过在特定 Namespace 中调用 mount() 和 umount()，仅影响当前 Namespace 内的香烟源码查询文件系统，确保容器内的应用无法访问宿主机上的文件系统。

       5. User Namespace 示例

       User Namespace 用于隔离用户 ID 和组 ID，允许容器内的进程拥有与宿主机不同的用户权限。通过指定特定的 User Namespace，Docker 可以确保容器内的应用具有有限的权限，增强安全性。

       三、总结与展望

       通过深入理解 Linux Namespace 的工作原理与应用，我们可以更好地掌握 Docker 的隔离机制。Namespace 提供了强大的资源隔离能力，确保容器内的应用运行在隔离的环境中，互不影响，为云原生应用提供了稳定、安全的运行环境。

       如果您对云原生技术感兴趣，欢迎关注微信公众号探索云原生，获取更多相关文章和资讯。

深入理解 Docker 核心原理：Namespace、Cgroups 和 Rootfs

       深入理解 Docker 核心原理：Namespace、Cgroups 和 Rootfs

       本文将深入解析 Docker 容器的核心实现原理，重点讲述 Namespace、Cgroups、Rootfs 等三个关键功能。

       首先，趋势助手源码思考容器与进程的区别，通过 Docker 等 Linux 容器，借助 Namespace 技术实现进程视图的隔离，使得容器和宿主机在多个层面上隔离。Linux Namespace 包括 Network Namespace、PID Namespace 等，通过这些 Namespace 可以实现不同资源的隔离，如网络、进程等。

       Namespace 最大的问题是隔离不彻底。为提升安全性，出现了 Firecracker、gVisor、Kata 等沙箱容器，它们不共享内核。通过 namespace 实现隔离的 Docker 确保了容器的独立性。

       在资源限制方面，Docker 通过 Cgroups 技术实现。启动容器时，可以指定 CPU、内存等资源限制。以 CPU 限制为例，通过在 Cgroups 目录下创建控制组，配置资源限制，精灵鼠标源码实现对进程的限制。如限制一个进程只能使用 0.5 个 CPU 核心。

       Cgroups 设计简洁，易于使用，为进程组设置资源上限，包括 CPU、内存、磁盘、网络带宽等。在 Linux 中，Cgroups 以文件系统方式呈现，通过 mount 命令查看。

       对于容器镜像，它由一系列 rootfs 层组成，每个层包含操作系统文件、目录和配置，但不包括内核。rootfs 将操作系统与应用及依赖打包，确保应用在不同环境下的一致运行。容器启动时，挂载 rootfs 到根目录。

       镜像层概念简化了 rootfs 的复用，通过联合文件系统（Union File System）将多个层合并挂载。镜像包含静态文件，容器内产生实时数据，实现容器 rootfs 的读写分离。

       Init 层用于保存容器启动时需要初始化的配置信息，如 /etc/hosts、/etc/resolv.conf 等，避免在提交镜像时包含这些动态数据。

       综上，Docker 容器的核心原理集中在 Namespace、Cgroups 和 Rootfs 功能上，通过这些机制实现容器的独立性、资源管理和镜像构建，推动了云原生技术的发展。

       欢迎关注微信公众号，获取更多云原生技术内容和资讯。

图文详解 | Docker 究极版入门指南，别再说 Docker 难了！

       Docker是一个开源的应用容器引擎，基于Go语言开发，利用Linux内核技术实现轻量级的虚拟化。它通过cgroup、namespace和AUFS等技术，将进程封装成独立的容器，每个容器都拥有独立的运行环境，类似于一个自给自足的迷你应用世界。

       使用Docker的主要优势在于：一是开发和运维人员可以快速构建和部署标准化的开发环境，确保代码在不同阶段的运行一致性；二是其环境隔离特性解决了不同算法研究中软件版本冲突的问题；三是Docker具有高效率，容器启动停止迅速，对系统资源需求低，易于移植到各种平台；四是通过Dockerfile，可以轻松管理和更新容器，实现自动化部署。

       Docker的架构采用Client/Server模式，客户端与服务器通过请求交互，后者负责容器的构建、运行和分发。安装Docker环境，首先需要确保Linux基础环境，如关闭防火墙和SeLinux等限制。然后，安装Docker Engine和容器，通过命令行管理镜像和容器，包括搜索、下载、上传、查看、创建、删除等操作。

       对于初学者，推荐通过免费视频课程进行学习，由浅入深讲解，实践与理论相结合，同时提供配套学习资源。如果你想深入Linux运维领域，可以考虑参加实战训练营，由经验丰富的讲师授课，涵盖基础命令、游戏平台搭建、企业网盘、高并发网站架构等内容，培训结束后还有福利赠送。

Docker容器网络-实现篇

       

        前面介绍了： Docker容器网络-基础篇

        前文说到容器网络对Linux虚拟化技术的依赖，这一篇章我们将一探究竟，看看Docker究竟是怎么做的。通常，Linux容器的网络是被隔离在它自己的Network Namespace中，其中就包括：网卡（Network Interface）、回环设备（Loopback Device）、路由表（Routing Table）和iptables规则。对于一个进程来说，这些要素，就构成了它发起和响应网络请求的基本环境。

        我们在执行 docker run -d --name xxx 之后，进入容器内部：

        并执行 ifconfig：

        我们看到一张叫eth0的网卡，它正是一个Veth Pair设备在容器的这一端。

        我们再通过 route 查看该容器的路由表：

        我们可以看到这个eth0是这个容器的默认路由设备。我们也可以通过第二条路由规则，看到所有对 ..1.1/ 网段的请求都会交由eth0来处理。

        而Veth Pair 设备的另一端，则在宿主机上，我们同样也可以通过查看宿主机的网络设备来查看它：

        在宿主机上，容器对应的Veth Pair设备是一张虚拟网卡，我们再用 brctl show 命令查看网桥：

        可以清楚的看到Veth Pair的一端 vethdbe 就插在 docker0 上。

        我现在执行docker run 启动两个容器，就会发现docker0上插入两个容器的 Veth Pair的一端。如果我们在一个容器内部互相ping另外一个容器的IP地址，是不是也能ping通？

        容器1：

        容器2：

        从一个容器ping另外一个容器：

        我们看到，在一个容器内部ping另外一个容器的ip，是可以ping通的。也就意味着，这两个容器是可以互相通信的。

        我们不妨结合前文时所说的，理解下为什么一个容器能访问另一个容器？先简单看如一幅图：

        当在容器1里访问容器2的地址，这个时候目的IP地址会匹配到容器1的第二条路由规则，这条路由规则的Gateway是0.0.0.0，意味着这是一条直连规则，也就是说凡是匹配到这个路由规则的请求，会直接通过eth0网卡，通过二层网络发往目的主机。而要通过二层网络到达容器2，就需要..0.3对应的MAC地址。所以，容器1的网络协议栈就需要通过eth0网卡来发送一个ARP广播，通过IP找到MAC地址。

        所谓ARP（Address Resolution Protocol），就是通过三层IP地址找到二层的MAC地址的协议。这里说到的eth0，就是Veth Pair的一端，另一端则插在了宿主机的docker0网桥上。eth0这样的虚拟网卡插在docker0上，也就意味着eth0变成docker0网桥的“从设备”。从设备会降级成docker0设备的端口，而调用网络协议栈处理数据包的资格全部交给docker0网桥。

        所以，在收到ARP请求之后，docker0就会扮演二层交换机的角色，把ARP广播发给其它插在docker0网桥的虚拟网卡上，这样，..0.3就会收到这个广播，并把其MAC地址返回给容器1。有了这个MAC地址，容器1的eth0的网卡就可以把数据包发送出去。这个数据包会经过Veth Pair在宿主机的另一端vethcf2cc，直接交给docker0。

        docker0转发的过程，就是继续扮演二层交换机，docker0根据数据包的目标MAC地址，在CAM表查到对应的端口为vethad2，然后把数据包发往这个端口。而这个端口，就是容器2的Veth Pair在宿主机的另一端，这样，数据包就进入了容器2的Network Namespace，最终容器2将响应（Ping）返回给容器1。在真实的数据传递中，Linux内核Netfilter/Iptables也会参与其中，这里不再赘述。

        CAM就是交换机通过MAC地址学习维护端口和MAC地址的对应表

        这里介绍的容器间的通信方式就是docker中最常见的bridge模式，当然此外还有host模式、container模式、none模式等，对其它模式有兴趣的可以去阅读相关资料。

        好了，这里不禁问个问题，到目前为止只是单主机内部的容器间通信，那跨主机网络呢？在Docker默认配置下，一台宿主机的docker0网桥是无法和其它宿主机连通的，它们之间没有任何关联，所以这些网桥上的容器，自然就没办法多主机之间互相通信。但是无论怎么变化，道理都是一样的，如果我们创建一个公共的网桥，是不是集群中所有容器都可以通过这个公共网桥去连接？

        当然在正常的情况下，节点与节点的通信往往可以通过NAT的方式，但是，这个在互联网发展的今天，在容器化环境下未必适用。例如在向注册中心注册实例的时候，肯定会携带IP，在正常物理机内的应用当然没有问题，但是容器化环境却未必，容器内的IP很可能就是上文所说的..0.2，多个节点都会存在这个IP，大概率这个IP是冲突的。

        如果我们想避免这个问题，就会携带宿主机的IP和映射的端口去注册。但是这又带来一个问题，即容器内的应用去意识到这是一个容器，而非物理机，当在容器内，应用需要去拿容器所在的物理机的IP，当在容器外，应用需要去拿当前物理机的IP。显然，这并不是一个很好的设计，这需要应用去配合配置。所以，基于此，我们肯定要寻找其他的容器网络解决方案。

        在上图这种容器网络中，我们需要在我们已有的主机网络上，通过软件构建一个覆盖在多个主机之上，且能把所有容器连通的虚拟网络。这种就是Overlay Network（覆盖网络）。

        关于这些具体的网络解决方案，例如Flannel、Calico等，我会在后续篇幅继续陈述。

深入学习docker -- 资源限制Cgroups

       在深入学习 Docker 的过程中，我们探索了如何用 Namespace 实现“伪容器”，但遗憾的是，Namespace 仅能提供一个虚拟环境，无法控制资源使用，甚至可能影响宿主机上的其他进程。为解决这一问题，我们引入了 Cgroups（Linux 控制组）的概念。

       Cgroups 允许限制一个进程组能使用的资源上限，包括 CPU、内存、磁盘、网络等。通过 Cgroups，我们可以更精确地控制进程的资源使用，实现资源隔离和限制。下面，我们将详细探讨如何利用 Cgroups 限制 CPU 使用。

       限制 CPU 使用时，关键参数包括 CPU 配额（cfs_quotaus）和 CPU 股权（cpu.shares）。下面我们将通过实例演示如何实现单个进程 CPU 使用率的限制，并探讨控制组内部资源的分配。

       首先，创建一个 CPU 控制组，然后启动消耗 CPU 的程序。程序运行后，我们观察到 CPU 使用率接近 2 个核心，即大约 %。接着，我们将 CPU 使用率设置为 %，并检查新进程的 CPU 使用率。可见，通过设置 cfs_quotaus 参数，我们成功实现了单个进程 CPU 使用率的限制。

       然而，限制并非仅适用于单个进程。控制组内的子组也影响资源分配。我们通过改变子组的 cpu.shares 参数，调整了资源的分配比例，使进程 CPU 使用率更加均衡或集中。

       在实际应用中，Cgroups 的 v1 和 v2 版本在控制组与资源的关系上有所差异。v1 版本更为传统，v2 版本则试图解决资源分配的局限性。在 Kubernetes 环境中，每个容器都会在 CPUCgroup 子系统中创建一个控制组，并将容器进程写入其中。资源限制如 CPU 和内存，则通过 cfs_quotaus 和 memory.limit_in_bytes 等参数来实现。

       总结而言，Cgroups 为 Docker 中资源管理提供了强大的工具，通过设置合理的参数，我们可以实现进程间资源的隔离和限制，为容器化应用提供更灵活、安全的运行环境。未来我们将继续探索 Docker 中的其他关键技术，如 OverlayFS，以更全面地理解容器化生态。