Kubernetes kubectl核心命令实战指南：18个高频诊断与干预命令

1. 这不是命令清单，而是一张 Kubernetes 环境里的“生存地图”

你刚在某实验室的集群里拿到一个 kubeconfig 文件，终端里敲下kubectl get nodes，回车后光标闪了三秒——终于跳出两行带Ready状态的机器名。那一刻你松了口气，但心里清楚：这仅仅是你在 Kubernetes 世界里迈出的第一步，连“站稳”都谈不上。kubectl 命令不是语法考试题，而是你在容器编排战场上实时调兵遣将的无线电频道。我带过十几期某高校的云原生实训班，几乎每届都有学员卡在“明明命令敲对了，为什么 pod 一直 Pending？”、“日志查不到，describe 又看不懂”这类问题上。他们缺的不是命令本身，而是命令背后那套“状态-动作-反馈”的闭环思维。这篇内容不罗列 200 条命令，只聚焦真正高频、真正容易出错、真正能帮你快速定位和干预的 18 个核心命令组合。它们覆盖了从集群健康快筛、工作负载生命周期管理、网络与存储状态诊断，到故障现场取证的完整动线。适合刚通过 CKA 认证但没实操过生产集群的新手，也适合运维老手在凌晨三点排查告警时快速翻阅的“应急手册”。所有命令均基于 v1.26+ 版本实测验证，参数取舍有明确依据，输出字段解读直指关键信号，不堆砌文档原文。

2. 命令设计逻辑：为什么是这 18 个？而不是更多或更少？

2.1 不是“功能全”，而是“路径短”：聚焦四类核心操作动线

Kubernetes 的命令体系庞大，但真实运维中 90% 的操作可归为四条主干路径。我们筛选命令的唯一标准是：能否在 3 步内完成一次有效干预或诊断。任何需要嵌套 5 层jsonpath或依赖外部工具链才能看懂的命令，一律排除。

• 集群健康快筛路径：从get nodes到describe node再到logs组件日志，形成“宏观状态→节点细节→组件日志”的三级穿透。例如kubectl get nodes -o wide会同时显示 IP 和 OS-Image，比单纯get nodes多出两个关键信息维度，却无需额外命令。

• 工作负载生命周期路径：create→get→describe→logs→exec→delete是最典型的 Pod 操作链。这里我们砍掉了apply -f（它属于声明式管理，非即时命令），保留run（用于快速测试镜像）、scale（应对突发流量）、rollout（滚动更新控制）这三个无法被apply完全替代的即时动作。

• 网络与存储状态路径：get svc和get endpoints必须成对出现。单独看 Service 往往误判——ClusterIP显示正常，但endpoints为空，说明后端 Pod 根本没注册进来。同理，get pvc和get pv要交叉验证，PVC 的STATUS是Bound，但 PV 的STATUS是Released，这就是典型的资源回收陷阱。

• 故障现场取证路径：describe是黄金命令，但它输出的信息量巨大。我们只提取其中 7 个必看字段：Conditions（节点就绪条件）、Allocated resources（资源分配水位）、Events（最近 10 条事件）、Containers（容器状态）、Volumes（挂载详情）、Node-Selectors（调度约束）、Tolerations（污点容忍）。其他字段如Annotations在 99% 的故障中无直接价值。

提示：kubectl get默认只显示NAME,READY,STATUS,RESTARTS,AGE五列。但READY列对 Deployment 是2/2，对 Pod 是1/1，对 StatefulSet 是3/3——这个数字本身不告诉你“为什么是 2”，必须结合describe中的Replicas和Available Replicas字段。新手常误以为READY为0/2就是 Pod 启动失败，实际可能是 HPA 尚未触发扩缩容。

2.2 参数精简原则：去掉“看起来有用，实则干扰判断”的选项

kubectl支持上百个 flag，但日常使用中超过 80% 的场景只需 5 个核心参数：

• -n <namespace>：命名空间是 Kubernetes 的第一道隔离墙。不加-n默认操作default，而生产环境里default几乎永远是空的。我见过三次线上事故，根源都是运维在kube-system下执行了delete pods --all，只因忘了加-n monitoring。

• -o wide：这是get类命令的“基础增强包”。get pods只显示 Pod 名和状态，get pods -o wide额外增加NODE（运行在哪台物理机）、IP（Pod IP）、CONTROLLER（由哪个控制器创建）三列。这三列信息在排查网络不通、节点资源争抢、控制器异常时，效率提升 3 倍以上。

