首页 文章 精选 留言 我的

为什么构建容器需要 Namespace

2021-03-21 575

Namespace 概念

Namespace 是 Linux 内核的一个特性，该特性可以实现在同一主机系统中，对进程 ID、主机名、用户 ID、文件名、网络和进程间通信等资源的隔离。Docker 利用 Linux 内核的 Namespace 特性，实现了每个容器的资源相互隔离，从而保证容器内部只能访问到自己 Namespace 的资源。

目前 Linux 内核中提供了 8 种类型的 Namespace：

各种 Namespace 的作用

Mount Namespace

Mount Namespace 是 Linux 内核实现的第一个 Namespace，从内核 2.4.19 版本开始加入。它可以用来隔离不同的进程或者进程组看到的挂载点。通俗地说，就是可以实现在不同的进程中看到不同的挂载目录。使用 Mount Namespace 可以实现容器内只能看到自己的挂载信息，在容器内的挂载操作不会影响主机的挂载目录。

下面我们通过一个实例来演示下 Mount Namespace。在演示之前，我们先来认识一个命令行工具 unshare。unshare 是 util-linux 工具包中的一个工具，CentOS 7 系统默认已经集成了该工具，使用 unshare 命令可以实现创建并访问不同类型的 Namespace。

首先我们使用以下命令创建一个 bash 进程并且新建一个 Mount Namespace：

#新建一个 Mount Namespace
root@docker-demo ~]# unshare --mount --fork /bin/bash

执行完上述命令后，这时我们已经在主机上创建了一个新的 Mount Namespace，并且当前命令行窗口加入了新创建的 Mount Namespace。下面我通过一个例子来验证下，在独立的 Mount Namespace 内创建挂载目录是不影响主机的挂载目录的。

然后在 /tmp 目录下创建一个目录，创建好目录后使用 mount 命令挂载一个 tmpfs 类型的目录：

[root@docker-demo ~]# mkdir /tmp/tmpfs
[root@docker-demo ~]# mount -t tmpfs -o size=20m tmpfs /tmp/tmpfs

然后使用 df 命令查看一下已挂载的目录信息：

[root@docker-demo ~]# df -h
文件系统                 容量  已用  可用 已用% 挂载点
/dev/mapper/centos-root   50G   15G   36G   29% /
devtmpfs                 3.9G     0  3.9G    0% /dev
tmpfs                    3.9G     0  3.9G    0% /dev/shm
tmpfs                    3.9G     0  3.9G    0% /sys/fs/cgroup
tmpfs                    3.9G  8.9M  3.9G    1% /run
tmpfs                    797M  8.0K  797M    1% /run/user/42
tmpfs                    797M     0  797M    0% /run/user/0
/dev/sda1               1014M  222M  793M   22% /boot
/dev/mapper/centos-home  142G   40M  142G    1% /home
tmpfs                     20M     0   20M    0% /tmp/tmpfs  #刚刚挂载的目录

可以看到 /tmp/tmpfs 目录已经被正确挂载。为了验证主机上并没有挂载此目录，我们新打开一个命令行窗口，同样执行 df 命令查看主机的挂载信息：

root@docker-demo ~]# df -hT
文件系统                类型      容量  已用  可用 已用% 挂载点
devtmpfs                devtmpfs  3.9G     0  3.9G    0% /dev
tmpfs                   tmpfs     3.9G     0  3.9G    0% /dev/shm
tmpfs                   tmpfs     3.9G  9.0M  3.9G    1% /run
tmpfs                   tmpfs     3.9G     0  3.9G    0% /sys/fs/cgroup
/dev/mapper/centos-root xfs        50G   15G   36G   29% /
/dev/sda1               xfs      1014M  222M  793M   22% /boot
/dev/mapper/centos-home xfs       142G   40M  142G    1% /home
tmpfs                   tmpfs     797M  8.0K  797M    1% /run/user/42
tmpfs                   tmpfs     797M     0  797M    0% /run/user/0

通过上面输出可以看到主机上并没有挂载 /tmp/tmpfs，可见我们独立的 Mount Namespace 中执行 mount 操作并不会影响主机。

为了进一步验证我们的想法，我们继续在当前命令行窗口查看一下当前进程的 Namespace 信息，命令如下：

