不能通过BindMount实现容器内对宿主机内核参数的动态修改，因其仅支持文件系统共享，无法突破命名空间隔离，且写入/proc/sys会因权限或上下文限制被拒绝。
不能通过 bindmount 实现容器内部对宿主机内核参数的动态修改。
BindMount 的作用范围有限
BindMount 是将宿主机上的文件或目录挂载到容器内，实现文件系统层面的数据共享。它不提供内核参数控制能力，也不突破命名空间隔离边界。
- 内核参数（如 /proc/sys/net/ipv4/ip_forward）由宿主机内核统一管理，每个容器运行在独立的 net namespace 或 uts namespace 中，但其底层 sysctl 接口仍依赖宿主机内核状态
- 即使把 /proc/sys 整个目录 bind mount 进容器（例如
docker run -v /proc/sys:/proc/sys:rw），容器内执行echo 1 > /proc/sys/net/ipv4/ip_forward实际修改的是宿主机的全局参数 —— 这不仅违反容器隔离原则，而且多数现代发行版（尤其是启用 sysctl unprivileged 限制时）会直接拒绝该操作，返回Permission denied - Linux 内核明确要求：修改影响全局行为的参数（如网络转发、IPC 限制等）必须具有 CAP_SYS_ADMIN 能力，且需在 init netns（即宿主机默认网络命名空间）中进行；普通容器即使挂载了 /proc/sys，也无权跨命名空间写入关键路径
容器能改哪些内核参数？
只有那些支持 per-namespace 配置、且容器启动时显式启用对应 namespace 的参数，才可能被单个容器独立调整。
- 例如：net.ipv4.ip_local_port_range、net.core.somaxconn、net.ipv4.tcp_tw_reuse 等，在容器拥有独立 net namespace 时可安全设置，且只影响该容器网络栈
- 这类参数必须在容器启动时用
--sysctl指定，例如：docker run --sysctl net.core.somaxconn=65535 ... - 运行中容器无法再追加或修改 sysctl 参数；
docker update不支持 sysctl 变更，只能调 CPU、内存等 cgroup 限制
真正可行的替代方案
若需让容器“感知”或“触发”宿主机内核参数变更，应走外部协调机制，而非试图绕过隔离强行 bind mount 修改。
-
宿主机侧配置 + 容器只读访问：把
/proc/sys以只读方式挂载（-v /proc/sys:/host_proc_sys:ro），供容器读取当前值做判断，但不用于写入 -
通过宿主机守护进程响应：容器内程序通过 API、文件通知、信号等方式告知宿主机上的 agent，由 agent 在具备权限前提下执行
sysctl -w或更新/etc/sysctl.conf -
使用 init 容器或特权 sidecar（慎用）：仅在绝对必要且可信环境中，用
--privileged启动辅助容器，由它执行宿主机级 sysctl 设置；但这破坏最小权限原则，不推荐生产使用
为什么常见误解会产生？
有人尝试 docker run -v /proc/sys:/proc/sys:rshared 或搭配 --privileged，误以为能“透传”修改能力。实际上：
-
rshared仅影响 mount 传播行为，不赋予 sysctl 权限 -
--privileged开放大量能力，但内核仍校验调用上下文 —— 容器内进程不在 init netns，写/proc/sys/...多数仍失败，或静默无效 - 实测表明：即使成功写入，也常因 namespace 边界导致效果不一致（如 ip_forward=1 在容器内生效，但路由转发实际不工作）
