题干与适用场景
你负责一个运行在 Linux、SELinux enforcing 节点上的多租户 Kubernetes 集群。平台使用 CSI 卷，部分工作负载会共享同一个卷；团队计划升级到 v1.36。请在不假设所有节点都启用 SELinux 的前提下，设计兼容性评估、灰度、观测和回滚方案。
面试官考察点
面试官希望听到你能区分 SELinux 节点与普通节点，理解卷挂载上下文和递归重标记的差异，并识别特权与非特权 Pod 共享卷的风险。高质量回答还会覆盖 CSI 驱动、Pod securityContext、启动时延、数据访问、准入边界和版本化回滚。
回答前需要澄清的问题
- 哪些节点处于 enforcing，哪些 CSI 驱动和文件系统在支持范围内？
- 共享卷是业务硬约束，还是可以通过拆分卷或数据交换替代？
- 迁移优先级是启动时延、租户隔离、作业连续性，还是三者的明确权衡？
- 当前版本是否允许显式选择卷标记策略，回滚窗口和证据保留期限是什么？
30 秒回答
“我先盘点节点 SELinux 模式、CSI 驱动、卷类型和共享关系。v1.36 的改进把支持卷的标记路径转向挂载上下文，减少递归重标记成本，但可能改变共享卷的访问结果。我会先在隔离节点池对可重试工作负载做对照测试，观察挂载、标签、读写、启动时延和拒绝日志；通过后再扩大灰度。发现不兼容时停止新工作负载进入灰度池，保留运行中 Pod 和证据，并按当前版本支持的策略回退。”
分步骤深入解答
1. 建立影响清单
记录每个节点的内核与 SELinux 状态、enforcing/permissive 模式、Kubernetes 版本、CSI 驱动版本和卷类型。将 Pod 的 seLinuxOptions、运行身份、特权级别、卷挂载路径与是否被多个 Pod 共享导出为清单。没有 SELinux 的节点不应被纳入本次行为结论。
2. 理解行为差异
官方变更说明 v1.36 将 SELinux 卷标记改进提升为稳定能力：对支持的卷，系统可使用挂载上下文代替逐文件递归重标记。这样通常能缩短大卷启动时间，但共享卷由不同安全域访问时，原有“先重标记再使用”的假设可能失效。不要把“挂载成功”当作“应用一定可读写”。
3. 检查驱动与策略边界
逐个 CSI 驱动确认是否支持挂载上下文、文件系统和挂载选项限制。按当前集群版本文档核对 seLinuxChangePolicy、相关 feature gate 及默认值，避免把旧版本的字段或开关直接复制到新集群。准入策略应限制不必要的特权、固定共享卷的安全域，并记录策略变更。
4. 设计可重复的对照测试
准备相同镜像、UID/GID、securityContext 和卷数据的测试 Pod，分别覆盖单 Pod、同安全域共享、特权与非特权混用、空卷和已有大量文件的卷。验证挂载上下文、文件标签、读写、重启恢复、扩容以及 CSI 重连；同时记录从 Pod 创建到 Ready 的分段时延。
5. 灰度与护栏
先建立独立节点池和少量 CSI StorageClass，选择可重试作业。灰度期间禁止把同一共享卷同时交给未经验证的安全域组合；将拒绝日志、挂载失败、应用权限错误、启动时延和重启成功率设为门槛。护栏触发后停止扩容，不要通过放宽 SELinux 或特权权限来掩盖问题。
6. 处理共享卷风险
如果一个卷在特权与非特权 Pod 之间共享，先拆分为独立卷或统一安全域，再决定是否继续迁移。对必须共享的场景，明确谁负责标签、何时挂载、如何回收，并用实际访问矩阵验证。只在应用恢复后才删除旧卷，避免把标签问题误判为数据损坏。
7. 回滚与证据保留
回滚时先停止新 Pod 进入灰度节点池，保留运行中作业和事件，再根据当前版本支持的策略显式选择递归路径或旧节点池。记录 feature gate、节点标签、CSI 配置、Pod 清单和 SELinux AVC 拒绝日志。回滚后重新执行同一对照测试，确认行为恢复，而不是只看部署命令成功。
高质量示范回答
我会把迁移拆成盘点、对照、灰度和回滚四层。先确认只有 SELinux 可用且 enforcing 的 Linux 节点受影响，再核对 CSI 驱动与当前版本的安全上下文字段。v1.36 对支持卷使用挂载上下文，减少递归重标记，但共享卷和不同安全域的组合需要重点验证。测试覆盖空卷、大卷、单 Pod、同域共享以及特权/非特权混用，比较标签、读写、拒绝日志、启动时延和重启恢复。灰度节点池只接收可重试作业；门槛失败就停止扩容、保留证据并按文档支持的策略回退。
常见错误
- 把所有节点都当作 SELinux 节点 → 得出错误影响范围 → 先按节点模式和 enforcing 状态分层。
- 只测挂载成功 → 应用运行时仍被拒绝 → 验证实际 UID、标签、读写和重启。
- 直接放宽特权权限 → 安全边界被扩大 → 修正安全域、共享关系和驱动配置。
- 忽略 CSI 差异 → 某类卷灰度失败 → 按驱动、文件系统和卷类型建矩阵。
- 回滚时删除所有 Pod → 丢失事故证据并中断作业 → 先冻结新流量，保留状态和日志。
追问及应对
如果节点是 permissive，还需要同样的迁移吗？
仍应记录并测试，因为 permissive 会记录拒绝但通常不强制阻断访问。它不能代表 enforcing 的结果；上线门槛必须在 enforcing 节点复现。
如何判断是标签问题还是 CSI 问题？
先在相同节点、镜像和安全上下文下替换卷类型或驱动，比较挂载事件、内核拒绝日志、文件标签和 CSI 日志。只有跨驱动仍稳定复现，才把问题归因到安全上下文路径。
大卷启动变快是否足以证明迁移成功？
不够。性能只是一个指标，还要证明不同安全域的访问矩阵、重启恢复、扩容、故障重连和审计日志满足门槛。
共享卷无法统一安全域怎么办？
优先拆分卷或改为显式数据交换。若业务必须共享，应让平台拥有安全域和生命周期决策，并把允许的 Pod 组合写入准入策略与回归测试。