• -l <label>：标签选择器是 Kubernetes 的“精准打击系统”。get pods -l app=nginx比get pods | grep nginx更可靠——后者可能匹配到nginx-ingress-controller，而前者只认app=nginx这个精确标签。标签键值对必须完全匹配，-l "env=prod,team=backend"表示 AND 关系，不存在 OR 逻辑。

• --field-selector：当标签不够用时的终极武器。例如get pods --field-selector spec.nodeName=node-03直接筛选运行在特定节点上的所有 Pod，绕过标签体系。这个参数在节点故障隔离、批量迁移时不可替代。

• --sort-by：get pods --sort-by=.status.startTime按启动时间排序，get nodes --sort-by=.status.capacity.cpu按 CPU 容量排序。排序本身不解决故障，但它让“异常值”自动浮到列表顶部——比如某个节点 CPU 容量突然变成0，一眼就能发现。

注意：-o yaml和-o json是调试神器，但绝不该用于日常巡检。它们输出的是完整对象定义，包含大量元数据（如creationTimestamp、resourceVersion），这些字段对判断服务是否可用毫无帮助，反而淹没关键信息。-o wide是平衡信息密度与可读性的最优解。

2.3 版本兼容性锚点：v1.26+ 的关键行为变更

Kubernetes 的命令行为随版本演进有细微但致命的变化。以下三点是 v1.26 引入、且直接影响命令结果的硬性变更：

• kubectl top不再默认启用：v1.26 起，top nodes和top pods需要 Metrics Server 显式部署，且其 API 组从metrics.k8s.io/v1beta1升级为metrics.k8s.io/v1。若执行top nodes报错the server doesn't have a resource type "nodes"，不是命令错了，而是 Metrics Server 未安装或版本不匹配。

• kubectl auth can-i的 RBAC 检查更严格：v1.26 对--list参数的响应格式做了调整。旧版返回yes/no，新版返回allowed: true/allowed: false，且新增reason字段说明拒绝原因（如RBAC: clusterrole.rbac.authorization.k8s.io "view" not found）。这意味着自动化脚本若用grep "yes"判断权限，会在 v1.26+ 环境下全部失效。

• kubectl get events的默认时间窗口缩短：v1.26 将事件默认保留时间从 1 小时缩短为 30 分钟。get events不再显示 1 小时前的事件，除非显式指定--field-selector lastTimestampAfter=2024-01-01T00:00:00Z。这对排查“昨天晚上发生的间歇性故障”造成障碍，必须养成get events --all-namespaces --sort-by=.lastTimestamp的习惯。

3. 核心命令详解与实操现场记录

3.1 集群健康快筛：3 条命令锁定 80% 的集群级故障

3.1.1kubectl get nodes -o wide

这是 Kubernetes 的“体温计”。它不告诉你病因，但能第一时间告诉你“是否发烧”。

$ kubectl get nodes -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME node-01 Ready control-plane 45d v1.26.3 10.0.1.101 <none> Ubuntu 22.04.3 LTS 5.15.0-86-generic containerd://1.7.2 node-02 Ready <none> 45d v1.26.3 10.0.1.102 <none> Ubuntu 22.04.3 LTS 5.15.0-86-generic containerd://1.7.2 node-03 NotReady <none> 2h v1.26.3 10.0.1.103 <none> Ubuntu 22.04.3 LTS 5.15.0-86-generic containerd://1.7.2

关键字段解读：

• STATUS：Ready表示 kubelet 正常上报心跳；NotReady是红色警报，但需进一步确认是网络中断、kubelet 崩溃，还是磁盘压力过大。
• ROLES：control-plane角色节点承担 etcd、API Server 等核心组件。若所有 control-plane 节点STATUS都是NotReady，整个集群已瘫痪。
• INTERNAL-IP：必须是集群内部可路由的 IP。若显示<none>，说明 kubelet 未正确配置--node-ip，Pod 网络将无法通信。
• CONTAINER-RUNTIME：containerd://1.7.2表示运行时版本。v1.26 要求 containerd ≥ v1.6.0，若此处显示docker://20.10，说明集群仍使用 Docker Engine，存在兼容性风险。

