首页 > 其他分享 >k8s 深入篇———— 一些容器操作的原理[三]

k8s 深入篇———— 一些容器操作的原理[三]

时间:2023-06-18 19:34:54浏览次数:42  
标签:容器 宿主机 原理 test 挂载 docker k8s 目录

前言

简单介绍一下一些容器的操作原理。

正文

docker exec 是怎么做到进入容器里的呢。

比如说:

这里有一个容器,我们可以exec 进去:

 docker exec -it b265 /bin/sh

我们为什么能看到和容器内部一样的场景呢?

首先我们知道了为什么容器进程只能看到规定的namespace了,那么如果我们能拿到这个namespace的信息,那么我们就能看到容器进程一样的场景了。

docker inspect --format '{{ .State.Pid }}' b26585ee826b

上面可以查看容器进程。

可以查看namespace信息。

#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");
}

写入到文件中,然后编译:

tee exectest.c <<- 'EOF' 
> #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");
> }
> EOF
gcc -o exectest exectest.c

然后运行./exectest:

./exectest /proc/17240/ns/mnt /bin/sh

那么看下这个进程看到的信息是啥:

./exectest /proc/17240/ns/mnt /bin/sh

看到的信息:

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

你也可以将网络带进去:

正如上所示,当我们执行 ifconfig 命令查看网络设备时,我会发现能看到的网卡“变
少”了:只有两个。而我的宿主机则至少有四个网卡。这是怎么回事呢?
实际上,在 setns() 之后我看到的这两个网卡,正是我在前面启动的 Docker 容器里的网
卡。也就是说,我新创建的这个 /bin/bash 进程,由于加入了该容器进程(PID=25686)
的 Network Namepace,它看到的网络设备与这个容器里是一样的,即:/bin/bash 进程
的网络设备视图,也被修改了。
而一旦一个进程加入到了另一个 Namespace 当中,在宿主机的 Namespace 文件上,也
会有所体现。

其实就是将自己的namespace 指向了原来容器进程的namespace。

查看进程号:

发现和原来的17240进程的net一样。

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

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

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

docker commit 干了啥? 比如我们提交一个容器。

docker commit,实际上就是在容器运行起来后,把最上层的“可读写层”,加上原先容
器镜像的只读层,打包组成了一个新的镜像。当然,下面这些只读层在宿主机上是共享的,
不会占用额外的空间。
而由于使用了联合文件系统,你在容器里对镜像 rootfs 所做的任何修改,都会被操作系统
先复制到这个可读写层,然后再修改。这就是所谓的:Copy-on-Write。
而正如前所说,Init 层的存在,就是为了避免你执行 docker commit 时,把 Docker 自己
对 /etc/hosts 等文件做的修改,也一起提交掉。

前面我已经介绍过,容器技术使用了 rootfs 机制和 Mount Namespace,构建出了一个同
宿主机完全隔离开的文件系统环境。这时候,我们就需要考虑这样两个问题:

  1. 容器里进程新建的文件,怎么才能让宿主机获取到?
  2. 宿主机上的文件和目录,怎么才能让容器里的进程访问到?
    这正是 Docker Volume 要解决的问题:Volume 机制,允许你将宿主机上指定的目录或
    者文件,挂载到容器里面进行读取和修改操作。

在 Docker 项目里,它支持两种 Volume 声明方式,可以把宿主机目录挂载进容器的 /test
目录当中:

docker run -v /test ...
docker run -v /home:/test ...

而这两种声明方式的本质,实际上是相同的:都是把一个宿主机的目录挂载进了容器的/test 目录。

只不过,在第一种情况下,由于你并没有显示声明宿主机目录,那么 Docker 就会默认在宿
主机上创建一个临时目录 /var/lib/docker/volumes/[VOLUME_ID]/_data,然后把它挂载
到容器的 /test 目录上。而在第二种情况下,Docker 就直接把宿主机的 /home 目录挂载
到容器的 /test 目录上