[root@docker-demo ~]# ls -l /proc/self/ns/
总用量 0
lrwxrwxrwx. 1 root root 0 3月  21 19:58 cgroup -> cgroup:[4026531835]
lrwxrwxrwx. 1 root root 0 3月  21 19:58 ipc -> ipc:[4026531839]
lrwxrwxrwx. 1 root root 0 3月  21 19:58 mnt -> mnt:[4026532670]
lrwxrwxrwx. 1 root root 0 3月  21 19:58 net -> net:[4026531992]
lrwxrwxrwx. 1 root root 0 3月  21 19:58 pid -> pid:[4026531836]
lrwxrwxrwx. 1 root root 0 3月  21 19:58 pid_for_children -> pid:[4026531836]
lrwxrwxrwx. 1 root root 0 3月  21 19:58 time -> time:[4026531834]
lrwxrwxrwx. 1 root root 0 3月  21 19:58 time_for_children -> time:[4026531834]
lrwxrwxrwx. 1 root root 0 3月  21 19:58 user -> user:[4026531837]
lrwxrwxrwx. 1 root root 0 3月  21 19:58 uts -> uts:[4026531838]

然后新打开一个命令行窗口，使用相同的命令查看一下主机上的 Namespace 信息：

[root@docker-demo ~]#  ls -l /proc/self/ns/
总用量 0
lrwxrwxrwx. 1 root root 0 3月  21 19:58 cgroup -> cgroup:[4026531835]
lrwxrwxrwx. 1 root root 0 3月  21 19:58 ipc -> ipc:[4026531839]
lrwxrwxrwx. 1 root root 0 3月  21 19:58 mnt -> mnt:[4026531840]
lrwxrwxrwx. 1 root root 0 3月  21 19:58 net -> net:[4026531992]
lrwxrwxrwx. 1 root root 0 3月  21 19:58 pid -> pid:[4026531836]
lrwxrwxrwx. 1 root root 0 3月  21 19:58 pid_for_children -> pid:[4026531836]
lrwxrwxrwx. 1 root root 0 3月  21 19:58 time -> time:[4026531834]
lrwxrwxrwx. 1 root root 0 3月  21 19:58 time_for_children -> time:[4026531834]
lrwxrwxrwx. 1 root root 0 3月  21 19:58 user -> user:[4026531837]
lrwxrwxrwx. 1 root root 0 3月  21 19:58 uts -> uts:[4026531838]

通过对比两次命令的输出结果，我们可以看到，除了 Mount Namespace 的 ID 值不一样外，其他Namespace 的 ID 值均一致。

通过以上结果我们可以得出结论，使用 unshare 命令可以新建 Mount Namespace，并且在新建的 Mount Namespace 内 mount 是和外部完全隔离的。

PID Namespace

PID Namespace 的作用是用来隔离进程。在不同的 PID Namespace 中，进程可以拥有相同的 PID 号，利用 PID Namespace 可以实现每个容器的主进程为 1 号进程，而容器内的进程在主机上却拥有不同的PID。例如一个进程在主机上 PID 为 122，使用 PID Namespace 可以实现该进程在容器内看到的 PID 为 1。

下面我们通过一个实例来演示下 PID Namespace的作用。首先我们使用以下命令创建一个 bash 进程，并且新建一个 PID Namespace：

[root@docker-demo ~]# unshare --pid --fork --mount-proc /bin/bash
[root@docker-demo ~]#

执行完上述命令后，我们在主机上创建了一个新的 PID Namespace，并且当前命令行窗口加入了新创建的 PID Namespace。在当前的命令行窗口使用 ps aux 命令查看一下进程信息：

[root@docker-demo ~]# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  1.7  0.0 116752  4884 pts/0    S    19:59   0:00 /bin/bash
root        31  7.0  0.0 151124  3872 pts/0    R+   19:59   0:00 ps aux

通过上述命令输出结果可以看到当前 Namespace 下 bash 为 1 号进程，而且我们也看不到主机上的其他进程信息。

UTS Namespace

UTS Namespace 主要是用来隔离主机名的，它允许每个 UTS Namespace 拥有一个独立的主机名。例如我们的主机名称为 docker，使用 UTS Namespace 可以实现在容器内的主机名称为 lagoudocker 或者其他任意自定义主机名。

同样我们通过一个实例来验证下 UTS Namespace 的作用，首先我们使用 unshare 命令来创建一个 UTS Namespace：

[root@docker-demo ~]# unshare --uts --fork /bin/bash
[root@docker-demo ~]#

创建好 UTS Namespace 后，当前命令行窗口已经处于一个独立的 UTS Namespace 中，下面我们使用 hostname 命令（hostname 可以用来查看主机名称）设置一下主机名：

