题干与适用场景
你管理数百个 Kubernetes 集群。v1.36 的核心组件提供 /statusz，默认返回人类可读文本，并可通过显式内容协商请求结构化 API。请设计采集、权限、版本兼容、告警和故障隔离方案。假设部分集群仍运行旧版本，且控制面端点不能暴露公网。
面试官考察点
面试官考察你能否区分健康探针、组件状态和业务 SLO，设计多集群采集的认证、限流、版本解析和降级。高质量回答还会处理敏感信息、告警风暴、采集器故障和控制面本身不可达的情况。
回答前需要澄清的问题
- 需要的是存活判断、依赖状态，还是版本化诊断字段？
- 采集器部署在每个集群内，还是由中心控制面拉取？
- 哪些角色可以读取 statusz，返回内容是否含内部拓扑或版本信息？
- 异常发现目标是秒级告警，还是分钟级容量与趋势分析？
30 秒回答
“我会把 statusz 当诊断信号，不把它直接当业务健康。集群内采集器通过最小权限和私网访问端点，优先请求结构化版本并保留文本用于人工排障；旧集群走兼容探针。中心平台按集群、组件和版本聚合，做限流、缓存和告警去重。控制面不可达时单独标记采集链路故障，不能误报为组件内部失败。”
分步骤深入解答
1. 定义信号与版本契约
记录组件身份、版本、响应格式、检查项和时间戳。结构化 API 的字段按版本解析，未知字段保留但不强依赖；文本只做展示和故障取证。把 statusz 与 /livez、/readyz 以及业务指标分层。
2. 设计采集拓扑
优先在集群内运行轻量采集器，通过本地网络访问 API server、scheduler 和 controller manager。中心只接收脱敏后的状态事件和聚合指标，避免把控制面端点暴露到公网。采集器本身要有队列、退避和本地缓存。
3. 处理认证与授权
为采集器创建只读、资源范围最小的身份，限制可访问的组件端点和网络路径。审计读取者、频率和响应大小；禁止复用管理员凭据。若字段包含版本或拓扑信息，按租户与运维角色过滤。
4. 控制负载与失败
设置每组件并发、超时、缓存和最大响应大小。控制面繁忙或不可达时退避，不反复重试放大故障。区分组件报告失败、HTTP 失败、网络不可达和采集器自身积压四类状态。
5. 聚合与告警
按集群、组件、版本和故障类型建立时间序列，使用事件指纹去重。告警需要连续窗口和影响范围，例如多个组件同时异常或同版本集群集中失败；单次采集超时只进入低优先级诊断。
6. 灰度与回滚
先在少量 v1.36 集群启用结构化采集，比较 API 负载、字段稳定性、告警精度和采集延迟，再扩大范围。发现字段或负载问题时关闭新解析器，退回兼容探针，保留原始响应和审计记录。
高质量示范回答
我会把 statusz 作为控制面诊断信号，与存活探针和业务 SLO 分层。每个集群内的只读采集器通过私网访问组件端点，中心只接收脱敏状态和聚合指标；旧版本使用兼容探针。结构化响应按版本解析，未知字段不阻断采集，文本只用于人工取证。限制并发、超时、缓存和响应大小，区分组件失败、网络失败和采集器积压。按事件指纹和连续窗口去重告警，先在少量 v1.36 集群灰度，必要时关闭新解析器回退。
常见错误
- 把 statusz 当业务 SLO → 误判用户体验 → 与业务指标分层。
- 中心直接访问公网端点 → 攻击面扩大 → 集群内采集、中心收状态。
- 复用管理员凭据 → 越权读取 → 创建最小只读身份。
- 未知字段导致整条流水线失败 → 升级即中断 → 按版本宽松解析。
- 所有超时都报警 → 告警风暴 → 区分采集链路与组件故障并去重。
追问及应对
为什么还要保留文本响应？
结构化字段适合机器聚合，文本便于值班人员快速阅读和事故取证。两者应来自同一端点，但用途不同。
控制面不可达时如何避免误报？
把网络不可达、认证失败、采集器积压和组件报告失败分开建模。只有有足够证据时才升级组件故障告警。
如何支持旧版本集群？
采集器先探测端点和版本，再选择结构化解析、文本解析或兼容探针；能力矩阵记录可用字段，不能假设所有集群都支持 Beta 接口。
如何防止 statusz 采集本身拖慢 API server？
限制频率和并发，使用缓存与退避，设置响应大小上限，并在 API server 负载升高时自动降低采集频率。