kubectl get 是干什么的
kubectl get 用来列资源、看状态，是日常使用频率最高的命令：给一个资源类型就能拿到列表，用命名空间参数限定范围，用输出格式参数扩展列（节点、地址、标签），再用排序参数找出最新或最旧的对象。把简写和几组常用组合记熟，绝大多数查询都能一条命令解决。
基本信息
| 基本用法 | kubectl get 资源类型 [名称] -n 命名空间 |
|---|---|
| 跨命名空间 | 加 -A 或 --all-namespaces 显示全部命名空间下的资源 |
| 输出扩展 | -o wide 增加节点与地址列，-o yaml 或 -o json 查看完整对象 |
| 过滤与排序 | -l 按标签过滤，--show-labels 显示标签，--sort-by 按字段排序 |
| 常用简写 | po=pods、deploy=deployments、svc=services、cm=configmaps、ns=namespaces |
| 字段筛选 | --field-selector 按字段过滤，如只看处于运行状态的 Pod |
典型使用场景
- 确认发布结果：发布后看新版本的 Pod 是否全部就绪，副本数是否符合期望
- 定位异常副本：一眼扫出重启次数多、状态不是运行中的 Pod
- 跨命名空间巡检：用 -A 一次性看清整个集群的资源分布与异常
- 排查调度问题：加 -o wide 看 Pod 落在哪个节点、分配了什么地址
- 按标签取数：用 -l 过滤出某一套应用的资源，供脚本批量处理
- 查看最近变动：按创建时间排序，确认刚才的操作到底改了哪些对象
- 确认资源是否被漏建：把配置里期望的资源类型逐个查一遍
输出逐列读法
| 列 | 含义 | 异常表现 |
|---|---|---|
| NAME | Pod 名称 | 名称带随机串说明由控制器创建 |
| READY | 就绪容器数比总容器数 | 左边小于右边表示有容器未通过就绪检查 |
| STATUS | 当前阶段或状态 | Pending、CrashLoopBackOff 都需要立即看事件 |
| RESTARTS | 重启次数 | 持续增长说明进程反复退出 |
| AGE | 创建至今的时间 | 很新说明刚被重建过 |
| IP / NODE | 地址与所在节点 | 为空通常是还没调度成功 |
使用示例
使用示例
kubectl get pods -n dev -o wide # 带节点与地址的列表
kubectl get pods -A --field-selector status.phase=Running # 只看运行中
kubectl get deploy,svc -n dev # 一次查多种资源
kubectl get pods --sort-by=.status.startTime | tail -5 # 最近启动的 5 个
kubectl get pods -l app=web -o name # 只输出资源名，便于脚本处理查不到资源先看命名空间：默认命名空间与资源实际所在的命名空间不一致，是『明明有却看不到』最常见的原因。
get all 不是全景图：它不包含配置、密钥、存储声明、入口等资源，排查缺信息时容易误判成『集群里没有』。
简写能省很多输入，但别用在文档与脚本里：简写可读性差，换人或换工具时容易出错，脚本里建议写全称。
输出格式可以做得更细：用自定义列把关心的字段单独列出来，比在完整输出里找字段快得多，也便于事后对照。
取数与脚本化的做法
- 用输出模板固定列，交给后续脚本处理而不是人工截图比对
- 只输出资源名再交给批量命令，避免误伤其他资源
- 按标签而不是按名称前缀筛选，命名规则变化后规则依然可用
- 查不到资源先确认命名空间，再考虑权限范围的问题
- 跨命名空间巡检时把集群上下文与范围一并记录，便于复核
- 把常用查询组合写进运维手册，减少临场拼参数出错
输出内容多时先限定命名空间与资源类型再逐步展开，查询范围越明确，结果越容易判断，也不容易看漏异常行。
把查询结果保存成文件并在发布前后各留一份，改动前后的差异一眼可见，比凭记忆比对可靠得多。