Kubernetes探针踩坑记

  • 作者:zccc
  • 来源:网络
  • 2020-09-16 12:19:23

1. 荒腔走板 最近一两个月生产K8s集群频繁出现短时503 Service Temporarily Unavailable,还不能主动复现,相当郁闷,压力山大。 HTTP 5xx响应状态码用于定义服务端错误。 500...

1. 荒腔走板

最近一两个月生产K8s集群频繁出现短时503 Service Temporarily Unavailable,还不能主动复现,相当郁闷,压力山大。

HTTP 5xx响应状态码用于定义服务端错误。

500 Internal Server Error:所请求的服务器遇到意外的情况并阻止其执行请求,通常针对单个请求,整个站点有时还是提供服务。 502 Bad Gateway Error 暗示连接链路中某个服务器下线或者不可用; 503 Service Unavailable 意味着托管您的应用程序的实际Web服务器上存在问题。

2. 排查记录

基本上每隔2-3天出现一次,每次2-3分钟,此时整站503; 因为不能主动复现,8月26日排查相应时间段的EFK日志: impala连接问题,大数据运维同事排查到webapp发起impala的请求与impala集群时钟未对齐,导致webapp impalaODBC Driver连不上impala集群;

进入k8s集群节点,确实部分节点的时钟对齐服务未启动,不定时出现比北京时间慢2,3分钟的情况,这个确实可以解释时间差导致的impala连接认证失败。

8月26日同步所有k8s节点的时钟,之后接近一周,并未出现问题; 9月3日又出现一次短时503无服务,EFK日志显示依旧是impala连接问题,此处大数据同事未能定位具体原因,暂时定义为偶发/抖动?

3.思考和推演

故障现场每次只有impala连接问题,我也搞不懂impala连接问题竟然会导致webapp service下线。

我们的webapp兼具toB和toC业务,站点强依赖mongodb、弱依赖于impala:impala即使连不上,只是不能查,站点sso+订单相关的写入操作应该还可用。

回想起前几天看到的k8s探针,糟糕,我们的就绪探针好像探测了impala

//ASP.NetCore上暴露的的探测逻辑:impala&&mongodbservices.AddHealthChecks().AddCheck(nameof(ImpalaHealthCheck),tags:new[]{"readyz"}).AddCheck(nameof(MongoHealthCheck),tags:new[]{"readyz"});app.UseHealthChecks("/readyz",newHealthCheckOptions{Predicate=(check)=>check.Tags.Contains("readyz")});

强烈推测:就绪探针3次探测impala失败, Pod将会被标记为Unready, 该Pod将从webapp服务负载均衡器移除, 不再分配流量,导致nginx无实际意义的后端服务,站点503。

迅速找一个beta环境,断开impala连接,验证猜想。

4.问题回顾

bugfix不是我正向推断出来的,而是纯靠经验推演出来的,倒不是有明确推断思路,也算给大家提前踩坑了。

docker的健康检查只能探测,Kubernetes存活、就绪探针不仅有探测,还有决策能力。

这里我们的k8s就绪探测使用策略出现了问题:

探测到webapp弱依赖impala有问题,就下线了整个webapp服务,应该只探测强依赖,强依赖有问题,才表明容器未就绪,这也是就绪探针的初衷。

<a href=http://www.xinnet.com target=_blank>新网</a><a href=http://www.xinnet.com/cs/cs.html target=_blank>箭头云服务器</a>

  • 相关专题

免责声明:本文内容由互联网用户自发贡献自行上传,本网站不拥有所有权,也不承认相关法律责任。如果您发现本社区中有涉嫌抄袭的内容,请发送邮件至:operations@xinnet.com进行举报,并提供相关证据,一经查实,本站将立刻删除涉嫌侵权内容。

相关文章

免费咨询获取折扣