首页 > 解决方案 > 寻找一种方法来确定为什么离开我的集群的数据包会保留它的 pod IP

问题描述

我的集群上有一个网络问题,起初我认为这是一个路由问题,但发现可能来自集群的传出数据包在离开节点时没有被节点 ip 包裹。

背景是我有两个集群。我使用本指南手动设置了第一个(几个月前),效果很好。然后,我在创建/调试 anisble 脚本时多次构建了第二个脚本,以自动化我创建第一个集群的方式。

在 cluster2 上,我遇到了网络问题...我可以访问其他节点上的 pod,但无法访问常规网络上的任何内容。当从busybox pod ping 和172.16.0.x 内部pod ip 作为源ip 在该接口上可见时,我在cluster2 中的node0 上进行了tcpdump 的物理接口-并且我在节点外的网络不知道该怎么做用它。但是在 cluster1 上,同样的测试显示了节点 ip 代替了 pod ip——这就是我认为它应该工作的方式。

我的问题是如何解决这个问题?任何想法都会很棒,因为我已经做了几天了。即使这看起来很明显,因为我再也无法透过树木看到森林......即。在我知道如何检查的任何地方,两个集群看起来都一样:)

警告“我的集群是相同的”:Cluster1 正在运行 kubectl 1.16 cluster2 正在运行 1.18

----在@Matt 对我放弃一些 kube-proxy 知识后进行编辑----

不知道 kube-proxy 规则只能通过 iptables 命令读取!惊人的!

我认为我的问题是损坏集群中的那些 10.net 地址。我什至不知道这些来自哪里,因为它们不在我的任何 ansible 配置脚本或 kube init 文件中……我在我的配置中使用了所有 172。

我确实从源代码中直接提取了一些配置(法兰绒和 CSI/CPI 的东西),我将把它们拉下来并检查它们是否有 10 个...希望它在法兰绒默认值或其他东西中,我可以改变它.yml 文件!

集群1工作:

[root@k8s-master ~]# iptables -t nat -vnL| grep POSTROUTING -A5
Chain POSTROUTING (policy ACCEPT 22 packets, 1346 bytes)
 pkts bytes target     prot opt in     out     source               destination
6743K  550M KUBE-POSTROUTING  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* kubernetes postrouting rules */
    0     0 MASQUERADE  all  --  *      !docker0  172.17.0.0/16        0.0.0.0/0
3383K  212M RETURN     all  --  *      *       172.16.0.0/16        172.16.0.0/16
 117K 9002K MASQUERADE  all  --  *      *       172.16.0.0/16       !224.0.0.0/4
    0     0 RETURN     all  --  *      *      !172.16.0.0/16        172.16.0.0/24
    0     0 MASQUERADE  all  --  *      *      !172.16.0.0/16        172.16.0.0/16

cluster2 - 不工作:

[root@testvm-master ~]# iptables -t nat -vnL | grep POSTROUTING -A5
Chain POSTROUTING (policy ACCEPT 1152 packets, 58573 bytes)
 pkts bytes target     prot opt in     out     source               destination
 719K   37M KUBE-POSTROUTING  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* kubernetes postrouting rules */
    0     0 RETURN     all  --  *      *       10.244.0.0/16        10.244.0.0/16
    0     0 MASQUERADE  all  --  *      *       10.244.0.0/16       !224.0.0.0/4
 131K 7849K RETURN     all  --  *      *      !10.244.0.0/16        172.16.0.0/24
    0     0 MASQUERADE  all  --  *      *      !10.244.0.0/16        10.244.0.0/16

标签: networkingkubernetes

解决方案


繁荣!@Matt 为胜利提供建议。

使用 iptables 来验证 flannel 应用的 nat 规则就可以了。我能够在我使用的指南中引用的法兰绒配置中找到 10.244 子网。

我有两个选择。1. 在部署 CNI 之前下载并更改 flannel yaml 或 2. 使我的 kubeadmin 初始化子网声明与 flannel 的声明相匹配。

我选择了选项 2,因为我不想每次都更改法兰绒配置……我只想下载他们的最新文件并使用它运行。这很好地解决了我的问题。


推荐阅读