Skip to main content

运维与排障

日常 80% 问题用同一套口令就能缩小范围：get → describe → logs →（必要时）exec。对象概念见前几篇。

常用 kubectl​

kubectl get deploy,svc,pods -n my-app
kubectl get pods -o wide                    # 看所在 Node、IP
kubectl describe pod <pod>                  # Events 最有用
kubectl logs <pod> -c <container> --tail=200
kubectl logs -f deploy/web                  # 跟 Deployment 选中的 Pod
kubectl exec -it <pod> -- sh                # 镜像无 sh 则换 bash
kubectl apply -f manifests/
kubectl delete pod <pod>                    # 控制器会再建（用于「踢一脚」）

输出太多时加标签：-l app=web。

排障路径​

Pending（一直排不上）​

describe 看 Events，常见：

线索可能原因
Insufficient cpu/memory节点资源不够，或 requests 过大
node affinity / taint调度约束不满足
PVC unbound存储供给失败

CrashLoopBackOff / Error​

容器反复崩：

  1. logs（加 --previous 看上次崩溃）
  2. 查启动命令、环境变量、依赖服务是否通
  3. 查 liveness 是否杀得太勤

ImagePullBackOff​

镜像名/标签错、仓库鉴权、镜像不存在。describe 里 pull 相关 Events 会写明。

Running 但访问不通​

  1. kubectl get endpoints 是否为空 → 标签 / readiness
  2. Service port / targetPort 是否对
  3. 探针是否未就绪
  4. 网络策略（若集群启用）是否挡了

requests / limits​

resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"
字段含义
requests调度与保证的基线；也影响 QoS
limits上限；内存超限常被 OOMKill

不设 requests 可能导致节点挤爆或调度行为难预期——以团队默认值为准。

HPA（一句话）​

Horizontal Pod Autoscaler 按 CPU/内存/自定义指标自动改 Deployment 的 replicas。面试能说到「根据指标扩缩副本」即可；落地依赖 metrics-server 等。

你不能做主时​

  1. 不随便 kubectl delete 生产 Namespace / PVC
  2. 热修后把变更回写 Git 清单
  3. 权限不够（RBAC）时走团队申请，勿共用管理员 kubeconfig
  4. 先 describe / logs，再考虑重启或扩容

要点​

  1. 口令：get → describe（Events）→ logs → exec
  2. Pending 看调度与资源；CrashLoop 看日志与探针；不通先看 Endpoints
  3. requests/limits 影响调度与 OOM
  4. 清单与集群一致，比在集群里手改更重要

面试速记​

  1. 排障顺序？ 资源状态 → Events → 日志 → 进容器验证。
  2. CrashLoopBackOff？ 容器启动后反复崩溃，K8s 在退避重启。
  3. requests vs limits？ 申请/调度基线 vs 硬上限。
  4. QoS 三类（了解）？ Guaranteed / Burstable / BestEffort（由 requests/limits 是否对齐等决定）。
  5. HPA 是什么？ 按指标自动调整 Pod 副本数。