代表性面试主题

系统设计面试:如何用 Kubernetes PodCertificateRequest 管理工作负载证书?

系统设计中等
Offer.cc 编辑团队发布 更新

题干

多租户集群中的服务需要 mTLS 客户端证书,却不能持有 Kubernetes API 凭据。你会如何设计 Pod 证书申请、投影、轮换和故障处理?

题干与适用场景

多租户 Kubernetes 集群中,服务需要向内部 API 发起 mTLS 请求。应用只能读取文件,不能直接访问 Kubernetes API,也不能把长期私钥写入镜像。请设计 PodCertificateRequest 从申请到签发、投影、轮换、撤销和审计的完整链路。

面试官考察点

  • 是否区分 PodCertificateRequest、传统 CertificateSigningRequest 和签发者职责。
  • 是否能说明 kubelet 投影卷如何隔离私钥、证书和信任根。
  • 是否处理 signer 授权、租户边界、轮换窗口、Pod 删除和节点失陷。
  • 是否识别 Kubernetes v1.35 beta 默认关闭、v1.36 需显式开启的版本事实。

回答前需要澄清的问题

  1. 证书用于客户端认证、服务端认证,还是双向 mTLS?
  2. 需要的 SAN、有效期、信任根和撤销语义是什么?
  3. 集群版本、feature gate、运行时配置和 kubelet 是否支持 Pod 证书投影?
  4. 应用能否在证书即将过期时重新打开文件或监听目录变化?

30 秒回答框架

我会让 kubelet 代表 Pod 申请证书,签发者仅接受经过授权的 signer 和受限身份字段,再把私钥、证书和信任根以只读 projected volume 投递给应用。应用不访问 API,只读取约定目录并在轮换时重新加载。申请、签发、投影和刷新都记录可审计事件;失败时保留旧的仍有效证书或阻止新连接。由于 PodCertificateRequest 在 v1.35 为 beta 且默认关闭,v1.36 还需要 feature gate 和运行时配置,我会先做版本探测与灰度。

分步骤深入解答

1. 划分身份和授权边界

Pod 只声明用途与目标 signer,不能自行选择任意 CA。准入策略将命名空间、服务账号、Pod 标签与允许的 signer 绑定;签发者校验请求来源、SAN 模板和密钥算法,拒绝跨租户主体。API 访问权限留在 kubelet 与控制面组件,应用只获得文件读取权限。

2. 设计申请和投影链路

kubelet 为 Pod 创建证书请求并取得签发结果,私钥在节点侧生成,避免把私钥交给镜像或业务 API。证书、私钥和 trust bundle 分开挂载,目录权限按容器用户最小化;投影文件采用原子替换,应用不会读到半写入内容。签发者名称、有效期和 SAN 写入可审计事件。

3. 处理轮换、撤销和故障

刷新阈值应早于有效期结束,并覆盖 kubelet 重启、网络中断和 CA 暂时不可用。应用同时保留旧证书直到新证书通过链验证,加载失败时拒绝新连接并保留健康检查信号。Pod 删除、服务账号变更或节点回收后立即移除投影;撤销依赖 CA 的 CRL、OCSP 或短有效期策略,不能假设 Kubernetes 对所有 signer 提供统一撤销接口。

4. 规划版本和观测

部署前验证 v1.35 beta 的默认关闭状态、v1.36 的 feature gate 与 runtime-config,并确认 signer 实现和 kubelet 版本矩阵。监控申请延迟、签发失败、剩余有效期、轮换成功率、文件权限错误和异常 SAN;日志只记录请求 UID、命名空间、Pod、signer 与结果,不记录私钥或完整证书内容。灰度期间保留短期的旧证书投影方案和回滚开关。

高质量示范回答

我会把 Pod 证书当作由 kubelet 代理的短期身份凭据。准入层先把命名空间和服务账号绑定到允许的 signer,签发者再校验 SAN、算法、有效期和租户边界;私钥在节点侧生成,证书、私钥和信任根以只读 projected volume 分离投递。应用不读 API,只监听目录或按请求重新打开文件,在新链验证成功后原子切换。轮换提前触发,短暂故障保留仍有效的旧证书,过期或身份变更则拒绝新连接并发出告警。删除 Pod 时清理投影,撤销依赖 signer 的短有效期或 CRL/OCSP 契约。上线前确认 v1.35 beta 默认关闭、v1.36 的 feature gate 与运行时配置,按节点池灰度并记录请求 UID、signer、延迟、失败率和剩余有效期。

常见错误

  • 让应用持有可创建任意 CSR 的 Kubernetes API token。
  • 允许请求者自由填写 signer、SAN 或跨命名空间主体。
  • 把私钥放进镜像、ConfigMap 或长期 Secret,并忽略节点侧权限。
  • 只在启动时读取证书,轮换后继续使用已过期文件描述符。
  • 将 beta 能力当作所有集群版本默认启用的稳定 API。
  • 记录完整 PEM、私钥或可关联租户的敏感审计字段。

追问及应对

为什么不直接使用长期 Secret?

长期 Secret 扩大泄露窗口,也难与 Pod 身份和删除事件绑定。短期证书配合 kubelet 投影和轮换能缩短凭据寿命,但仍需明确 signer 的撤销与恢复契约。

节点被攻陷时如何降低影响?

限制节点可读取的 Pod 目录和容器用户权限,证书使用短有效期与最小 SAN;将高价值身份放到隔离节点或硬件保护的 signer,并通过审计与异常连接检测缩短响应时间。

feature gate 未开启怎么办?

部署控制器先探测 API 资源、运行时配置和 kubelet 能力,未满足时暂停该工作负载或切换到已审计的旧方案;禁止静默生成看似成功但不会轮换的文件。

公开来源

同类题目

相关面试工具

用 Solve 整理系统设计回答

从澄清需求开始,展开规模、架构、组件选择和取舍。

查看工具