7.1 kubectl农具箱：日常操作一览

7.1 kubectl 农具箱：日常操作一览

本节摘要：kubectl 的子命令按动词可归为四组：看（get、describe、logs、top）、进（exec、port-forward）、改（apply、edit、scale、set）、删（delete）。配合 -n 选田、-l 圈苗、-o 定格式三个通用开关，足以覆盖日常巡田与排错的绝大多数场景。本节按一天巡田的顺序演练这套工具，并给出危急时刻的命令套路卡。

先把工具箱倒出来看看

新手面对 kubectl 的第一感受是"命令浩如烟海"，其实它的语法整齐得像农具架：kubectl 动词 资源类型 名字 开关。动词按用途归四组，记住分组就不必背命令：

三个高频开关走天下：-n 选哪块田（不带就看 default），-l 按苗牌圈一群，-o 定输出格式（wide 加列、yaml 看全档）。资源类型都有短名（po、deploy、svc、ns、pvc），敲短的名字速度快一倍。

巡田一小时

早上到岗，先花一分钟看全局：

# 全田大名单：所有块的苗一起看
kubectl get pods -A
# NAMESPACE       NAME                            READY   STATUS      RESTARTS   AGE
# greenlib-prod   greenlib-web-7d9b6c5f4-8xzqm    1/1     Running     0          2d
# greenlib-prod   greenlib-api-66d8f9bcb-mn2pv    1/1     Running     1          2d
# greenlib-prod   shelf-db-0                      1/1     Running     0          5d
# kube-system     log-collector-7xz9m             1/1     Running     0          5d
# 一眼扫 STATUS 与 RESTARTS 两列：红色状态或重启数异动都要追查

# 只看生产田的计划与水闸
kubectl get deploy,svc -n greenlib-prod
# NAME          READY   UP-TO-DATE   AVAILABLE   AGE
# deployment.apps/greenlib-web   3/3   3   3   9d
# NAME          TYPE        CLUSTER-IP     PORT(S)
# service/greenlib-web   ClusterIP   10.96.12.40   80/TCP
​

发现接口苗重启过一次，顺着往下挖：

# 档案与事件：苗的病历本
kubectl describe pod -n greenlib-prod greenlib-api-66d8f9bcb-mn2pv
# 输出节选：
#   Last State: Terminated  Reason: OOMKilled  Exit Code: 137
# Events 里往往还有上一轮的调度与拉镜像记录
# OOMKilled：内存超限被掐——线索直指 7.3 的 Limits 话题

# 看苗吐过什么（-p 是上一世的遗言）
kubectl logs -n greenlib-prod greenlib-api-66d8f9bcb-mn2pv --previous | tail -n 5
# 09:41:02 WARN memory usage 91% of limit
# 09:41:31 WARN memory usage 96% of limit
# （然后就没有然后了——被掐前内存逼近上限的完整轨迹）

# 钻进苗里摸现场
kubectl exec -it -n greenlib-prod deploy/greenlib-api -- sh
# 进去后可以看进程 试连通 验证环境变量
# curl -s greenlib-db.greenlib-prod:5432 与数据库的连通性一把摸清
exit
​

# 把水闸拉到本地调试（不惊动任何访客）
kubectl port-forward -n greenlib-prod svc/greenlib-web 18080:80
# Forwarding from 127.0.0.1:18080 -> 80
# 本机浏览器访问 localhost 的 18080 即直通生产网页组

# 看看各家水肥用量（需要 metrics-server，8.2 细讲）
kubectl top pods -n greenlib-prod
# NAME                   CPU(cores)   MEMORY(bytes)
# greenlib-web-8xzqm     12m          86Mi
# greenlib-api-mn2pv     93m          241Mi
# shelf-db-0             201m         812Mi
# 接口苗内存两百四 限额若只给了两百五 危险信号已写在墙上
​

改与删的分寸

改期望的两条正路：改清单再 apply（长期状态的唯一正路）、命令行临时调（应急）。kubectl edit 直接在编辑器里改台账，图快但绕过了评审，生产环境我持保留意见。删除命令要带着敬畏敲：

# 删一株苗：园丁会补新的（重启某个实例的正规姿势）
kubectl delete pod -n greenlib-prod greenlib-api-66d8f9bcb-mn2pv

# 删整份计划：苗、ReplicaSet 一并收走（水闸 PVC 不会跟着删）
kubectl delete deploy -n greenlib-prod greenlib-api

# 危险动作前先加 --dry-run=client 预演
kubectl delete deploy -n greenlib-prod greenlib-api --dry-run=client
# deployment.apps "greenlib-api" deleted (dry run)
# 预演不落台账 确认无误后再动真格
​

排错套路卡

把最常用的巡诊顺序压成一张卡，危急时照单执行：

1. kubectl get pods -A：圈出异常苗（状态非 Running、READY 不满、重启数高）
2. kubectl describe pod 名字：看事件段，重点 FailedScheduling、ImagePullBackOff、Unhealthy
3. kubectl logs 名字 --previous：上一世的临终日志
4. kubectl exec -it 名字 -- sh：进苗摸现场（起不来就进不了，回到上一步）
5. kubectl top pods：水肥账对不对得上
6. 还不行：看节点（kubectl describe node）与整田事件（kubectl get events -A --sort-by=.lastTimestamp）

⚠️ 常见坑：kubectl logs 报 "previous container not found"，说明苗从没重启过，去掉 --previous 直接看即可；反过来，看到 CrashLoopBackOff 却不加 --previous，读到的多半是当前这世刚醒时的几行，关键死因在前一世。排错时先想清楚你要问哪一世的日志。

本节要点回顾

• 语法骨架动词加资源加名字加开关，动词按看、进、改、删四组归位
• 三开关走天下：-n 选田，-l 圈苗，-o 定格式
• 苗的病历在 describe 事件段，死因常在 logs 加 previous
• 重启实例的正规姿势是删掉让园丁补
• 危险命令先 --dry-run 预演，删除永远带着敬畏敲