Kubernetes 1.30 版本终于支持了真正的只读卷挂载
聊点别的
不知道是因为关注新能源车还是因为新闻报道的多，最近各种电车品牌接连展开发布会，价格亦颇为诱人。读者朋友是否也在精打细算，考虑加入电动车大军，此时怎么看？
有个好消息！公众号给我开通了留言功能，就在文章底部等你！不再需要跳转后台，直接在阅读完毕的地方，留下你的想法和见解。加入我们的讨论大家庭，与众多读者朋友一起互动交流，让你的声音成为我们共同进步的力量！快来分享你的独特观点，参与精彩对话，激发灵感火花吧！??
附加服务：可以给读者查询关注时间哦！
别忘了，现在就下滑，精彩留言等你来发！
近日见闻
- Ant Design 5.16.4 发布，众多更新 --
https://github.com/ant-design/ant-design/releases/tag/5.16.4 - 4 月 16 日，百度创始人、董事长兼首席执行官李彦宏在 Create 2024 百度 AI 开发者大会上宣布，第二届 “文心杯” 创业大赛正式启动，参赛选手有机会获得最高 5000 万人民币投资。--百度
我觉得做一个操作系统，如果跟现在的操作系统是一样的，就没有未来，不可能发展起来。开源鸿蒙操作系统是我们国家在基础软件领域里面唯一一次在架构上是创新的，它不是简单的国产替代，它是面向未来万物互联的。--王成录,曾主导鸿蒙系统开发- 摘抄：
人活在世界上，需要这样的经历：
做成了一件事，又做成了一件事，
逐渐地对自己要做的事有了把握。
——王小波
王小波（1952年5月13日-1997年4月11日），出生于北京，毕业于美国匹兹堡大学，中国当代学者、作家。 1968年，在云南兵团劳动，并开始尝试写作。1978年，顺利录取中国人民大学，就读于贸易经济系商品学专业。1980年，在《丑小鸭》杂志发表处女作《地久天长》。1982年，开始写作历经十年才完成面世的成名作《黄金时代》。1984年，在东亚研究中心做研究生。1986年，获硕士学位；同年开始写作以唐传奇为蓝本的仿古小说，并继续修改《黄金时代》。1988年，与妻子一道回国，任北京大学社会学所讲师。1989年，出版第一部小说集《唐人秘传故事》。1991年，小说《黄金时代》获第13届《联合报》文学奖中篇小说大奖。1995年5月，小说《未来世界》获第16届《联合报》文学奖中篇小说大奖。 1997年4月11日，病逝于北京，年仅45岁。今日推荐
开发人员快速参考备忘清单【速查表】。基本覆盖了全技术栈，大家快去看看啊！https://cheatsheets.zip/
比如常见的状态码：
Kubernetes 1.30 版本终于支持了真正的只读卷挂载
最近查看k8s官网博客，发现有这个内容，这里分享给大家：
Kubernetes 1.30 引入的新特性解决了一个长期存在的问题：在特定条件下，标记为只读的卷挂载不是完全只读的。新的 recursiveReadOnly 选项允许用户确保指定挂载点下的所有子挂载都是只读的，这对于保障容器内的文件系统安全性是一大步。虽然这个特性目前还处于 alpha 测试阶段，但它展现了 Kubernetes 社区对于提升容器运行时安全性和可靠性的持续承诺，并且随着此功能的成熟和稳定，未来可能成为默认配置的一部分。对于那些对Kubernetes安全性有特别需求的用户来说，这将是一个值得关注和尝试的更新。
在 Kubernetes 环境中，当你将卷挂载到容器中，并通过设置 readOnly: true 标记为只读时，这个设置的本意是防止容器内的进程对这些挂载的文件系统进行修改。然而，在某些特定条件下，这种只读设置并不是完绝对的，原因主要涉及到如何处理子挂载（submounts）或者挂载的继承性。
问题的核心在于 Linux 文件系统挂载的工作方式以及 Kubernetes 如何处理这些挂载。当你在宿主机上有一个挂载点，并且在这个挂载点下面又有其他的挂载点（即子挂载），这些子挂载点的行为并不会自动继承父挂载点的只读属性。这意味着，即使父挂载点在 Kubernetes pod 配置中被设置为只读，其下的子挂载点仍然可能是可写的，除非这些子挂载点也被显式地设置为只读。
例如，如果你有一个挂载点 /mnt，它在容器中被设置为只读。但是，如果 /mnt 下有一个子挂载点 /mnt/my-nfs-server，并且这个子挂载点在宿主机上是可写的，那么在容器内，尽管 /mnt 下的文件和目录不能被修改（符合只读设置），对 /mnt/my-nfs-server 的写操作却可能成功，因为它的只读属性没有被递归应用到所有的子挂载点。
这就是为什么 Kubernetes 1.30 引入了 recursiveReadOnly 选项，它允许在定义卷挂载时通过显式设置，确保所有的子挂载点都继承只读属性，从而实现真正意义上的只读挂载，解决了这个特定条件下的限制。
以下为原文内容，这边结合GPT翻译分享给大家原文内容[1]
自 Kubernetes 问世以来，只读卷挂载一直是其特性之一。但令人惊讶的是，在特定条件下，Linux 上的只读挂载并不完全是只读的。从 v1.30 版本开始，它们可以被设置为完全只读，同时支持递归只读挂载处于 alpha 测试阶段。
默认情况下，只读卷挂载并不真正只读，卷挂载可能出乎意料的复杂。
你可能会期望以下清单能使容器中 /mnt 下的所有内容都为只读：
---
apiVersion: v1
kind: Pod
spec:
volumes:
- name: mnt
hostPath:
path: /mnt
containers:
- volumeMounts:
- name: mnt
mountPath: /mnt
readOnly: true
然而，位于 /mnt 下的任何子挂载仍可能是可写的！例如，如果宿主机上的 /mnt/my-nfs-server 是可写的，在容器内对 /mnt/* 的写操作将被拒绝，但对 /mnt/my-nfs-server/* 的写操作仍然是可行的。
新的挂载选项：recursiveReadOnly Kubernetes 1.30 添加了一个新的挂载选项 recursiveReadOnly，以便使子挂载递归地只读。
该选项可以如下启用：
---
apiVersion: v1
kind: Pod
spec:
volumes:
- name: mnt
hostPath:
path: /mnt
containers:
- volumeMounts:
- name: mnt
mountPath: /mnt
readOnly: true
# 新增
# 可能的值有 `Enabled`, `IfPossible`, 和 `Disabled`。
# 需要与 `readOnly: true` 一起指定。
recursiveReadOnly: Enabled
这是通过使用 mount_setattr(2) 函数和 AT_RECURSIVE 标志（在 Linux 内核 v5.12 中添加）应用 MOUNT_ATTR_RDONLY 属性来实现的。
为了向后兼容，recursiveReadOnly 字段并不是 readOnly 的替代品，而是要与它一起使用。要得到一个正确的递归只读挂载，你必须同时设置这两个字段。
功能可用性
要启用 recursiveReadOnly 挂载，必须使用以下组件：
- Kubernetes：v1.30 或更高版本，需要启用 RecursiveReadOnlyMounts 特性门控。从 v1.30 版本开始，此门控标记为 alpha 测试阶段。
- CRI 运行时：
- containerd：v2.0 或更高版本
- OCI 运行时：
- runc：v1.1 或更高版本
- crun：v1.8.6 或更高版本
- Linux 内核：v5.12 或更高版本
参考资料
[1]
Kubernetes 1.30: Read-only volume mounts can be finally literally read-only: https://kubernetes.io/blog/2024/04/23/recursive-read-only-mounts/