kubectl 常用命令

日常和 Kubernetes 集群打交道,绝大部分操作都绕不开 kubectl。命令本身不难,难的是需要用的时候想不起来——尤其是节点维护、强制删除这类低频但关键的操作。这篇把我平时用得最多的命令按场景整理一遍,忘了就回来翻。

kubectl 的所有操作本质上都是向 kube-apiserver 发 REST 请求:查看是 GET,应用配置是对期望状态的声明式更新,删除则是把对象从 etcd 中移除,再由各控制器去收敛实际状态。理解这一点,很多命令的行为就好解释了。

先从最基础的开始,不确定参数怎么写时,帮助信息永远是第一入口:

# 查看帮助信息,也可以针对子命令,如 kubectl get --help
kubectl --help

集群与节点查看

# 查看集群节点数及各节点状态(Ready / NotReady)
kubectl get nodes

# 查看 node 节点详细信息:pod 信息以及硬件资源占用情况
# 排查节点资源不足、Pod 无法调度时常用
kubectl describe node <节点名称>

describe node 的输出里,Conditions、Allocated resources 和 Events 三段信息量最大,节点异常时优先看这几处。

命名空间与 Pod 查看

Kubernetes 用命名空间做资源隔离,查询类命令大多需要用 -n 指定命名空间,不指定则默认 default:

# 查看命名空间
kubectl get namespace

# 查看对应命名空间下 pod 信息
kubectl get pod -n <命名空间>

# 查看所有命名空间下的 pod,-A 是 --all-namespaces 的缩写
kubectl get pods -A

# 查看所有命名空间下的 pod(完整参数写法为 --all-namespaces)
kubectl get pod --all-namespace

定位到具体 Pod 之后,排查问题主要靠 describe 和 logs 两个命令,一个看事件,一个看日志:

# 显示一个或多个资源对象的详细信息
# 调度失败、镜像拉取失败等原因都在 Events 里
kubectl describe

# 输出 pod 资源对象中一个容器的日志
# 多容器 Pod 需要用 -c 指定容器名
kubectl logs

一个经验:Pod 起不来先 describe 看事件,起来了但行为不对再 logs 看日志,顺序反了往往白翻半天。

资源的创建与删除

kubectl 管理资源有两种风格:create 是命令式,直接告诉集群创建什么;apply 是声明式,把 yaml 里描述的期望状态提交给集群,已存在则做增量更新。日常维护配置文件推荐用 apply,同一份文件可以反复执行。

# 通过 yaml/json 文件或者标准输入创建一个资源对象
kubectl create

# 应用 pod 配置文件,设置资源;文件已应用过则做增量更新
kubectl apply -f <pod.yaml>

# 取消应用 pod 配置文件,删除资源
kubectl delete -f <pod.yaml>

# 删除指定命名空间下的 Deployment
# 注意:删除 Deployment 会级联删除它管理的 ReplicaSet 和 Pod
kubectl delete Deployments -n <命名空间> <Deployment名称>

批量清理和强制删除的几个命令,破坏性依次递增:

# 强制删除状态为 Terminating 的 pod
# --grace-period=0 表示跳过优雅终止等待
kubectl delete pod <podname> -n <namespace> --force --grace-period=0

# 删除某个 namespace 下所有 pod
# 由 Deployment 等控制器管理的 Pod 会被自动重建
kubectl delete --all pods --namespace=<namespace>

# 清除掉 namespace,其下所有资源一并级联删除
kubectl delete ns <namespace>

还有两个修改类的命令,用来给资源打标签和临时改配置:

# 设置资源标签,标签是 Service 选择后端、节点亲和性调度的依据
kubectl label

# 使用默认编辑器编辑服务器上定义的资源对象,保存即生效
kubectl edit

edit 适合应急调试,但改动不会同步回本地 yaml 文件,改完记得把变更落回配置文件,否则下次 apply 会被覆盖。

节点维护

下线节点做维护(升级内核、换硬件)的标准流程是先 cordon 再 drain:cordon 只是把节点标记为不可调度,存量 Pod 不受影响;drain 在此基础上把节点上已有的 Pod 驱逐走,由控制器在其他节点重建。

# 驱逐节点:标记节点不可调度,新 Pod 不再调度到该节点
kubectl cordon <节点名称>

# 驱逐节点 pod
kubectl drain

# 驱逐该节点所有的 pod
# --ignore-daemonsets:跳过 DaemonSet 管理的 Pod(它们本就每节点一份,驱逐了也会重建)
# --delete-local-data:连带删除使用 emptyDir 本地数据的 Pod
kubectl drain <节点名称> --delete-local-data --force --ignore-daemonsets

# 维护完成后从集群中删除掉 node 节点
kubectl delete nodes <节点名称>

导出资源配置

线上手动改过的资源,想把当前状态固化成 yaml 文件时,可以用 -o yaml 加重定向导出:

# 把现有的 pod 导出 yaml 配置文件
kubectl get deployment -n <命名空间> <pod名称> -o yaml > <文件名称>.yaml

导出的 yaml 会带上 status、resourceVersion、uid 这类集群运行时字段,拿去别处 apply 之前最好先清理掉,只留 spec 相关的部分。

踩坑与注意

1)--all-namespace 这个写法容易记错,完整参数是 --all-namespaces(带 s),日常直接用缩写 -A 最省事。

2)--force --grace-period=0 强制删除只是让 API Server 立即移除对象,容器进程未必真的退出了。对有状态服务慎用,可能导致同一实例"脑裂"式地跑两份。

3)删除 namespace 是级联操作,其下的 Deployment、Service、ConfigMap 全部一起消失,执行前先 kubectl get all -n <namespace> 确认一遍里面还有什么。

4)drain 时如果不加 --ignore-daemonsets,遇到 DaemonSet 管理的 Pod 命令会直接报错中断;--delete-local-data 在较新版本中已更名为 --delete-emptydir-data,旧参数报错时换新名字即可。

注意

drain 会真实驱逐业务 Pod,生产环境执行前确认副本数足够、其他节点有余量,避免服务容量骤降。

小结

这份清单覆盖了查看、创建删除、节点维护、配置导出四类高频场景。命令记不全没关系,记住两条主线就够了:查询排障走 get → describe → logs,节点下线走 cordon → drain → delete node。其余的,--help 随时可查。