K8S集群优化之修复ServiceEndpoint更新的延迟

  • 时间:
  • 浏览:8
  • 来源:5分11选5APP下载_5分11选5APP官方

想到这里,就能都还都都还可以 继续排查问题了。下面在更新 Deployment的过程中通过 watch 命令来观察有问题的 Service 的 Endpoint。

一结速我怀疑是应用那么优雅删除意味着着的,但当我在更新 Deployment 的过程中(删除旧的 Pod,启动新的 Pod)通过 curl 来测试该应用的健康检查(liveness)和就绪检查(readiness)Endpoints 时,很慢就排除了你这人 完后 性。

这另一一一有一个 参数的默认值是20,但当集群中的主机数量非常多时,默认值显然不满足集群运行的工作负载。经过不断调试完后 ,我将参数 --kube-api-qps的值设置为 1000,将 --kube-api-burst的值设置为 325,后边的日志信息便消失了,同去添加或移除Pod 时Endpoint也都都还都都还可以 立即更新。

几个 月前,我在更新 Kubernetes 集群中的 Deployment 时发现了另一一一有一个 很奇怪的连接超时问题,在更新 Deployment 完后 的 1000 秒到两分钟左右,所有与以该 Deployment作为服务后端的 Service 的连接都会超时或失败。同去我还注意到很多应用在这段时间内也会再次出现莫名其妙的延迟问题。

--kube-api-qps 和--kube-api-burst参数的值越大,kube-apiserver 和etcd 的负载就越高。在我的集群中,通过适当地增加很多负载来解决你这人 问题是很值得的。

I0412 22:59:59.914517 1 request.go:638] Throttling request took 2.489742918s, request: GET:https://10.3.0.1:443/api/v1/namespaces/[some namespace]/endpoints/[some endpoints]"

但还是感觉哪里不对劲,明明延迟了几分钟,为哪几种这里显示的只有两秒?

再次仔细阅读源码后,我找到了另一一一有一个 能不都还都都还可以 都还都都还可以 扭转战局的参数:--kube-api-qps 和--kube-api-burst。kube-controller-manager能都还都都还可以 通过这另一一一有一个 参数来限制任何 Controller(包括 Endpoint Controller)对 kube-apiserver发起的请求的强度。

我结速怀疑人生,结速怀疑我的职业选者,几个 小时完后 我忽然想起来 Service 并都会 直接与 Deployment关联的,但是我按照标签对一组提供相同功能的 Pods的抽象,并为它们提供另一一一有一个 统一的入口。更重要的是,Service 是由一组 Endpoint 组成的,我希望Service中的一组Pod趋于稳定变更,Endpoint就会被更新。

Endpoint Controller 内内外部运行了一组 workers来解决哪几种事件并更新Endpoint,完后 有足够多的对 Endpoint发起的请求被阻塞,那么所有的 workers 都会忙于等待被阻塞的请求,这完后 新事件只有被添加到队列中排队等待,完后 该队列很长,就会花很长时间来更新 Endpoint。

$ watch kubectl describe endpoints [endpoint name]

为何让我能 发现了罪魁祸首,在旧 Pod被移除的 1000 秒到几分钟左右的时间段内,哪几种被删除的Pod的 IP:Port 仍然再次出现在Endpoint 的就绪列表中,同去新启动的 Pod的IP:Port也那么被添加到 Endpoint中。终于发现了连接失败的根源,为何让为哪几种会再次出现你这人 具体情况呢?仍然无解。

为了解决你这人 问题,首先我通过调整kube-controller-manager 的 参数--concurrent-endpoints-syncs来增加Endpoint Controller的workers,但收效甚微。

在阅读了kube-controller-manager的源码后,我发现了问题所在。Kube-controller-manager的主要职责是通过内内外部的众多 Controller将集群的当前具体情况调整到期望具体情况,其中 Endpoint Controller用于监控Pod 的生命周期事件并根据哪几种事件更新 Endpoint。

又经历了几天折腾完后 ,我又有了新点子,那但是我调试负责更新Endpoint 的组件:kube-controller-manager,最后终于在kube-controller-manager 的日志输出中发现了如下可疑的信息: