k8s configmap subpath bug

mount的subpath为原子操作，如果文件内容发生变化，会重新生成时间戳，导致原来的mount path失效。
如果此时容器发生了OOM，或者其他问题导致容器重启，那么容器将无法启动，因为mount的源已经不存在了。此问题将会在1.9版本修复
https://github.com/kubernetes/kubernetes/pull/89629

pod使用shareProcessNamespace: true

从 k8s v1.17+ 起 ，ShareProcessNamespace
字段 就已经是 stable 状态了，启用后pod 中多个容器间可以共享进程，Infra容器中启动一个pause的进程作为1号进程管理pod 中的子进程，这样就可以回收容器中的僵尸进程了。

理解进程命名空间共享

  1. 容器进程不再具有 PID 1。 在没有 PID 1 的情况下，一些容器镜像拒绝启动（例如，使用 systemd 的容器)，或者拒绝执行 kill -HUP 1 之类的命令来通知容器进程。在具有共享进程命名空间的 pod 中，kill -HUP 1 将通知 pod 沙箱（在上面的例子中是 /pause）。
  2. 进程对 pod 中的其他容器可见。 这包括 /proc 中可见的所有信息，例如作为参数或环境变量传递的密码。这些仅受常规 Unix 权限的保护。
  3. 容器文件系统通过 /proc/$pid/root 链接对 pod 中的其他容器可见。 这使调试更加容易，但也意味着文件系统安全性只受文件系统权限的保护。

参考：