K8s系列第十四篇：K8s 故障排查实战：常见故障定位与解决方法

前言：在上一篇文章中，我们聚焦K8s监控告警的核心需求，详细讲解了Prometheus + Grafana方案的部署与配置，从监控告警原理、组件分工，到Prometheus完整实操、Grafana可视化与告警配置，再到存储优化、生产最佳实践和常见问题排错，全程实操、命令可复制，帮你彻底解决了"无法实时监控集群状态、故障无法及时发现"的难题，搭建了"实时监控→异常告警"的基础体系，为故障排查提供了重要支撑。

重点回顾3点（衔接上一篇核心）：

1. 监控告警的核心是"实时采集、异常识别、及时通知"，Prometheus负责指标采集与存储，Grafana负责可视化与告警，二者协同形成监控闭环；

2. Prometheus核心部署：Server（采集存储）+ Node Exporter（节点指标）+ kube-state-metrics（组件指标），需开启持久化、配置监控目标；

3. 生产环境中，需优化指标存储、配置多渠道告警，定期演练和复盘，减少误告警，确保故障能及时被发现。

正如上一篇结尾预告，本节课我们将进入K8s运维体系的核心实战环节------故障排查。在前面的教程中，我们解决了应用的"部署、调度、自愈、监控、日志收集"等问题，但生产环境中，K8s集群和应用难免会出现各种故障：Pod启动失败、Service无法访问、集群节点异常、应用日志报错、监控指标异常等。很多小白遇到故障时，往往无从下手，不知道该查看哪些日志、执行哪些命令，导致故障排查效率极低，甚至扩大故障影响。

K8s故障排查的核心是"定位根源、快速解决"，而高效排查的关键的是"掌握排查思路、熟悉常用命令、结合日志与监控"。本文依然针对小白，延续系列"全程实操、命令可复制、场景化讲解"的风格，从"故障排查核心思路、常用排查命令、常见故障实战（Pod/Service/节点/集群）、故障排查工具、生产环境排查最佳实践"五个维度，手把手教你掌握K8s故障排查的核心方法，结合前面学到的日志收集（EFK/ELK）、监控告警（Prometheus+Grafana）知识，形成"监控→告警→排查→解决"的完整闭环，彻底解决"遇到故障无从下手"的痛点，贴合生产环境实际需求，为后续集群优化打下基础。

前置要求：已搭建好K8s集群，掌握Pod、Deployment、Service、EFK/ELK、Prometheus+Grafana的基本概念和基础操作（参考前十三篇教程）；熟悉常用的Linux命令（如grep、tail、ps）；已部署基础应用（如Nginx、Redis），用于模拟故障场景；具备基本的日志分析能力。

一、先掌握：K8s故障排查核心思路（小白必记）

小白排查K8s故障，最容易陷入"盲目执行命令、到处找日志"的误区，浪费大量时间。其实，K8s故障排查有固定的思路，只需遵循"从现象到本质、从上层到下层、从局部到整体"的原则，一步一步定位根源，就能高效解决问题。

核心排查思路（四步走，适用于所有K8s故障）：

1.1 第一步：明确故障现象（找准问题起点）

遇到故障时，首先要明确"故障是什么、影响范围有多大"，避免盲目排查。常见的故障现象描述：

• 应用层面：Pod启动失败（状态为CrashLoopBackOff、Error）、Pod无法调度（状态为Pending）、应用无法访问（接口返回404/500）；

• 服务层面：Service无法访问、Ingress转发失败、负载均衡异常；

• 集群层面：节点异常（状态为NotReady）、核心组件（kube-apiserver、kubelet）故障、集群无法创建资源；

• 监控层面：Prometheus指标异常、Grafana告警触发（如CPU使用率过高、Pod重启次数过多）。

关键：明确故障现象时，要记录关键信息（如Pod名称、命名空间、故障时间、影响范围），为后续排查提供依据。

1.2 第二步：定位故障范围（缩小排查区间）

明确故障现象后，下一步是定位故障范围，判断故障是"单个Pod""单个应用""单个节点"还是"整个集群"，缩小排查区间：

• 若只有单个Pod异常，其他Pod正常 → 故障范围为"单个Pod"（优先排查Pod配置、镜像、资源）；

• 若同一应用的所有Pod异常，其他应用正常 → 故障范围为"应用本身"（优先排查Deployment配置、Service配置）；

• 若某个节点上的所有Pod异常，其他节点正常 → 故障范围为"节点"（优先排查节点状态、kubelet服务）；

