Kubernetes中get deployment与get deployment/status的区别及权限差异

Kubernetes 所有带/status后缀的API子资源和对应主资源做权限拆分，本质是遵循期望配置（Spec）与运行状态（Status）权责分离的底层设计原则，和两个接口的请求参数、返回结构体是否相似没有关系。

首先要明确两类资源的操作边界：

• 主资源（例如deployments）的读写权限，对应操作资源的用户侧期望配置：包括副本数、镜像版本、更新策略、安全上下文等用户主动提交的配置内容，也就是资源对象里的spec段。
• /status子资源的读写权限，对应操作资源的系统侧运行状态：包括当前可用副本数、滚动更新进度、调度异常原因、控制器调谐记录等由集群控制器根据实际运行情况自动回填的内容，也就是资源对象里的status段。默认情况下只有对应资源的控制器（比如Deployment Controller）持有/status子资源的写权限，普通用户不会被默认授予该写权限，避免手动篡改状态导致控制器调谐逻辑异常。

典型授权场景 #

两类权限的拆分完全是为了满足最小权限原则，常见的拆分授权场景分两类：

授予主资源权限、不授予/status权限 #

这类授权面向只需要处理资源配置、不需要接触运行时数据的主体：

• 配置合规审计工具：这类工具只需要扫描资源的spec段是否符合企业规范（比如是否禁止使用latest镜像、是否配置了资源限制、是否开启了root权限限制），不需要感知当前业务的运行副本数、调度拓扑、运行错误等运行时信息，剥离/status权限可以缩小权限范围，避免工具获取不必要的敏感运行数据。
• CI/CD配置校验角色：流水线在更新应用配置时，只需要拉取现有主资源配置做diff校验、提交新的期望配置，不需要读取运行状态，同样遵循最小权限要求。

授予/status权限、不授予主资源权限 #

这类授权面向只需要观测运行状态、不允许接触/修改资源配置的主体：

• 监控采集组件：例如kube-state-metrics这类监控组件，只需要读取资源的status段生成监控指标（比如Deployment可用副本数、Pod就绪状态），不需要读取spec段里的镜像地址、环境变量、挂载密钥等敏感配置，剥离主资源读权限可以从RBAC层面避免配置泄露。
• 一线运维值班角色：值班人员只需要查看资源运行状态是否异常、触发告警的原因是什么，不需要有权限查看或修改核心业务配置，既可以避免误操作，也符合运维权责分离的合规要求。

容易混淆的接口表现 #

你在API文档里看到两个GET端点都返回Deployment类型对象，不代表实际返回内容完全一致：当你调用主资源GET接口但没有对应/status子资源的读权限时，返回体里的status字段会被API Server自动置空，不会返回真实运行状态数据。

内容的提问来源于stack exchange，提问作者Quido