登录/ 注册
 找回密码
 立即注册
关闭

CSDN热搜

程序园 精品问答 技术交流 资源下载
返回列表 发新帖
首页 › 业界区 › 业界 ›Golang 版本导致的容器运行时问题

Golang 版本导致的容器运行时问题

东新 前天 22:01
问题现场

用户反馈安装了某个 containerd 版本的节点无法正常拉起容器，业务场景是在 K8S Pod 里面运行一个 Docker，在容器里面通过 docker 命令再启动新的容器。
报错信息如下：
  1. $ docker run -it ubuntu /bin/bash
  3. docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "proc" to rootfs at "/proc": mount proc:/proc (via /proc/self/fd/10), flags: 0xe: operation not permitted: unknown.
  5. ERRO[0000] error waiting for container: context canceled
复制代码
排查过程

从报错信息flags: 0xe: operation not permitted可以知道这个问题的直接原因是挂载 proc文件系统的时候没有权限，导致这一现象的根本原因还需要进一步定位。
Containerd

在用户反馈的信息中，比较关键的一点是某个 containerd 版本开始存在问题，很容易联想到可能和 Containerd 引入的改动有关系。
经过分析，出现问题的 containerd 版本与上一个版本相比，仅新增了两个 Commit，改动内容非常少。通过仔细分析这些引入的改动，发现它们与上述报错信息并无关联，并且新增的特性不会默认打开。因此，基本确定和 containerd 引入的改动无关。
Pod 配置

既然 Containerd 的改动不会有影响，是不是用户 Pod 配置的不同导致呢？
经过对比 Pod yaml，我们发现用户在两个不同 containerd 版本的节点上的 Pod 没有影响权限的配置项。

  • 都是用了特权容器，配置相同
    1. securityContext:
    2.   privileged: true
    3.   runAsNonRoot: false
    复制代码
  • 都挂载了节点上的以下目录（排除 ConfigMap，PVC 等内容）：
    1. volumes:
    2.   -hostPath:
    3.       path:/usr
    4.       type:Directory
    5.     name:host-usr
    6.   -hostPath:
    7.       path:/var/lib/containerd
    8.       type:Directory
    9.     name:containerd-image
    10.   -hostPath:
    11.       path:/run/containerd
    12.       type:Directory
    13.     name:containerd-dir
    14.   -hostPath:
    15.       path:/var/lib/lxc/lxcfs/proc/cpuinfo
    16.       type:File
    17.     name:lxcfs-proc-cpuinfo
    18.   -hostPath:
    19.       path:/var/lib/lxc/lxcfs/proc/meminfo
    20.       type:File
    21.     name:lxcfs-proc-meminfo
    22.   -hostPath:
    23.       path:/var/lib/lxc/lxcfs/sys/devices/system/cpu/online
    24.       type:File
    25.     name:system-cpu-online
    复制代码
由于暂时无法确定根因，提供了回退 Containerd 版本的脚本：
  1. TOS_URL=https://xxx/containerd-$VERSION.tar.gz
  3. function downgrade() {
  4.         wget $TOS_URL -o containerd.tar.gz
  5.         tar -zxvf containerd.tar.gz -C /usr/
  6.         systemctl restart containerd
  7. }
  9. downgrade
复制代码
Runc