实操心得：我曾在某次升级后发现get nodes输出中VERSION列全部为空。排查发现是 kubelet 配置文件中--kubeconfig路径错误，导致 kubelet 无法连接 API Server，自然无法上报版本信息。此时get nodes本身仍是成功的（因为缓存），但describe node会立即暴露Unable to connect to the server错误。

3.1.2kubectl describe node <node-name>

当get nodes显示NotReady时，describe node是你的“CT 扫描仪”。它输出约 200 行信息，但只需盯住三个区块：

$ kubectl describe node node-03 ... Conditions: Type Status LastHeartbeatTime LastTransitionTime Reason Message ---- ------ ----------------- ------------------ ------ ------- MemoryPressure False Mon, 01 Jan 2024 10:00:00 +0000 Mon, 01 Jan 2024 09:55:00 +0000 KubeletHasSufficientMemory kubelet has sufficient memory available DiskPressure True Mon, 01 Jan 2024 10:00:00 +0000 Mon, 01 Jan 2024 09:50:00 +0000 KubeletHasInsufficientDisk kubelet has insufficient disk space available PIDPressure False Mon, 01 Jan 2024 10:00:00 +0000 Mon, 01 Jan 2024 09:55:00 +0000 KubeletHasSufficientPID kubelet has sufficient PID available Ready False Mon, 01 Jan 2024 10:00:00 +0000 Mon, 01 Jan 2024 09:50:00 +0000 KubeletNotReady runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized Allocated resources: (Total limits may be over 100 percent, i.e., overcommitted.) Resource Requests Limits -------- -------- ------ cpu 1100m (55%) 2100m (105%) memory 1800Mi (45%) 3200Mi (80%) ephemeral-storage 0 (0%) 0 (0%) Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning ImageGCFailed 2m (x15 over 1h) kubelet failed to garbage collect required amount of images. Wanted to free 123456789 bytes, but freed 0 bytes Normal NodeHasSufficientMemory 1m (x20 over 1h) kubelet Node node-03 status is now: NodeHasSufficientMemory Warning EvictionThresholdMet 30s kubelet Attempting to reclaim ephemeral-storage

• Conditions 区块：这是诊断核心。DiskPressure: True直接解释了Ready: False的原因——磁盘空间不足。Reason字段KubeletHasInsufficientDisk和Message字段kubelet has insufficient disk space available是精准定位的关键线索。

• Allocated resources 区块：cpu请求量1100m（即 1.1 核），占节点总容量2000m的 55%；但memory限制量3200Mi占总容量4000Mi的 80%。这说明内存是瓶颈，CPU 尚有余量。若此处ephemeral-storage显示10Gi (95%)，则印证了磁盘压力。

• Events 区块：ImageGCFailed事件反复出现，表明镜像垃圾回收失败，这是磁盘空间耗尽的直接前兆。EvictionThresholdMet是 kubelet 启动驱逐的信号。

提示：describe node输出的Capacity和Allocatable字段常被忽略。Capacity是硬件真实容量，Allocatable是 Kubernetes 实际可调度的容量（已扣除系统预留资源）。若Allocatable远小于Capacity，说明 kubelet 配置了过高的--system-reserved，导致可用资源被过度预留。

3.1.3kubectl get componentstatuses（已弃用，但必须知道替代方案）

v1.26+ 中componentstatuses已被移除，因其依赖的/healthz端点不再提供细粒度状态。替代方案是直接检查核心组件的健康端点：

# 检查 API Server（通常暴露在 6443 端口） $ curl -k https://127.0.0.1:6443/healthz ok # 检查 etcd（需在 control-plane 节点执行） $ kubectl exec -n kube-system etcd-node-01 -- etcdctl endpoint health --cluster https://10.0.1.101:2379 is healthy: successfully committed proposal: took = 12.345ms # 检查 Scheduler 和 Controller Manager（通过日志） $ kubectl logs -n kube-system kube-scheduler-node-01 | tail -5 I0101 10:00:00.000000 1 leaderelection.go:248] attempting to acquire leader lease kube-system/kube-scheduler... I0101 10:00:00.000000 1 leaderelection.go:258] successfully acquired lease kube-system/kube-scheduler

leaderelection.go:258日志中的successfully acquired lease是 Scheduler 正常工作的铁证。若日志中持续出现failed to renew lease，说明 Scheduler 选举失败，需检查kube-system命名空间下的endpoints资源。