当容器进程被创建之后,尽管开启了 Mount Namespace,但是在它执行 chroot(或者 pivot_root)之前,容器进程一直可以看到宿主机上的整个文件系统

而宿主机上的文件系统,也自然包括了我们要使用的容器镜像。这个镜像的各个层,保存在
/var/lib/docker/aufs/diff 目录下,在容器进程启动后,它们会被联合挂载在
/var/lib/docker/aufs/mnt/ 目录中,这样容器所需的 rootfs 就准备好了。
所以,我们只需要在 rootfs 准备好之后,在执行 chroot 之前,把 Volume 指定的宿主机
目录(比如 /home 目录),挂载到指定的容器目录(比如 /test 目录)在宿主机上对应的
目录(即 /var/lib/docker/aufs/mnt/[可读写层 ID]/test)上,这个 Volume 的挂载工作
就完成了。

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

注意:这里提到的 " 容器进程 ",是 Docker 创建的一个容器初始化进程
(dockerinit),而不是应用进程 (ENTRYPOINT + CMD)。dockerinit 会负责
完成根目录的准备、挂载设备和目录、配置 hostname 等一系列需要在容器
内进行的初始化操作。最后,它通过 execv() 系统调用,让应用进程取代自
己,成为容器里的 PID=1 的进程。

而这里要使用到的挂载技术,就是 Linux 的绑定挂载(bind mount)机制。它的主要作
用就是,允许你将一个目录或者文件,而不是整个设备,挂载到一个指定的目录上。并且,
这时你在该挂载点上进行的任何操作,只是发生在被挂载的目录或者文件上,而原挂载点的
内容则会被隐藏起来且不受影响

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

这样,进程在容器里对这个 /test 目录进行的所有操作,都实际发生在宿主机的对应目录
(比如,/home,或者 /var/lib/docker/volumes/[VOLUME_ID]/_data)里,而不会影响
容器镜像的内容。
那么,这个 /test 目录里的内容,既然挂载在容器 rootfs 的可读写层,它会不会被 docker
commit 提交掉呢?
也不会。

这个原因其实我们前面已经提到过。容器的镜像操作,比如 docker commit,都是发生在
宿主机空间的。而由于 Mount Namespace 的隔离作用,宿主机并不知道这个绑定挂载的
存在。所以,在宿主机看来,容器中可读写层的 /test 目录
(/var/lib/docker/aufs/mnt/[可读写层 ID]/test),始终是空的。

不过,由于 Docker 一开始还是要创建 /test 这个目录作为挂载点,所以执行了 docker
commit 之后,你会发现新产生的镜像里,会多出来一个空的 /test 目录。毕竟,新建目录
操作,又不是挂载操作,Mount Namespace 对它可起不到“障眼法”的作用。

实验:

docker run -d -v /test nginx

查看挂载信息:

那么是哪一个呢?

docker inspect a9c79

直接看这个好了。

docker exec -it a9c79 /bin/bash

然后运行一下:

在里面写了一下文件.

然后看下这个目录里面有不。

然后我们看下读写层有不:

有一个test 目录,但是是空的。

可以确认,容器 Volume 里的信息,并不会被 docker commit 提交掉;但这个挂载点目录 /test 本身,则会出现在新的镜像当中。

如果你执行 docker run -v /home:/test 的时候,容器镜像里的 /test 目录下本来就有内容的话,你会发现,在宿主机的 /home 目录下,也会出现这些内容。这是怎么回事?为什么它们没有被绑定挂载隐藏起来呢?(提示:Docker 的“copyData”功能)

下一节k8s的本质。

标签:容器,宿主机,原理,test,挂载,docker,k8s,目录
From: https://www.cnblogs.com/aoximin/p/17489617.html