既然 Containerd 的改动不会影响权限，这个报错信息是什么地方导致的呢？
这个报错信息来自 runc，分析 runc 报错的具体位置：
  1. // prepareRootfs sets up the devices, mount points, and filesystems for use
  2. // inside a new mount namespace. It doesn't set anything as ro. You must call
  3. // finalizeRootfs after this function to finish setting up the rootfs.
  4. func prepareRootfs(pipe io.ReadWriter, iConfig *initConfig, mountFds []int) (err error) {
  5.     config := iConfig.Config
  6.     if err := prepareRoot(config); err != nil {
  7.         return fmt.Errorf("error preparing rootfs:%w", err)
  8.     }
  10.     if mountFds != nil && len(mountFds) != len(config.Mounts) {
  11.         return fmt.Errorf("malformed mountFds slice. Expected size: %v, got: %v. Slice: %v", len(config.Mounts), len(mountFds), mountFds)
  12.     }
  14.     mountConfig := &mountConfig{
  15.         root:            config.Rootfs,
  16.         label:           config.MountLabel,
  17.         cgroup2Path:     iConfig.Cgroup2Path,
  18.         rootlessCgroups: iConfig.RootlessCgroups,
  19.         cgroupns:        config.Namespaces.Contains(configs.NEWCGROUP),
  20.     }
  21.     setupDev := needsSetupDev(config)
  22.     for i, m := range config.Mounts {
  23.         for _, precmd := range m.PremountCmds {
  24.             if err := mountCmd(precmd); err != nil {
  25.                 return fmt.Errorf("error running premount command:%w", err)
  26.             }
  27.         }
  29.         // Just before the loop we checked that if not empty, len(mountFds) == len(config.Mounts).
  30.         // Therefore, we can access mountFds[i] without any concerns.
  31.         if mountFds != nil && mountFds[i] != -1 {
  32.             mountConfig.fd = &mountFds[i]
  33.         } else {
  34.             mountConfig.fd = nil
  35.         }
  37.         if err := mountToRootfs(m, mountConfig); err != nil {
  38.             return fmt.Errorf("error mounting %q to rootfs at %q:%w", m.Source, m.Destination, err)
  39.         }
  41.     // 省略部分内容
  43.     returnnil
  44. }
复制代码
prepareRootfs中调用了mountToRootfs：
  1. func mountToRootfs(m *configs.Mount, c *mountConfig) error {
  2.     rootfs := c.root
  4.     // procfs and sysfs are special because we need to ensure they are actually
  5.     // mounted on a specific path in a container without any funny business.
  6.     switch m.Device {
  7.     case"proc", "sysfs":
  8.         // If the destination already exists and is not a directory, we bail
  9.         // out. This is to avoid mounting through a symlink or similar -- which
  10.         // has been a "fun" attack scenario in the past.
  11.         // TODO: This won't be necessary once we switch to libpathrs and we can
  12.         //       stop all of these symlink-exchange attacks.
  13.         dest := filepath.Clean(m.Destination)
  14.         if !strings.HasPrefix(dest, rootfs) {
  15.             // Do not use securejoin as it resolves symlinks.
  16.             dest = filepath.Join(rootfs, dest)
  17.         }
  18.         if fi, err := os.Lstat(dest); err != nil {
  19.             if !os.IsNotExist(err) {
  20.                 return err
  21.             }
  22.         } elseif !fi.IsDir() {
  23.             return fmt.Errorf("filesystem %q must be mounted on ordinary directory", m.Device)
  24.         }
  25.         if err := os.MkdirAll(dest, 0o755); err != nil {
  26.             return err
  27.         }
  28.         // Selinux kernels do not support labeling of /proc or /sys.
  29.         return mountPropagate(m, rootfs, "", nil)
  30.     }
  32.     // 省略部分内容
  33. }
复制代码
对于proc 和 sysfs 文件系统，最终会调用mountPropagate：
  1. // Do the mount operation followed by additional mounts required to take care
  2. // of propagation flags. This will always be scoped inside the container rootfs.
  3. func mountPropagate(m *configs.Mount, rootfs string, mountLabel string, mountFd *int) error {
  4.     var (
  5.         data  = label.FormatMountLabel(m.Data, mountLabel)
  6.         flags = m.Flags
  7.     )
  8.     // Delay mounting the filesystem read-only if we need to do further
  9.     // operations on it. We need to set up files in "/dev", and other tmpfs
  10.     // mounts may need to be chmod-ed after mounting. These mounts will be
  11.     // remounted ro later in finalizeRootfs(), if necessary.
  12.     if m.Device == "tmpfs" || utils.CleanPath(m.Destination) == "/dev" {
  13.         flags &= ^unix.MS_RDONLY
  14.     }
  16.     // Because the destination is inside a container path which might be
  17.     // mutating underneath us, we verify that we are actually going to mount
  18.     // inside the container with WithProcfd() -- mounting through a procfd
  19.     // mounts on the target.
  20.     source := m.Source
  21.     if mountFd != nil {
  22.         source = "/proc/self/fd/" + strconv.Itoa(*mountFd)
  23.     }
  25.     if err := utils.WithProcfd(rootfs, m.Destination, func(procfd string) error {
  26.         return mount(source, m.Destination, procfd, m.Device, uintptr(flags), data)
  27.     }); err != nil {
  28.         return err
  29.     }
  30.     // We have to apply mount propagation flags in a separate WithProcfd() call
  31.     // because the previous call invalidates the passed procfd -- the mount
  32.     // target needs to be re-opened.
  33.     if err := utils.WithProcfd(rootfs, m.Destination, func(procfd string) error {
  34.         for _, pflag := range m.PropagationFlags {
  35.             if err := mount("", m.Destination, procfd, "", uintptr(pflag), ""); err != nil {
  36.                 return err
  37.             }
  38.         }
  39.         returnnil
  40.     }); err != nil {
  41.         return fmt.Errorf("change mount propagation through procfd:%w", err)
  42.     }
  43.     returnnil
  44. }
复制代码
最终调用的标准库中的unix.Mount：
  1. // mount is a simple unix.Mount wrapper. If procfd is not empty, it is used
  2. // instead of target (and the target is only used to add context to an error).
  3. func mount(source, target, procfd, fstype string, flags uintptr, data string) error {
  4.     dst := target
  5.     if procfd != "" {
  6.         dst = procfd
  7.     }
  8.     if err := unix.Mount(source, dst, fstype, flags, data); err != nil {
  9.         return &mountError{
  10.             op:     "mount",
  11.             source: source,
  12.             target: target,
  13.             procfd: procfd,
  14.             flags:  flags,
  15.             data:   data,
  16.             err:    err,
  17.         }
  18.     }
  19.     returnnil
  20. }
复制代码
从 runc 源码看，在挂载 proc 的时候，Mount 系统调用返回的错误信息。因此，挂载失败和 runc 调用 mount 时的现场有关系。
我们通过修改 runc 源码，打印 runc 挂载 proc 时相关的现场信息。
正常启动 case：
  1. [31017-09+00 17:24:24] Destination: /proc,
  2. uid: 0,
  3. uid_map:          0       1000          1
  4.          1     100000      65536
  5.      65537     165536      65536
  6. ,
  7. gid_map:          0       1000          1
  8.          1     100000      65536
  9.      65537     165536      65536
  10. ,
  11. userns: user:[4026534201],
  12. mntns: mnt:[4026534601],
  13. cgroupns: cgroup:[4026531835],
  14. mode: dr-xr-xr-x, owner: 65534,
  15. fileGid: 65534
  16. cap: "Name:\trunc:[2:INIT]\nUmask:\t0022\nState:\tR (running)\nTgid:\t749\nNgid:\t0\nPid:\t749\nPPid:\t739\nTracerPid:\t0\nUid:\t0\t0\t0\t0\nGid:\t0\t0\t0\t0\nFDSize:\t64\nGroups:\t0 \nNStgid:\t749\t1\nNSpid:\t749\t1\nNSpgid:\t749\t1\nNSsid:\t749\t1\nVmPeak:\t 1090280 kB\nVmSize:\t 1090280 kB\nVmLck:\t       0 kB\nVmPin:\t       0 kB\nVmHWM:\t    9664 kB\nVmRSS:\t    9664 kB\nRssAnon:\t    2540 kB\nRssFile:\t    7124 kB\nRssShmem:\t       0 kB\nVmData:\t   86400 kB\nVmStk:\t     132 kB\nVmExe:\t    5208 kB\nVmLib:\t     772 kB\nVmPTE:\t     148 kB\nVmSwap:\t       0 kB\nHugetlbPages:\t       0 kB\nCoreDumping:\t0\nTHP_enabled:\t1\nThreads:\t6\nSigQ:\t0/900794\nSigPnd:\t0000000000000000\nShdPnd:\t0000000000000000\nSigBlk:\t0000000000000000\nSigIgn:\t0000000000000000\nSigCgt:\tfffffffdffc1feff\nCapInh:\t0000000000000000\nCapPrm:\t0000003fffffffff\nCapEff:\t0000003fffffffff\nCapBnd:\t0000003fffffffff\nCapAmb:\t0000000000000000\nNoNewPrivs:\t0\nSeccomp:\t0\nSpeculation_Store_Bypass:\tthread vulnerable\nCpus_allowed:\t3ffffff,ffffffff\nCpus_allowed_list:\t0-57\nMems_allowed:\t00000000,00000001\nMems_allowed_list:\t0\nvoluntary_ctxt_switches:\t3\nnonvoluntary_ctxt_switches:\t0\n"
复制代码
异常 case：
  1. [31017-09+00 17:24:24] uid: 0,
  2. uid_map:          0       1000          1
  3.          1     100000      65536
  4.      65537     165536      65536
  5. ,
  6. gid_map:          0       1000          1
  7.          1     100000      65536
  8.      65537     165536      65536
  9. ,
  10. userns: user:[4026534201],
  11. mntns: mnt:[4026534601],
  12. cgroupns: cgroup:[4026531835],
  13. mode: dr-xr-xr-x, owner: 65534,
  14. fileGid: 65534
  15. cap: "Name:\trunc:[2:INIT]\nUmask:\t0022\nState:\tR (running)\nTgid:\t812\nNgid:\t0\nPid:\t812\nPPid:\t802\nTracerPid:\t0\nUid:\t0\t0\t0\t0\nGid:\t0\t0\t0\t0\nFDSize:\t64\nGroups:\t0 \nNStgid:\t812\t1\nNSpid:\t812\t1\nNSpgid:\t812\t1\nNSsid:\t812\t1\nVmPeak:\t 1090536 kB\nVmSize:\t 1090536 kB\nVmLck:\t       0 kB\nVmPin:\t       0 kB\nVmHWM:\t   10032 kB\nVmRSS:\t   10032 kB\nRssAnon:\t    2988 kB\nRssFile:\t    7044 kB\nRssShmem:\t       0 kB\nVmData:\t   86656 kB\nVmStk:\t     132 kB\nVmExe:\t    5208 kB\nVmLib:\t     772 kB\nVmPTE:\t     160 kB\nVmSwap:\t       0 kB\nHugetlbPages:\t       0 kB\nCoreDumping:\t0\nTHP_enabled:\t1\nThreads:\t6\nSigQ:\t0/900794\nSigPnd:\t0000000000000000\nShdPnd:\t0000000000000000\nSigBlk:\t0000000000000000\nSigIgn:\t0000000000000000\nSigCgt:\tfffffffdffc1feff\nCapInh:\t0000000000000000\nCapPrm:\t0000003fffffffff\nCapEff:\t0000003fffffffff\nCapBnd:\t0000003fffffffff\nCapAmb:\t0000000000000000\nNoNewPrivs:\t0\nSeccomp:\t0\nSpeculation_Store_Bypass:\tthread vulnerable\nCpus_allowed:\t3ffffff,ffffffff\nCpus_allowed_list:\t0-57\nMems_allowed:\t00000000,00000001\nMems_allowed_list:\t0\nvoluntary_ctxt_switches:\t3\nnonvoluntary_ctxt_switches:\t0\n"
复制代码
正常拉起 docker 容器和拉起失败情况下，runc 的 userns 相同，target 的 owner 都是 65534（没有 map id）。此外，查看 runc 进程的 Capability，都包括 SYS_ADMIN：
  1. # capsh --decode=0000003fffffffff
  2. 0x0000003fffffffff=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read
复制代码
异常 case 和正常 case 的 runc 进程环境也没区别，为什么挂载 proc 会失败呢？
进一步修改 runc 源码，当 mount 失败之后，让进程不退出，保留现场，然后进入 runc 所在 user namespace 和 mount namespace，尝试 mount proc 文件系统，结果【失败】。
Bind mount 没问题，但是 mount proc 失败：
1.png

场景分析

通过分析，用户的使用场景大致如下：
2.jpeg

docker in container architecture

  • 用户挂载了节点上的一些目录到外部容器。
  • Docker 用的 runc 是社区提供的。
核心问题：节点上 Containerd 版本的变化为什么会影响容器中的 Runc ？
对比容器中的挂载点信息，发现有些区别。
正常 case：
  1. 2409 2408 0:308 / /proc rw,nosuid,nodev,noexec,relatime master:461 - proc proc rw
  2. 2410 2409 0:235 /proc/cpuinfo /proc/cpuinfo ro,relatime master:462 - fuse.lxcfs lxcfs rw,user_id=0,group_id=0,allow_other,force_umount
  3. 2411 2409 0:235 /proc/meminfo /proc/meminfo ro,relatime master:463 - fuse.lxcfs lxcfs rw,user_id=0,group_id=0,allow_other,force_umount
  4. 2633 2632 0:308 / /run/containerd/io.containerd.runtime.v2.task/k8s.io/17c97f222c6a02eb46f170cdf5ed6621bee116836a57c6121de9f3818494182f/rootfs/proc rw,nosuid,nodev,noexec,relatime master:609 - proc proc rw
  5. 3010 3009 0:330 / /ebs/docker/165536.165536/fuse-overlayfs/70c276e0d397f4bebfea4239e967132baa2db0746181b0b7dc0ea7b24912f1e3/merged/proc rw,nosuid,nodev,noexec,relatime - proc proc rw
复制代码
异常 case：
  1. 2779 2778 0:308 / /proc rw,nosuid,nodev,noexec,relatime master:461 - proc proc rw
  2. 2827 2779 0:235 /proc/meminfo /proc/meminfo ro,relatime master:462 - fuse.lxcfs lxcfs rw,user_id=0,group_id=0,allow_other,force_umount
  3. 2828 2779 0:235 /proc/cpuinfo /proc/cpuinfo ro,relatime master:463 - fuse.lxcfs lxcfs rw,user_id=0,group_id=0,allow_other,force_umount
  4. 3074 3073 0:308 / /run/containerd/io.containerd.runtime.v2.task/k8s.io/a33db564c39c8573ea92e3e5327be27ca205684cb965b8f03d9eaa0ae2b8aff7/rootfs/proc rw,nosuid,nodev,noexec,relatime master:608 - proc proc rw
  5. 3075 3074 0:235 /proc/meminfo /run/containerd/io.containerd.runtime.v2.task/k8s.io/a33db564c39c8573ea92e3e5327be27ca205684cb965b8f03d9eaa0ae2b8aff7/rootfs/proc/meminfo ro,relatime master:609 - fuse.lxcfs lxcfs rw,user_id=0,group_id=0,allow_other,force_umount
  6. 3076 3074 0:235 /proc/cpuinfo /run/containerd/io.containerd.runtime.v2.task/k8s.io/a33db564c39c8573ea92e3e5327be27ca205684cb965b8f03d9eaa0ae2b8aff7/rootfs/proc/cpuinfo ro,relatime master:610 - fuse.lxcfs lxcfs rw,user_id=0,group_id=0,allow_other,force_umount
复制代码
注意，异常 case 中多出了两条挂载点。正常 case 只有：

  • /run/containerd/xxx/rootfs/proc
异常 case 除了这条挂载点，还多出了：

  • /run/containerd/xxx/rootfs/proc/meminfo
  • /run/containerd/xxx/rootfs/proc/cpuinfo
Golang 版本（柳暗花明）

除了 Containerd 版本不一样，我们注意到，编译 Containerd 的环境也有一些区别，旧版本是用 Golang 1.18 编译，新版本使用了 Golang 1.20。基于这个思路，我们使用不同 Golang 版本编译了相同的 Containerd 源码。
Golang 1.18 编译的 containerd 没问题：
3.png

Golang 1.20 编译的 containerd 有问题：
4.png

从这个现象基本可以确定这个问题和 Golang 版本有关系。
通过编译 Golang 源码找到引入问题的 commit。golang 1.19 的第一个 commit：936c7fbc1c154964b6e3e8a7523bdf0c29b4e1b3[1]
通过二分查找的方法，找到引入问题的 commit：
Step 1:
  1. 4a4127bccc go1.19.1
  2. 43456202a1 go1.19
  3. ad672e7ce1 go1.19rc2
  4. bac4eb53d6 go1.19rc1
  5. 2cfbef4380 go1.19beta1 --> failed
  7. d81dd12906 --> fail
  8. 797e8890 --> ok
  10. 2ea7d3461b go1.9.2 --> build error
  11. 7f40c1214d go1.9.1 --> build error
  12. c8aec4095e go1.9 --> build error
  13. 048c9cfaac go1.9rc2 --> build error
  14. 65c6c88a94 go1.9rc1 --> build error
  15. 936c7fbc1c go1.19 start --> ok
复制代码
Step 2:
  1. 1:* d81dd12906 --> fail
  2. 2:* 420a1fb223
  3. 88:* e0ae8540ab
  4. 735:* 0670afa1b3 --> fail
  5. 760:* 2c73f5f32f --> fail
  6. 772:* d2552037 --> fail
  8. 773:* 72e77a7f41 --> fail
  9. 774:* 9298f604f4 --> ok
  11. 775:* d65a41329e --> ok
  12. 778:* 517781b391 --> ok
  13. 785:* d85694ab4f --> ok
  14. 839:* 6f6942ef7a --> ok
  15. 992:* 1724077b78 --> ok
  16. 1136:* 79861be205
  17. 1269:* 797e889046 --> ok
复制代码
最终，找到导致问题的 Commit：72e77a7f41bbf45d466119444307fd3ae996e257[2]
72e77a7f41：
5.jpeg

上一个 commit 9298f604f4：
6.jpeg

这个 commit 修改了sort.Sort()的实现，从稳定排序变成不稳定排序。
为了进一步验证这个改动对 containerd 的影响，修改 containerd 中所有sort.Sort()为sort.Stable()，即修改为稳定排序，问题修复。
Containerd 调用 sort.Sort() 排序 mounts：pkg/cri/opts/spec_linux.go#L120[3]
7.jpeg

修改 containerd，输出稳定排序和非稳定排序场景下的 mounts 结果。
stable sort mounts：
8.png

unstable sort mounts：
9.png

为什么挂载顺序的区别会导致 mount proc 失败？
Mount 限制（根因）

runc 调用 mount 系统调用返回的错误信息，根因是mount_too_revealing 返回 1 导致挂载失败：
10.jpeg

11.jpeg

在 mount_too_revealing 函数中，如果是 proc 和 sys 会走到 mnt_already_visible 来检查权限。
“
参考 cve-2022-0492[4]
源码如下：
  1. static bool mnt_already_visible(struct mnt_namespace *ns,
  2.                                     const struct super_block *sb,
  3.                                     int *new_mnt_flags)
  4.     {
  5.             int new_flags = *new_mnt_flags;
  6.             struct mount *mnt;
  7.             bool visible = false;
  9.             down_read(&namespace_sem);
  10.             lock_ns_list(ns);
  11.             list_for_each_entry(mnt, &ns->list, mnt_list) {
  12.                     struct mount *child;
  13.                     int mnt_flags;
  15.                     ...
  16.                     list_for_each_entry(child, &mnt->mnt_mounts, mnt_child) {
  17.                             struct inode *inode = child->mnt_mountpoint->d_inode;
  18. /* Only worry about locked mounts */
  19.                             if (!(child->mnt.mnt_flags & MNT_LOCKED))
  20.                                     continue;
  21. /* Is the directorypermanetly empty? */
  22.                             if (!is_empty_dir_inode(inode))
  23.                                     goto next;
  24.                     }
  25. /* Preserve the locked attributes */
  26.                     *new_mnt_flags |= mnt_flags & (MNT_LOCK_READONLY | \
  27.                                             MNT_LOCK_ATIME);
  28.                     visible = true;
  29.                     goto found;
  30.             next:        ;
  31.             }
  32.     found:
  33.             unlock_ns_list(ns);
  34.             up_read(&namespace_sem);
  35.             return visible;
  36.     }
复制代码
mnt_already_visible会遍历新的 mount namespace 并且检查是否有子挂载点，如果已经有子挂载点并且不是全部对当前 mount namespace 可见，则不能挂载 proc 和 sys。原因如下：procfs 和 sysfs 包括许多全局数据，不能直接挂载到容器中。
“
mnt_already_visible will iterate the new mount namespace and check whether it has child mountpoint. If it has child mountpoint, it is not fully visible to this mount namespace so the procfs will not be mounted.
“
This reason is as following. The procfs and sysfs contains some global data, so the container should not touch. So mouting procfs and sysfs in new user namespace should be restricted.
这是内核的限制：
12.jpeg

13.jpeg

回头看下我们拿到的容器中的挂载点信息。
正常 case：
14.png
  1. 2409 2408 0:308 / /proc rw,nosuid,nodev,noexec,relatime master:461 - proc proc rw
  2. 2410 2409 0:235 /proc/cpuinfo /proc/cpuinfo ro,relatime master:462 - fuse.lxcfs lxcfs rw,user_id=0,group_id=0,allow_other,force_umount
  3. 2411 2409 0:235 /proc/meminfo /proc/meminfo ro,relatime master:463 - fuse.lxcfs lxcfs rw,user_id=0,group_id=0,allow_other,force_umount
  4. 2633 2632 0:308 / /run/containerd/io.containerd.runtime.v2.task/k8s.io/17c97f222c6a02eb46f170cdf5ed6621bee116836a57c6121de9f3818494182f/rootfs/proc rw,nosuid,nodev,noexec,relatime master:609 - proc proc rw
  5. 3010 3009 0:330 / /ebs/docker/165536.165536/fuse-overlayfs/70c276e0d397f4bebfea4239e967132baa2db0746181b0b7dc0ea7b24912f1e3/merged/proc rw,nosuid,nodev,noexec,relatime - proc proc rw
复制代码
异常 case：
15.png
  1. 2779 2778 0:308 / /proc rw,nosuid,nodev,noexec,relatime master:461 - proc proc rw
  2. 2827 2779 0:235 /proc/meminfo /proc/meminfo ro,relatime master:462 - fuse.lxcfs lxcfs rw,user_id=0,group_id=0,allow_other,force_umount
  3. 2828 2779 0:235 /proc/cpuinfo /proc/cpuinfo ro,relatime master:463 - fuse.lxcfs lxcfs rw,user_id=0,group_id=0,allow_other,force_umount
  4. 3074 3073 0:308 / /run/containerd/io.containerd.runtime.v2.task/k8s.io/a33db564c39c8573ea92e3e5327be27ca205684cb965b8f03d9eaa0ae2b8aff7/rootfs/proc rw,nosuid,nodev,noexec,relatime master:608 - proc proc rw
  5. 3075 3074 0:235 /proc/meminfo /run/containerd/io.containerd.runtime.v2.task/k8s.io/a33db564c39c8573ea92e3e5327be27ca205684cb965b8f03d9eaa0ae2b8aff7/rootfs/proc/meminfo ro,relatime master:609 - fuse.lxcfs lxcfs rw,user_id=0,group_id=0,allow_other,force_umount
  6. 3076 3074 0:235 /proc/cpuinfo /run/containerd/io.containerd.runtime.v2.task/k8s.io/a33db564c39c8573ea92e3e5327be27ca205684cb965b8f03d9eaa0ae2b8aff7/rootfs/proc/cpuinfo ro,relatime master:610 - fuse.lxcfs lxcfs rw,user_id=0,group_id=0,allow_other,force_umount
复制代码
在异常 case 中，多出来的两个挂载点的父挂载点是 3074，也就是 proc 的挂载点。
至此，问题的根因已经确定。
runc 会先挂载 /proc/cpuinfo 和 /proc/meminfo，这两个目录实际对应节点上 /run/containerd 下的子目录，比较巧的是，用户刚好挂载了 /run/containerd 目录到容器。
因此，先挂载的 /proc/cpuinfo 和 /proc/meminfo 由于是/run/containerd/xxx/rootfs/proc 的子挂载点，在挂载 /run/containerd 目录的时候会被传播到容器内。而先挂载 /run/containerd 则不存在这个问题。
问题复现


  • 在节点安装 lxcfs
  1. $ apt-get update && apt-get install lxcfs -y
复制代码

  • 异常 case：创建 Pod，其中 /run/containerd 晚于 /proc/cpuinfo 和 /proc/meminfo 挂载，docker 无法启动容器
  1. apiVersion: v1
  2. kind:Pod
  3. metadata:
  4. name:docker-mount-sort-stable-test-pod
  5. namespace:default
  6. spec:
  7. hostNetwork:true
  8. containers:
  9. -image:ghcr.io/sctb512/docker-test:latest
  10.     imagePullPolicy:Always
  11.     name:docker
  12.     securityContext:
  13.       privileged:true
  14.       runAsNonRoot:false
  15.     terminationMessagePath:/dev/termination-log
  16.     terminationMessagePolicy:File
  17.     volumeMounts:
  18.     -mountPath:/var/lib/containerd
  19.       mountPropagation:HostToContainer
  20.       name:containerd-image
  21.     -mountPath:/proc/meminfo
  22.       name:lxcfs-proc-meminfo
  23.       readOnly:true
  24.     -mountPath:/proc/cpuinfo
  25.       name:lxcfs-proc-cpuinfo
  26.       readOnly:true
  27.     -mountPath:/run/containerd
  28.       name:containerd-dir
  29. volumes:
  30. -hostPath:
  31.       path:/var/lib/lxc/lxcfs/proc/meminfo
  32.       type:File
  33.     name:lxcfs-proc-meminfo
  34. -hostPath:
  35.       path:/var/lib/lxc/lxcfs/proc/cpuinfo
  36.       type:File
  37.     name:lxcfs-proc-cpuinfo
  38. -hostPath:
  39.       path:/run/containerd
  40.       type:Directory
  41.     name:containerd-dir
  42. -hostPath:
  43.       path:/var/lib/containerd
  44.       type:Directory
  45.     name:containerd-image
复制代码
通过 docker 拉起容器：
  1. $ docker run --rm -it nginx:latest
复制代码
16.png


  • 正常 case：创建 Pod /run/containerd 早于 /proc/cpuinfo 和 /proc/meminfo 挂载，docker 可以启动容器
  1. apiVersion: v1
  2. kind:Pod
  3. metadata:
  4. name:docker-mount-sort-stable-test-pod
  5. namespace:default
  6. spec:
  7. hostNetwork:true
  8. containers:
  9. -image:ghcr.io/sctb512/docker-test:latest
  10.     imagePullPolicy:Always
  11.     name:docker
  12.     securityContext:
  13.       privileged:true
  14.       runAsNonRoot:false
  15.     terminationMessagePath:/dev/termination-log
  16.     terminationMessagePolicy:File
  17.     volumeMounts:
  18.     -mountPath:/var/lib/containerd
  19.       mountPropagation:HostToContainer
  20.       name:containerd-image
  21.     -mountPath:/run/containerd
  22.       name:containerd-dir
  23.     -mountPath:/proc/meminfo
  24.       name:lxcfs-proc-meminfo
  25.       readOnly:true
  26.     -mountPath:/proc/cpuinfo
  27.       name:lxcfs-proc-cpuinfo
  28.       readOnly:true
  29. volumes:
  30. -hostPath:
  31.       path:/var/lib/lxc/lxcfs/proc/meminfo
  32.       type:File
  33.     name:lxcfs-proc-meminfo
  34. -hostPath:
  35.       path:/var/lib/lxc/lxcfs/proc/cpuinfo
  36.       type:File
  37.     name:lxcfs-proc-cpuinfo
  38. -hostPath:
  39.       path:/run/containerd
  40.       type:Directory
  41.     name:containerd-dir
  42. -hostPath:
  43.       path:/var/lib/containerd
  44.       type:Directory
  45.     name:containerd-image
复制代码
17.png

总结

Containerd 老版本使用 Golang 1.18 编译，新版本使用 golang 1.20 编译，Golang 1.19 在 commit 72e77a7f41bbf45d466119444307fd3ae996e257[5] 将 sort.Sort 由稳定排序修改为不稳定排序。containerd 使用 sort.Sort 对挂载点进行排序，sort.Sort变为不稳定之后，containerd 传给 runc 的挂载点顺序发生了变化。
用户场景会将 /run/containerd 目录挂载到容器中，不同挂载顺序会导致 runc 挂载 procfs 时看到的子挂载点信息不同：

  • /proc/meminfo 和 /proc/cpuinfo 先于 /run/containerd 挂载，containerd 传的挂载参数是 rbind（类似于 bind，会递归 bind 当前挂载点上已有的子挂载点），meminfo 和 cpuinfo 作为 /run/containerd/xxx/proc 的子挂载点在挂载 /run/containerd 时会被挂载，也就是说，runc 挂载 procfs 时， /run/containerd/xxx/proc 存在子挂载点，因此，不能挂载。
  • /proc/meminfo 和 /proc/cpuinfo 晚于 /run/containerd 挂载，runc 挂载 /run/containerd 时 meminfo 和 cpuinfo 还没被挂载，因此，runc 挂载 /run/containerd 时不存在子挂载点，可以挂载 procfs。
问题触发条件：

  • 容器挂载了 /proc/xxx 目录 & 挂载了节点上的 /run/containerd 目录
  • sysfs 也有类似问题
解决方案：

  • Containerd 侧：修改sort.Sort为sort.Stable
pkg/cri/opts/spec_linux.go#L120[6]
18.png

有个有意思的点，containerd 社区给OrderedMounts 加了单元测试，用例中用的 sort.Stable，但代码逻辑中实际用的是 sort.Sort。可能默许了 sort.Sort 包含稳定排序的特征，只不过在 Golang 1.19 被打破了，才导致的问题。
pkg/cri/opts/spec_test.go#L44[7]
19.png


  • 用户侧：确保 Pod yaml 中容器挂载点的顺序 /run/containerd 在 /proc/xxx 挂载点之前。
向社区提交的 PR：
containerd/containerd/pull/10021[8]
回合到 1.6 分支：
containerd/containerd/pull/10045[9]
正式 release 版本：v1.6.32[10]
参考资料
[1] 936c7fbc1c154964b6e3e8a7523bdf0c29b4e1b3: https://github.com/golang/go/commit/936c7fbc1c154964b6e3e8a7523bdf0c29b4e1b3
[2] 72e77a7f41bbf45d466119444307fd3ae996e257: https://github.com/golang/go/commit/72e77a7f41bbf45d466119444307fd3ae996e257
[3] pkg/cri/opts/spec_linux.go#L120: https://github.com/containerd/containerd/blob/91a68edd775bba554a9eac7e04898b22069db5aa/pkg/cri/opts/spec_linux.go#L120
[4] cve-2022-0492: https://terenceli.github.io/技术/2022/03/06/cve-2022-0492
[5] 72e77a7f41bbf45d466119444307fd3ae996e257: https://github.com/golang/go/commit/72e77a7f41bbf45d466119444307fd3ae996e257
[6] pkg/cri/opts/spec_linux.go#L120: https://github.com/containerd/containerd/blob/v1.6.31/pkg/cri/opts/spec_linux.go#L120
[7] pkg/cri/opts/spec_test.go#L44: https://github.com/containerd/containerd/blob/v1.6.31/pkg/cri/opts/spec_test.go#L44
[8] containerd/containerd/pull/10021: https://github.com/containerd/containerd/pull/10021
[9] containerd/containerd/pull/10045: https://github.com/containerd/containerd/pull/10045
[10] v1.6.32: https://github.com/containerd/containerd/releases/tag/v1.6.32
20.png


来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

使用道具 举报
相关推荐
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 立即注册
发帖
东新
前天 22:01

0

粉丝关注

5

主题发布

板块介绍填写区域，请于后台编辑
微信扫一扫