我有一个在裸机上运行的内部 5 节点集群，我正在使用 Calico。集群工作了 22 天，但突然停止工作。在调查了这个问题后，我发现当所有组件都启动并且 kubectl 正常工作时，与 pod 通信的服务中断了。

如果我尝试bridge使用其 IP 卷曲另一个组件（），则从集群（组件 A）中它可以工作：

ns 对服务的查找也在工作（它解析到服务 IP）：

但是与 pod 通信的服务中断了，当我大多数时候（60-70%）卷曲到服务名称时，它卡住了：

当我检查该服务的端点时，我可以看到该 pod 的 IP 在那里：

但正如我所说，使用服务名称的 curl（和任何其他方法）不起作用。这是服务描述：

这个问题不仅限于这个组件，对于所有组件都是如此。

我重新启动了 CoreDNS（删除了它的 pod），但它仍然是一样的。我之前和以前都遇到过这个问题，我认为它与我正在使用的 Weavenet 有关，我需要集群，所以我拆除了集群并用 Calico 重建它，但现在我确定这与 CNI 无关，它是别的东西。

环境：- Kubernetes 版本（使用kubectl version）：

• 云提供商或硬件配置：这是一个由 5 个节点、1 个主节点和 4 个工作节点组成的裸机集群。所有节点都运行 Ubuntu 18.04，并且它们连接到同一个子网。

• 操作系统（例如：）cat /etc/os-release：

• 内核（例如uname -a）：

• 安装工具：Kubeadm

• 网络插件和版本（如果这是与网络相关的错误）：Calico "cniVersion": "0.3.1"

更新

删除所有 kube-proxy pod 问题后似乎解决了，但我仍然想知道是什么导致了这个问题。顺便说一句，我在 kube-proxy 日志中没有看到任何错误。

我正在开发的应用程序作为 Kubernetes 集群中的部署运行。为此部署创建的 Pod 分布在集群中的各个节点上。我们的应用程序一次只能处理一个 TCP 连接，并且会拒绝进一步的连接。目前，我们使用 kube-proxy（Iptables 模式）在各个节点的 pod 之间分配负载，但是 pod 是随机选择的，当它传递给繁忙的 pod 时，连接会被丢弃。我可以为我的用例使用 Kube-router 的基于最少连接的负载平衡算法吗？我希望流量在各个节点中运行的各个 pod 之间进行负载平衡。我可以使用 Kube-router 来实现这一点吗？

据我所知，kube-proxy 的 IPVS 模式仅在同一节点中的 pod 之间平衡流量，因为 kube-proxy 作为守护程序集运行。Kube-router也一样吗？

我有一个 Kubernetes 集群，其部署类似于下一个：

这里的目标是将应用程序部署在通过名为my-app. 在多个命名空间（A、B 和 C）中进行相同的部署，稍微更改应用程序的配置。然后，在某些节​​点中，我有一个使用 hostNetwork 绑定到节点端口的 HAProxy。这些 HAProxy 通过指向它们的 DNS (my_app.com) 向我的客户端公开。

当客户端连接到我的应用程序时，它们会发送一个标头，指定请求应重定向到的命名空间（A、B 或 C），并且 HAProxy 使用do-resolve类似 的 dns 条目解析服务的 IP，该条目my_app.A.svc.cluster.local返回的 IPmy_app命名空间中的服务A。这样，我的集群就可以有一个入口点（单个 DNS 记录）和一个端口（80），这是我的要求之一。我还能够创建新的命名空间并部署我的应用程序的其他配置，而无需修改 HAProxies，这是第二个要求。

现在，我收到的请求是短请求和长请求的混合，所以我需要在这里使用最少的连接。这在 HAProxies 中是不可能的，因为我没有后端列表（重定向是动态的，如您在下面的代码中所见）。我正在尝试将 kube-proxy 与 IPVS 和最少连接模式一起使用。我注意到的是，到不同 pod 的连接跟踪是按节点进行的，并且这些信息不会在不同节点之间共享。这样，如果两个my_app.com Namespace: A不同的节点处理两个请求，则两者都可以转到同一个 pod（例如 pod_1），因为在每个节点中，到该 pod 的活动连接数为 0。随着我增加问题，问题变得更糟DNS 后面的 HAProxy 数量。

