标签：总结 Endpoint Service 更新 问题 Deployment Pod kube

Service Endpoint 更新延迟

在更新 Kubernetes 集群中的 Deployment 时发现了一个很奇怪的连接超时现象，在更新 Deployment 之后的 30 秒到两分钟左右，所有与以该 Deployment 作为服务后端的 Service 的连接都会超时或失败。同时我还注意到其他应用在这段时间内也会出现莫名其妙的延迟现象

一开始我怀疑是应用没有优雅删除导致的，但当我在更新 Deployment 的过程中（删除旧的 Pod，启动新的 Pod）通过 curl 来测试该应用的健康检查（liveness）和就绪检查（readiness）Endpoints 时，很快就排除了这个可能性

几个小时之后我忽然想起来 Service 并不是直接与 Deployment 关联的，而是按照标签对一组提供相同功能的 Pods 的抽象，并为它们提供一个统一的入口。更重要的是，Service 是由一组 Endpoint 组成的，只要 Service 中的一组 Pod 发生变更，Endpoint 就会被更新。想到这里，就可以继续排查问题了。下面在更新 Deployment 的过程中通过 watch 命令来观察有问题的 Service 的 Endpoint。

watch kubectl describe endpoints [endpoint name]

然后我就发现了罪魁祸首，在旧 Pod 被移除的 30 秒到几分钟左右的时间段内，这些被删除的 Pod 的 IP:Port 仍然出现在 Endpoint 的就绪列表中，同时新启动的 Pod 的 IP:Port 也没有被添加到 Endpoint 中。终于发现了连接失败的根源，但是为什么会出现这种状况呢？

负责更新 Endpoint 的组件：kube-controller-manager，在其日志输出中发现了如下可疑的信息

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-controller-manager 的主要职责是通过内部的众多 Controller 将集群的当前状态调整到期望状态，其中 Endpoint Controller 用于监控 Pod 的生命周期事件并根据这些事件更新 Endpoint。如果有足够多的对 Endpoint 发起的请求被阻塞，那么所有的 workers 都会忙于等待被阻塞的请求，这时候新事件只能被添加到队列中排队等待，如果该队列很长，就会花很长时间来更新 Endpoint。

kube-controller-manager 可以通过这两个参数来限制任何 Controller（包括 Endpoint Controller）对 kube-apiserver 发起的请求的速率。将参数 --kube-api-qps 的值设置为 300，将 --kube-api-burst 的值设置为 325，上面的日志信息便消失了，同时添加或移除 Pod 时 Endpoint 也能够立即更新。

标签：总结,Endpoint,Service,更新,问题,Deployment,Pod,kube
来源： https://www.cnblogs.com/yunwei/p/15204345.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。