问题标签 [kube-proxy]

这是我的集群环境：</p>

kubectl 版本

我期望的结果：我可以从kubernetes master正常访问SVC IP。在master主机上，我已经部署了kube-proxy和flannel。

我的 kubernetes 集群的所有组件都是通过发布二进制文件部署的。

我已经正常部署了我的集群，大部分情况下，它可以对外提供服务。我已经部署了一个nginx服务器，我的截图：

nginx服务器

我在kubernetes master主机上直接访问pod IP（172.30.21.3）时，可以正常访问。

我的截图： http请求

但是当我访问服务IP时，会出现访问超时。

我的截图： 访问 SVC IP 超时

这只会在容器外部的主机上请求 SVC IP 时发生。如果我在容器中，我可以正常访问 SVC IP。

我的截图： 在容器http请求中

这是我的 ipvs 规则列表： ipvs rule list

使用tcpdump监听nginx pod节点主机上的flannel.1网卡和docker0网卡，发现如下问题：

当我在 kubernetes master 主机上直接访问 pod IP 时，我的 master 主机上的 flannel 网卡会将数据包发送到节点主机 flannel NIC ，然后转发到 docker0 网卡，最后是 pod IP。同时pod IP会响应我的请求，一切正常。但是当我在kubernetes master主机上访问SVC IP时，发现发包的网卡变成了eth0而不是使用flannel网卡，所以node主机上的flannel网卡直接丢掉了请求，没有继续转发到码头工人0。

我意识到这可能是基于策略的路由的问题。如果我将目标为 10.254 的请求转发到正确的网关，我可以解决这个问题吗？

但这应该有一个更标准的解决方案。谁能帮我？

（对不起，我的英文不是很好……）</p>

我正在使用 Rancher 进行 Kubernetes 安装和集群管理。为了解决与 IP 表相关的问题，我需要更新 Kubeproxy 配置中的 cluster-cidr 属性（https://github.com/kubernetes/kubernetes/issues/36835），我不确定如何更新 kube-proxy。有人可以告诉我如何通过 Kubectl 或 UI 更新它，或者如何登录 kubeproxy 并更改它吗？

我们有一个使用 KOPS 创建的 AWS EC2 实例的 Kubernetes 集群设置。我们在通过 kubernetes 服务进行内部 pod 通信时遇到问题（这将负载平衡目标 pod 之间的流量）。当源 pod 和目标 pod 位于同一个 EC2 实例（节点）上时，就会出现问题。Kubernetes 使用 flannel 设置，用于使用 vxlan 进行节点间通信，并且 kubernetes 服务由 kube-proxy 使用 iptables 管理。

在以下情况下：

• 在 EC2 实例 1 上运行的 PodA（ip-172-20-121-84，us-east-1c）：100.96.54.240
• 在 EC2 实例 1（ip-172-20-121-84，us-east-1c）上运行的 PodB：100.96.54.247
• ServiceB（PodB 是可能的目标端点的服务）：100.67.30.133

如果我们进入 PodA 并执行“curl -v http://ServiceB/ ”，则没有收到任何响应，最后产生超时。

当我们检查流量（实例 1 中的 cni0 接口）时，我们观察到：

1. PodA 向 ServiceB IP 发送 SYN 包
2. 包被破坏，目标 IP 从 ServiceB IP 更改为 PodB IP

3. Conntrack 记录发生变化：

   /li>

4. PodB 向 PodA 发送 SYN+ACK 包

5. SYN+ACK 包的源 IP 不会从 PodB IP 恢复到 ServiceB IP
6. PodA 收到来自 PodB 的 SYN+ACK 包，这是意料之外的，它会发回一个 RESET 包
7. PodA超时后再次向ServiceB发送SYN包，整个过程重复

这里 tcpdump 注释的详细信息：

实例 1 (ip-172-20-121-84, us-east-1c) 上的相关 iptable 规则（由 kube-proxy 自动管理）：

这是服务定义：

如果我们直接使用 PodB IP 而不是服务（因此无需破坏包），则连接有效。

如果我们使用该服务，但随机选择的目标 pod 在不同的实例中运行，则连接跟踪机制正常工作，它会破坏包，以便 PodA 按预期看到 SYN+ACK 包（来自 ServiceB IP） . 在这种情况下，流量通过 cni0 和 flannel.0 接口。

这种行为是几周前开始的，在我们没有发现任何问题之前（一年多），我们不记得对集群设置或我们正在运行的 Pod 有任何重大更改。有没有人有任何想法可以解释为什么 SYN+ACK 包没有重新回到预期的 src/dst IPs？

我正在尝试深入研究 K8s 网络模型，并且我认为到目前为止我对它已经有了很好的理解，但是有一件事我无法理解。在Cluster Networking指南中，提到了以下内容：

