

# **Kubernetes 网络一出事，先别重启：一条从 Pod 打到内核的排查路线图**

---

说句掏心窝子的话：

> **Kubernetes 里，十个疑难杂症，八个最后都能追溯到“网络”。**

服务超时、探针失败、Pod 起不来、节点 NotReady、偶发 502……
你去翻日志，啥也没有；
你问开发，人家说“我代码没改”；
你一看监控，CPU、内存都挺健康。

最后，锅往往落在一句很抽象的话上：

> “网络好像不太稳定。”

而 Kubernetes 的网络，恰恰是**最容易被“想当然”对待的东西**。

今天我想干一件事：
**给你一条真正能落地的、从 Pod 一路查到 Linux 内核的排查路径。**
不是技巧合集，而是一种**系统化思维方式**。

---

## 一、先说结论：K8s 网络不是“一个东西”

很多人一排查就犯的第一个错是：

> 把 Kubernetes 网络，当成一个整体问题。

但在我眼里，它至少分 **5 层**：

1. **Pod 内部网络**
2. **Pod ↔ Pod（同节点 / 跨节点）**
3. **Service / kube-proxy**
4. **Node 网络 & CNI**
5. **Linux 内核网络栈**

**你要是没分层，排查一定是乱的。**

---

## 二、第一层：Pod 内部，别急着甩锅给集群

网络不通？
**先别怪 CNI，先看 Pod 自己。**

### 你第一步该干啥？

```bash
kubectl exec -it pod-a -- sh
```

然后在 Pod 里做三件事：

```bash
ip addr
ip route
ping 127.0.0.1
```

你要确认的只有几件小事：

* Pod 有没有 IP？
* 默认路由是不是指向 eth0？
* 本地 loopback 通不通？

我见过真实事故：

> Pod 用的是 distroless 镜像，
> 容器里连 `ip` 命令都没有，
> 最后靠猜查了一晚上。

**结论很扎心：**

> **你连 Pod 自己是不是“醒着的”都没确认，就开始怀疑整个集群。**

---

## 三、第二层：Pod ↔ Pod，先区分“同节点”还是“跨节点”

这是一个**90% 的人忽略、但极其关键的分叉点**。

### 怎么快速判断？

```bash
kubectl get pod -o wide
```

看 `NODE` 列。

#### 情况 A：**同一个 Node 上 Pod 不通**

优先怀疑：

* CNI bridge / veth
* iptables / eBPF 规则异常
* Pod 网卡被删了

你可以在 Node 上看：

```bash
ip link | grep veth
```

如果 veth 对不上，那基本已经接近真相了。

#### 情况 B：**跨 Node 才不通**

那你要开始怀疑：

* Node 间路由
* Overlay 网络（VXLAN / Geneve）
* 防火墙 / 安全组

一个很实用的命令：

```bash
kubectl exec pod-a -- traceroute pod-b-ip
```

**看包卡在哪一跳，比你盲猜一小时都有用。**

---

## 四、第三层：Service 不通？别急着骂 kube-proxy

我见过太多人，一遇到 Service 问题就一句话：

> “kube-proxy 又抽风了。”

但事实是：
**Service 只是 iptables / IPVS 规则的“外壳”。**

### 你该确认三件事：

#### 1️⃣ Endpoints 对不对？

```bash
kubectl get endpoints svc-name
```

如果这里是空的，那网络再好也没用。

#### 2️⃣ kube-proxy 模式是啥？

```bash
kubectl -n kube-system get cm kube-proxy -o yaml
```

iptables 还是 IPVS？
**排查方式完全不一样。**

#### 3️⃣ Node 上规则是否存在？

iptables 模式：

```bash
iptables -t nat -L | grep svc-name
```

IPVS 模式：

```bash
ipvsadm -Ln
```

我踩过一个很典型的坑：

> kube-proxy 在
> Node 上 OOM 被杀了，
> 规则还在，但不再更新。

**结论：**

> Service 出问题，很多时候是“数据面还在，控制面已经死了”。

---

## 五、第四层：CNI 网络，问题集中营

说句大实话：

> **Kubernetes 网络 80% 的复杂度，都在 CNI。**

无论你用的是：

* Calico
* Flannel
* Cilium

你都必须搞清楚三件事：

1. **Pod IP 怎么来的**
2. **跨节点流量怎么走**
3. **策略在哪一层生效**

### 以 Calico 为例

你至少得会看：

```bash
calicoctl node status
calicoctl get ippool -o yaml
```

我遇到过一个很经典的事故：

> IPPool CIDR 改了，
> 老节点没同步，
> 新 Pod 分配的 IP 根本路由不到。

表面现象：

* Pod 偶发不通
* 重启“有时好，有时坏”

**这类问题，不系统排查，你根本抓不到。**

---

## 六、第五层：Linux 内核，真·终极形态

当你走到这一步，说明：

> **你已经比 80% 的 K8s 使用者走得更深了。**

几个你必须掌握的工具：

### conntrack 表爆了

```bash
conntrack -L | wc -l
```

再看看最大值：

```bash
sysctl net.netfilter.nf_conntrack_max
```

真实线上事故：

> 高并发短连接
> conntrack 满
> 新连接直接被 DROP
> 应用层只看到 timeout

---

### 丢包？别光看网卡

```bash
ethtool -S eth0
netstat -s
```

再配合：

```bash
tcpdump -i eth0
```

**抓包不是为了装逼，是为了终止争论。**

---

## 七、我自己的一个“血泪总结”

干了这么多年运维，我越来越坚定一个观点：

> **Kubernetes 网络排查，拼的不是命令多，而是路径清楚。**

如果你愿意记住一句话，那就是：

> **从 Pod 开始，一层一层往下，不要跳步。**

* 不要一上来重启节点
* 不要一上来升级 CNI
* 不要一上来甩锅云厂商

因为：

> **重启解决的问题，通常不是被你解决的，而是被你“掩盖”的。**

---

## 写在最后

Kubernetes 网络这玩意儿，说难是真难，
但一旦你脑子里有了**分层模型**，
很多“玄学问题”会突然变得特别理性。



服务超时、探针失败、Pod 起不来、节点 NotReady、偶发 502……你去翻日志，啥也没有；你问开发，人家说“我代码没改”；你一看监控，CPU、内存都挺健康。

Kubernetes 网络一出事，先别重启：一条从 Pod 打到内核的排查路线图

编程语言

Kubernetes网络问题排查指南：从Pod到内核的5层排查路径。先检查Pod内部网络，再区分同节点/跨节点问题，接着排查Service和kube-proxy，深入CNI网络配置，最终定位Linux内核问题。系统化分层排查方法，避免盲目重启和甩锅，解决80%K8s网络疑难杂症。

Kubernetes

防火墙

容器

路由

Linux

2026新春采购季

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Kubernetes 网络一出事，先别重启：一条从 Pod 打到内核的排查路线图-腾讯云开发者社区-腾讯云

Kubernetes 网络一出事，先别重启：一条从 Pod 打到内核的排查路线图

Kubernetes 网络一出事，先别重启：一条从 Pod 打到内核的排查路线图

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