讲解
kubectl 是和 Kubernetes 交互的唯一入口工具，所有操作最终都是调用 API Server 的 REST API。它的命令结构高度统一：kubectl <动作> <资源类型> <资源名> [参数]。动作最常用的是 get（查看）、describe（详情与事件）、apply（声明式创建/更新）、delete（删除）、logs（日志）、exec（进容器）；资源类型有全称也有简写——pods 简写 po、services 简写 svc、deployments 简写 deploy、namespaces 简写 ns，用 kubectl api-resources 能看到完整清单和每个资源的简写、是否按命名空间隔离。
get 的输出格式由 -o 控制：默认是表格，-o wide 加节点/IP 等列，-o yaml/-o json 输出完整对象（看真实字段值的唯一权威途径），-o jsonpath='{...}' 按路径精确取字段，适合脚本。describe 和 get -o yaml 的分工要清楚：describe 给人看，重点是末尾的 Events（调度、拉镜像、探针失败等事件流，排查问题第一站）；get -o yaml 给机器和较真的人看，包含 status 等运行时字段。
两个元命令能省下大量查文档的时间。kubectl explain <资源>.<字段> 是内置的字段手册，比如 kubectl explain pod.spec.containers 会列出容器字段的含义和类型，一层层点进去就能看到任何字段的文档。kubectl api-resources 则回答「这个集群里有哪些资源可用」。另外记住 --dry-run=client -o yaml 这个组合：kubectl create/run 加上它只生成 YAML 不真正创建，是从命令行生成清单骨架的标准手法，生成后存成文件再 apply，就完成了从命令式到声明式的过渡。
示例
集群里有哪些资源类型、各自简写是什么（截取开头几行）：
kubectl api-resources | head -8
内置文档：容器字段有哪些、各是什么意思：
kubectl explain pod.spec.containers | head -12
直接访问 API Server 的原始接口——/version 返回服务端版本信息：
kubectl get --raw /version
当前 context（本教程的验证集群）与 jsonpath 精确取字段：
kubectl config current-context
kubectl get nodes -o jsonpath='kubelet 版本: {.items[0].status.nodeInfo.kubeletVersion}'
echo
看一眼当前命名空间（ohmydocs-verify）里的工作负载——现在应该是空的，后面章节会一点点填满它：
kubectl get all
常见坑
- 资源名单复数混用报错：pods、pod、po 都行，但 pod 后面直接跟名字（kubectl get pod nginx），类型和名字之间没有等号。
- 忘了 -n 指定命名空间：命令默认操作 current context 里的命名空间，「明明创建了却 get 不到」多半是命名空间不对，加 -n 或用 kubectl get pods -A 看全部。
- describe 当监控用：Events 默认只保留一小时，历史问题要去日志系统查；describe 是「现场勘查」工具。
- 滥用 -o yaml 的输出直接改：get -o yaml 拿到的内容带 status、resourceVersion 等运行时字段，原样 apply 回集群可能报错或造成混乱；只保留 metadata/spec 部分。
小结
kubectl 命令 = 动作 + 资源类型 + 名字；api-resources 和 explain 是两本内置手册；-o/jsonpath 控制输出，describe 看事件；--dry-run=client -o yaml 是生成清单的捷径。下一章创建第一个真正的 workload：Pod。