以下内容转载自：kubernetes 的挂载传播(mount propagation)机制

概述

今天在看 kubectl-debug 这个项目的时候，看到其部署文件的 volumeMounuts 中使用了一个 mountPropagation 字段，因为不清楚这个字段的作用，就做了一下了解。mount propagation 背后的东西还是很多的，因此整理了这篇文章，顺便梳理一下知识点。

kubernetes 的 mount propagation 翻译成中文就是挂载传播。挂载传播提供了共享卷挂载的能力，它允许在同一个 Pod，甚至同一个节点内，在多个容器之间共享卷的挂载。

kubernetes 的挂载传播

卷的挂载传播由 Container.volumeMounts 的 mountPropagation 字段控制。它的值有：

• None: 这种卷挂载将不会收到任何后续由 host 创建的在这个卷上或其子目录上的挂载。同样的，由容器创建的挂载在 host 上也是不可见的。这是默认的模式。这个其实很好理解，就是容器内和 host 的后续挂载完全隔离。
• HostToContainer: 这种卷挂载将会收到之后所有的由 host 创建在该卷上或其子目录上的挂载。换句话说，如果 host 在卷挂载内挂载的任何内容，在容器中都是可见的。同样，如果任何具有 Bidirectional 的 Pod 挂载传播到该卷挂载上，具有 HostToContainer 的挂载传播都可以看见。整个挂载传播的流程如下：

• Bidirectional: 这种挂载机制和 HostToContainer 类似。此外，任何在容器中创建的挂载都会传播到 host，然后传播到使用相同卷的所有 Pod 的所有容器。注意：Bidirectional 挂载传播是很危险的。可能会危害到 host 的操作系统。因此只有特权容器在允许使用它。

在了解了这几种挂载传播之后，我们可以做一些实验来验证一下，首先验证的是 None 的挂载传播类型，我们创建一个 nginx 的Pod:

apiVersion: v1
kind: Pod
metadata:
    name: mount-a
    namespace: default
    label:
      app: mount
spec:
    containers:
    - name: main
      image: nginx:latest
      volumeMounts:
      - name: testmount
        mountPath: /home
        mountPropagation: None
    volumes:
    - name: testmount
      hostPath:
        path: /mnt/

YAML

然后我们分别向 host 的 /mnt 和容器的 /home 下挂载目录并查看容器和 host 的情况：

容器中：

$ kubectl exec -it mount-a sh
$ cd /home
$ ls 
sda1

Bash

host 上：

$ cd /mnt
$ ls 
sda1

Bash

然后在 host 上创建挂载：

$ mkdir /mnt/none
$ sudo mount --bind /var /mnt/none
$ ls none
cache  empty  lib  lock  log  run  spool  tmp

Bash

这个时候，我们再看容器中的文件：

$ ls none
# 无输出

Bash

这说明 host 上在该卷下的挂载并不会改变容器中的文件。接下来我们可以在容器中按照上面的方案来验证容器中的挂载也不会影响 host 中的目录视图。这里就不展示了。接下来看一下 HostToContainer 的挂载传播，我们将上面的 Pod 的 mountPropagation 字段改成 HostToContainer，然后先取消 host 上的挂载：

sudo umoint /mnt/none

然后重新创建 Pod，和上面一样，在 host 上创建挂载，查看容器中的挂载情况：

$ ls none
cache  empty  lib  lock  log  run  spool  tmp

Bash

host 上的挂载因为 HostToContainer 机制传播到了容器中。我们继续看最后一种 Bidirectional 机制。这次我们要创建两个 Pod: mount-a, mount-b，并把 mountPropagation 字段改成 Bidirectional。注意，因为 Bidirectional 是危险的，所以只有特权容器才可以使用。因此这里还需要把容器改成特权模式，最后在 mount-a 中的容器执行挂载，验证挂载是否传播到 host 和 mount-b 的容器中。

apiVersion: v1
kind: Pod
metadata:
    name: mount-a
    namespace: default
    labels:
      app: mount
