namespace在docker中的作用(docker容器网络默认桥模式)

大家好，今天来介绍namespace在docker中的作用(docker是干什么的)的问题，以下是渲大师小编对此问题的归纳和整理，感兴趣的来一起看看吧！

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的介绍，请点我点我 。

创建容器，并将宿主机的3306端口绑定到容器的3306端口：docker run -tid –name db -p 3306:3306 mysql

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

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

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

摘抄自陆平的《基于Kubernetes的容器云平台实战》一书的第10章Kubernetes网络

Docker&k8s（一）

​ 容器技术的核心功能，就是通过约束和修改进程的动态表现，从而为其创造出一个“边界” 。对于 Docker 等大多数 Linux 容器来说， Cgroups 技术 是用来制造早派约陆游贺束的主要手段，而 Namespace 技术 则是用来修改进程视图的主要方法。

其实只是 Linux 创建新进程的一个可选参数。我们知道，在 Linux 系统中创建线程的系统调用是 clone()，比如：

​ 这个系统调用就会为我们创建一个新的进程，并且返回它的进程号 pid。而当我们用 clone() 系统调用创建一个新进程时，就可以在参数中指定 CLONE_NEWPID 参数，比如：

​ 这时，新创建的这个进程将会“看到”一个全新的进程空间，在这个进程空间里，它的 PID 是 1。之所以说“看到”，是因为这只是一个“障眼法”，在宿主机真实的进程空间里，这个进程的 PID 还是真实的数值，比如 100。

​ 而 除了 PID Namespace，Linux 操作系统还提供了 Mount、UTS、IPC、Network 和 User 这些 Namespace，用来对各种不同的进程上下文进行“障眼法”操作。

​ 比如，Mount Namespace，用于让被隔离进程只看到当前 Namespace 里的挂载点信息；Network Namespace，用于让被隔离进程看到当前 Namespace 里的网络设备和配置。

​ 这，就是 Linux 容器最基本的实现原理了。所以说，容器，其实是一种特殊的进程而已。Namespace 技术实际上修改了应用进程看待整个计算机“视图”，即它的“视线”被操作系统做了限制，只能“看到”某些指定的内容 。

优势：更加的轻量且没有损耗资源。弊端：隔离不彻底

Cgroups（Linux Control Group） 就是 Linux 内核中用来为进程设置资源限制的一个重要功能。它最主要的作用，就是限制一个进程组能够使用的资源上限，包括 CPU、内存、磁盘、网络带宽等等

Cgroups 给用户暴露出来的操作接口是文件系统

比如，向 container 组里的 cfs_quota 文件写入 20 ms（20000 us）：

意味着在每 100 ms 的时间里，被该控制组限制的进程只能使用 20 ms 的 CPU 时间，也就是说这个进程只能使用到 20% 的 CPU 带宽。

把被限制的进程的 PID 写入 container 组里的 tasks 文件，上面的设置就会对该进程生效了：

除 CPU 子系统外，Cgroups 的每一项子系统都有其独有的资源限制能力，比如：

Linux Cgroups 的设计还是比较易用的，简单粗暴地理解呢，它就是一个子系统目录加上一组资源限制文件的组合。容器是一个“单进程”模型。

​ Mount Namespace 修改的，是容器进程对文件系统“挂载点”的认知。Mount Namespace 跟其他 Namespace 的使用略有不同的地方：它对容器进程视图的改变，一定是伴随着挂载操作（mount）才能生效。实际上，Mount Namespace 正是基于对 chroot 的不断改良才被发明出来的，它也是 Linux 操作系统里的第一个 Namespace。

​ 而这个挂载在容器根目录上、用来为容器进程提供隔离后执行环境的文件系统，就是所谓的“容器镜像”。它还有一个更为专业的名字，叫作：rootfs（根文磨肢件系统）。

对 Docker 项目来说，它最核心的原理实际上就是为待创建的用户进程：

​ rootfs 只是一个操作系统所包含的文件、配置和目录，并不包括操作系统内核。在 Linux 操作系统中，这两部分是分开存放的，操作系统只有在开机启动时才会加载指定版本的内核镜像。

容器的 rootfs 由如下图所示的三部分组成：

