<think>好的，用户现在想了解KubernetesPod出现[Errno104]
Connection resetby peer问题的
原因和解决方法。之前他们提到了Docker中类似问题的解决方法是重建docker0网桥，但现在转向Kubernetes环境，我需要将问题与Kubernetes的相关组件联系起来。首先，我需要回忆一下Kubernetes网络模型和可能导致
连接重置的
原因。
常见的因素包括网络策略（NetworkPolicy）、服务配置错误、CNI插件问题、防火墙或iptables规则，以及应用层的问题。用户之前的问题是关于NetworkPolicy的调试，所以可能他们已经了解了一些NetworkPolicy的知识，但需要更全面的分析。
接下来，我需要参考用户提供的引用内容。引用1提到Docker中通过重建docker0网桥解决问题，但在Kubernetes中，网络问题可能涉及不同的组件，比如CNI插件（如Calico、Flannel）、服务（Service）和端点（Endpoints）等。需要将类似的问题迁移到Kubernetes环境中，比如网桥问题可能对应到CNI配置或节点网络设置。用户可能遇到的场景包括：Pod之间的通信被NetworkPolicy阻止，服务选择器配置错误导致流量无法正确路由，或者CNI插件的问题导致网络接口异常。此外，应用本身的问题，如突然关闭
连接，也可能导致RST包。
在分析
原因时，需要分层次排查，从网络策略、服务配置、CNI插件状态、节点网络到应用日志。需要给出具体的检查命令，比如检查NetworkPolicy是否存在，服务的Endpoints是否正确，以及使用tcpdump抓包分析。解决方案方面，可能需要调整NetworkPolicy规则，修复服务的选择器标签，重启或重新配置CNI插件，检查节点防火墙设置，或者修复应用程序的
连接处理逻辑。此外，用户之前的Docker经验中重建网桥的方法，可能在Kubernetes中对应到重启CNI组件或节点网络服务。
还需要考虑用户的技术水平，提供逐步排查的步骤，避免过于复杂的操作。例如，先检查NetworkPolicy，再检查服务配置，然后查看CNI插件日志，最后检查应用日志。每一步都给出具体的kubectl命令或诊断方法，帮助用户自主排查。
另外，用户可能对CNI插件的工作原理不太熟悉，需要简要解释Calico或Flannel如何处理网络策略，以及它们如何与iptables交互，导致
连接被重置。同时，引用之前提到的NetworkPolicy排查步骤，比如使用np-viewer工具，或者检查iptables规则，可以增强回答的连贯性。最后，生成的相关问题需要围绕Kubernetes网络问题展开，比如如何监控网络策略的影响、不同CNI插件的差异、使用Wireshark分析RST包等，这些都能帮助用户深入理解问题。</think>### Kubernetes Pod [Errno 104]
Connection reset by peer 原因分析与解决方案
---
#### 一、核心
原因分析
1. **网络策略拦截**
Kubernetes NetworkPolicy 若未正确配置，可能导致流量被拦截。当目标 Pod 的入口规则（`ingress`）未包含源 Pod 的标签或 IP 范围时，会触发 TCP
连接重置[^1]。
$$ \text{策略生效条件
:} \quad \text{源Pod标签} \in \text{策略允许的源范围} $$
2. **服务配置异常**
Service 的 `selector` 与 Pod 标签不匹配时，流量无法正确路由到后端 Pod，导致
连接中断：
```yaml
# 错误示例：Service selector 与 Pod 标签不匹配
spec
:
selector
:
app
: nginx-v1 # 实际 Pod 标签为 app
: nginx-v2
```
3. **CNI 插件问题**
Calico/Flannel 等 CNI 插件异常时，可能导致网络接口失效或路由表错误，触发 `RST` 包[^2]。
4. **应用层主动关闭
连接**
目标应用在处理请求时崩溃或主动发送 `RST` 包（如 MySQL
连接池耗尽）。
---
#### 二、分层排查步骤
##### 1. 网络策略检查
```bash
# 检查目标 Pod 所在命名空间的 NetworkPolicy
kubectl get networkpolicy -n <namespace>
# 查看策略规则是否允许当前流量
kubectl describe networkpolicy <policy-name> -n <namespace>
```
若策略存在 `deny-all` 或未开放特定端口，需调整 `ingress/egress` 规则[^1]。
##### 2. 服务与端点验证
```bash
# 检查 Service 的 Endpoints 是否包含目标 Pod
kubectl get endpoints <service-name> -n <namespace>
# 验证 Service selector 与 Pod 标签匹配
kubectl get pods -l app=nginx -n <namespace>
```
##### 3. CNI 插件诊断
```bash
# 查看 Calico 组件状态
kubectl get pods -n kube-system -l k8s-app=calico-node
# 检查节点路由表
ip route show | grep <pod-cidr>
```
##### 4. 网络抓包分析
```bash
# 在目标 Pod 抓取 SYN/RST 包
kubectl exec -it <target-pod> -- tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn|tcp-rst) != 0'
# 在源 Pod 测试
连接
kubectl exec -it <source-pod> -- curl -v http
://<target-service>
:<port>
```
若抓包显示 `RST` 但无 `SYN-ACK`，说明
连接被策略或防火墙拦截[^1]。
---
#### 三、典型解决方案
##### 场景1：NetworkPolicy 配置缺失
添加允许特定流量的入口规则：
```yaml
apiVersion
: networking.k8s.io/v1
kind
: NetworkPolicy
metadata
:
name
: allow-nginx
spec
:
podSelector
:
matchLabels
:
app
: nginx
ingress
:
- from
:
- podSelector
:
matchLabels
:
app
: client
ports
:
- protocol
: TCP
port
: 80
```
##### 场景2：Service 端点异常
修复 Service 的 `selector` 标签：
```yaml
# 修正后的 Service 配置
spec
:
selector
:
app
: nginx-v2 # 与 Pod 实际标签一致
```
##### 场景3：CNI 插件故障
重启 Calico 组件：
```bash
kubectl delete pod -n kube-system -l k8s-app=calico-node
# 重建 Docker 网桥（参考用户提供的 Docker 方案）
systemctl restart docker
```
##### 场景4：应用层问题
检查应用日志并优化
连接池：
```bash
kubectl logs <pod-name> -n <namespace> --tail=100
```
---
#### 四、高级诊断工具
1. **网络策略模拟**
使用 `np-viewer` 生成策略拓扑图：
```bash
np-viewer --namespace <ns> --output format=dot | dot -Tpng > policy.png
```
2. **iptables 规则检查**
进入 Pod 网络命名空间查看规则：
```bash
nsenter -n -t $(docker inspect <container-id> --format '{{.State.Pid}}')
iptables -L -n -v | grep DROP
```
3. **Prometheus 监控**
通过 `kube-proxy` 指标监控丢弃数据包：
```promql
sum(rate(kube_proxy_network_programming_duration_seconds_count{operation="sync_proxy_rules"}[5m]))
by (namespace)
```
---
扫一扫
411
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