3.2 工作负载生命周期管理：从创建到销毁的 7 个关键动作

3.2.1kubectl run：不只是“跑个容器”，而是“快速验证镜像可用性”

kubectl run是kubectl create deployment的快捷方式，但它的核心价值在于即时性。create deployment创建的是声明式对象，需等待控制器同步；run则直接启动一个 Pod，用于快速验证。

# 最简模式：启动单个 nginx Pod $ kubectl run nginx-test --image=nginx:alpine # 带端口映射和环境变量（模拟真实应用） $ kubectl run web-test \ --image=nginx:alpine \ --port=80 \ --env="ENV=staging" \ --labels="app=web-test" # 暴露为 Service（一步到位） $ kubectl run db-test \ --image=postgres:13 \ --port=5432 \ --expose \ --name=db-service

关键参数解析：

• --port=80：此参数仅设置容器端口，不创建 Service。它等价于在 Pod Spec 中添加containers[0].ports[0].containerPort: 80。若想对外提供服务，必须配合expose或后续create service。
• --expose：这是run命令的隐藏王牌。它会在创建 Pod 的同时，自动生成一个同名的 ClusterIP Service，并将 Service 的targetPort自动设为--port指定的值。run db-test --port=5432 --expose生成的 Service，其spec.ports[0].targetPort就是5432。

实操心得：run创建的 Pod 默认不带重启策略（restartPolicy: Always），但若 Pod 因错误退出，run不会自动重建——它只是“运行一次”。这与deployment的“确保始终有 N 个副本”有本质区别。因此run仅用于测试，切勿用于生产工作负载。

3.2.2kubectl scale：应对流量洪峰的“手动油门”

scale是 Deployment/StatefulSet 的“实时扩缩容开关”，它绕过 HPA 的监控-决策-执行循环，实现秒级响应。

# 将 nginx-deployment 从 3 个副本扩到 10 个 $ kubectl scale deployment nginx-deployment --replicas=10 # 缩容到 1 个（谨慎！） $ kubectl scale deployment nginx-deployment --replicas=1 # 对 StatefulSet 扩容（注意：StatefulSet 扩容是有序的，新 Pod 名为 nginx-3） $ kubectl scale statefulset nginx-statefulset --replicas=5

底层原理：scale命令直接 PATCH 更新 Deployment 的spec.replicas字段。API Server 接收到请求后，立即触发 Deployment Controller 的 Reconcile 循环，Controller 比较当前status.replicas（实际运行数）与spec.replicas（期望数），若不一致，则创建或删除 ReplicaSet。

注意：scale不修改 Pod 的resources限制。若原有 Pod 申请 512Mi 内存，扩容后的 Pod 依然申请 512Mi。若集群剩余内存不足，新 Pod 将处于Pending状态。此时需先scale down其他工作负载，或editDeployment 增加资源限制。

3.2.3kubectl rollout：滚动更新的“手术刀”

rollout是管理 Deployment 更新过程的专用命令，它把抽象的“滚动更新”变成了可观察、可控制、可回退的具体动作。

# 查看 rollout 历史（每个 revision 对应一次更新） $ kubectl rollout history deployment nginx-deployment deployment.apps/nginx-deployment REVISION CHANGE-CAUSE 1 kubectl run nginx-deployment --image=nginx:1.20 --replicas=3 2 kubectl set image deployment nginx-deployment nginx=nginx:1.21 # 回退到上一个版本（revision 1） $ kubectl rollout undo deployment nginx-deployment # 回退到指定 revision $ kubectl rollout undo deployment nginx-deployment --to-revision=1 # 暂停 rollout（冻结更新过程，便于人工检查） $ kubectl rollout pause deployment nginx-deployment # 恢复 rollout $ kubectl rollout resume deployment nginx-deployment

rollout history输出的CHANGE-CAUSE字段至关重要。它默认为空，需在首次创建 Deployment 时添加--record参数才能捕获命令行：

$ kubectl create deployment nginx-deployment --image=nginx:1.20 --replicas=3 --record

实操心得：rollout pause是我的“安全网”。在更新关键业务 Deployment 前，我会先pause，然后get pods确认新 Pod 已 Running 且 Ready，再logs检查应用日志无 ERROR，最后resume。这避免了“更新后才发现数据库连接字符串写错了”的灾难。

3.2.4kubectl get pods -o wide --sort-by=.status.startTime