第一部分，只读层 ：它是这个容器的 rootfs 最下面的五层，对应的正是 ubuntu:latest 镜像的五层，挂载方式都是只读的（ro+wh，即 readonly+whiteout）

这些层，都以增量的方式分别包含了 Ubuntu 操作系统的一部分

第二部分，可读写层。 (rw)

​ 在没有写入文件之前，这个目录是空的。而一旦在容器里做了写操作，你修改产生的内容就会以增量的方式出现在这个层中。如果要删除AuFS 会在可读写层创建一个 whiteout 文件，把只读层里的文件“遮挡”起来。

专门用来存放你修改 rootfs 后产生的增量，原先的只读层里的内容则不会有任何变化

第三部分，Init 层。

​ 有些文件本来属于只读的 Ubuntu 镜像的一部分，但是用户往往需要在启动容器时写入一些指定的值比如 hostname，所以就需要在可读写层对它们进行修改。可是，这些修改往往只对当前的容器有效，我们并不希望执行 docker commit 时，把这些信息连同可读写层一起提交掉。所以，Docker 做法是，在修改了这些文件之后，以一个单独的层挂载了出来。而用户执行 docker commit 只会提交可读写层，所以是不包含这些内容的。可以参考git ignore的思想。

Dockerfile ：

ENTRYPOINT：entrypoint才是正统地用于定义容器启动以后的执行体的，其实我们从名字也可以理解，这个是容器的“入口”。

CMD：cmd给出的是一个容器的默认的可执行体。也就是容器启动以后，默认的执行的命令。如果docker run没有指定任何的执行命令或者dockerfile里面也没有entrypoint，那么，就会使用cmd指定的默认的执行命令执行如果你不额外指定，那么就执行cmd的命令，否则呢？只要你指定了，那么就不会执行cmd，也就是cmd会被覆盖。

docker commit，实际上就是在容器运行起来后，把最上层的“可读写层”，加上原先容器镜像的只读层，打包组成了一个新的镜像。当然，下面这些只读层在宿主机上是共享的，不会占用额外的空间。

而由于使用了联合文件系统，你在容器里对镜像 rootfs 所做的任何修改，都会被操作系统先复制到这个可读写层，然后再修改。这就是所谓的：Copy-on-Write。

​ 一个进程的每种 Linux Namespace，都在它对应的 /proc/[进程号]/ns 下有一个对应的虚拟文件，并且链接到一个真实的 Namespace 文件上。

​ 这也就意味着：一个进程，可以选择加入到某个进程已有的 Namespace 当中，从而达到“进入”这个进程所在容器的目的，这正是 docker exec 的实现原理。

Volume 机制，允许你将宿主机上指定的目录或者文件，挂载到容器里面进行读取和修改操作。

​ 当容器进程被创建之后，尽管开启了 Mount Namespace，但是在它执行 chroot（或者 pivot_root）之前，容器进程一直可以看到宿主机上的整个文件系统。所以在 rootfs 准备好之后，在执行 chroot 之前，把 Volume 指定的宿主机目录（比如 /home 目录），挂载到指定的容器目录（比如 /test 目录）在宿主机上对应的目录（即 /var/lib/docker/aufs/mnt/[可读写层 ID]/test）上，这个 Volume 的挂载工作就完成了。

​ 由于执行这个挂载操作时，“容器进程”已经创建了，也就意味着此时 Mount Namespace 已经开启了。所以，这个挂载事件只在这个容器里可见。你在宿主机上，是看不见容器内部的这个挂载点的。这就 保证了容器的隔离性不会被 Volume 打破 。

​ 而这里要使用到的挂载技术，就是 Linux 的 绑定挂载（bind mount）机制 。它的主要作用就是，允许你将一个目录或者文件，而不是整个设备，挂载到一个指定的目录上。并且，这时你在该挂载点上进行的任何操作，只是发生在被挂载的目录或者文件上，而原挂载点的内容则会被隐藏起来且不受影响。绑定挂载实际上是一个 inode 替换的过程。在 Linux 操作系统中，inode 可以理解为存放文件内容的“对象”，而 dentry，也叫目录项，就是访问这个 inode 所使用的“指针”。