如何在没有集群入口点的情况下解决这个问题并获得更好的平衡（在 DNS 后面有一个 HAProxy）？

我在这里添加了 HAProxy 中使用的代码，以根据标头进行路由：

使用 kubespray 将工作节点添加到现有集群。已加入集群的节点，但节点上计划的新 pod 失败并出现错误“get https://10.233.0.1 : dial tcp 10.233.0.1: 443 connection denied”

网络插件 - 以 ipvs 模式运行的 calico kube-proxy

1. 从新的工作节点，可以连接到超过 6443 的主服务器 IP 地址
2. 从新的工作节点，无法通过端口 443 访问集群 ip 10.233.0.1
3. Calico、nodelocaldns 和 kube-proxy pod 在新节点上处于运行状态
4. Kube-proxy 日志显示错误“无效的 nodeIP，使用 127.0.0.1 作为 nodeIP 初始化 kube-proxy”无法写入事件：'Post https://127.0.0.1:6443/api/v1/namespaces/default/events dial tcp 127.0 .0.1:6443 连接被拒绝”
5. ipvsadm -ln 输出不显示任何服务
6. ip addr show 输出不显示 kube-ipvs0 和 calico 接口

有人可以帮忙吗。谢谢

我是 K8S 的新手，我试图了解在集群中每个节点上运行的 kube-proxy 的确切作用。该文档提到“kube-proxy 反映了每个节点上 Kubernetes API 中定义的服务，并且可以在一组后端进行简单的 TCP、UDP 和 SCTP 流转发或循环 TCP、UDP 和 SCTP 转发”。要做到这一点，每个 kube-proxy 都需要有关于集群中运行的所有服务的完整信息，因为 kube-proxy 有责任提供对运行在 pod 上的应用程序所需的任何服务的访问（在相应的节点上）。那么这是否意味着 K8S 集群内的所有 kube-proxy（在每个节点上运行）都是镜像？如果是这样，为什么每个节点上都存在 kube-proxy 而不是整个集群的集中式代理？

链接到关于代理的 K8S 文档：https ://kubernetes.io/docs/concepts/cluster-administration/proxies/

我有一个 ClusterIP 服务，用于在内部将负载分配到 2 个 POD。负载在 POD 中分布不均。

如何使负载分布均匀？

我正在使用 Docker for Windows (docker-desktop)，它附带一个小型单节点 kubernetes 实例。我有一个场景，我的 pod 需要与运行在同一 localhost（windwos 10 机器）上但在 k8s 集群之外的一些外部服务进行通信。

我知道我可以kubernetes.docker.internal在集群内使用来访问我的node/localhost. 但不幸的是，Pod 在图像中有一些我不想更改的默认连接字符串 - 假设 Pod 默认尝试连接到 dns 字符串 - “my-server”。因此，在我的场景中，我想定义一个名为“my-server”的 K8s 服务，该服务具有对 kubernetes.docker.internal 的端点引用，以便 kube-proxy 将其正确路由到我的本地主机，即我的 windows 10 机器。

这有可能吗？我已经检查过这个解决方案，但它谈到了在其他节点或云上运行的外部服务。我也在考虑将本地计算机主机名作为外部名称，但这在我的用例的 dns 解析中并不完全可靠。所以我真的很想使用kubernetes.docker.internal作为服务端点。有什么想法吗？

官方 kubernetes 文档明确指出kube-proxy “不会扩展到具有数千个服务的非常大的集群”，但是当LoadBalancer在 GKE 上创建类型 Service时，默认externalTrafficPolicy设置为Cluster（这意味着每个请求将由除了外部负载平衡之外，无论如何都是 kube-proxy）。正如在Next '17 的这段视频中所解释的那样，这是为了避免流量不平衡（因为 Google 的外部负载均衡器无法询问集群每个节点上有多少给定服务的 pod）。

因此问题是：这是否意味着：

a) 默认情况下，GKE 不能用于“具有数千个服务的超大型集群”，为此我需要通过设置externalTrafficPolicy来冒流量不平衡的风险Local