Kubernetes 对任何网络实现都提出了以下基本要求（除非任何有意的网络分段策略）：

• 所有容器都可以在没有 NAT 的情况下与所有其他容器通信
• 所有节点都可以在没有 NAT 的情况下与所有容器通信（反之亦然）
• 容器认为自己的 IP 与其他人认为的 IP 相同

第二个要点指定 x-node 容器通信应该可以在没有 NAT 的情况下进行。然而，当 kube-proxy 在iptables模式下运行时，情况并非如此。这是来自我的一个节点的 iptables 转储：

看起来 K8s 正在将标记的出站数据包的源 IP 更改为节点的 IP（对于 ClusterIP 服务）。他们甚至在Source IP for Services with Type=ClusterIP中明确提到了这一点：

如果你在 iptables 模式下运行 kube-proxy，从集群内部发送到 ClusterIP 的数据包永远不会进行源 NAT，这是自 Kubernetes 1.2 以来的默认设置。如果客户端 Pod 和服务器 Pod 在同一个节点中，则 client_address 是客户端 Pod 的 IP 地址。但是，如果客户端 pod 和服务器 pod 位于不同的节点中，则 client_address 是客户端 pod 的节点 flannel IP 地址。

首先说集群中的数据包从不经过 SNAT，然后继续说发送到其他节点中的 pod 的包实际上是经过 SNAT 的。我对此感到困惑 - 我是否误解了所有节点都可以在没有 NAT要求的情况下与所有容器通信（反之亦然） ？

我只需要从当前节点上运行的 Pod 将 kube-proxy 配置为服务器，并避免连接在不同节点之间反弹。

I have a deployment where the replicas scale up and down which are all under a headless service. I am able to query ..svc.cluster.local which returns list of all pod IPs.

I wanted to know if its possible to query for each pod IP and get the hostname of the pod? It works for Pods on the same host machine. But its not resolving the pods from other hosts.

I noticed that it works for a StatefulSet. But its not working for Deployment.

我在网上找了很久。但是没有用。请帮助或尝试提供一些想法如何实现这一目标。

服务定义：

kubectl 描述服务 eureka1：

kubectl 获取 ep:

如果我在 eureka1 应用程序 telnet 到10.254.65.233 80

但我可以ping通10.254.65.233

尝试另一个服务 IP，而不是选择器，并且可以 telnet。

kube-proxy 模式是 ipvs

谢谢

我在 Ubuntu 16.04 机器上设置 Kubernetes 集群时遇到问题，我已正确设置：

1. 主节点（机器IP：10.10.1.122）
2. 工作节点（机器 IP：10.10.1.38）

进入包含以下信息的集群：

我的集群信息

我的豆荚

我在这里面临的问题是，每当我想从主节点卷曲服务或 Pod IP 时，它永远不会命中，同时从工作节点卷曲服务/Pod 很好，我是 Kubernetes 的新手，但是我找不到任何线索如何诊断这个问题，任何帮助将不胜感激。

当我尝试卷曲暴露的服务时，即使我从主人那里得到了这个结果：

我刚刚将我的 1.10.0 kubernetes 集群升级到 1.10.12。

我还将一个或两个节点更新到相同的版本。

但是，我现在看到：

显示日志给出：

帮助？我不知道如何进一步解决这个问题。

巧合的是，我同时添加了一个新节点，看到weave启动也有问题：

我想这是因为 kube-proxy 没有启动。

可能不相关，但我确实遇到了 cri-tools 的问题并kubeadm join说它找不到dockershim.sock. 所以我做了一个rpm -e --nodeps cri-tools，这似乎修复了加入。我很确定 docker 子系统正在工作，因为我可以看到机器上的其他 kubernetes pod（例如 k8s_POD_weave-net-mb299_kube-system、k8s_weave-npc_weave-net-mb299_kube-system）

来自其中一个奴才的日志快照：

如果我移动一个相关的配置文件并运行kubectl proxy它，它将允许我通过这个 URL 访问 Kubernetes 仪表板：

但是，如果我尝试直接访问节点，而不使用kubectl proxy，我将得到 403 Forbidden。

我们的 kubernetes 集群隐藏在用户需要通过 VPN 接入的专用网络中；此外，在对 VPN 进行身份验证后，只有我们中的一些人可以与我们每个集群的主节点通信。因此，运行kubectl proxy是一个多余的步骤，为每个集群选择合适的配置文件是一个额外的痛苦，尤其是当我们想要比较不同集群的状态时。

需要更改哪些内容才能允许“匿名”HTTP 访问这些已经安全的 kubernetes 主节点的仪表板？