• 若整个集群的所有资源都无法操作 → 故障范围为"集群核心组件"（优先排查kube-apiserver、etcd）。

1.3 第三步：查看日志与指标（定位故障根源）

定位故障范围后，通过查看日志和监控指标，找到故障的具体原因------这是故障排查的核心步骤。重点查看三类信息：

• Pod日志：查看异常Pod的日志，排查应用本身的错误（如代码报错、配置错误）；

• 组件日志：查看K8s核心组件（kubelet、kube-apiserver、etcd）的日志，排查集群层面的故障；

• 监控指标：通过Prometheus+Grafana查看异常指标（如CPU、内存、网络），辅助定位故障（如资源不足导致Pod启动失败）。

补充：日志查看优先使用EFK/ELK（集中化日志），若EFK/ELK未部署，可使用kubectl logs命令查看单个Pod日志。

1.4 第四步：验证与解决（快速恢复服务）

找到故障根源后，执行对应的解决方法，然后验证故障是否解决，确保服务恢复正常：

• 解决方法：根据故障原因，修改配置（如Pod资源限制、镜像地址）、重启组件（如kubelet）、修复节点（如重启节点）；

• 验证方法：查看Pod状态、访问应用接口、查看监控指标，确认故障已解决，服务恢复正常。

关键提醒：故障解决后，要记录故障原因、解决方法和预防措施，避免同类故障再次发生。

二、必备工具：K8s故障排查常用命令（必背）

排查K8s故障，离不开常用的kubectl命令和Linux命令，本节整理了最常用的排查命令，按"Pod排查、Service排查、节点排查、集群排查"分类，命令可直接复制使用，小白务必熟记。

2.1 Pod相关排查命令（最常用）

Pod是K8s最小的部署单元，也是故障最常出现的地方，以下命令覆盖Pod状态、日志、配置、事件等核心排查场景：

# 1. 查看指定命名空间的所有Pod状态（核心命令）
kubectl get pods -n <命名空间>  # 如kubectl get pods -n default
kubectl get pods -n <命名空间> -o wide  # 查看Pod所在节点、IP等详细信息

# 2. 查看单个Pod的详细信息（定位Pod故障核心）
kubectl describe pod <Pod名称> -n <命名空间>  # 重点看Events字段，显示Pod启动失败原因

# 3. 查看Pod日志（排查应用本身错误）
kubectl logs <Pod名称> -n <命名空间>  # 查看Pod最新日志
kubectl logs <Pod名称> -n <命名空间> -f  # 实时查看Pod日志（类似tail -f）
kubectl logs <Pod名称> -n <命名空间> --tail=100  # 查看最近100行日志
kubectl logs <Pod名称> -n <命名空间> -c <容器名称>  # 当Pod有多个容器时，指定容器查看日志

# 4. 进入Pod容器内部（排查容器内环境、应用配置）
kubectl exec -it <Pod名称> -n <命名空间> -- /bin/bash  # 进入容器终端
kubectl exec -it <Pod名称> -n <命名空间> -c <容器名称> -- /bin/bash  # 指定容器进入

# 5. 重启Pod（临时解决Pod异常，如CrashLoopBackOff）
kubectl delete pod <Pod名称> -n <命名空间>  # Deployment管理的Pod会自动重建
kubectl rollout restart deployment <Deployment名称> -n <命名空间>  # 重启整个Deployment的Pod

# 6. 查看Pod的资源使用情况（排查资源不足）
kubectl top pod <Pod名称> -n <命名空间>  # 查看Pod的CPU、内存使用率

2.2 Service相关排查命令

Service负责Pod的访问入口，若应用无法访问，优先排查Service配置，常用命令如下：

# 1. 查看指定命名空间的所有Service状态
kubectl get svc -n <命名空间>
kubectl get svc -n <命名空间> -o wide  # 查看Service的ClusterIP、端口等详细信息

# 2. 查看单个Service的详细信息（定位Service配置错误）
kubectl describe svc <Service名称> -n <命名空间>  # 重点看Endpoints字段，确认是否关联Pod

# 3. 测试Service的连通性（排查Service是否能访问Pod）
kubectl exec -it <测试Pod名称> -n <命名空间> -- curl <Service ClusterIP>:<端口>

# 4. 查看Service关联的Pod（Endpoints）
kubectl get endpoints <Service名称> -n <命名空间>  # 若Endpoints为空，说明Service未关联到Pod