spec:
    containers:
    - name: main
      image: nginx:latest
      securityContext:
        privileged: true
      volumeMounts:
      - name: testmount
        mountPath: /home
        mountPropagation: Bidirectional
    volumes:
    - name: testmount
      hostPath:
        path: /mnt/
---
apiVersion: v1
kind: Pod
metadata:
    name: mount-b
    namespace: default
    labels:
      app: mount
spec:
    containers:
    - name: main
      image: nginx:latest
      securityContext:
        privileged: true
      volumeMounts:
      - name: testmount
        mountPath: /home
        mountPropagation: Bidirectional
    volumes:
    - name: testmount
      hostPath:
        path: /mnt/

YAML

然后进入 mount-a，创建挂载：

$ kubectl exec -it mount-a sh
$ su
$ mount --bind /var /home/none
$ ls /home/none
backups  lib    lock  mail  run    tmp
cache    local  log   opt   spool

Bash

这时候查看 host 下的 /mnt/none:

$ ls /mnt/none
backups  lib    lock  mail  run    tmp
cache    local  log   opt   spool

Bash

可以发现，容器中的挂载传播到了 host 上。这时候再查看 mount-b 中的容器。

$ ls /home/none
backups  lib    lock  mail  run    tmp
cache    local  log   opt   spool

Bash

挂载也传播到了 mount-b 的容器中。

linux mount 的几种类型

上面分析了 kubernetes 的挂载传播机制，在 linux mount 中，也有类似的概念。mount 分为下面几种：

• shared mount： 相当于上面所说的 Bidirectional 的挂载传播
• slave mount： 每个 slave mount 都有一个 shared master mount，挂载传播只能从 master -> slave，等同于上面的 HostToContainer， host 是 master，container 是 slave。
• private mount： 很明显，private 就是相当于 None，挂载不会向任何一方传播。
• unbindable mount：unbindable mount 其实就是 unbindable private mount，也就是不允许使用 --bind 的挂载。

mount namespace 的机制

kubernetes 的挂载传播不是其本身实现的，也不是 docker 之类的容器运行时提供的。这是由容器化技术的基础：linux namespace 提供的，linux namespace 当前共有 6 种:

• cgroup namespace: 隔离 cgroup 根目录
• pid namespace: 隔离进程 id
• ipc namespace: 隔离 System V IPC, POSIX message queues
• uts namespace: 隔离 Hostname 和 NIS domain name
• user namespace: 隔离用户和用户组 ID
• mount namespace: 隔离挂载点
• network namespace: 隔离网络设备，网络栈，端口等

其中，mount namespace 是这篇文章的重点。我们可以通过 clone 调用来看看 mount namespace 的使用：

#define _GNU_SOURCE
#include <stdio.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <sys/mount.h>
#include <sched.h>
#include <signal.h>
#include <unistd.h>

#define STACK_SIZE (1024*1024)
static char container_stack[STACK_SIZE];

char* const container_args[] = {
    "/bin/bash",
    NULL
};

int container_main(void* arg)
{
    printf("Container [%5d] - inside the container!\n", getpid());
    mount("none", "/", NULL, MS_REC|MS_PRIVATE, NULL);
    execv(container_args[0], container_args);
    printf("Something's wrong!\n");
    return 1;
}
int main()
{
    printf("Parent [%5d] - start a container!\n", getpid());
    /* 启用Mount Namespace - 增加CLONE_NEWNS参数 */
    int container_pid = clone(container_main, container_stack+STACK_SIZE, CLONE_NEWNS | SIGCHLD, NULL);
    waitpid(container_pid, NULL, 0);
    printf("Parent - container stopped!\n");
    return 0;
}

C

编译运行:

$ gcc main.c -o mount
$ sudo ./mount

Bash

然后尝试挂载，来验证挂载 MS_PRIVATE 的挂载传播问题。MS_PRIVATE 下 namespace 内和 host 应该是隔离的。MS_PRIVATE 还可以替换成 MS_UNBINDABLE， MS_SLAVE，MS_SHARED。

关于更多的 namespace 的资料，建议看这两篇文章：

• DOCKER基础技术：LINUX NAMESPACE（上）
• DOCKER基础技术：LINUX NAMESPACE（下）