[root@docker-demo ~]# hostname -b lagoudocker

#查看更改后的主机名
[root@docker-demo ~]# hostname
lagoudocker

通过上面命令的输出，我们可以看到当前UTS Namespace 内的主机名已经被修改为 lagoudocker。然后我们新打开一个命令行窗口，使用相同的命令查看一下主机的 hostname：

[root@docker-demo ~]# hostname
docker-demo

可以看到主机的名称仍然为 docker-demo，并没有被修改。由此，可以验证 UTS Namespace 可以用来隔离主机名。

IPC Namespace

IPC Namespace 主要是用来隔离进程间通信的。例如 PID Namespace 和 IPC Namespace 一起使用可以实现同一 IPC Namespace 内的进程彼此可以通信，不同 IPC Namespace 的进程却不能通信。

同样我们通过一个实例来验证下IPC Namespace的作用，首先我们使用 unshare 命令来创建一个 IPC Namespace：

[root@docker-demo ~]# unshare --ipc --fork /bin/bash
[root@docker-demo ~]#

下面我们需要借助两个命令来实现对 IPC Namespace 的验证。

  • ipcs -q 命令：用来查看系统间通信队列列表。
  • ipcmk -Q 命令：用来创建系统间通信队列。

我们首先使用 ipcs -q 命令查看一下当前 IPC Namespace 下的系统通信队列列表：

[root@docker-demo ~]# ipcs -q

--------- 消息队列 -----------
键        msqid      拥有者  权限     已用字节数 消息

由上可以看到当前无任何系统通信队列，然后我们使用 ipcmk -Q 命令创建一个系统通信队列：

[root@docker-demo ~]# ipcmk -Q
消息队列 id：0

再次使用 ipcs -q 命令查看当前 IPC Namespace 下的系统通信队列列表：

[root@docker-demo ~]# ipcs -q

--------- 消息队列 -----------
键        msqid      拥有者  权限     已用字节数 消息
0x91ce1a3d 0          root       644        0            0

可以看到我们已经成功创建了一个系统通信队列。然后我们新打开一个命令行窗口，使用ipcs -q 命令查看一下主机的系统通信队列：

[root@docker-demo ~]# ipcs -q

--------- 消息队列 -----------
键        msqid      拥有者  权限     已用字节数 消息

通过上面的实验，可以发现，在单独的 IPC Namespace 内创建的系统通信队列在主机上无法看到。即 IPC Namespace 实现了系统通信队列的隔离。

User Namespace

User Namespace 主要是用来隔离用户和用户组的。一个比较典型的应用场景就是在主机上以非 root 用户运行的进程可以在一个单独的 User Namespace 中映射成 root 用户。使用 User Namespace 可以实现进程在容器内拥有 root 权限，而在主机上却只是普通用户。User Namesapce 的创建是可以不使用 root 权限的，下面我们以普通用户的身份创建一个 User Namespace，命令如下：

# 创建并切换到普通用户
[root@docker-demo ~]# su - chengzw
[chengzw@docker-demo ~]$ id
uid=1002(chengzw) gid=1004(chengzw) groups=1004(chengzw) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
# 创建 User Namespace
[chengzw@docker-demo ~]$ unshare --user -r /bin/bash

然后执行 id 命令查看一下当前的用户信息：

[root@docker-demo ~]# id
uid=0(root) gid=0(root) 组=0(root) 环境=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

通过上面的输出可以看到我们在新的 User Namespace 内已经是 root 用户了。下面我们使用只有主机 root 用户才可以执行的 reboot 命令来验证一下，在当前命令行窗口执行 reboot 命令：

[root@docker-demo ~]# reboot
Failed to open /dev/initctl: Permission denied
Failed to talk to init daemon.

查看当前 User Namespace 所在的进程：

[root@docker-demo ~]# echo $$
2157

在宿主机上查看该进程对应的用户，可以看到实际上在宿主机上是 chengzw 用户：

[root@docker-demo ~]# ps -ef  | grep 2157
chengzw   2157  2092  0 20:41 pts/0    00:00:00 /bin/bash

可以看到，我们在新创建的 User Namespace 内虽然是 root 用户，但是并没有权限执行 reboot 命令。这说明在隔离的 User Namespace 中，并不能获取到主机的 root 权限，也就是说 User Namespace 实现了用户和用户组的隔离。

Net Namespace

