Kubernetes节点有无法到达的路由
我有一个Kubernetes集群。这些节点位于具有10.0.0.0/8IPs的内部网中，pod网络范围为192.168.0.0/16。
问题是，一些工作节点在其他节点上有无法到达的pod网络路由，例如：
0.0.0.0 10.a.b.65 0.0.0.0 UG 0 0 0 eth0
10.a.b.64 0.0.0.0 255.255.255.192 U 0 0 0 eth0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.20.0 - 255.255.255.192 ! 0 - 0 -
192.168.21.128 - 255.255.255.192 ! 0 - 0 -
192.168.22.64 0.0.0.0 255.255.255.192 U 0 0 0 *
192.168.22.66 0.0.0.0 255.255.255.255 UH 0 0 0 cali3859982c59e
192.168.24.128 - 255.255.255.192 ! 0 - 0 -
192.168.39.192 - 255.255.255.192 ! 0 - 0 -
192.168.49.192 - 255.255.255.192 ! 0 - 0 -
...
192.168.208.128 - 255.255.255.192 ! 0 - 0 -
192.168.228.128 10.14.170.104 255.255.255.192 UG 0 0 0 tunl0
192.168.108.64/26 unreachable [Mesh_10_15_39_59 08:04:59 from 10.a.a.a] * (100/-) [i]
192.168.112.128/26 unreachable [Mesh_10_204_89_220 08:04:58 from 10.b.b.b] * (100/-) [i]
192.168.95.192/26 unreachable [Mesh_10_204_30_35 08:04:59 from 10.c.c.c] * (100/-) [i]
192.168.39.192/26 unreachable [Mesh_10_204_89_152 08:04:59 from 10.d.d.d] * (100/-) [i]
...
我尝试重新启动一个中断的节点，将其从集群中删除，运行Kubeadm reset，然后重新加入它。但一切都保持不变。
可能的原因是什么？我应该如何解决这个问题？提前多谢。
共有1个答案
coredns等群集服务的默认ip是10.96.0.1和10.0.0.0/8
您应该为群集上的节点更改节点ip，并重新加入它们。
或
如果您使用calico，则放弃网络规则并路由到calico项目。
-
我有kubernetes集群，有3个主人和7个工人。我用印花布做CNI。当我部署Calico时，calico-kube-controllers-xxx失败，因为它不能达到10.96.0.1:443。 这是kube-system名称空间中的情况： 集群pod cidr为192.168.0.0/16。
-
如果一个节点没有响应（可能是由于过载或网络问题），那么Kubernetes是否可以在原来的pod仍在运行的情况下在另一个节点上重新安排一个pod？ 似乎其中一些行为已经明确指定，但我不知道如何验证它，除非在云提供商上设置多个节点并尝试它。
-
我有一棵看起来像上面的树，由一个链接结构表示： 我的目标是找到从根节点到叶节点的所有路径。 我的树遍历算法如下所示： 当我运行它时，我确信树正在按图所示构建。我已经测试过了。然而，我无法找出我的树遍历分割错误的原因。 我得到的输出是： 我已经在高度较小的树上测试了它，它是有效的。但是出于某种原因，它不适用于高度大于2的树。我认为这是树出了问题，我检查并打印了每个父级、左子级和右子级，它们打印出来如
-
我试图建立一个示例Hadoop集群在OpenShift/Kuberentes/Docker（OpenShift 3.5），我遇到了以下问题： 一次只能在Namenode上注册一个Datanode，因为Namenode可以看到同一IP（192.168.20.1）下的所有Datanode。这显然是由于集群中的网络路由 实际示例配置： 名称节点 数据阳极 Namenode日志： 配置（hdfs site
-
我有一个场景 我想从一个特定的节点（比如ID:7）开始运行BFS 如果有无法从该节点访问的节点，我想重新启动BFS（使用任何剩余节点），直到访问图的所有顶点 到目前为止，我得到的是从节点0开始并用另一个未访问的顶点重新启动的代码（部分）： 如何有效地更改此代码以满足我的要求？
-
工作节点1上的Curl对群集IP来说是最合适的（这是运行pod的节点） Curl在其他工作节点上也失败：