RedHat OpenShift QuickStart 2.4 容器主机

Posted tiandz

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了RedHat OpenShift QuickStart 2.4 容器主机相关的知识,希望对你有一定的参考价值。

原文:https://learn.openshift.com/subsystems/container-internals-lab-2-0-part-4

 

一、容器引擎&Linux内核

如果在搜索引擎上搜索docker架构,会出现大量描述错误的架构设计或者只讲对了一部分。

为什么人们总是理解错误,有两个主要原因:

首先,大多数架构图都将docker守护进程画为容器主机上的蓝色框,显示容器运行在docker守护进程之上,那是错误的,容器不在docker上运行,docker引擎只是通用容器引擎的一个例子,人们将命令传达给docker引擎,docker引擎在将其传给Linux内核-事实上容器是由Linux内核创建、运行的。即使画对了容器引擎和内核的架构关系,他们也从未显示和容器引擎并排运行的容器。

技术图片

其次,当设计图显示容器是Linux进程时,它们从不并排显示容器引擎。这导致人们从不把这两件事放在一起考虑,因此用户会对一部分内容感到困惑:

技术图片

做一个简单的实验,使用top命令运行三个容器

docker run -td registry.access.redhat.com/ubi7/ubi top
docker run -td registry.access.redhat.com/ubi7/ubi top
podman run -td registry.access.redhat.com/ubi7/ubi top

现在来检查容器主机的进程表:

ps -efZ | grep -v grep | grep " top"

ps -efZ # 查看主体(进程)的安全上下文

grep -v grep # 排除掉带grep命令的进程

grep " top " # 查看带有top的进程

 

现在在每个容器中都使用了 top 命令,两个使用docker启动的,一个使用podman启动的。通过ps 命令我们发现他们就是常规的进程,因为容器化进程只是花哨的Linux进程,和普通进程之间存在额外的隔离。docker 守护进程和容器化进程是并排运行的,就像下图这样:

技术图片

在内核中,没有单一的数据结构表示容器是什么。目前Linux社区的思想是提供许多从试验性的到非常成熟的技术,使用户能够以创造性的方式来将其混合在一起。这正是容器引擎所做的(docker,podman,CRI-O等),它利用内核去创建我们称之为容器等东西。容器的概念是人们创造出来的,而不是内核。这是Linux常见的模式:区分底层(kernel)技术和上层(userspace)技术,这允许内核开发者专注于新增技术,而用户可以尝试使用这些技术去更好的工作。

技术图片 

Linux内核只有一个主要的数据结构来追踪进程--进程id表。ps命令转储此数据结构的内容。但是这不是容器的全部定义:容器引擎追踪使用了哪些内核隔离技术,甚至是挂载了哪些数据卷,这些可以看作是容器的元数据。目前为止,我们应该明白容器化进程就是常规的Linux进程,使用namespace、selinux和cgroups内核技术将其隔离。有时将其描述为虚拟化的沙盒、隔离或者幻觉。

最后,容器化进程只是常规的Linux进程。所有的进程并排运行,无论是常规的Linux进程、长期运行的守护进程、批处理进程、你手动运行的交互式命令或者是虚拟化进程。所有这些进程都会向Linux内核请求受保护的资源像存储,RAM,TCP套接字等。

 

二、一步一步来创建一个容器

这一节看一下容器等基本构造,几乎所有符合OCI的容器引擎的容器基本构造都相同。

  1. 拉取/扩展/挂载镜像
  2. 创建符合OCI规范的文件
  3. 使用spec文件调用runc

1. 拉取/扩展/挂载镜像

Podman可让您轻松分解容器构造的每个步骤以进行学习。首先拉取镜像,拓展它,给容器创建一个新的覆盖文件系统作为容器的读/写根文件系统。为了做到这一点,使用一个特殊构造的容器镜像,来分解步骤,而不是一次全都开始。