Net Namespace 是用来隔离网络设备、IP 地址和端口等信息的。Net Namespace 可以让每个进程拥有自己独立的 IP 地址，端口和网卡信息。例如主机 IP 地址为 192.168.1.41 ，容器内可以设置独立的 IP 地址为 172.16.1.2。

同样用实例验证，我们首先使用 ip addr 命令查看一下主机上的网络信息：

[root@docker-demo ~]$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:50:56:9b:2d:90 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.41/24 brd 192.168.1.255 scope global ens192
       valid_lft forever preferred_lft forever
    inet6 fe80::2556:f369:b4e7:fb64/64 scope link tentative dadfailed
       valid_lft forever preferred_lft forever
    inet6 fe80::6b8d:29f7:a5fe:dbee/64 scope link tentative dadfailed
       valid_lft forever preferred_lft forever
    inet6 fe80::f387:57a3:4975:d8f2/64 scope link tentative dadfailed
       valid_lft forever preferred_lft forever

然后我们使用以下命令创建一个 Net Namespace：

[root@docker-demo ~]# unshare --net --fork /bin/bash

同样的我们使用 ip addr 命令查看一下网络信息：

[root@docker-demo ~]# ip addr
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

可以看到，宿主机上有 lo、ens192 等网络设备，而我们新建的 Net Namespace 内则与主机上的网络设备不同。我们可以在 Net Namespace 中新增网卡并配置 IP：

[root@docker-demo ~]# ip link add eth0 type dummy
[root@docker-demo ~]# ip addr add 172.16.1.2/24 dev 
[root@docker-demo ~]# ip addr
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN qlen 1000
    link/ether e6:b7:92:d4:cc:ae brd ff:ff:ff:ff:ff:ff
    inet 172.16.1.2/24 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::e4b7:92ff:fed4:ccae/64 scope link
       valid_lft forever preferred_lft forever

Time Namespace

首先查看宿主机的时间，目前是3月21号：

[root@docker-demo ~]# date
2021年 03月 21日 星期日 21:02:38 CST

启动一个 centos 容器，查看时间和宿主机一致（UTC + 8 = CST）：

[root@docker-demo ~]# docker exec -it centos bash
[root@a695de10917d /]# date
Sun Mar 21 13:02:46 UTC 2021

尝试在容器中修改时间，提示权限不够：

[root@a695de10917d /]# date -s 05/28
date: cannot set date: Operation not permitted

在启动容器的时候，加上--cap-add SYS_TIME参数，在容器内将时间修改成3月20号：

root@docker-demo ~]# docker run -it --cap-add SYS_TIME --name centos centos /bin/bash

[root@e7b61aba6222 /]# date -s 03/20
Sat Mar 20 00:00:00 UTC 2021
[root@e7b61aba6222 /]# date
Sat Mar 20 00:00:01 UTC 2021

# 退出容器
[root@e7b61aba6222 /]# exit
exit

在宿主机上查看时间发现也改成3月20号了：

[root@docker-demo ~]# date
2021年 03月 20日 星期六 08:00:07 CST

--cap-add SYS_TIME是为了将宿主机的内核时间挂载进来与容器共享，因此容器时间更改了，宿主机时间也会跟着更改。

为什么 Docker 需要 Namespace？

Linux 内核从 2002 年 2.4.19 版本开始加入了 Mount Namespace，而直到内核 3.8 版本加入了 User Namespace 才为容器提供了足够的支持功能。

当 Docker 新建一个容器时， 它会创建这六种 Namespace，然后将容器中的进程加入这些 Namespace 之中，使得 Docker 容器中的进程只能看到当前 Namespace 中的系统资源。

正是由于 Docker 使用了 Linux 的这些 Namespace 技术，才实现了 Docker 容器的隔离，可以说没有 Namespace，就没有 Docker 容器。

Docker exec 原理

在了解了 Linux Namespace 的隔离机制后，你应该会很自然地想到一个问题：docker exec 是怎么做到进入容器里的呢？

实际上，Linux Namespace 创建的隔离空间虽然看不见摸不着，但一个进程的 Namespace 信息在宿主机上是确确实实存在的，并且是以一个文件的方式存在。

首先创建一个容器：

$ docker run -p 4000:80 helloworld python app.py

通过如下指令，你可以看到当前正在运行的 Docker 容器的进程号（PID）是 25686：

$ docker inspect --format '{{ .State.Pid }}' 4ddf4638572d25686

这时，你可以通过查看宿主机的 proc 文件，看到这个 25686 进程的所有 Namespace 对应的文件：

