kubectl get --raw 是什么
kubectl 的常规子命令只暴露集群已经抽象好的资源对象，--raw 则允许直接向 API Server 发起 GET 请求并原样输出返回体（通常是 JSON）。它操作的是 API 路径本身：健康检查端点、聚合 API 的注册信息、指标端点、OpenAPI 描述都能读，因此常被当作绕过 kubectl 封装的探针使用。判断控制面是否正常、确认某个聚合 API 组有没有真的注册成功时，它往往比 kubectl get 更直接。
基本信息
| 用途 | 直接请求 API Server 的任意 GET 路径，原样输出返回体 |
|---|---|
| 语法 | kubectl get --raw <API路径> |
| 适用对象 | 控制面健康端点、聚合 API、指标端点、资源原始列表 |
| 权限要求 | 沿用当前 kubeconfig 身份，路径本身仍受 RBAC 约束 |
| 输出格式 | 未格式化的原始 JSON 或纯文本 |
典型使用场景
- 判断控制面是否健康：直接读存活与就绪端点，不受业务对象状态干扰
- 确认聚合 API 是否注册：metrics 等路径不可用会连带影响 kubectl top
- 核对服务端版本与能力：读版本端点，升级前后做对照
- 查看原始资源列表：需要完整字段又不想拼 -o json 时直接取 REST 路径
- 验证访问链路：路径能通说明认证、证书与网络到 API Server 都正常
常用端点示例
常用端点示例
kubectl get --raw /livez # 控制面存活检查，正常返回 ok
kubectl get --raw '/readyz?verbose' # 逐项列出就绪检查的通过情况
kubectl get --raw /version # 服务端版本，关注 gitVersion 字段
kubectl get --raw /apis # 已注册的 API 组，含聚合组
kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes # metrics-server 的节点指标
kubectl get --raw /api/v1/namespaces/prod/pods | head -c 300 # 原始列表，量大先截断
kubectl get --raw '/api/v1/namespaces/prod/pods?limit=1' # 用查询参数控制返回体大小端点含义与异常指向
| 端点 | 含义 | 异常时先看什么 |
|---|---|---|
| /livez | 进程仍存活并能处理请求 | 进程卡死或无响应，通常需要重启组件 |
| /readyz | 依赖组件就绪，可接收写入 | etcd 连通性、聚合层与后端服务 |
| /healthz | 早期使用的汇总端点 | 老脚本仍在调用，新脚本建议改用 livez 与 readyz |
| /apis | 已注册 API 组清单 | 聚合组缺失说明对应 APIService 异常 |
| /version | 服务端版本信息 | 升级前后对照，确认组件版本一致 |
就绪端点加 ?verbose 会逐项列出检查名与结果，比只看一个 failed 有用得多；担心端点无响应时给 kubectl 加 --request-timeout，避免命令长时间挂住后无法判断是网络慢还是组件挂了。
返回体不会自动格式化，内容大时接 jq、python -m json.tool 或 head -c 截取再读；--raw 只做 GET，创建与修改资源仍要回到正常的写入流程。
把 --raw 输出贴进工单或聊天前先脱敏：指向 secrets、serviceaccounts 等路径时会直接返回凭据、Token 与证书数据，这类内容一旦外发无法收回。