问题现象与背景

在生产环境中，基于Calico实现容器网络策略时，经常出现Pod之间或Pod与外部服务访问不通的情况。此类问题往往由网络策略（NetworkPolicy）配置错误、Calico组件异常或底层iptables规则冲突引起。本文提供系统性排查流程，帮助运维人员快速定位并修复。

常见原因分析

• 策略规则过于严格：未正确配置允许规则，导致合法流量被拒绝。
• 标签选择器不匹配：Pod或Namespace的标签未与策略的selector对应。
• 策略顺序冲突：多条策略并存时，优先级或生效顺序导致意外阻挡。
• Calico组件故障：calico-node或calico-kube-controllers未正常运行，策略未同步到iptables。
• iptables规则被覆盖：其他CNI插件或手动修改的iptables规则与Calico冲突。

系统化排查步骤

第一步：确认基本连通性

使用kubectl exec从源Pod向目标Pod发起ICMP或TCP测试，排除应用层问题。若直接ping或curl超时，则进入网络层排查。

第二步：检查网络策略定义

执行kubectl get networkpolicy -n 查看当前生效的策略。注意策略的podSelector和namespaceSelector是否正确指定。使用kubectl describe networkpolicy 查看策略细节，重点关注Ingress和Egress规则中的from/to字段。

第三步：查看Calico组件状态

运行kubectl get pods -n kube-system -l k8s-app=calico-node确认所有节点上的calico-node处于Running状态。检查日志：kubectl logs -n kube-system -c calico-node，关注ERROR或WARNING级别信息，特别是与policy或iptables相关的错误。

第四步：分析iptables规则

登录出现问题的节点，使用iptables -t filter -L FORWARD -v --line-numbers查看Calico管理的链（通常包含cali-FORWARD、cali-INPUT等）。检查cali-policy链中是否有丢弃（DROP）命中计数异常增多的规则。使用iptables-save | grep -i cali导出全量规则，对比策略预期。

第五步：使用Calico诊断工具

安装calicoctl（或使用kubectl calico插件），执行calicoctl get networkpolicy --all-namespaces查看策略是否在etcd中一致。运行calicoctl node status确认节点间BGP或VXLAN隧道状态正常。若使用IPIP模式，检查tunl0接口是否存在且up。

第六步：临时放通验证

为了区分策略导致还是组件异常，可以创建一个允许全通（0.0.0.0/0）的策略进行测试：
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
name: allow-all
spec:
selector: all()
ingress:
- action: Allow
egress:
- action: Allow
应用后重新测试连通性。若恢复，则说明原策略存在限制性规则。

常见场景与解决方案

• 场景1：只配置了Deny规则，未显式Allow。Calico采用白名单机制，必须加上action: Allow的规则。
• 场景2：跨Namespace访问时，Namespace选择器缺失。例如目标Pod在production，但策略只设置了podSelector，需添加namespaceSelector: matchLabels: { name: production }。
• 场景3：Egress策略阻挡了DNS解析。需确保策略中允许UDP 53端口访问CoreDNS的Pod IP。
• 场景4：Calico升级后规则未更新。重启calico-node Pod或执行calicoctl apply -f policy.yaml强制同步。

验证与优化

修复后，建议使用calicoctl policy analyse（需安装calicoctl）进行静态分析，检查策略冲突。同时启用Calico的日志级别为Debug（通过修改calico-node DaemonSet的环境变量LOG_LEVEL为debug），观察日志确认流量匹配正确。定期使用calicoctl get workloadendpoint确保所有Pod的WorkloadEndpoint存在且状态活跃。