参考资料

• MOUNT_NAMESPACES
• NAMESPACES
• Shared Subtrees
• DOCKER基础技术：LINUX NAMESPACE（上）
• DOCKER基础技术：LINUX NAMESPACE（下）
• Namespace 在 Kernel 里是怎么实现的？以 mount namespace 为例
• Mount propagation

  References

• kubernetes 的挂载传播(mount propagation)机制

TL;DR

Octant 是一个以开发人员为中心的开源 Kubernetes Web 界面，可让您检查 Kubernetes 集群及其应用程序，能够帮助开发人员更好理解 Kubernetes 集群复杂性的平台。在这里发现的。

虽然 VMware 已结束该项目的积极开发 ，但看起来确实很好用，收藏备用。

# ArchLinux
yay -S octant-bin

# Windows
choco install octant --confirm

# MacOS
brew install octant

Usage

octant

References

• vmware-archive/octant
• https://aur.archlinux.org/packages/octant-bin
• https://octant.dev/

TL;DR

配置 ingress 服务时调整一下大小即可：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress-with-annotations
  annotations:
    nginx.org/proxy-connect-timeout: "30s"
    nginx.org/proxy-read-timeout: "20s"
    nginx.org/client-max-body-size: "4m"
    nginx.org/server-snippets: |
      location / {
        return 302 /coffee;
      }      
spec:
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /tea
        pathType: Prefix
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      - path: /coffee
        pathType: Prefix
        backend:
          service:
            name: coffee-svc
            port:
              number: 80

References

• Nginx Ingress returns 413 Entity Too Large
• Advanced configuration with Annotations

From V

以下内容转载自 https://www.v2ex.com/t/968514#r_13557021

k8s 这个东西真的内容太多了，没有啥系统性的资料，里面各种知识点真的没法说，太多了，最好的就是看官方文档，并且结合工作当中的实践慢慢积累，才能由浅入深，只是看文档想掌握深点，个人感觉很困难。

如果你不是专做这行，只是把它当作你应用部署的底层平台的话可以给你个简单的流程做参考：
1 、云服务商买一套，或者自己搭建个 k8s 环境
2 、运行起来一套简单的前后端分离服务，这里主要练习的是多个镜像启动多个不同的 workload ，然后怎么能互相访问对接，这个环节能掌握清楚 workload service ingress 都是干嘛的，该怎么用，怎么关联
3 、你会发现当你测试环境发生重启，或者 pod 重建后，数据库数据都没了，这会你就应该研究数据持久化了，pv pvc 的概念就出来了
5 、然后你又创建了个前端服务，想修改个前端页面的配置文件参数，比如网页的 title ，其他都一模一样，但是每个服务一个镜像，太麻烦了，容器里直接修改，重建就没了，配置文件放 pv pvc ，太小题大做，这会 configmap 出现了。连接数据库的配置文件，密钥明文，太 low 了，secret 出现了
6 、前端页面镜像有 bug ，必须要重打镜像了，cicd 出现了，你是选择 docker build 还是 jenkins ，新的知识又增加了
7 、更新 workload 的镜像，问题又来了，服务会不会受损，多副本就不会受损吗？如何优雅终止，健康检查，无损更新？
8 、服务高峰期怎么应对，手动扩副本数太傻，hpa 来了

如果你想深点，做些 k8s 运维或者技术支持的，那么除了上面的必须熟悉，下面的东西必知必会
1 、清楚 k8s 的工作逻辑，master 的三大件是干嘛的，kubelet ，kube-proxy ，coredns 都是干嘛的，比如执行个创建或查询一个 workload ，系统组件之间怎么通讯的，创建一个 pod 后，容器网络和外界是怎么打通的，k8s 资源调度和分配逻辑是什么
2 、自己搭建一套 k8s 集群，多 master 的最好，master 和 worker 节点分开（一定是自己搭建，不要购买云服务商现成的容器服务，自己搭建过程你会收获不少东西）
3 、熟练使用 kubectl 命令进行各种查询分析
4 、清楚 rbac 的功能和使用