2.3 节点相关排查命令

节点异常会导致Pod无法调度或运行失败，常用排查命令如下：

# 1. 查看集群所有节点状态
kubectl get nodes
kubectl get nodes -o wide  # 查看节点IP、操作系统、容器运行时等信息

# 2. 查看单个节点的详细信息（定位节点故障）
kubectl describe node <节点名称>  # 重点看Conditions、Allocatable、Capacity字段

# 3. 查看节点的资源使用情况（排查节点资源耗尽）
kubectl top node <节点名称>  # 查看节点CPU、内存、磁盘使用率

# 4. 查看节点上的Pod（排查节点负载过高）
kubectl get pods -n all --field-selector spec.nodeName=<节点名称>

# 5. 登录节点（排查节点系统故障）
ssh <节点IP>  # 需配置节点SSH登录权限

# 6. 查看节点kubelet服务状态（核心节点组件）
systemctl status kubelet  # 查看kubelet运行状态
journalctl -u kubelet -f  # 实时查看kubelet日志

2.4 集群核心组件排查命令

集群核心组件（kube-apiserver、kube-controller-manager、etcd、kube-scheduler）故障会导致整个集群异常，常用排查命令如下：

# 1. 查看集群核心组件的Pod状态（默认在kube-system命名空间）
kubectl get pods -n kube-system
kubectl get pods -n kube-system -l component=kube-apiserver  # 查看kube-apiserver状态
kubectl get pods -n kube-system -l component=etcd  # 查看etcd状态

# 2. 查看核心组件的日志（排查组件故障）
kubectl logs <kube-apiserver-pod名称> -n kube-system
kubectl logs <etcd-pod名称> -n kube-system
kubectl logs <kube-controller-manager-pod名称> -n kube-system

# 3. 查看集群信息（确认集群状态）
kubectl cluster-info  # 查看集群核心组件的访问地址
kubectl get componentstatuses  # 查看集群核心组件状态（已废弃，推荐用kubectl get pods -n kube-system）

# 4. 查看集群事件（排查集群级别的异常）
kubectl get events -n <命名空间>  # 查看指定命名空间的事件
kubectl get events --all-namespaces  # 查看所有命名空间的事件

三、实战：K8s常见故障排查（小白必练）

本节结合生产环境中最常见的6类故障，按"故障现象→排查步骤→解决方法→验证"的流程，手把手实操，让小白能直接套用排查思路和命令，解决实际问题。所有故障场景均模拟真实生产环境，命令可直接复制执行。

3.1 故障1：Pod启动失败，状态为CrashLoopBackOff

【故障现象】：部署Nginx Pod后，Pod状态一直为CrashLoopBackOff，反复重启，无法正常运行。

【排查步骤】：

# 1. 查看Pod状态，确认故障现象
kubectl get pods -n default  # 看到Pod状态为CrashLoopBackOff

# 2. 查看Pod详细信息，重点看Events字段
kubectl describe pod <nginx-pod名称> -n default
# 假设Events字段显示：Back-off restarting failed container，说明容器启动失败，反复重启

# 3. 查看Pod日志，排查容器启动失败原因
kubectl logs <nginx-pod名称> -n default -f
# 假设日志显示：nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
# 原因：容器内80端口被占用，导致Nginx启动失败

【解决方法】：

# 1. 编辑Nginx Deployment，修改容器端口（如将80端口改为8080）
kubectl edit deployment nginx-log-test -n default
# 修改containers.ports.containerPort为8080

# 2. 重启Deployment，应用配置
kubectl rollout restart deployment nginx-log-test -n default

# 补充：若日志显示"镜像拉取失败"（ImagePullBackOff），则修改镜像地址为正确地址（如nginx:1.24）

【验证】：kubectl get pods -n default，查看Pod状态变为Running，说明故障解决。

3.2 故障2：Pod无法调度，状态为Pending

【故障现象】：创建Pod后，Pod状态一直为Pending，无法调度到任何节点。

【排查步骤】：

# 1. 查看Pod状态，确认故障现象
kubectl get pods -n default  # Pod状态为Pending

# 2. 查看Pod详细信息，重点看Events字段
kubectl describe pod <pod名称> -n default
# 常见原因1：节点资源不足（Events显示：0/3 nodes are available: 3 Insufficient cpu.）
# 常见原因2：节点污点（Taint）导致Pod无法调度（Events显示：No nodes available to schedule pods）
# 常见原因3：Pod配置了节点亲和性，无匹配节点

