如果我用

主机网络：真

然后附加到它

kubectl exec -it my-pod-test bash

并产生一些愚蠢的东西

nc -l <​​主机IP> 5678

netstat 给我看

tcp 0 0 0.0.0.0:34592 0.0.0.0:* 听 94/nc

为什么分配随机端口（在这种情况下）34592？我希望看到端口 5678 正在使用中。

这是 Weave 的“功能”吗，我应该去找另一个网络插件吗？

更多背景信息：我正在尝试关注 https://www.compoundtheory.com/scaling-dedicated-game-servers-with-kubernetes-part-1-containerising-and-deploying/

我的集群当前已关闭，我无法在其上启动新的 pod。我尝试使用 kops 从 1.9.1 升级到 1.9.3 并添加 pvc resize admissionControl。随着滚动升级的发生，我注意到新节点没有正常上线（即使滚动升级认为它们是）。我中止了滚动升级。我发现豆荚抱怨：

kube api 服务器显示：

请帮忙

首先我想说我是kubernetes-topic的初学者，当我给服务一个固定的IP时，我遇到的问题是我无法（通过服务）到达一个pod，所以我想总结一下我认为我已经理解的事情，也许这里有人可以纠正我或了解我解决问题的方法。

我使用 ansible-script kubespray 在裸机（2 个 CentOS 7 的节点）上部署我的集群，并配置脚本和生成的集群如下：

• 代理模式：ipvs
• 服务网络：10.0.0.0/24
• 吊舱网络：10.0.1.0/24
• 网络插件：编织网
• dns_mode: dnsmasq_kubedns

部署成功后，我可以将 pod、服务、机密等部署到集群，所以对我来说它工作正常，但是当我现在定义一个外部 IP 时，例如：

我可以通过他的内部 IP、端点的 IP 和主服务器的 IP 而不是通过我为此服务定义的 IP 到达 pod，当我尝试这个时，我通过 curl 错误得到：“没有到主机的路由“对我来说奇怪的是，当我将服务的 IP 设置为与 kubernetes master 相同的 IP 时，即

我可以到达吊舱。

现在，在我阅读了大量文档和操作指南后，当我配置自己的负载均衡器来管理外部 IP 时，问题是可以解决的，因为如果我没有定义固定 IP，服务会等待外部 IP 的状态为“待定” .

但不幸的是，在阅读完所有文档之后，我不确定架构是否真的以这种方式工作，我的意思是 pod <-> service <-> load-balancer (<-> DHCP)

所以我可以通过服务到达吊舱。

当我开始时，我想关闭这篇文章，我不确定这是解决我的问题的正确方向。这就是为什么如果有人可以确认或纠正我，我将非常感激:-) 最好的问候丹

手动添加一些 iptables 规则并重新启动机器后，所有规则都消失了（无论规则类型如何）。

前任。

重启后：

如果我没记错的话，kube-proxy在每个节点上运行都是动态修改iptables. 如果这是正确的，我如何添加永久的规则但仍然使 kubernetes/kube-proxy 能够做到这一点，而不是删除Kubernetes 和 Weave 插件网络动态生成的所有INPUT,FORWARD和规则？OUTPUT

我越来越重复

NetworkPlugin cni 无法设置 pod \"POD_NAME\" 网络：无法分配 IP 地址：发布http://127.0.0.1:6784/ip/LONG_HEX_ID：拨打 tcp 127.0.0.1:6784：连接：连接被拒绝”

kubelet 日志中的错误。

互联网上有很多关于此错误消息的问题，但我还没有找到任何人真正说出应该在该端口上接受连接的问题。这令人沮丧，因为如果我有基本的信息，也许我可以弄清楚要开始/重新启动什么来让事情正常进行。

将 Kubernetes 1.10 与 weave-net 一起使用。

背景

我们维护一个运行我们生产应用程序的 Ubuntu 主机“集群”。主机运行各种各样的 docker 容器，例如

• 用于容器监控和 prometheus 服务发现的 consul
• 具有多个logstash和kibana的elasticsearch集群
• 普罗米修斯
• 格拉法纳
• 内部开发的应用程序（下图中的服务 A 到 K）

每个主机也运行

• 文件节拍
• nginx
• 保活
• docker覆盖网络的领事

设置如下：

图片信息

• 主机 consul 在 2xxx 而不是标准的 8xxx 中公开端口
• 并非所有 docker 容器都暴露给外界，例如elasticsearch-slave1没有暴露的端口，但内部使用的端口显示为:9200
• docker consul 使用覆盖网络进行所有通信，并且只有consul-masterHost1 上的端口8500对外暴露。