$ ls -l  /proc/25686/ns
total 0
lrwxrwxrwx 1 root root 0 Aug 13 14:05 cgroup -> cgroup:[4026531835]
lrwxrwxrwx 1 root root 0 Aug 13 14:05 ipc -> ipc:[4026532278]
lrwxrwxrwx 1 root root 0 Aug 13 14:05 mnt -> mnt:[4026532276]
lrwxrwxrwx 1 root root 0 Aug 13 14:05 net -> net:[4026532281]
lrwxrwxrwx 1 root root 0 Aug 13 14:05 pid -> pid:[4026532279]
lrwxrwxrwx 1 root root 0 Aug 13 14:05 pid_for_children -> pid:[4026532279]
lrwxrwxrwx 1 root root 0 Aug 13 14:05 user -> user:[4026531837]
lrwxrwxrwx 1 root root 0 Aug 13 14:05 uts -> uts:[4026532277]

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

有了这样一个可以“hold 住”所有 Linux Namespace 的文件，我们就可以对 Namespace 做一些很有意义事情了，比如：加入到一个已经存在的 Namespace 当中。

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

而这个操作所依赖的，乃是一个名叫 setns() 的 Linux 系统调用。它的调用方法，我可以用如下一段小程序为你说明：


#define _GNU_SOURCE
#include <fcntl.h>
#include <sched.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>

#define errExit(msg) do { perror(msg); exit(EXIT_FAILURE);} while (0)

int main(int argc, char *argv[]) {
    int fd;
    
    fd = open(argv[1], O_RDONLY);
    if (setns(fd, 0) == -1) {
        errExit("setns");
    }
    execvp(argv[2], &argv[2]); 
    errExit("execvp");
}

这段代码功能非常简单：它一共接收两个参数，第一个参数是 argv[1]，即当前进程要加入的 Namespace 文件的路径，比如 /proc/25686/ns/net；而第二个参数，则是你要在这个 Namespace 里运行的进程，比如 /bin/bash。

这段代码的核心操作，则是通过 open() 系统调用打开了指定的 Namespace 文件，并把这个文件的描述符 fd 交给 setns() 使用。在 setns() 执行后，当前进程就加入了这个文件对应的 Linux Namespace 当中了。

现在，你可以编译执行一下这个程序，加入到容器进程（PID=25686）的 Network Namespace 中：


$ gcc -o set_ns set_ns.c 
$ ./set_ns /proc/25686/ns/net /bin/bash 
$ ifconfig
eth0      Link encap:Ethernet  HWaddr 02:42:ac:11:00:02  
          inet addr:172.17.0.2  Bcast:0.0.0.0  Mask:255.255.0.0
          inet6 addr: fe80::42:acff:fe11:2/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:12 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
     collisions:0 txqueuelen:0 
          RX bytes:976 (976.0 B)  TX bytes:796 (796.0 B)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

正如上所示，当我们执行 ifconfig 命令查看网络设备时，我会发现能看到的网卡“变少”了：只有两个。而我的宿主机则至少有四个网卡。这是怎么回事呢？

实际上，在 setns() 之后我看到的这两个网卡，正是我在前面启动的 Docker 容器里的网卡。也就是说，我新创建的这个 /bin/bash 进程，由于加入了该容器进程（PID=25686）的 Network Namepace，它看到的网络设备与这个容器里是一样的，即：/bin/bash 进程的网络设备视图，也被修改了。

而一旦一个进程加入到了另一个 Namespace 当中，在宿主机的 Namespace 文件上，也会有所体现。

在宿主机上，你可以用 ps 指令找到这个 set_ns 程序执行的 /bin/bash 进程，其真实的 PID 是 28499：

# 在宿主机上
ps aux | grep /bin/bash
root     28499  0.0  0.0 19944  3612 pts/0    S    14:15   0:00 /bin/bash

这时，如果查看一下这个 PID=28499 的进程的 Namespace，你就会发现这样一个事实：


$ ls -l /proc/28499/ns/net
lrwxrwxrwx 1 root root 0 Aug 13 14:18 /proc/28499/ns/net -> net:[4026532281]

$ ls -l  /proc/25686/ns/net
lrwxrwxrwx 1 root root 0 Aug 13 14:05 /proc/25686/ns/net -> net:[4026532281]

在 /proc/[PID]/ns/net 目录下，这个 PID=28499 进程，与我们前面的 Docker 容器进程（PID=25686）指向的 Network Namespace 文件完全一样。这说明这两个进程，共享了这个名叫 net:[4026532281]的 Network Namespace。