这不是一个命令，而是一个“故障发现流水线”。它把时间维度引入 Pod 状态分析。

$ kubectl get pods -n production -o wide --sort-by=.status.startTime NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES api-7c8b9d4f5c-abcde 1/1 Running 0 15d 10.244.2.10 node-02 <none> <none> worker-5f6b8c7d4e-fghij 1/1 Running 0 15d 10.244.3.15 node-03 <none> <none> frontend-6d5c4b3a2f-klmno 0/1 Pending 0 2m <none> <none> <none> <none>

AGE列显示2m，但--sort-by=.status.startTime让frontendPod 排在最底部，说明它是最新创建的。STATUS为Pending，IP和NODE为空，这是典型的调度失败信号。此时应立即describe pod frontend-6d5c4b3a2f-klmno，重点查看Events中的FailedScheduling事件。

提示：--sort-by支持任意 JSONPath 表达式。--sort-by=.metadata.creationTimestamp按创建时间排序，--sort-by=.status.phase按状态排序（Pending排最前），--sort-by=.spec.nodeName按节点分组。这些技巧让get pods从“状态快照”变成“动态诊断面板”。

3.2.5kubectl logs：不止是“看日志”，而是“构建上下文”

logs命令的威力在于其上下文感知能力。它不是简单地 cat 容器日志，而是理解 Kubernetes 的多容器、多副本、多命名空间结构。

# 查看单个 Pod 的日志（默认第一个容器） $ kubectl logs api-7c8b9d4f5c-abcde # 查看指定容器的日志（Pod 内有多个容器时必需） $ kubectl logs api-7c8b9d4f5c-abcde -c api-server # 查看最近 100 行（避免刷屏） $ kubectl logs api-7c8b9d4f5c-abcde --tail=100 # 查看过去 5 分钟的日志（需容器运行时支持） $ kubectl logs api-7c8b9d4f5c-abcde --since=5m # 跟踪实时日志（类似 tail -f） $ kubectl logs api-7c8b9d4f5c-abcde -f # 查看已终止 Pod 的日志（容器退出后日志仍可读） $ kubectl logs api-7c8b9d4f5c-abcde --previous

--previous是救命参数。当 Pod 因 CrashLoopBackOff 重启时，logs默认显示当前容器（可能刚启动，日志为空），而--previous显示上一个崩溃容器的日志，这才是错误真相所在。

实操心得：logs的-f模式在排查间歇性故障时极有用。我曾遇到一个服务每 30 分钟 panic 一次，-f模式让我在终端里守株待兔，直接捕获到 panic stack trace，而不用去翻查分散在各节点的 log 文件。

3.2.6kubectl exec：进入容器的“物理通道”

exec是 Kubernetes 的“SSH”，但它比 SSH 更受限、更安全。exec的核心是nsenter，它利用 Linux namespace 隔离机制，将用户进程注入到目标容器的 PID、NET、UTS 等 namespace 中。

# 进入容器执行 shell（需容器内有 sh/bash） $ kubectl exec -it api-7c8b9d4f5c-abcde -- sh # 执行单条命令（无需交互） $ kubectl exec api-7c8b9d4f5c-abcde -- ls /app/config # 指定容器（多容器 Pod） $ kubectl exec -it api-7c8b9d4f5c-abcde -c api-server -- ps aux # 以特定用户执行（绕过容器默认用户限制） $ kubectl exec -it api-7c8b9d4f5c-abcde -u 0 -- sh

-u 0参数允许你以 root 用户执行命令，这在调试权限问题时必不可少。但生产环境应禁用此功能，通过 RBAC 的securityContext严格控制。

注意：exec依赖容器内存在sh或bash。Alpine 镜像默认只有ash，此时需kubectl exec -it pod-name -- ash。若容器是scratch构建的（无任何 shell），exec将失败，只能通过logs或describe间接诊断。

3.2.7kubectl delete：删除不是终点，而是“资源释放确认”

delete命令看似简单，但其背后的垃圾回收（Garbage Collection）机制决定了删除是否真正完成。

# 立即删除（不等待） $ kubectl delete pod nginx-test # 强制删除（绕过 graceful termination） $ kubectl delete pod nginx-test --force --grace-period=0 # 删除时等待所有依赖资源清理完毕 $ kubectl delete deployment nginx-deployment --cascade=foreground # 删除 Deployment 但保留其创建的 Pod（孤儿化） $ kubectl delete deployment nginx-deployment --cascade=orphan