podman create -dt --name on-off-container -v /mnt:/mnt:Z quay.io/fatherlinux/on-off-container

使用上面命令使用本地镜像创建一个容器,使用 podman ps -a 命令来查看状态,容器是created状态,而不是running。

 使用mount命令来查看存储:mount | grep -v docker | grep merged 。发现没有任何结果,这是因为它被挂载在所谓的mount namespace中,你只能在容器内看到挂载。podman提供了叫做podman-mount的功能,你可以用这个功能在容器外查看挂载的路径:

podman mount on-off-container

返回的目录是容器使用的覆盖文件系统中的系统级挂载点。 您现在可以立即更改容器文件系统中的任何内容。 可以通过下面命令创建/test文件夹:

touch $(podman mount on-off-container)/test
ls $(podman mount on-off-container)

技术图片

 

现在可以看见test文件,下面在容器里运行shell的时候你同样可以看到这个test文件。

 

2. 创建spec文件

容器已经存在本地并挂载了数据卷,但是目前还没有runc的spec文件。手动创建spec文件非常繁琐,因为他们是由许多不同选项的复杂JSON组成的(由OCI 运行时规范控制),幸运的是,容器引擎会帮我们创建这个spec文件,任何OCI兼容的运行时都可以使用此完全相同的规范文件(runc,crun,katacontainer,gvisor等)。首先来检查一下它在哪里:

cat /var/lib/containers/storage/overlay-containers/$(podman ps -l -q --no-trunc)/userdata/config.json|jq .

#jq . 规范json文件

这命令现在会报错因为容器引擎还没有创建它,现在使用podman和一个特点的容器镜像来创建这个文件:

podman start on-off-container

现在config.json文件已经被创建,继续使用上面的cat 命令检查这个文件,其中有一些选项与podman选项十分相似,这spec文件真正突出了API。

podman此时并未启动容器,使用podman ps -a查看 发现STATUS是Exited。使用inspect命令检查细节,发现:

技术图片

 

# -f filename 如果 filename为常规文件,则为真 。shell 命令

 

即如果/mnt下面由on文件,容器才会运行top命令。

 

3. 调用运行时

现在我们有了存储和一个config.json,通过config.json创建一个虚拟化进程。我们已经构建了一个容器镜像,它只有在/mnt/on文件存在的情况下才会创建一个进程,现在来创建这个on文件:touch /mnt/on,并启动容器podman start on-off-container,继续使用podman ps -a命令查看容器状态,发现此时的状态是up。使用exec命令在容器中创建交互式终端:

podman exec -it on-off-container bash

使用ls -alh命令查看,发现结果和预期的一样,test文件就存在那。我们通过三个基本步骤才真正创建了一个容器

 

三、ELinux和sVirt:动态生成上下文来保护您的容器

运行下面命令,得到如下结果:

$ podman run -dt registry.access.redhat.com/ubi7/ubi sleep 10
244b6bda438e899db9d055335dbd015b93a50e5de7277f8ac0919c65f9b32470
$ podman run -dt registry.access.redhat.com/ubi7/ubi sleep 10
a2652ee6f9e4b4b849fedcbad4872c36e1cef398fa6b00e90988811237bfbbf8
$ sleep 3
$ ps -efZ | grep container_t | grep sleep
system_u:system_r:container_t:s0:c666,c809 root 25067 25023  7 14:03 pts/0 00:00:00 sleep 10
system_u:system_r:container_t:s0:c471,c835 root 25189 25174  7 14:03 pts/0 00:00:00 sleep 10
$

请注意,每个容器都标有动态生成的多级安全性(Multi Level Security (MLS))标签。例如上面结果第一个MLS标签是c66,c809,第二个MLS标签是c471,c835。因此每个容器启动都会生成一个不同的MLS标签,它们被阻止访问彼此的存储和文件等。

SELinux不只是标记进程,它还必须标记进程访问的文件,下面为数据创建一个目录,并检查目录上的SELinux标签。注意,类型设置为“user_tmp_t”,但没有设置MLS标签:

$ ls -alhZ /tmp/selinux-test/
drwxr-xr-x. root root unconfined_u:object_r:user_tmp_t:s0 .
drwxrwxrwt. root root system_u:object_r:tmp_t:s0       ..
$

多启动几次同一个镜像,发现每次多MLS都不一样,这是sVirt在工作:

$ podman run -t -v /tmp/selinux-test:/tmp/selinux-test:Z registry.access.redhat.com/ubi7/ubi ls -alhZ /tmp/selinux-test
drwxr-xr-x. root root system_u:object_r:container_file_t:s0:c729,c736 .
drwxrwxrwt. root root system_u:object_r:container_file_t:s0:c729,c736 ..
$ podman run -t -v /tmp/selinux-test:/tmp/selinux-test:Z registry.access.redhat.com/ubi7/ubi ls -alhZ /tmp/selinux-test
drwxr-xr-x. root root system_u:object_r:container_file_t:s0:c363,c698 .
drwxrwxrwt. root root system_u:object_r:container_file_t:s0:c363,c698 ..
$ podman run -t -v /tmp/selinux-test:/tmp/selinux-test:Z registry.access.redhat.com/ubi7/ubi ls -alhZ /tmp/selinux-test
drwxr-xr-x. root root system_u:object_r:container_file_t:s0:c479,c515 .
drwxrwxrwt. root root system_u:object_r:container_file_t:s0:c479,c515 ..
$

最终,查看/tmp/selinux-test目录多MLS,发现始终和最后一次运行的容器的MLS相同。:Z选项会自动标记和绑定挂载,以便容器可以访问和更改挂载点上的文件。 这样可以防止任何其他进程访问此数据,并且对最终用户是透明的。

 

四、Cgroups:使用容器实例动态创建

本节的目的是为了了解容器如何防止使用彼此的保留资源.Linux内核有一个称为cgroups (control groups的缩写)的特性,它限制、说明和隔离进程的资源使用(CPU、内存、磁盘I/O、网络等)。通常,这些控制组是由系统管理员(使用cgexec)设置的,或者使用systemd (system -run--slice)配置的,但是使用容器引擎时,会自动处理这种配置。

podman run -dt registry.access.redhat.com/ubi7/ubi sleep 10
podman run -dt registry.access.redhat.com/ubi7/ubi sleep 10
sleep 3
for i in $(podman ps | grep sleep | awk {print $1} | grep [0-9]); do find /sys/fs/cgroup/ | grep $i; done

容器引擎自动将容器化进程放进自己的cgroup中,这是十分方便的,类似sVirt。

 

五、SECCOMP:限制容器化进程与内核交互的方式

可以将SECCOMP看过是防火墙,它可以阻止某些系统调用。虽然这是可选的,并且默认情况下是关闭的。但它是一个可以用来阻挡不正常容器的十分强大的工具。

$ cat ~/labs/lab3-step5/chmod.json
{
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "name": "fchmodat",
      "action": "SCMP_ACT_ERRNO"
    }
  ]
}
$ podman run -it --security-opt seccomp=./labs/lab3-step5/chmod.json registry.access.redhat.com/ubi7/ubi chmod 777 /etc/hosts
chmod: changing permissions of /etc/hosts: Operation not permitted
$

# fchmodat - change permissions of a file relative to a directory file descriptor

更改/etc/hosts权限的行为被阻止

以上是关于RedHat OpenShift QuickStart 2.4 容器主机的主要内容,如果未能解决你的问题,请参考以下文章

在线阅读 Redhat OpenShift 内部的秘密?

RedHat OpenShift QuickStart 2.3 容器注册

RedHat OpenShift QuickStart 2.4 容器主机

OpenShift RedHat 上 CI 中的 ImageMagick 库无法正常工作

OpenShift image registry 概述

一文读懂OpenShift总体架构设计 | 五一送福利