相关文章

  • linux学习笔记(31)容器
    【1】容器的介绍(1.1)基本概念容器:针对应用(服务)所需的运行环境,比如依赖、目录、网络、用户等整体封装的技术。封装好的应用(服务)环境叫做镜像,可以理解成迷你版虚拟机或者豪华软件包。当前大多数镜像,是软件厂商自己封装好的,我们直接下载使用即可。如:nginx。核心三个......
  • STL vector容器存储键值对
    在阅读tvm源码时,发现了一个挺有意思的代码:std::vector<std::pair<std::string,ObjectRef>>update;vector容器里竟然存储的是键值对,amazing啊!!!还是第一次遇到这种写法的,这与直接写成map有啥不一样呢?首先,这两种方式都可以用于存储键值对,只是它们具有不同的特性和实用场景。s......
  • Dagonfly 镜像分发:提高容器部署效率的利器
    随着容器技术的快速发展,越来越多的企业和开发者开始将应用程序打包成容器镜像,并使用容器编排工具进行部署和管理。然而,随着容器数量的增加,容器镜像的分发和部署效率成为一个挑战。在这种情况下,Dagonfly镜像分发技术应运而生。Dagonfly是一个开源的镜像分发系统,旨在提供高效、稳......
  • SpringBoot自动配置的原理
    以WebMvcAutoConfiguration自动配置的原理为例,SpringBoot内部对大量的第三方库或Spring内部库进行了默认配置,这些配置是否生效,取决于我们是否引入了对应库所需的依赖,如果有那么默认配置就会生效。如果引入springboot-starter-web那么对应的web配置就会自动配置。那么是如何自动配......
  • CentOS7.9 k8s集群环境搭建
    环境搭建本次环境搭建需要安装三台Centos服务器(一主二从),k8s采用1.25.4版本主机安装安装虚拟机过程中注意下面选项的设置:操作系统环境:CPU(2C)内存(4G)硬盘(50G)语言选择:English软件选择:基础设施服务器分区选择:自动分区网络配置:按照下面配置网路地址信息主机名设置:按照下面信......
  • per-CPU变量的静态和动态分配原理
    per-CPU是2.6内核中引入的,访问per-CPU变量几乎不需要锁,每个处理器都在其自己的副本上工作。这些副本是如何生成的呢?本文尝试解答这个问题。静态per-CPU结构设计思路大体可以分为两个阶段:编译阶段和运行时阶段在编译阶段,实际上只生成了一个CPU原本。系统中所有per-CPU结构都放到了一......
  • k8s 深入篇———— docker 镜像是什么[二]
    前言简单介绍一下docker的镜像。正文前面讲到了容器的工作原理了(namespace限制了时间,cgroup限制了资源),知道docker历史的也知道,docker之所以能够称为容器大佬,是因为其只做了容器。也就是做到了一次打包,到处运行的这种思想得到了实现。那么容器的镜像涉及思路是怎么样的呢?......
  • kafka工作原理
    1.工作流程以及文件存储机制 kafka中的消息是以topic进行分类的,生产消费消息都是面向topic。 topic是逻辑上的概念,partition分区是物理上的概念,每个分区对应一个log文件,该log文件存储的就是producer生产的log数据。producer生产的数据会追加到文件末端。消费者组中的每个消费......
  • k8s 梳理及使用总结
    ---1.Kubernetes概述1.最初Google开发了1个叫Borg的系统(现在命名为Omega),来调度近20多亿个容器从2014年第1个版本发布以来,迅速得到了开源社区的追捧,?前,k8s已经成为了发展最快、市场占有率最高的容器编排引擎产品。---2.特点轻量级,资源消耗小开源弹性伸缩负载均衡IPVS---3.重要......
  • 镜像,容器,容器数据卷,DockerFile 相关命令 使用总结
    镜像,容器,容器数据卷,DockerFile相关命令使用总结镜像是1种轻量级、可执行的独立的软件包。包含:代码,运行时,库,环境变量和配置文件。所有软件包,直接打包docker镜像,就可以直接跑起来.独立的运行环境。一.镜像命令1.列出本机所有镜像,查看镜像dockerimages2.搜索镜像dockersearc......