​ 所以，在一个正确的时机，进行一次绑定挂载，Docker 就可以成功地将一个宿主机上的目录或文件，不动声色地挂载到容器中。

docker有用user隔离吗

单单就Docker来说，安全性可以概括为两点：丛源弊
1. 不会对主机造成影响
2. 不会对其他容器造成影响
所以安全性问题90%以上可以归结为隔离性问题。而Docker的安全问题本质上就是容器技术的安全性问题，这包括共用内核问题以及Namespace还不够完善的限制：
其实传统虚拟机系统也绝非100%安裂毁全，只需攻破Hypervisor便足以令整个虚拟机毁于一旦，问题是有谁能随随便便就攻破吗？如上所述，Docker的隔离性主要运用Namespace 技术。传统上Linux中的PID是唯一且独立的，在正常情况下，用户不会看见重复的PID。然而在Docker采用了Namespace，从而令相同的PID可于不同的Namespace中独立存在。举个例子，A Container 之中PID=1是A程序，而B Container之中的PID=1同样可以是A程序。虽然Docker可透过Namespace的方式分隔出看似是独立的空间，然而Linux内核（Kernel）却不能Namespace，所以即使有多个Container，所有的system call其实都是通过主机的内核处理，这便为Docker留下了不可否认的安全问题。
传统的虚拟机同样地很多操作都需要通过内核处理，但这只是虚拟机的内核，并非宿主主机内核。因此万一出现问题时，最多只影响到虚拟系统本身。当然你可以说黑客可以先Hack虚拟机的内核，然后再找寻Hypervisor的漏洞同时不能被发现，之后再攻破SELinux，然后向主机内核发动攻击。文字表达起来渗族都嫌繁复，更何况实际执行？所以Docker是很好用，但在迁移业务系统至其上时，请务必注意安全性！

Docker swarm中的LB和服务发现详解

Docker 提供了 overlay driver，使用户可以创建基于 VxLAN 的 overlay 网络。VxLAN 可将二层数据封装到 UDP 进行传输，VxLAN 提供与 VLAN 相同的以太网二层服务，但是拥有更强的扩展性和灵活性。linux下是使用了net namespace来和喊隔离docker创建的overlay网络。

Docker 网络模型如下：

一个Sandbox包含了一个容器网络栈的配置。其中包括了对容器的网卡，路由表以及对DNS设置的管理。通常，一个Sandbox的实现可以是一个Linux Network Namespace，一个FreeBSD Jail或者其他类似的东西。一个Sandbox可以包含多个处于不同Network的Endpoint。

Endpoint将一个Sandbox加入一个Network。Endpoint的实现可以是一个veth对，一个Open vSwitch internal port或者其他类似的东西。一个Endpoint只能属于一个Network和一个Sandbox。

Network是一个能够互相通信的Endpoint的唤渣野集合。Network的实现可以是一个Linux网桥，一个VLAN等等。

上图展示了task1.client请求两个不同资源dns返回的不同结果

环境：
swarm-a(manager node)：10.10.8.92

swarm-b(work node)：10.10.8.93

swarm-c(work node)：10.10.8.94

在docker swarm集群创建的开始，docker 会给每台host创建除了docker0以外的两个网络，分是bridge类型(docker_gwbridge网桥)和overlay类型(ingress)的网络，以及一个过度的命名空间ingress_sbox，我们可以使用如下命令自建overlay网络，结果如下：

docker network create –driver overlay mynet （后续会有用到）

注意1：要是想看到容器创建的两个Net Namespace需要执行
ln -s /var/run/docker/netns /var/run/netns

1)、部署一个service使用默认的ingress网络：

docker service create –name web_ingress_lb –replicas=2 –publish 8090:80 httpd

2)、Ingress Load Balancing实现方式：

这样一来即使梁升容器的副本没有落到host上我们仍可以通过这种转发方式来访问到服务。这应该就是routing mesh吧！

1)、部署一个service使用我们自己创建的mynet网络：

docker service create –name web_mynet –replicas=2 –network=mynet –publish 8080:80 httpd
部署的两个容器分别处在a和c节点上：

结合例子如下：

