Pod Terminating 续集：最终章

最新推荐文章于 2022-06-17 12:39:22 发布
最新推荐文章于 2022-06-17 12:39:22 发布
阅读量250 收藏 1
点赞数
文章标签： 定位 gwt docker ext stylesheet


更多奇技淫巧欢迎订阅博客：https://fuckcloudnative.io

前言

承接????上文，近期我们排查弹性云线上几起故障时，故障由多个因素共同引起，列举如下：

  • 弹性云在逐步灰度升级 docker 版本至 18.06.3-ce

  • 由于历史原因，弹性云启用了 docker 服务的 systemd 配置选项 MountFlags=slave

  • 为了避免 dockerd 重启引起业务容器重建，弹性云启用了 live-restore=true 配置，docker 服务发生重启，dockerd 与 shim 进程 mnt ns 不一致

在以上三个因素合力作用下，线上容器在重建与漂移场景下，出现删除失败的事件。

同样，文章最后也给出了两种解决方案：

  • 长痛：修改代码，忽略错误

  • 短痛：修改配置，一劳永逸

作为优秀的社会主义接班人，我们当然选择短痛了！依据官方提示 MountFlags=slave 与 live-restore=true 不能协同工作，那么我们只需关闭二者之一就能解决问题。

与我们而言，docker 提供的 live-restore 能力是一个很关键的特性。docker 重启的原因多种多样，既可能是人为调试因素，也可能是机器的非预期行为，当 docker 重启后，我们并不希望用户的容器也发生重建。似乎关闭 MountFlags=slave 成了我们唯一的选择。

等等，回想一下docker device busy 问题解决方案[1]，别人正是为了避免 docker 挂载泄漏而引起删除容器失败才开启的这个特性。

但是，这个 17 年的结论真的还具有普适性吗？是与不是，我们亲自验证即可。

1. 对比实验

为了验证在关闭 MountFlags=slave 选项后，docker 是否存在挂载点泄漏的问题，我们分别挑选了一台 1.13.1 与 18.06.3-ce 的宿主进行实验。实验步骤正如docker device busy 问题解决方案[2]所提示，在验证之前，环境准备如下：

  • 删除 docker 服务的 systemd 配置项 MountFlags=slave

  • 挑选启用 systemd 配置项 PrivateTmp=true 的任意服务，本文以 httpd 为例

下面开始验证：

// docker 1.13.1 验证步骤及结果
// 1. 重新加载配置
[stupig@hostname2 ~]$ sudo systemctl daemon-reload


// 2. 重启docker
[stupig@hostname2 ~]$ sudo systemctl restart docker


// 3. 创建容器
[stupig@hostname2 ~]$ sudo docker run -d nginx
c89c2aeff6e3e6414dfc7f448b4a560b4aac96d69a82ba021b78ee576bf6771c


// 4. 重启httpd
[stupig@hostname2 ~]$ sudo systemctl restart httpd


// 5. 停止容器
[stupig@hostname2 ~]$ sudo docker stop c89c2aeff6e3e6414dfc7f448b4a560b4aac96d69a82ba021b78ee576bf6771c
c89c2aeff6e3e6414dfc7f448b4a560b4aac96d69a82ba021b78ee576bf6771c


// 6. 清理容器
[stupig@hostname2 ~]$ sudo docker rm c89c2aeff6e3e6414dfc7f448b4a560b4aac96d69a82ba021b78ee576bf6771c
Error response from daemon: Driver overlay2 failed to remove root filesystem c89c2aeff6e3e6414dfc7f448b4a560b4aac96d69a82ba021b78ee576bf6771c: remove /home/docker_rt/overlay2/6c77cfb6c0c4b1e809c47af3c5ff6a4732a783cc14ff53270a7709c837c96346/merged: device or resource busy


