就绪探测器和Apache公共Http客户端
我有一个简单的OpenShift设置与服务配置2后端荚。分离舱已经配置好了就绪探测器。该服务通过节点端口公开。所有这些配置都很好，工作正常。一旦就绪性探测失败，服务将pod标记为不可达，任何新的请求都不会被路由到POD。
场景1：我执行CURL命令来访问服务。当curl命令执行时，我引入了pod-1的准备失败。我看到没有新请求发送到pod-1。这是FINE
场景 2：我使用 Java Client 并使用 Apache Commons Http Client 库启动与 Kubernetes Service 的连接。连接已建立，工作正常。当我引入 Pod-1 的准备失败时，问题就来了。我仍然看到客户端仅向 Pod-1 发送请求，即使服务只有 Pod-2 的endpoint。
我的预感是，由于Http客户端在通过NodePorts公开时使用持久连接和服务，Http连接的目标地址是POD-1本身。因此，即使就绪探测失败，它仍然向pod-1发送请求。
有人能解释一下为什么他们上面描述的方式会起作用吗？？
共有1个答案
kube-proxy（或者更确切地说是它生成的 iptables 规则）在更改endpoint映射时故意不关闭现有的 TCP 连接（这是失败的就绪探测将触发的内容）。多年来，这在许多票证上已经讨论了很多，但对于是否应该改变行为通常几乎没有共识。目前，最好的选择是将入口控制器用于HTTP流量，因为这些流量都会实时更新并绕过kube-proxy。您还可以在响应中发回 Keep-Alive 标头，并在 N 秒或请求后终止持久连接，尽管这只会缩小窗口。
-
我试图在Azure中新部署的aks Kuberbetes(1.9.6)集群中部署zalenium helm chart。但我不让它起作用。豆荚给出了下面的日志： 描述pod给出：警告不健康4M(x12超过6M)kubelet，aks-agentpool-93668098-0就绪探测失败：HTTP探测失败，状态代码：502 Zalenium图像版本：Dosel/Zalenium:3 如果使用Kube
-
为了简单起见，我认为在kubernetes中最好只检查TCP端口的活跃度和就绪度，因为它不需要了解健康检查endpoint（HTTP路径），而只需要端口号。任何关于仅仅依赖TCP端口进行服务健康检查的缺点的指南都非常赞赏，请假设POD不是其他服务的代理，并且所有业务逻辑都在POD本身中。 https://kubernetes.io/docs/tasks/configure-pod-containe
-
我正在使用Spring开发一个服务，并将其部署在OpenShift上。目前，我正在使用Spring Actuctor health endpoint作为Kubernetes的活跃度和就绪度探测器。 但是，我将在执行器健康endpoint中添加一个对另一个服务的调用，在这种情况下，我认为我需要为我的服务实现新的活跃度探测。如果我不这样做，那么第二个服务的失败将导致活跃度探测失败，Kubernetes
-
在上使用helm upgrade命令运行容器时，出现了以下错误： “准备探测失败：获取http://172.17.0.6:3003/:拨号tcp 172.17.0.6:3003:GetSockopt:连接拒绝”。
-
我遇到了一个问题： 获取健康检查以成功。尝试使用容器本机负载平衡（CNLB）时，在IIS容器中运行的Net app。 我有一个网络endpoint组（NEG），由GKE中的入口资源定义和VPC本机集群创建。 当我通过公开NodePort或制作LoadBalancer类型的服务来规避CNLB时，站点会毫无问题地解决。 所有的吊舱条件从一个描述看起来不错：吊舱准备就绪 运行时会显示网络endpoint
-
我可以找到文件，其中提到我如何添加我的自定义探针和改变探针参数，如初始延迟等，但不能找到默认的探针方法使用的K8S。