kubernetes - 在 kubernetes 中挂载传播

Question

我正在使用 Mount propagation Kubernetes 的功能，用于检查特定类型挂载点的健康状况。我创建了一个 daemonset 并运行一个脚本，该脚本将在这些挂载点上执行简单的 ls。我注意到 Pod 中没有列出新的挂载点。这是预期的行为吗。

volumeMounts:
            - mountPath: /host
              name: host-kubelet
              mountPropagation: HostToContainer
      volumes:
          - name: host-kubelet
            hostPath:
              path: /var/lib/kubelet

相关问题:hostPath containing mounts do not update as they change on the host #44713

Answer 1

简而言之，Mount propagation 允许将一个 Container 挂载的卷共享给同一 Pod 中的其他 Container，甚至共享给同一节点上的其他 Pod。
卷的装载传播由 Container.volumeMounts 中的 mountPropagation 字段控制。它的值是:

• HostToContainer - 从主机到容器的单向传播。如果你在卷内安装任何东西，容器会在那里看到它。
• 双向 - 除了从主机到容器的传播之外，容器创建的所有卷安装都将传播回主机，因此使用相同卷的所有 Pod 的所有容器都将也看到了。

基于 documentation集群 v1.9 的 Mount 传播功能处于 alpha 状态，并将在 v1.10 上成为 beta

我在 kubernetes v1.9.2 上重现了你的案例，发现它完全忽略了 MountPropagation 配置参数。如果您尝试检查 DaemonSet 或 Deployment 的当前状态，您会发现列出的 yaml 配置中缺少此选项

$ kubectl get daemonset --export -o yaml

如果您尝试只运行带有挂载传播选项的 docker 容器，您可能会看到它按预期工作:

docker run -d -it -v /tmp/mnt:/tmp/mnt:rshared ubuntu

在卷挂载部分比较 docker 容器配置与 kubernetes pod 容器，您可能会看到 kubernetes 容器中缺少最后一个标志 (shared/rshared)。

这就是它发生在 Google kubernetes clusters 中的原因并且可能发生在由其他供应商管理的集群上:

To ensure stability and production quality, normal Kubernetes Engine clusters only enable features that are beta or higher. Alpha features are not enabled on normal clusters because they are not production-ready or upgradeable.

Since Kubernetes Engine automatically upgrades the Kubernetes control plane, enabling alpha features in production could jeopardize the reliability of the cluster if there are breaking changes in a new version.

Alpha level features availability :致力于主要的 kubernetes repo ；出现在官方发布中；默认情况下禁用该功能，但可以通过标志启用(如果您能够设置标志)

在挂载传播可以在某些部署(CoreOS、RedHat/Centos、Ubuntu)上正常工作之前，必须在 Docker 中正确配置挂载共享，如下所示。

编辑 Docker 的 systemd 服务文件。设置 MountFlags 如下:

MountFlags=shared

或者，删除 MountFlags=slave(如果存在)。然后重启 Docker 守护进程:

 $ sudo systemctl daemon-reload
 $ sudo systemctl restart docker