// 7. 定位挂载点
[stupig@hostname2 ~]$ grep -rwn /home/docker_rt/overlay2/6c77cfb6c0c4b1e809c47af3c5ff6a4732a783cc14ff53270a7709c837c96346/merged /proc/*/mountinfo
/proc/19973/mountinfo:40:231 227 0:40 / /home/docker_rt/overlay2/6c77cfb6c0c4b1e809c47af3c5ff6a4732a783cc14ff53270a7709c837c96346/merged rw,relatime shared:119 - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX
/proc/19974/mountinfo:40:231 227 0:40 / /home/docker_rt/overlay2/6c77cfb6c0c4b1e809c47af3c5ff6a4732a783cc14ff53270a7709c837c96346/merged rw,relatime shared:119 - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX
/proc/19975/mountinfo:40:231 227 0:40 / /home/docker_rt/overlay2/6c77cfb6c0c4b1e809c47af3c5ff6a4732a783cc14ff53270a7709c837c96346/merged rw,relatime shared:119 - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX
/proc/19976/mountinfo:40:231 227 0:40 / /home/docker_rt/overlay2/6c77cfb6c0c4b1e809c47af3c5ff6a4732a783cc14ff53270a7709c837c96346/merged rw,relatime shared:119 - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX
/proc/19977/mountinfo:40:231 227 0:40 / /home/docker_rt/overlay2/6c77cfb6c0c4b1e809c47af3c5ff6a4732a783cc14ff53270a7709c837c96346/merged rw,relatime shared:119 - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX
/proc/19978/mountinfo:40:231 227 0:40 / /home/docker_rt/overlay2/6c77cfb6c0c4b1e809c47af3c5ff6a4732a783cc14ff53270a7709c837c96346/merged rw,relatime shared:119 - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX


// 8. 定位目标进程
[stupig@hostname2 ~]$ ps -ef|egrep '19973|19974|19975|19976|19977|19978'
root     19973     1  0 15:13 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache   19974 19973  0 15:13 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache   19975 19973  0 15:13 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache   19976 19973  0 15:13 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache   19977 19973  0 15:13 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache   19978 19973  0 15:13 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND

docker 1.13.1 版本的实验结果正如网文所料，容器读写层挂载点出现了泄漏，并且 docker rm 无法清理该容器（注意 docker rm -f 仍然可以清理，原因参考上文）。

弹性云启用 docker 配置 MountFlags=slave 也是为了避免该问题发生。

那么现在压力转移到 docker 18.06.3-ce 这边来了，新版本是否仍然存在这个问题呢？

// docker 18.06.3-ce 验证步骤及结果
[stupig@hostname ~]$ sudo systemctl daemon-reload


[stupig@hostname ~]$ sudo systemctl restart docker


[stupig@hostname ~]$ sudo docker run -d nginx
718114321d67a817c1498e530b943c2514ed4200f2d0d138880f8c345df7048f


[stupig@hostname ~]$ sudo systemctl restart httpd


[stupig@hostname ~]$ sudo docker stop 718114321d67a817c1498e530b943c2514ed4200f2d0d138880f8c345df7048f
718114321d67a817c1498e530b943c2514ed4200f2d0d138880f8c345df7048f


[stupig@hostname ~]$ sudo docker rm 718114321d67a817c1498e530b943c2514ed4200f2d0d138880f8c345df7048f
718114321d67a817c1498e530b943c2514ed4200f2d0d138880f8c345df7048f

针对 docker 18.06.3-ce 的实验非常丝滑顺畅，不存在任何问题。回顾上文知识点，当容器读写层挂载点出现泄漏后，docker 18.06.3-ce 清理容器必定失败，而现在的结果却成功了，说明容器读写层挂载点没有泄漏。

这简直就是黎明的曙光。

2. 蛛丝马迹

上一节对比实验的结果给了我们莫大的鼓励，本节我们探索两个版本的 docker 的表现差异，以期定位症结所在。

既然核心问题在于挂载点是否被泄漏，那么我们就以挂载点为切入点，深入分析两个版本 docker 的差异性。我们对比在两个环境下执行完 步骤4 后，不同进程内的挂载详情，结果如下：

// docker 1.13.1
[stupig@hostname2 ~]$ sudo docker run -d nginx
0fe8d412f99a53229ea0df3ec44c93496e150a39f724ea304adb7f924910d61b

[stupig@hostname2 ~]$ sudo docker inspect -f {{.GraphDriver.Data.MergedDir}} 0fe8d412f99a53229ea0df3ec44c93496e150a39f724ea304adb7f924910d61b
/home/docker_rt/overlay2/4e09fa6803feab9d96fe72a44fb83d757c1788812ff60071ac2e62a5cf14cd97/merged

// 共享命名空间
[stupig@hostname2 ~]$ grep -rw /home/docker_rt/overlay2/4e09fa6803feab9d96fe72a44fb83d757c1788812ff60071ac2e62a5cf14cd97/merged /proc/$$/mountinfo
223 1143 0:40 / /home/docker_rt/overlay2/4e09fa6803feab9d96fe72a44fb83d757c1788812ff60071ac2e62a5cf14cd97/merged rw,relatime - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX


[stupig@hostname2 ~]$ sudo systemctl restart httpd

[stupig@hostname2 ps -ef|grep httpd|head -n 1
root     16715     1  2 16:09 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND

// httpd进程命名空间
[stupig@hostname2 ~]$ grep -rw /home/docker_rt/overlay2/4e09fa6803feab9d96fe72a44fb83d757c1788812ff60071ac2e62a5cf14cd97/merged /proc/16715/mountinfo
257 235 0:40 / /home/docker_rt/overlay2/4e09fa6803feab9d96fe72a44fb83d757c1788812ff60071ac2e62a5cf14cd97/merged rw,relatime shared:123 - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX
// docker 18.06.3-ce
[stupig@hostname ~]$ sudo docker run -d nginx
ce75d4fdb6df6d13a7bf4270f71b3752ee2d3849df1f64d5d5d19a478ac7db8d

[stupig@hostname ~]$ sudo docker inspect -f {{.GraphDriver.Data.MergedDir}} ce75d4fdb6df6d13a7bf4270f71b3752ee2d3849df1f64d5d5d19a478ac7db8d
/home/docker_rt/overlay2/a9823ed6b3c5a752eaa92072ff9d91dbe1467ceece3eedf613bf6ffaa5183b76/merged

// 共享命名空间
[stupig@hostname ~]$ grep -rw /home/docker_rt/overlay2/a9823ed6b3c5a752eaa92072ff9d91dbe1467ceece3eedf613bf6ffaa5183b76/merged /proc/$$/mountinfo
218 43 0:105 / /home/docker_rt/overlay2/a9823ed6b3c5a752eaa92072ff9d91dbe1467ceece3eedf613bf6ffaa5183b76/merged rw,relatime shared:109 - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX

[stupig@hostname ~]$ sudo systemctl restart httpd

[stupig@hostname ~]$ ps -ef|grep httpd|head -n 1
root      63694      1  0 16:14 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND

// httpd进程命名空间
[stupig@hostname ~]$ grep -rw /home/docker_rt/overlay2/a9823ed6b3c5a752eaa92072ff9d91dbe1467ceece3eedf613bf6ffaa5183b76/merged /proc/63694/mountinfo
435 376 0:105 / /home/docker_rt/overlay2/a9823ed6b3c5a752eaa92072ff9d91dbe1467ceece3eedf613bf6ffaa5183b76/merged rw,relatime shared:122 master:109 - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX

咋一看，好像没啥区别啊！睁大你们的火眼金睛，是否发现差异所在了？

如果细心对比，还是很容易分辨出差异所在的：

  • 共享命名空间中

    • docker 18.06.3-ce 版本创建的挂载点是 shared 的

    • 而 docker 1.13.1 版本创建的挂载点是 private 的

  • httpd 进程命名空间中

    • docker 18.06.3-ce 创建的挂载点仍然是共享的，并且接收共享组 109 传递的挂载与卸载事件，注意：共享组 109 正好就是共享命名空间中对应的挂载点

    • 而 docker 1.13.1 版本创建的挂载点虽然也是共享的，但是却与共享命名空间中对应的挂载点没有关联关系

可能会有用户不禁要问：怎么分辨挂载点是什么类型？以及不同类型挂载点的传递属性呢？请参阅：mount 命名空间说明文档[3]。

问题已然明了，由于两个版本 docker 所创建的容器读写层挂载点具备不同的属性，导致它们之间的行为差异。

3. 刨根问底

相信大家如果理解了上一节的内容，就已经了解了问题的本质。本节我们继续探索问题的根因。

为什么两个版本的 docker 行为表现不一致？不外乎两个主要原因：

  1. docker 处理逻辑发生变动

  2. 宿主环境不一致，主要指内核

第二个因素很好排除，我们对比了两个测试环境的宿主内核版本，结果是一致的。所以，基本还是因 docker 代码升级而产生的行为不一致。理论上，我们只需逐个分析 docker 1.13.1 与 docker 18.06.3-ce 两个版本间的所有提交记录，就一定能够定位到关键提交信息，大力总是会出现奇迹。

但是，我们还是希望能够从现场中发现有用信息，缩小检索范围。

仍然从挂载点切入，既然两个版本的 docker 所创建的挂载点在共享命名空间中就已经出现差异，我们顺藤摸瓜，找找容器读写层挂载点链路上是否存在差异：

// docker 1.13.1
// 本挂载点
[stupig@hostname2 ~]$ grep -rw /home/docker_rt/overlay2/4e09fa6803feab9d96fe72a44fb83d757c1788812ff60071ac2e62a5cf14cd97/merged /proc/$$/mountinfo
223 1143 0:40 / /home/docker_rt/overlay2/4e09fa6803feab9d96fe72a44fb83d757c1788812ff60071ac2e62a5cf14cd97/merged rw,relatime - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX


// 定位本挂载点的父挂载点
[stupig@hostname2 ~]$ grep -rw 1143 /proc/$$/mountinfo
1143 44 8:4 /docker_rt/overlay2 /home/docker_rt/overlay2 rw,relatime - xfs /dev/sda4 rw,attr2,inode64,logbsize=256k,sunit=512,swidth=512,prjquota


// 继续定位祖父挂载点
[stupig@hostname2 ~]$ grep -rw 44 /proc/$$/mountinfo
44 39 8:4 / /home rw,relatime shared:28 - xfs /dev/sda4 rw,attr2,inode64,logbsize=256k,sunit=512,swidth=512,prjquota


// 继续往上
[stupig@hostname2 ~]$ grep -rw 39 /proc/$$/mountinfo
39 1 8:3 / / rw,relatime shared:1 - ext4 /dev/sda3 rw,stripe=64,data=ordered


// docker 18.06.3-ce
// 本挂载点
[stupig@hostname ~]$ grep -rw /home/docker_rt/overlay2/a9823ed6b3c5a752eaa92072ff9d91dbe1467ceece3eedf613bf6ffaa5183b76/merged /proc/$$/mountinfo
218 43 0:105 / /home/docker_rt/overlay2/a9823ed6b3c5a752eaa92072ff9d91dbe1467ceece3eedf613bf6ffaa5183b76/merged rw,relatime shared:109 - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX


// 定位本挂在点的父挂载点
[stupig@hostname ~]$ grep -rw 43 /proc/$$/mountinfo
43 61 8:17 / /home rw,noatime shared:29 - xfs /dev/sdb1 rw,attr2,nobarrier,inode64,prjquota


// 继续定位祖父挂载点
[stupig@hostname ~]$ grep -rw 61 /proc/$$/mountinfo
61 1 8:3 / / rw,relatime shared:1 - ext4 /dev/sda3 rw,data=ordered

两个版本的 docker 所创建的容器读写层挂载点链路上差异还是非常明显的：

  • 容器读写层挂载点的父级挂载点不同

    • docker 18.06.3-ce 创建的容器读写层挂载点的父级挂载点是 /home/ ，并且是共享的

    • docker 1.13.1 创建的容器读写层挂载点的父级挂载点是 /home/docker_rt/overlay2 ，并且是私有的

这里补充一个背景，弹性云机器在初始化阶段，会将 /home 初始化为 xfs 文件系统类型，因此所有宿主上 /home 挂载点都具备相同属性。

那么，问题基本就是由 docker 1.13.1 中多出的一层挂载层 /home/docker_rt/overlay2 引起。

如何验证这个猜想呢？现在，其实我们已经具备了检索代码的关键目标，docker 1.13.1 会设置容器镜像层根目录的传递属性。拿着这个先验知识，我们直接查代码，检索过程基本没费什么功夫，直接展示相关代码：

// filepath: daemon/graphdriver/overlay2/overlay.go
func init() {
   graphdriver.Register(driverName, Init)
}

func Init(home string, options []string, uidMaps, gidMaps []idtools.IDMap) (graphdriver.Driver, error) {
   if err := mount.MakePrivate(home); err != nil {
      return nil, err
   }

   supportsDType, err := fsutils.SupportsDType(home)
   if err != nil {
      return nil, err
   }
   if !supportsDType {
      // not a fatal error until v1.16 (#27443)
      logrus.Warn(overlayutils.ErrDTypeNotSupported("overlay2", backingFs))
   }

   d := &Driver{
      home:          home,
      uidMaps:       uidMaps,
      gidMaps:       gidMaps,
      ctr:           graphdriver.NewRefCounter(graphdriver.NewFsChecker(graphdriver.FsMagicOverlay)),
      supportsDType: supportsDType,
   }

   d.naiveDiff = graphdriver.NewNaiveDiffDriver(d, uidMaps, gidMaps)

   if backingFs == "xfs" {
      // Try to enable project quota support over xfs.
      if d.quotaCtl, err = quota.NewControl(home); err == nil {
         projectQuotaSupported = true
      }
   }

   return d, nil
}

很明显，问题就出在 mount.MakePrivate 函数调用上。

官方将 GraphDriver 根目录设置为 Private，本意是为了避免容器读写层挂载点泄漏。那为什么在高版本中去掉了这个逻辑呢？显然官方也意识到这么做并不能实现期望的目的，官方也在修复[4]中给出了详细说明。

实际上，不设置 GraphDriver 根目录的传播属性，反而能避免绝大多数挂载点泄漏的问题。。。

4. 结语

现在，我们已经了解了问题的来龙去脉，我们总结下问题的解决方案：

  • 针对 1.13.1 版本 docker，存量宿主较多，我们可以忽略 device or resource busy 问题，基本也不会给线上服务带来什么影响

  • 针对 18.06.3-ce 版本 docker，存量宿主较少，我们删除 docker 服务的 systemd 配置项 MountFlags，通过故障自愈解决 docker 卡在问题

    • 在容器创建后，卸载容器读写层挂载，如果不影响容器内文件访问。那么可以直接卸载所有挂载点，修改 docker 配置，并重启 docker 服务【本方案尚未验证】

  • 针对增量宿主，全部删除 docker 服务的 systemd 配置项 MountFlags

参考资料

[1]

docker device busy 问题解决方案: https://blog.terminus.io/docker-device-is-busy/

[2]

docker device busy 问题解决方案: https://blog.terminus.io/docker-device-is-busy/

[3]

mount 命名空间说明文档: https://man7.org/linux/man-pages/man7/mount_namespaces.7.html

[4]

修复: https://github.com/moby/moby/pull/36047

原文链接：https://www.likakuli.com/posts/docker-pod-terminating2/


你可能还喜欢

点击下方图片即可阅读

Docker 限速不用怕，因为我有 Grafana

云原生是一种信仰 ????

扫码关注公众号

后台回复◉k8s◉获取史上最方便快捷的 Kubernetes 高可用部署工具，只需一条命令，连 ssh 都不需要！

点击 "阅读原文" 获取更好的阅读体验！

❤️给个「在看」，是对我最大的支持❤️
米开朗基杨
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
《CKA/CKAD应试指南/从docker到kubernetes 完全攻略》学习笔记 第5章 pod （5.2-5.3-5.4-5.5）
日拱一足
04-28 327
先把这些准备工作做完，再运行容器C1就可以把容器A和容器B配置成容器C1的初始化容器。kubectl cp pod:/path2/file2 /path1/file2 把容器里目录 /path2/里的东西拷贝到物理机的/path1里 注意：如果从容器里拷贝的是文件不是目录的话，则需要在物理机里指定文件名。在普通容器podx里，会把存储卷workdir挂载到本容器的/xx里，访问/xx的时候实际上访问的就是存储卷workdir，这样在普通容器podx里应该是能看到/xx里面有aa.txt的。
kubernetes Pod&资源清单
qq_45070541的博客
12-13 451
kubernetes资源清单&资源控制器
从容器里umount 一个/dev/rbd设备
dengxiafubi的博客
01-15 1399
背景： 　　(1) 我们的平台docker默认的挂载方式是MountFlags=slave, 该挂载方式的一个特性是：一旦某个container的以这种方式挂载后启动后，则host节点的信息变动，不会再同步到container里 (2) 因为节点监控数据采集工具node-exporter, 需要挂载host节点的根目录，若以MountFlags=slave的方式挂载，会导致节点...
docker恢复 /var/run/netns 删除恢复
yuezhilangniao的博客
09-27 1442
原文：/var/run/netns恢复 http://www.dockone.io/article/5272 背景 docker使用namespace实现网络，计算等资源的隔离，当需要排查网络问题时，使用p netns命令却无法在主机上看到任何network namespace，这是因为默认docker把创建的网络命名空间链接文件隐藏起来了，导致ip netns命令无法读取，给分析网络原理和排查问题带来了麻烦。 下面是恢复netns命名空间的办法。 恢复容器的netns 执行下面的命令来获取容器进程号 do
Docker 问题汇总
柳清风的专栏
08-23 2359
没法退出问题 当我们通过exec进入docker容器后，执行完一大堆命令后执行exit退出发现没法退出，一直提示 There are stopped jobs 其实这个和docker本身没有关系，是控制台关联的后端程序没有停止，子程序没有退出 可以通过jobs命令查看后端任务。 ps 找出相关的进程，然后关闭即可...
Kubernetes版本对接对象存储几种方案
琦彦
04-27 5854
Kubernetes版本对接对象存储 文章目录Kubernetes版本对接对象存储对象存储社区方案方案1：Object Storage API (COSI)**[方案2：csi-s3](https://github.com/ctrox/csi-s3)**Kubernetes 要求MountFlags为什么要将S3 以文件存储的方式挂载到 Kubernetes 平台?什么是 S3FS ？后续参考链接 对象存储 想要通过创建 PersistentVolume（PV）/PersistentVolumeClai
linux udev 自动挂载,udev自动挂载 - wuqingyan的个人空间 - OSCHINA - 中文开源技术交流社区...
weixin_32252929的博客
05-12 285
1、cp /usr/lib/systemd/system/systemd-udevd.service /etc/systemd/system/systemd-udevd.service2、sed 's#MountFlags=slave#MountFlags=shared#' systemd-udevd.service3、systemctl restart systemd-udevd.service...
K8S 学习四（POD详解）
qq_42427924的博客
02-09 2580
POD详解 POD结构 每个pod中都可以包含一个或者多个容器，这些容器可以分为两类： 1） 用户程序所在的容器，数量可多可少（上图的第一、第二层） 2) Pause容器，这是每个pod都会有的一个根容器，它的作用有两个 ： 2.1）可以以它为依据，评估整个Pod的健康状态 2.2） 可以在根容器上设置IP地址，其他容器都以此IP（Pod ip），以实现POD内部的网路通信 这里POD内部的通讯，POD之间的通讯采用虚拟二层网络技术来实现，我们当...
k8s入门
Jsben的博客
04-23 1655
第1章 k8s系统架构 从系统架构来看，k8s分为2个节点 Master 控制节点 指挥官 Node 工作节点 干活的 1.Master节点组成 API Server ：提供k8s API接口 主要处理Rest操作以及更新Etcd中的对象 是所有资源增删改查的唯一入口。 Scheduler：资源调度器 根据etcd里的节点资源状态决定将Pod绑定到哪个Node上 Controller ...
【k8s】kube-scheduler
qq_41123190的博客
06-17 1127
Scheduler在整个系统中承担了“承上启下”的重要功能。“承上”是指它负责接受Controller Manager创建的新Pod，为其安排Node；“启下”是指安置工作完成后，目标Node上的kubelet服务进程接管后续工作。Pod是Kubernetes中最小的调度单元，Pod被创建出来的工作流程如图所示：在这张图中通过这个流程我们可以看出整个过程中最重要的就是apiserver watch API和kube-scheduler的调度策略。总之，kube-scheduler的功能是为还没有和任何Nod
docker安装配置
wq1205750492的博客
04-29 8412
一、docker配置参数 docker.service文件内容 /usr/lib/systemd/system/docker.service [Unit] Description=Docker Application Container Engine Documentation=http://docs.docker.com After=network.target Wants=docker-storage-setup.service Requires=docker-cleanup.timer [Servi
谈谈k8s1.12新特性--Mount propagation(挂载命名空间的传播)
weixin_34021089的博客
09-29 1425
Mount propagation 挂载传播允许将Container挂载的卷共享到同一Pod中的其他Container，甚至可以共享到同一节点上的其他Pod。一个卷的挂载传播由Container.volumeMounts中的mountPropagation字段控制。它的值是： None 此卷挂载不会接收到任何后续挂载到该卷或是挂载到该卷...
docker 删除容器的时候出现的bug解决方案
纵横四海的博客
09-14 1885
相关的issuesvi /etc/docker/daemon.json 的参数 "live-restore": false/usr/lib/systemd/system/docker.service 添加了参数 MountFlags=slave
kubernetes 升级问题笔录
纵横四海的博客
09-21 2万+
本笔录主要是记录kubernetes从v1.7.6升级到v1.11.2的问题以及相关的解决办法 问题一:不能访问master的10255 日志 [root@test-master-113 qinzhao]# kubectl logs heapster-1967565778-v5wkr -n kube-system heapster I0918 10:37:05.893124 1 he...
Docker 故障device or resource busy
XiaoXiao__cc的博客
09-04 1万+
Docker 故障（device or resource busy） 概述：最近遇到几次出现device or resource busy的报错，当时以为是devicemapper系统的问题但是经过查资料发现这是docker的一个bug，所以就总结了下面这个写内容，希望跟大家多多交流。 出现故障原因 .CentOS/RedHat 3.10.0内核NameSpace bug，...
Docker1.10.1以上版本配置http API访问
The magic of fingertips
05-23 2040
修改文件 # vi /usr/lib/systemd/system/docker.service 修改为如下方式 [Unit] Description=Docker Application Container Engine Documentation=https://docs.docker.com After=network.target doc
linux脚本攻击驱动,linux – 从udev规则和shell脚本自动挂载usb驱动器
weixin_34693167的博客
05-06 285
我正在尝试自动安装连接到我的电脑的任何USB驱动器.我的目标是使用标签安装usb设备(如果有的话),如果没有,则使用uuid.为此,我在/etc/udev/rules.d/10-usb-detect.rules中写了一个udev规则：ACTION=="add", KERNEL=="sd?[0-9]", SUBSYSTEM=="block", RUN+="/usr/local/bin/add.sh"...
Docker数据卷挂载命令volume(-v)与mount的总结
热门推荐
SchRHT Blog
05-22 4万+
命令用法 参数--mount是用来挂载volume的，这些volume可以通过docker volume进行管理。示例： docker run --name $CONTAINER_NAME -it \ --mount source=${CONTAINER_NAME}-app,destination=/app \ --mount source=${CONTAINER_NAME}-data,destination=/data,readonly \ --mount source=${CONTAINER_NAME}
pod的terminating是什么状态
最新发布
06-02
Pod的Terminating状态表示该Pod正在被删除。当您使用kubectl delete命令删除Pod或者删除Pod的控制器（如Deployment、ReplicaSet等），Kubernetes会将该Pod的状态更改为Terminating，并开始删除该Pod。 在...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值