【解决方法】（以"节点资源不足"为例）：

# 1. 查看节点资源使用情况，确认节点CPU/内存不足
kubectl top node

# 2. 方法1：扩容节点，增加集群资源（生产环境常用）
# 方法2：减少Pod的资源请求值（测试环境临时解决）
kubectl edit pod <pod名称> -n default
# 修改resources.requests.cpu和resources.requests.memory为更小的值（如cpu: 100m，memory: 128Mi）

# 方法3：删除节点上无用的Pod，释放资源
kubectl delete pod <无用Pod名称> -n default

【验证】：kubectl get pods -n default，查看Pod状态变为Running，说明故障解决。

3.3 故障3：Service无法访问，应用接口不通

【故障现象】：Pod状态为Running，但通过Service的ClusterIP无法访问应用，接口返回"Connection refused"。

【排查步骤】：

# 1. 查看Pod状态，确认Pod正常运行
kubectl get pods -n default -l app=nginx-log  # Pod状态为Running

# 2. 查看Service详细信息，重点看Endpoints字段
kubectl describe svc <nginx-service名称> -n default
# 若Endpoints字段为空，说明Service未关联到Pod（原因：Service的selector与Pod的labels不匹配）

# 3. 查看Service和Pod的标签，确认匹配
kubectl get svc <nginx-service名称> -n default -o jsonpath='{.spec.selector}'
kubectl get pods <nginx-pod名称> -n default -o jsonpath='{.metadata.labels}'
# 对比两者的标签，若不一致，即为故障原因

【解决方法】：

# 编辑Service，修改selector，使其与Pod的labels一致
kubectl edit svc <nginx-service名称> -n default
# 例如：Pod标签为app=nginx-log，Service的selector也改为app=nginx-log

# 补充：若Endpoints不为空，可测试Pod直接访问（排除应用本身问题）
kubectl exec -it <测试Pod名称> -n default -- curl <Pod IP>:<端口>

【验证】：kubectl exec -it <测试Pod名称> -n default -- curl :<端口>，能正常返回应用页面，说明故障解决。

3.4 故障4：节点状态为NotReady，Pod无法在该节点运行

【故障现象】：集群中某个节点状态变为NotReady，该节点上的Pod无法正常运行，新Pod也无法调度到该节点。

【排查步骤】：

# 1. 查看节点状态，确认故障现象
kubectl get nodes  # 节点状态为NotReady

# 2. 查看节点详细信息，重点看Conditions字段
kubectl describe node <节点名称>
# 常见原因1：kubelet服务未运行（Conditions显示：KubeletNotReady）
# 常见原因2：容器运行时（如containerd）故障（Conditions显示：ContainerRuntimeUnhealthy）
# 常见原因3：节点磁盘满、内存耗尽

# 3. 登录节点，查看kubelet服务状态
ssh <节点IP>
systemctl status kubelet  # 若显示inactive，说明kubelet未运行

【解决方法】（以"kubelet服务未运行"为例）：

# 1. 登录节点，重启kubelet服务
ssh <节点IP>
systemctl restart kubelet

# 2. 查看kubelet日志，确认无报错
journalctl -u kubelet -f

# 3. 若kubelet启动失败，查看配置文件（/etc/kubernetes/kubelet.conf），修复配置错误