--cascade=foreground是安全删除的黄金标准。它让 API Server 先将 Deployment 的ownerReferences设置为blockOwnerDeletion=true，然后等待其管理的所有 ReplicaSet 和 Pod 完全终止后，才删除 Deployment 本身。这避免了“Deployment 已删，但 Pod 还在野跑”的混乱。

实操心得：--force --grace-period=0是“最后手段”。它直接向 etcd 发送 DELETE 请求，不通知 kubelet。若 kubelet 正在同步状态，可能导致 etcd 中资源已删，但节点上容器仍在运行。我只在delete卡死（如 Pod 处于Terminating状态超 5 分钟）时使用，且事后必查get pods --all-namespaces | grep Terminating。

3.3 网络与存储状态诊断：4 组命令交叉验证

3.3.1kubectl get svc与kubectl get endpoints：Service 的“双盲测试”

Service 是 Kubernetes 的网络抽象，但它的可用性取决于后端 Endpoint 是否真实存在。

$ kubectl get svc -n production NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE api-service ClusterIP 10.96.123.45 <none> 80/TCP 30d db-service ClusterIP 10.96.234.56 <none> 5432/TCP 30d $ kubectl get endpoints -n production NAME ENDPOINTS AGE api-service 10.244.2.10:80,10.244.2.11:80 30d db-service <none> 30d

api-service的ENDPOINTS显示两个 IP，说明后端 Pod 注册成功；db-service的ENDPOINTS为<none>，这是严重警告。此时get pods -n production -l app=db应返回 0 个 Pod，或返回的 PodSTATUS不是Running。

提示：get endpoints的ENDPOINTS列显示的是PodIP:Port，而非 Service IP。这证明 Service 的负载均衡是直接作用于 Pod，而非通过中间代理。若此处 IP 是10.244.x.x，说明 CNI 插件（如 Calico、Flannel）工作正常；若显示127.0.0.1，则是 CNI 配置错误。

3.3.2kubectl get pvc与kubectl get pv：存储的“供需匹配表”

PVC（PersistentVolumeClaim）和 PV（PersistentVolume）是 Kubernetes 的存储配对机制，它们的状态必须严格匹配。

$ kubectl get pvc -n production NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE db-data-pvc Bound pvc-12345678-9abc-def0-1234-567890abcdef 10Gi RWO standard 30d app-config-pvc Pending <none> 1Gi RWO standard 2h $ kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-12345678-9abc-def0-1234-567890abcdef 10Gi RWO Delete Bound production/db-data-pvc standard 30d pv-manual-01 100Gi RWO Retain Available <none> manual 10d

db-data-pvc的STATUS是Bound，PV的STATUS是Bound，且CLAIM字段指向production/db-data-pvc，匹配成功。app-config-pvc的STATUS是Pending，说明没有 PV 满足其要求。查看PV列表，pv-manual-01的STATUS是Available，但ACCESS MODES是RWO（ReadWriteOnce），而 PVC 要求RWO，容量1Gi小于100Gi，理论上应匹配。问题出在STORAGECLASS：PVC 的STORAGECLASS是standard，而pv-manual-01的STORAGECLASS是manual，不匹配。

实操心得：get pvc的VOLUME列显示pvc-xxx，这是 PV 的名字。若此处为空，说明 PVC 未绑定；若此处有值但get pv中找不到对应 PV，说明 PV 被手动删除，PVC 进入Lost状态，需patchPVC 清除volumeName字段才能重新绑定。

3.3.3kubectl get networkpolicies：网络策略的“隐形防火墙”

NetworkPolicy 是 Kubernetes 的微隔离工具，它默认是“全通”，只有显式定义的策略才生效。

$ kubectl get networkpolicies -n production NAME POD-SELECTOR AGE deny-all <none> 1d api-to-db app=db 1d $ kubectl describe networkpolicy deny-all -n production Name: deny-all Namespace: production Created on: 2024-01-01 00:00:00 +0000 UTC Labels: <none> Annotations: <none> Spec: PodSelector: <none> (Allowing the specific traffic to all pods in this namespace) Allowing ingress traffic: <none> (Selected pods are isolated for ingress connections) Allowing egress traffic: <none> (Selected pods are isolated for egress connections) Policy Types: Ingress, Egress