剩下的太多太多了，说不完了，
等你发现 k8s 了解差不多了，发现总得有个监控吧，prometheus 出现了
流量治理，服务分析也得有吧，istio 来了
日志得持久化保存下吧，els 来了
学了那么多了，得给老板展示下漂亮帅气的监控吧，得研究 grafana 了。
服务都上 k8s 了，集群越来越重要，万一哪天 etcd 崩了怎么办，备份总得有吧，etcd 原理和备份恢复得研究下吧。
想自建镜像仓库了？ harbor 研究下。
这个云平台太贵了，业务想换个云平台，集群要迁移，velero 走起
想给 pod 限速了，想给集群加审计了。。。。

References

• https://www.v2ex.com/t/968514#r_13557021

demo ingress

这个实例中，实现将 访问 https://image.frytea.com/Avatar.jpg 请求302到 https://image.frytea.com/i/Avatar.jpg

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app
  namespace: imagehost
  annotations:
    cert-manager.io/cluster-issuer: "dnspod-cluster-issuer"
    nginx.ingress.kubernetes.io/configuration-snippet: |
      location = /Avatar.jpg {
        return 301 https://image.frytea.com/i/Avatar.jpg$is_args$args;
      }
spec:
  ingressClassName: nginx
  tls:
  - hosts:
      - image.frytea.com
      - imagehost-cdn.frytea.com
      - cdn-imagehost.frytea.com
    secretName: image-frytea-com-tls
  rules:
  - host: image.frytea.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app
            port:
              name: web

直接配置会提示报错：