配置

其中一些信息可能与问题完全无关。

主机：Ubuntu 16.04.3 LTS

主机服务 | Application | Version | | ----------- | ---------- | | docker | 18.03.1-ce | | consul | v1.0.2 | Docker 服务 | Application | Version | | ------------- | ------- | | consul | v1.0.2 | | elasticsearch | 5.6.4 | | logstash | 5.6.4 | | kibana | 5.6.4 | | prometheus | 2.0.0 |

码头工人服务

每台主机上的 Docker 配置如下： [Service] ExecStart=/usr/bin/dockerd -H fd:// -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock --cluster-advertise ${THIS_MACHINES_IP}:2375 --cluster-store consul://${THIS_MACHINES_IP}:2500 --label com.domain.hostname=host05.domain.com

问题

当我们第一次部署这个配置时，它运行得非常好。但随着时间的推移，docker 覆盖网络变得越来越不可靠。HostX 上的容器将无法使用覆盖网络与 HostY 上的其他容器通信。

例如，prometheus在 Host5service A上从 Host1 上抓取信息，但会频繁报告“ no route to host”或“ context deadline exceeded”。如果我docker exec进入prometheus容器并尝试 ping 或 curl service A，我只会收到超时。但是，如果我docker exec进入service A并尝试 ping 和 curlprometheus数据包通过，这似乎“唤醒”了网络。现在prometheus可以再次看到服务。

多个服务之间会出现同样的问题 - 这经常导致logstash无法发布elasticsearch或elasticsearch-master无法联系slaves破坏集群的服务。

因为这个设置在我们的生产环境中被积极使用，所以我们无法承受这样的网络停机时间。我已经实现了一组计划的作业，这些作业在各种服务之间进行 curl/ping 以保持网络活跃。这显然不是一个好的长期解决方案！

更糟糕的是，有时网络变得如此糟糕，以至于 curl/ping 作业无济于事，并且重新启动主机或 docker 也没有任何效果。我找到的唯一解决方案是

• 创建一个新temporary overlay网络
• 从 断开每个容器primary overlay并将它们连接到temporary overlay
• 删除primary overlay
• 创建一个新的primary overlay
• 从 断开每个容器temporary overlay并将它们连接到primary overlay
• 删除temporary overlay

这种方法是迄今为止我找到的完全恢复网络的最佳解决方案。然后它将运行良好一段时间，然后再次跌倒。

问题

对我来说最紧迫的问题是如何调试这个问题并找到根本原因？

有一些人遇到过这个问题，但它通常是在小型设置中，并且与上面的规模不同。目前感觉就像我在运行薛定谔的网络......

其次 -有没有更好的方法来实现覆盖网络？

我已经开始尝试，weave但Open vSwitch都不是当前网络的一个很好的替代品。

Weave需要重新部署所有容器（这是可能的），但它为每个容器添加了一个辅助网络接口，并且该ethwe接口不是导致问题consul并prometheus绑定到特定接口/地址的主要接口。

Open vSwitch似乎是一个替代品，但我无法让它与 LTS 版本 (2.5.x) 一起工作，不得不从源代码构建 2.10.x。这似乎最初有效，但elasticsearch不是集群，consul似乎真的很难通过网络进行通信。prometheus由于某种原因也无法查询consul。我假设交换机丢弃了一些数据包，这可能只是配置问题。

编辑 - 28/09/2018

自从发布这个问题以来，我一直在测试使用 Docker Swarm 来管理覆盖网络。

到目前为止，它运行良好，网络并没有像使用 consul 集群存储时那样随机停止工作。但是，存在一些关键差异和一些常见故障。例如：

• docker network inspect <my overlay network>在主机上执行只会显示在该主机上运行的容器。当使用 Consul 作为集群存储时，您可以从任何主机查看整个网络。
• 仍然有可能使网络进入容器无法看到彼此的不良状态。这可以通过相对快速地停止、删除和重新创建容器（与以前的名称相同）来实现。在这种情况下，现有容器继续使用旧的DNS 条目并且无法连接。

这是我的工作流程：

1. 搭建一个由 3 台主机组成的 Docker swarm 集群：

2. 设置 Weave 网络

我按照https://github.com/weaveworks-guides/old-guides/blob/master/docker-legacy/part-2.md的说明进行操作

3、部署6个容器，组成树状拓扑

