问题标签 [kube-proxy]

我按照kubernetes-the-hard-way guide设置了一个单节点 kubernetes ，除了我在 CentOS-7 上运行并且我在同一个节点中部署了一个 master 和一个 worker。我已经关闭了firewalld服务。

安装后，我部署了一个 mongodb 服务，但是集群 IP 不可访问，但端点可访问。服务详情如下：

我在主机上运行 mongo 10.254.0.2，它可以工作，但是当我运行 mongo 10.254.0.117 时，它不起作用。顺便说一句，如果我启动另一个 mongo pod，例如

我尝试了 mongo 10.254.0.2 和 mongo 10.254.0.117，它们根本不起作用。

我使用的kubernetes版本是1.10.0。

我认为这是一个 kube-proxy 问题，kube-proxy 配置如下：

并且配置文件是

这是我得到的 ip 表

一个月前，我使用 kubeadm 部署了一个 v1.13.0 的 kubernetes 集群，其中有一个主节点和三个工作节点。一切都很好。
但是当我要向这个集群注册一个新的工作人员时。kube-proxy deamonset 容器启动时出现以下错误日志：

由于 kube-proxy 在容器内，所以主要问题是：

e

（版本兼容性已被证明不是这个问题的主要原因）

希望有这方面的专家可以帮助我。

我想尝试这种新的代理模式以及它为我们的一些应用程序提供的各种调度程序。到目前为止，我一直无法找到将默认模式更改为iptablesGKEipvs节点上的方法。

Everywere 说要传递--proxy-mode=ipvs给 kube-proxy，但这对于 GKE 的“弹性/动态”部署没有意义，新节点不会接受这些更改。

我也在这里看到：https : //kubernetes.io/blog/2018/07/09/ipvs-based-in-cluster-load-balancing-deep-dive/ “GCE 脚本”（我没有真的知道那些是什么）支持设置KUBE_PROXY_MODE=ipvs环境变量，但我找不到在创建时通过gcloud或 Web 界面将环境变量传递给节点池的方法。

知道这是否可能吗？（顺便说一句，我使用的是版本1.11.6-gke.2）

根据一些技术博客（例如了解 kubernetes 网络：服务），k8s 服务通过 iptable 规则调度所有请求。
如果碰巧在该 pod 上路由请求时，其中一个上游 pod 崩溃了怎么办。
kubernetes 服务中是否有故障转移机制？
请求会自动转发到下一个 pod 吗？
kubernetes 是如何通过 iptable 解决这个问题的？

我最近在测试我的 Kubernetes 服务。而且我发现它非常不可靠。情况如下：
1. 在端口 80 接收 HTTP 请求的测试服务“A”在三个节点上部署了五个 Pod。
2. nginx 入口设置为将外部流量路由到服务“A”。
3.入口设置如下：

3. http_load 在客户端主机上启动，并以每秒 1000 的速度不断向入口 nginx 发送请求。所有请求都被路由到 k8s 中的服务“A”，一切顺利。

当我手动重启其中一个节点时，出现了问题：
在接下来的 3 分钟内，大约 20% 的请求超时，这在产品环境中是不可接受的。

不知道为什么k8s反应这么慢，有没有办法解决这个问题？

创建 nodePort 类型的 kubernetes 服务时， kube-proxy 将每个工作节点配置为侦听特定端口。

kube-proxy（在 iptables 代理模式下）实际上是如何配置的？它只是使用打开端口的 iptables 完成的吗？（不确定这是否可能）

我有一项服务，在某些情况下，它会向自身发送请求。我可以从集群外部访问服务，但自请求失败（超时）。

环境：

• minikube v0.34.1
• Linux 版本 4.15.0 (jenkins@jenkins) (gcc 版本 7.3.0 (Buildroot 2018.05)) #1 SMP Fri Feb 15 19:27:06 UTC 2019

我一直在使用https://kubernetes.io/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip作为故障排除指南，但我'm down the step that says "寻求帮助"。

故障排除结果：

故障排除指南表明“hairpin-veth”是可以的。

注意使用的指南/sys/devices/virtual/net/cbr0/brif/*，但在这个版本的 minikube 中，路径是/sys/devices/virtual/net/docker0/brif/veth*. 我想了解为什么路径不同，但似乎没有启用 hairpin_mode。

指南中的下一步是：Seek help if none of above works out.

1. 我认为我需要启用 hairpin_mode 是否正确？
2. 如果是这样，我该怎么做？

我已经部署了几个不同的服务并且总是得到同样的错误。

可以从运行 pod 的机器的节点端口访问该服务。在其他两个节点上，我得到了超时。

kube-proxy 在所有工作节点上运行，我可以在 kube-proxy 的日志文件中看到添加了服务端口并打开了节点端口。在这种情况下，我部署了来自 calico 的 stars 演示

Kube-proxy 日志输出：

kube-proxy 正在监听 30002 端口

还定义了一些 iptable 规则：

有趣的部分是我可以从任何工作节点访问服务 IP

如果我执行“curl http://10.32.0.133:9001 ” ，则可以从任何工作节点访问服务 IP/端口

我不明白为什么 kube-proxy 不能正确“路由”这个......
有没有人暗示我可以在哪里找到错误？

这里有一些集群规格：

这是一个手工构建集群，灵感来自 Kelsey Hightower 的“kubernetes the hard way”指南。

• 6 个节点（3 个主节点：3 个工作节点）本地虚拟机
• 操作系统：Ubuntu 18.04
• K8s：v1.13.0
• 码头工人：18.9.3
• Cni: 印花布

主节点上的组件状态看起来不错

如果我信任 kubectl，工作节点看起来还不错

正如 P Ekambaram 所问：

可以通过将网络请求发送到它们所属的服务的 dns 来访问 kubernetes 集群中的 Pod。网络请求必须发送到[service].[namespace].svc.cluster.local该服务的所有成员并在该服务的所有成员之间进行负载平衡。

这可以很好地让某个 pod 到达另一个 pod，但是如果一个 pod 尝试通过他所属的服务到达自己，它会失败。它总是导致超时。

这是 Kubernetes 中的一个错误（在我的例子中是 minikube v0.35.0）还是需要一些额外的配置？

这是一些调试信息：

让我们从其他 pod 联系服务。这工作正常：

现在我们尝试让 pod 联系他所属的服务：

如果我正确阅读了 curl 调试日志，则 dns 解析为 ip 地址 10.107.209.9。可以通过该 ip 从任何其他 pod 访问该 pod，但该 pod 不能使用它来访问自己。

以下是尝试访问自身的 pod 的网络接口：

这是部署到 minikube 的 kubernetes 文件：

我是 Kubernetes 的新手，我正在尝试创建一个集群。但是在我使用 kubeadm 命令配置 master 之后，我发现 pod 出现了一些错误，这导致 master 始终处于 NotReady 状态。

一切似乎都源于 kube-proxy 无法列出端点和服务的事实......因此（或者我理解）无法更新 iptables。

这是我的 kubectl 版本：

以下是来自 kube-proxy pod 的日志：

现在，我以这种方式创建了一个新的 ClusterRoleBinding：

如果我描述 ClusterRole，我可以看到：

所以用户“system:kube-proxy”应该能够列出端点和服务，对吧？现在，如果我打印 kube-proxy daemonSet 的 YAML 文件，我会得到他的：

我可以看到让我感到困惑的“用户：默认”......它试图与哪个用户进行身份验证？是否有一个名为“default”的实际用户？

非常感谢！

kubectl 的输出 get po -n kube-system

集群运行状况看起来很健康