此外，Docker 还专门提供了一个参数，可以让你启动一个容器并“加入”到另一个容器的 Network Namespace 里，这个参数就是 -net，比如:


$ docker run -it --net container:4ddf4638572d busybox ifconfig

这样，我们新启动的这个容器，就会直接加入到 ID=4ddf4638572d 的容器，也就是我们前面的创建的应用容器（PID=25686）的 Network Namespace 中。所以，这里 ifconfig 返回的网卡信息，跟我前面那个小程序返回的结果一模一样，你也可以尝试一下。

而如果我指定–net=host，就意味着这个容器不会为进程启用 Network Namespace。这就意味着，这个容器拆除了 Network Namespace 的“隔离墙”，所以，它会和宿主机上的其他普通进程一样，直接共享宿主机的网络栈。这就为容器直接操作和使用宿主机网络提供了一个渠道。

欢迎关注

上一篇 下一篇
优秀的个人博客,低调大师

微信关注我们

原文链接：https://my.oschina.net/u/4923278/blog/4993392

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

JVM 调优系列 2：GC 如何判断对象是否为垃圾，三色标记算法应用原理及存在的问题？

文章原标题：JVM 调优系列 2：GC 如何判断对象是否为垃圾，三色标记算法应用原理及存在的问题，由此 GC 的制定机制是什么？不同 GC age 如何取值？ 文章目录 前言 一、如何判断一个对象是否为垃圾？ 1.1、reference count（引用计数） 1.2、reference count（引用计数）存在的问题 二、Root Searching（根可达算法或根搜索算法） 2.1、Root Searching 释义 2.2、根对象（root）的类型 三、三色标记算法原理与存在的问题 3.1、Mark-Sweep（标记清除） 3.1.1、Mark-Sweep（标记清除）应用原理 3.1.2、存在问题-内存碎片化 3.2、Copying（拷贝） 3.2.1、Copying（拷贝）应用原理 3.2.2、存在问题-浪费空间 3.3、Mark-Compact（标记压缩或标记整理） 3.3.1、Mark-Compact（标记压缩或标记整理）应用原理 3.3.2、存在的问题-效率过低 四、垃圾回收器的制定原则 4.1、综合三种算法的 GC 4.2、新生代里面对象的 age 要取值多少？ 4....
2021-03-21
829
上一篇

刚哥谈架构 （十一） 开源API网关架构分析

春未老，风细柳斜斜。试上超然台上望，半壕春水一城花。烟雨暗千家。 寒食后，酒醒却咨嗟。休对故人思故国，且将新火试新茶。诗酒趁年华。 苏轼·送《望江南·超然台作》 春天来了，樱花开了，刚哥我今天就在这春色中和大家探讨一下API Gateway。 在微服务的架构下，API网关是一个常见的架构设计模式。以下是微服务中常见的问题，需要引入API网关来协助解决。 微服务提供的API的粒度通常与客户端所需的粒度不同。微服务通常提供细粒度的API，这意味着客户端需要与多个服务进行交互。例如，如上所述，需要产品详细信息的客户需要从众多服务中获取数据。 不同的客户端需要不同的数据。例如，产品详细信息页面桌面的桌面浏览器版本通常比移动版本更为详尽。 对于不同类型的客户端，网络性能是不同的。例如，与非移动网络相比，移动网络通常要慢得多并且具有更高的延迟。而且，当然，任何WAN都比LAN慢得多。这意味着本机移动客户端使用的网络性能与服务器端Web应用程序使用的LAN的性能差异很大。服务器端Web应用程序可以向后端服务发出多个请求，而不会影响用户体验，而移动客户端只能提供几个请求。 微服务实例数量及其位置（...
2021-03-22
473
下一篇

相关文章

发表评论

资源下载

更多资源
优质分享App

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

时间: 2025-12-03 大小: 4.36MB 下载: 23次
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

时间: 2025-12-12 大小: 211.28KB 下载: 54次
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2025-12-17 大小: 5MB 下载: 1次
Rocky Linux

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

时间: 2026-01-03 大小: 1.42GB 下载: 2次
手机查看

扫码在手机上查看文章

扫描二维码，手机阅读更方便

热门标签
Nacos3 SpringCloud OpenAi Docker DeepSeek Service Mesh Jdk25 HarmonyOS6 Gemini3 SpringBoot4 Rocky Redis Kubernetes

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册