b) ...或者有关 kube-proxy 可扩展性差的信息不正确或已过时

c) ...或其他我想不出的东西

谢谢！

我试图深入了解从公开暴露的负载均衡器的第 2 层 VIP 转发到服务的集群 IP 的工作原理。我已经阅读了MetalLB如何做到这一点的高级概述，并且我尝试通过设置 keepalived/ucarp VIP 和 iptables 规则来手动复制它。但是我必须遗漏一些东西，因为它不起作用；-]

我采取的步骤：

1. 创建了一个集群，kubeadm其中包含一个主节点 + 3 个节点，在单台计算机上的 libvirt/KVM 虚拟机上运行 k8s-1.17.2 + calico-3.12。所有虚拟机都在192.168.122.0/24虚拟网络中。

2. 创建了一个简单的 2 pod 部署并将其公开为设置为的NodePort服务： 我已经验证我可以从主机上的每个节点的 IP 的 32292 端口访问它。externalTrafficPolicycluster
$ kubectl get svc dump-request NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE dump-request NodePort 10.100.234.120 <none> 80:32292/TCP 65s
   

3. ucarp在所有 3 个节点上创建了一个 VIP ：（
   ucarp -i ens3 -s 192.168.122.21 -k 21 -a 192.168.122.71 -v 71 -x 71 -p dump -z -n -u /usr/local/sbin/vip-up.sh -d /usr/local/sbin/vip-down.sh来自 knode1 的示例）
   我已经验证我可以 ping 192.168.122.71VIP。我什至可以通过它连接到当前持有 VIP 的虚拟机。
   现在，如果 kube-proxy 处于iptables模式，我还可以通过 VIP 访问其节点端口上的服务http://192.168.122.71:32292。然而，令我惊讶的是，在ipvs模式下，这总是导致连接超时。

4. 在每个节点上添加了一个 iptables 规则，用于将传入的数据包192.168.122.71转发到服务的 cluster-IP 10.100.234.120：（
   iptables -t nat -A PREROUTING -d 192.168.122.71 -j DNAT --to-destination 10.100.234.120
   后来我也尝试将规则缩小到相关端口，但它并没有以任何方式改变结果：
   iptables -t nat -A PREROUTING -d 192.168.122.71 -p tcp --dport 80 -j DNAT --to-destination 10.100.234.120:80)

结果：

在iptables模式下，所有请求都会http://192.168.122.71:80/导致连接超时。

在ipvs模式下它部分工作：
如果192.168.122.71VIP 被一个有 pod 的节点持有，那么大约 50% 的请求是成功的，并且它们总是由本地 pod 提供服务。该应用程序还获得了主机的真实远程 IP ( 192.168.122.1)。其他 50%（大概被发送到另一个节点上的 pod）正在超时。
如果 VIP 被没有 pod 的节点持有，那么所有请求都超时。

我还检查了它是否无论如何都会影响结果，以始终将规则保留在所有节点上，而不是将规则仅保留在持有 VIP 的节点上并在 VIP 发布时将其删除：两者的结果都相同案例。

有谁知道为什么它不起作用以及如何解决它？我会很感激这方面的帮助:)

根据我对 Kubernetes 的了解，如果 master(s) 死了，worker 应该仍然能够正常工作（https://stackoverflow.com/a/39173007/281469），尽管不会发生新的调度。

但是，我发现当 master 也可以调度 worker pod 时，情况并非如此。以一个 2 节点集群为例，其中一个节点是主节点，另一个节点是工作节点，并且主节点已移除污点：

如果我关闭 master 并docker exec进入 worker 上的一个容器，我可以看到：

成功，但是

一半的时间失败。Kubernetes 版本为 v1.15.10，kube-proxy 使用 iptables 模式。

我猜测由于工作节点上的 kube-proxy 无法连接到 apiserver，它不会从 iptables 规则中删除主节点。

问题：

1. kube-proxy 不会停止路由到主节点上的 pod 是预期的行为，还是有什么“坏的”？
2. 是否有任何变通办法可用于这种设置以允许工作节点仍然正常运行？

我意识到最好的办法是分离 CP 节点，但这对于我目前正在做的事情是不可行的。