➜  imagehost git:(main) ✗ kubectl apply -f ingress.yaml  
Error from server (BadRequest): error when applying patch:  
{"metadata":{"annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"networking.k8s.io/v1\",\"kind\":\"Ingress\",\"metadata\":{\"annotati  
ons\":{\"cert-manager.io/cluster-issuer\":\"dnspod-cluster-issuer\",\"nginx.ingress.kubernetes.io/configuration-snippet\":\"location = /Avatar.jpg {\\n  return 301 ht  
tps://image.frytea.com/i/Avatar.jpg$is_args$args;\\n}\\n\"},\"name\":\"app\",\"namespace\":\"imagehost\"},\"spec\":{\"ingressClassName\":\"nginx\",\"rules\":[{\"host\  
":\"image.frytea.com\",\"http\":{\"paths\":[{\"backend\":{\"service\":{\"name\":\"app\",\"port\":{\"name\":\"web\"}}},\"path\":\"/\",\"pathType\":\"Prefix\"}]}},{\"ho  
st\":\"imagehost-cdn.frytea.com\",\"http\":{\"paths\":[{\"backend\":{\"service\":{\"name\":\"app\",\"port\":{\"name\":\"web\"}}},\"path\":\"/\",\"pathType\":\"Prefix\  
"}]}},{\"host\":\"cdn-imagehost.frytea.com\",\"http\":{\"paths\":[{\"backend\":{\"service\":{\"name\":\"app\",\"port\":{\"name\":\"web\"}}},\"path\":\"/\",\"pathType\  
":\"Prefix\"}]}}],\"tls\":[{\"hosts\":[\"image.frytea.com\",\"imagehost-cdn.frytea.com\",\"cdn-imagehost.frytea.com\"],\"secretName\":\"image-frytea-com-tls\"}]}}\n",  
"nginx.ingress.kubernetes.io/configuration-snippet":"location = /Avatar.jpg {\n  return 301 https://image.frytea.com/i/Avatar.jpg$is_args$args;\n}\n","nginx.ingress.k  
ubernetes.io/rewrite-rule":null}}}  
to:  
Resource: "networking.k8s.io/v1, Resource=ingresses", GroupVersionKind: "networking.k8s.io/v1, Kind=Ingress"  
Name: "app", Namespace: "imagehost"  
for: "ingress.yaml": error when patching "ingress.yaml": admission webhook "validate.nginx.ingress.kubernetes.io" denied the request: annotation group ConfigurationSn  
ippet contains risky annotation based on ingress configuration

这个错误来自于 Nginx Ingress Controller 自带的一个叫做 “Admission Webhook” 的安全校验机制。它的作用是在你创建或更新 Ingress 资源时进行检查，防止应用不安全或可能导致问题的配置。 很多 Nginx Ingress Controller 的默认安装配置或者管理员策略会禁用或限制 configuration-snippet 和 server-snippet 这类强大的注解

开启 Snippet 注释

使用 helm 部署的 nginx-ingress ，首先修改 Values.yaml 中的内容，启动

controller:
  allowSnippetAnnotations: true

将配置应用到集群：

helm upgrade --install ingress-nginx ingress-nginx  \
    --repo https://kubernetes.github.io/ingress-nginx  \
    --namespace ingress-nginx --create-namespace -f vaules.yaml

之后调整 ConfigMap

kubectl -n ingress-nginx edit cm ingress-nginx-controller

增加两行：

...
apiVersion: v1
data:
  allow-snippet-annotations: "true"
  annotations-risk-level: Critical
  use-forwarded-headers: "true"
kind: ConfigMap
...

其中 ：

• annotations-risk-level: Critical: 设置 Webhook 接受的最高风险门槛，确保 Snippets（作为 Critical 风险注解）在被评估时不会因为风险等级过高而被直接拒绝，从而让 allow-snippet-annotations 的设置能够生效
• use-forwarded-headers: "true": 告诉 Nginx Ingress Controller 信任并使用由其上游代理（通常是你的云服务商提供的负载均衡器，如 AWS ELB/ALB/NLB, GCP Load Balancer, Azure Load Balancer 等）设置的 X-Forwarded-* 或 Forwarded HTTP 头部信息，来确定原始客户端的真实信息

再重启所有 nginx controller

kubectl rollout restart -n ingress-nginx daemonset ingress-nginx-controller

之后在尝试 apply 上面的 demo 就可以成功了。

References

• Admission Controller Error with allowSnippetAnnotations: true #12648
• Gemini 2.5 Pro

下面介绍更新 Deployment 以重新拉取相同标签镜像的方法，不要只会杀 pod 触发了，个人最喜欢方法二。

当镜像名称和标签都没有变化，但需要重新拉取镜像时（比如镜像内容已更新但标签保持不变），可以采用以下方法：

方法一：修改 Pod 模板以触发重新部署

为 Deployment 的 Pod 模板添加或更新一个注释（annotation）来触发滚动更新：

kubectl patch deployment [deployment-name] -p \
  "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"kubectl.kubernetes.io/restartedAt\":\"$(date +%s)\"}}}}}"

这会添加或更新一个时间戳注释，使 Kubernetes 认为 Pod 模板已更改，从而触发重新部署。

方法二：强制重启 Deployment

kubectl rollout restart deployment/[deployment-name]

这是 Kubernetes 1.15 及更高版本提供的便捷命令，效果与方法一类似。

方法三：修改 imagePullPolicy

确保容器的 imagePullPolicy 设置为 Always，这样每次 Pod 重启都会重新拉取镜像：

kubectl patch deployment [deployment-name] -p '{"spec":{"template":{"spec":{"containers":[{"name":"[container-name]","imagePullPolicy":"Always"}]}}}}'

设置后，可以使用方法一或方法二触发重新部署。

方法四：删除 Pod（不推荐）

手动删除 Pod，让 Deployment 控制器创建新的 Pod：

kubectl delete pod -l app=[your-app-label]

注意： 此方法不推荐用于生产环境，因为它可能导致服务中断。

最佳实践建议

1. 始终使用唯一标签：最好的做法是为每个新版本的镜像使用唯一标签，如使用 Git commit SHA 或时间戳。

2. 设置 Always 拉取策略：在 Deployment 中设置：

   spec:
     template:
       spec:
         containers:
         - name: your-container
           image: your-image:tag
           imagePullPolicy: Always

3. 对于生产环境：推荐使用前两种方法（添加注释或使用 rollout restart），它们符合 Kubernetes 的声明式设计理念，并且会进行受控的滚动更新。

使用 kubectl rollout restart deployment/[deployment-name] 是最简单且符合 Kubernetes 最佳实践的方式。