4. 测试 #1：子网在运行路由之前运行良好

Node1 有 4 个网络接口，如下所示：

它通过 ethwe0 成功 ping 到 10.10.0.2/28（由 node0 拥有）-> 太好了！此外，node4 (10.10.0.51/28) 无法从 node0 访问 -> 这正是我所期望的，这意味着这些子网络是相互隔离的。这是 node1 中的路由表：

5.测试#2：运行Olsrd后，子网不再相互隔离

为了启用多跳连接（例如，node1->node0->node2->node4），我在每个容器上运行 Olsrd。这是 node1 中的 Olsrd.conf：

然后，node1 能够 ping 到 node4。但是，问题是 node1 可以直接 ping 到 node4 而无需通过 node0 和 node2。这是 node1 中的路由表：

这是我在 node1 中运行 traceroute 10.10.0.51 时的输出。来自 Node1 (10.10.0.3/28) 的数据包甚至可以直接到达 node2 (10.10.0.51/28)，尽管它们不在同一个子网中。

另外，当我运行 tcpdump 记录 node1 的 ethwe0 上接收到的所有流量时，我发现它接收到了其他子网的所有广播数据包。这是 tcpdump 的日志：

总之，我的问题是在我运行路由软件（在本例中为 Olsrd）后，子网没有相互隔离。有没有人有任何想法来处理这个问题？提前致谢

每次我初始化一个新集群时，从 3 天到一个月左右的任何时间都可以完美运行。然后 kube-dns 就会停止运行。我可以进入 kubedns 容器，它似乎运行良好，虽然我真的不知道要寻找什么。我可以 ping 一个主机名，它可以解析并且可以访问，所以 kubedns 容器本身仍然有 dns 服务。它只是不为集群中的其他容器提供它。并且失败发生在自启动之前一直在运行的两个容器中（因此它们曾经能够解析+ping主机名，但现在无法解析它，但仍然可以使用IP ping），以及创建的新容器。

我不确定这是否与时间有关，或者与已创建的作业或 pod 的数量有关。最近的事件发生在创建了 32 个 Pod 和 20 个工作岗位之后。

如果我使用以下命令删除 kube-dns pod：

创建了一个新的 kube-dns pod，一切恢复正常（DNS 适用于所有新旧容器）。

我有一个主节点和两个工作节点。它们都是 CentOS 7 机器。

要设置集群，在主服务器上，我运行：

在这两个工人身上，我运行：

这是我运行的一些 shell 命令+输出，它们可能很有用：

在故障开始发生之前，这是一个在其中一个工作人员上运行的容器：

失败开始后，一直在运行的同一个容器：

以下是 kube-dns 容器中的一些命令：

主节点+工作节点上的版本/操作系统信息：

我们的 Kubernetes 集群包括一个 nginx 负载均衡器，它将请求转发到其他 pod。

但是，nginx 看到本地源 IP，因此无法设置正确的 X-Real-IP 标头。我尝试将 nginx 的 externalTrafficPolicy 值设置为“Local”，但 IP 没有改变。

nginx服务配置部分：

结果：

我们使用带有 metallb 的裸机集群。

我有一种情况，我想在同一个 AWS VPC 共享子网中运行两个 kubernetes 集群。这似乎工作正常，除了 weave CNI 插件似乎发现了另一个集群中的节点。这些节点因“IP分配由不同的对等方播种”而被拒绝，这是有道理的。它们是不同的集群。有没有办法阻止编织在备用集群中找到机器。当我这样做时weave --local status ipam，weave --local status targets我会看到每个集群的预期目标和 ipam。

Weave pod 处于连接和拒绝来自备用集群的节点的无限循环中。这会消耗 CPU 并影响集群。如果我kube-utils在 weave pod 内运行，它会为每个集群返回正确的节点。似乎 kubernetes 应该知道哪些对等点可用，我可以只编织使用集群知道的对等点。

经过进一步调查，我认为问题在于我已经为两个集群向上和向下扩展了机器。在此过程中，IP 地址从一个集群重复使用到下一个集群。例如，集群 A 缩小了一个节点。Weave 继续尝试连接到现在丢失的节点。集群 B 扩展并使用最初在集群 A 中使用的 ip。Weave 找到该节点。这然后使编织“发现”其他集群节点。一旦它从另一个集群中发现一个节点，它就会发现所有节点。

我已经从 2.4.0 升级到 2.4.1，看看是否有一些与重用 ips 相关的修复可以缓解这个问题。