# 补充：若节点磁盘满，删除无用文件（如日志文件），释放磁盘空间
df -h  # 查看磁盘使用率
rm -rf /var/log/*.log  # 临时删除日志文件（生产环境需谨慎）

【验证】：kubectl get nodes，查看节点状态变为Ready，该节点上的Pod恢复正常运行，说明故障解决。

3.5 故障5：监控告警触发（CPU使用率过高），应用响应缓慢

【故障现象】：Grafana触发"节点CPU使用率过高"告警，应用接口响应缓慢，甚至出现超时。

【排查步骤】：

# 1. 查看节点CPU使用率，确认告警原因
kubectl top node <告警节点名称>  # 查看节点CPU使用率（如超过80%）

# 2. 查看该节点上的Pod CPU使用情况，定位占用CPU过高的Pod
kubectl top pod -n all --field-selector spec.nodeName=<节点名称>

# 3. 查看占用CPU过高的Pod日志，排查应用是否存在异常（如死循环、请求量突增）
kubectl logs <高CPU Pod名称> -n <命名空间> -f

# 4. 查看应用请求量，确认是否存在请求突增（结合EFK/ELK日志）
# 访问Kibana，查询该应用的请求日志，查看请求量变化

【解决方法】：

# 方法1：扩容应用Pod，分担CPU压力（生产环境常用）
kubectl scale deployment <deployment名称> -n <命名空间> --replicas=3  # 增加副本数

# 方法2：调整Pod资源限制，增加CPU配额（临时解决）
kubectl edit deployment <deployment名称> -n <命名空间>
# 修改resources.limits.cpu为更大的值（如2核）

# 方法3：优化应用代码，解决CPU占用过高的问题（根本解决）
# 若为请求量突增，可配置HPA（自动扩缩容），避免手动扩容

【验证】：kubectl top node <节点名称>，查看CPU使用率降至正常范围；访问应用接口，响应恢复正常，说明故障解决。

3.6 故障6：etcd故障，集群无法创建资源

【故障现象】：集群无法创建Pod、Service等资源，kubectl命令执行缓慢，甚至报错"connection refused"。

【排查步骤】：

# 1. 查看etcd组件状态（默认在kube-system命名空间）
kubectl get pods -n kube-system -l component=etcd  # 查看etcd Pod状态

# 2. 查看etcd日志，排查故障原因
kubectl logs <etcd-pod名称> -n kube-system
# 常见原因1：etcd数据损坏（日志显示：corrupt database）
# 常见原因2：etcd集群节点故障（单节点etcd宕机）
# 常见原因3：etcd磁盘满、内存不足

# 3. 查看etcd健康状态
kubectl exec -it <etcd-pod名称> -n kube-system -- etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key health

【解决方法】（以"etcd单节点故障"为例）：

# 1. 重启etcd Pod，尝试恢复
kubectl delete pod <etcd-pod名称> -n kube-system  # etcd会自动重建

# 2. 若etcd数据损坏，需恢复数据（生产环境需提前备份etcd数据）
# 恢复命令（需使用备份文件）：
kubectl exec -it <etcd-pod名称> -n kube-system -- etcdctl restore <备份文件路径> --data-dir=/var/lib/etcd

# 3. 若etcd磁盘满，删除无用数据，释放磁盘空间
ssh <etcd节点IP>
df -h  # 查看磁盘使用率
rm -rf /var/lib/etcd/old-data  # 删除旧数据（需谨慎）

【验证】：kubectl get pods -n kube-system -l component=etcd，查看etcd Pod状态为Running；尝试创建Pod，能正常创建，说明故障解决。

四、进阶：K8s故障排查工具推荐（提升效率）

除了常用的kubectl命令，生产环境中还可以使用一些第三方工具，提升故障排查效率，小白可根据需求选择使用，以下推荐3个最常用、最易上手的工具。

4.1 kubectl-debug（快速调试Pod）

kubectl-debug是kubectl的插件，可快速进入Pod的调试环境，无需手动配置，适合排查Pod内部环境、网络、配置等问题。

# 1. 安装kubectl-debug
kubectl krew install debug

# 2. 快速调试Pod（自动创建调试容器，与目标Pod共享网络和挂载）
kubectl debug <Pod名称> -n <命名空间> --image=busybox:1.35 --share-processes --copy-to=debug-pod

# 3. 进入调试容器，执行排查命令
kubectl exec -it debug-pod -n <命名空间> -- /bin/sh
# 可执行ping、curl、netstat等命令，排查网络、接口问题

4.2 kube-ps1（集群状态提示）

kube-ps1是一个Shell插件，可在终端提示符中显示当前所在的K8s集群和命名空间，避免因切换集群/命名空间导致的操作错误，提升排查效率。

# 1. 安装kube-ps1（适用于bash/zsh）
git clone https://github.com/jonmosco/kube-ps1.git
source kube-ps1/kube-ps1.sh

# 2. 配置终端提示符（在~/.bashrc中添加）
PS1='[\u@\h \W $(kube_ps1)]\$ '

# 3. 生效配置
source ~/.bashrc

# 效果：终端提示符会显示当前集群和命名空间，如[root@node1 ~ (kube:default)]$

4.3 k9s（终端可视化排查工具）

k9s是一个终端可视化的K8s管理工具，可通过交互界面查看Pod、Service、节点、日志等信息，操作简单、直观，适合小白快速排查故障，无需记忆复杂命令。

# 1. 安装k9s（Linux系统）
curl -sS https://webinstall.dev/k9s | bash

# 2. 启动k9s
k9s

# 3. 常用操作（交互界面）
# - 按Enter：查看选中资源的详细信息
# - 按l：查看选中Pod的日志
# - 按e：编辑选中资源的配置
# - 按d：删除选中资源
# - 按q：退出k9s

补充说明：以上工具均为开源工具，安装简单、使用便捷，可根据自身习惯选择，核心目的是提升故障排查效率，减少命令记忆成本。

五、生产环境故障排查最佳实践（面试必问）

生产环境的故障排查，不仅要"快速解决问题"，还要"避免同类故障再次发生"，本节总结生产环境故障排查的最佳实践，帮助小白规范排查流程，提升排查能力，同时应对面试提问。

5.1 排查流程规范化

• 遵循"四步排查法"：明确故障现象→定位故障范围→查看日志与指标→验证与解决，避免盲目排查；

• 记录排查过程：详细记录故障现象、排查步骤、故障原因、解决方法，形成排查文档，便于后续复盘和参考；

• 优先排查高频故障：生产环境中，Pod启动失败、Service无法访问、节点NotReady是高频故障，可提前整理排查手册，快速套用。

5.2 日志与监控最大化利用

• 日志集中化：必须部署EFK/ELK，实现日志集中收集、查询，避免逐个节点、逐个Pod查看日志，提升排查效率；

• 监控全覆盖：Prometheus+Grafana需监控集群、节点、应用、组件的关键指标，设置合理的告警规则，确保故障能及时被发现；

• 日志与监控结合：通过监控告警发现异常，通过日志定位故障根源，形成"监控→告警→排查→解决"的完整闭环。

5.3 预防大于排查

• 提前做好备份：定期备份etcd数据、应用配置、日志数据，避免故障导致数据丢失，便于快速恢复；

• 规范配置：严格规范Pod、Service、Deployment等资源的配置，避免因配置错误导致故障（如标签不匹配、资源限制不足）；

• 定期巡检：定期查看集群状态、节点资源、监控指标，提前发现潜在问题（如节点磁盘即将满、Pod资源使用率过高），避免故障发生；

• 定期演练：定期模拟常见故障，练习排查流程，提升团队排查能力，确保故障发生时能快速响应。

5.4 故障复盘常态化

• 故障解决后，组织复盘会议，分析故障原因、排查过程中的问题、解决方法的合理性；

• 总结经验教训，优化配置和排查流程，避免同类故障再次发生；

• 更新排查手册，补充新的故障场景和解决方法，形成知识库，提升团队整体运维能力。

六、总结及下一篇预告

本文详细讲解了K8s故障排查的核心方法，从故障排查思路、常用命令，到6类常见故障的实战排查，再到排查工具推荐和生产环境最佳实践，全程实操、命令可复制，帮你彻底解决了"遇到故障无从下手"的痛点，掌握了K8s故障排查的核心技能，结合前面学到的日志收集、监控告警知识，形成了"监控→告警→排查→解决"的完整运维闭环。

重点记住3点：

1. 故障排查的核心思路是"从现象到本质、从上层到下层、从局部到整体"，遵循"四步走"，高效定位故障根源；

2. 常用的排查命令要熟记，重点掌握Pod、Service、节点、核心组件的排查命令，是快速排查故障的基础；

3. 生产环境中，要结合EFK/ELK和Prometheus+Grafana，最大化利用日志和监控，同时做好预防和复盘，避免同类故障再次发生。

截至本文，我们已完成K8s系列14篇内容的学习，从K8s基础入门，到核心组件、服务暴露、应用调度、健康检查、资源限制、日志收集、监控告警，再到本节课的故障排查，已覆盖K8s运维的全流程核心模块，最后一篇将聚焦集群优化，带你实现从"能用K8s"到"用好K8s"的最终跨越。

下一篇文章，我们将学习K8s系列的最后一篇------《K8s 集群优化实战：性能、稳定性与安全性优化》，带你深入掌握K8s集群的性能优化（CPU、内存、网络）、稳定性优化（高可用、容灾）、安全性优化（权限控制、镜像安全），帮助你搭建一个高效、稳定、安全的K8s集群，适配生产环境的高要求，为你的K8s学习之旅画上圆满句号，敬请期待！

最后，如果你觉得这篇文章对你有帮助，欢迎点赞、收藏、关注，K8s系列实战文章（共15篇）即将完结，全程从入门到精通，带你轻松搞定K8s运维！