2)、查看web_mynet.1容器和mynet网络命名空间的网卡情况：

3)、查看web_mynet.1容器和ingressingress_sbox网络命名空间的网卡对应情况：

可以看mynet网络下vlan-id 为4097，ingress网络空间同样操作可以得到vlan-id为4096

swarm-c节点上的情况也是差不多就不操作了，好了我们来画下网络连接的大致图：

可以看到这里ingress_sbox和创建容器的ns共用一个ingress网络空间。

4)、 Internal Load Balancing实现方式：

有两种实现方式dns rr和vip形式，在dns rr 的情况下可能会存在一定是的问题，当容器重启后dns的解析会存在一定时间的延迟。vip则是由vip+内核ipvs来实现。docker swarm默认使用的是vip，这里就以vip的形式来解析。（想要了解dns rr的可以看文章后面的参考链接都是大牛写的）

VIP形式下的流量路径：

操作流程如下：
通过busybox服务做dns解析，可以发现该服务后端挂载的容器和该服务对应的
VIP地址。web_mynet服务对应的VIP为10.0.0.6。

在Internal Load Balancing也就是文中我们自建的mynet overlay网络中，我们会看到创
建的service会同时应用到两个网络环境里面去，为何要这样呢？

原因是swarm自带ingress不具备有服务发现的功能，而容器的生命周期又是不固定的，
service每次的消亡和启用都会改变容器内部的ip地址以及vip地址，那么集群中服务之间
的通信势必会造成问题，这里有人会说，要使多个service之间能够互相通信可以将所有
的service都publish出去，然后通过routing mesh 访问，这样是没错也能行得通，但是存
在一个缺点，那就是不安全，我们仅仅只需要的是将最终提供服务的端口publish即可。
那么不publish所有的service需要做到以下几点：

这里我理解的是ingress是单单提供LB实现routing mesh而mynet是服务发现和LB的结合

所以上文中Internal Load Balancing中的数据流应该分成两种情景如下：

1、当一个外部请求到主机端口8080之后， 数据包的流向如下所示：
主机端口8080 => Ingress-sbox-VIP:8080 => 容器Ingress-sbox => IPVS分发到containers。

2、处于 同mynet网络的service内部通信时：
处于 同mynet网络的test service(busybox容器)发起访问web_mynet域名的请求=>请求转发到docker engine内置的DNS解析web_mynet的vip=>web_mynet(容器)在其ns中将
VIP数据包打上标签，并通过ipvs来负载到后端对应的容器=>数据包通过vip地址路由到
mynet的ns，由mynet中的fdb来做转发走tunnel出去。

https://zhuanlan.zhihu.com/p/25954203

https://www.jianshu.com/p/4433f4c70cf0

https://docs.docker.com/network/overlay/

http://julyerr.club/2018/03/20/docker-swarm/

Docker是如何实现隔离的

Docker是如何实现隔离的

1、进程隔离
在容器内部都只能看到自己内部的进程，那 Docker 是如何做到的呢？它其实是借助了Linux内核的Namespace技术来实现的
CLONE_NEWPID会让执行的程序内部重新编号PID，也就是从1号进程开始
CLONE_NEWNS 会克隆新的挂载环境出来，通过在子进程内部重新挂载 proc文件夹，可以屏蔽父进程的进程信息。
在容器内部都只能看到自己判山内部的进程
这就是容器隔离进程的基本原理了，Docker主要就是借助 Linux 内核技术Namespace来做到隔离的，其实包括文件的慎销隔离，资源的隔离都是在新的命名空间下通过mount挂载的方式来隔离的。

Docker 技术 完全是依赖 Linux 内核特性 Namespace 和Cgroup 技术来实现的，本质来说：你运行在容器的应用在宿主机来说还是一个普通的进程，还是直接由宿主机来调度的，相对来说，性能的损耗 就很少，这也是 Docker 技术的掘孝中重要优势。

Docker容器是共用宿主机操作系统的，docker image里没有内核，只有shell。
/proc/[pid]/ns 目录下包含进程所属的 namespace 信息，使用以下命令可查看当前进程所属的 namespace 信息：
$ ll /proc/$$/ns