本文转载自微信公众号「Dotnet Plus」,可以通过以下二维码关注。转载本文请联系Dotnet Plus公众号。
1. 荒腔走板
最近一两个月生产K8s集群频繁出现短时503 Service Temporarily Unavailable,还不能主动复现,相当郁闷,压力山大。
HTTP 5xx响应状态码用于定义服务端错误。
2. 排查记录
进入k8s集群节点,确实部分节点的时钟对齐服务未启动,不定时出现比北京时间慢2,3分钟的情况,这个确实可以解释时间差导致的impala连接认证失败。
3.思考和推演
故障现场每次只有impala连接问题,我也搞不懂impala连接问题竟然会导致webapp service下线。
我们的webapp兼具toB和toC业务,站点强依赖mongodb、弱依赖于impala:impala即使连不上,只是不能查,站点sso+订单相关的写入操作应该还可用。
回想起前几天看到的k8s探针,糟糕,我们的就绪探针好像探测了impala
- // ASP.NetCore上暴露的的探测逻辑:impala && mongodb
- services.AddHealthChecks()
- .AddCheck<ImpalaHealthCheck>(nameof(ImpalaHealthCheck), tags: new[] { "readyz" })
- .AddCheck<MongoHealthCheck>(nameof(MongoHealthCheck), tags: new[] { "readyz" });
- app.UseHealthChecks("/readyz", new HealthCheckOptions
- {
- Predicate = (check) => check.Tags.Contains("readyz")
- });
强烈推测:就绪探针3次探测impala失败, Pod将会被标记为Unready, 该Pod将从webapp服务负载均衡器移除, 不再分配流量,导致nginx无实际意义的后端服务,站点503。
迅速找一个beta环境,断开impala连接,验证猜想。
4.问题回顾
bugfix不是我正向推断出来的,而是纯靠经验推演出来的,倒不是有明确推断思路,也算给大家提前踩坑了。
docker的健康检查只能探测,Kubernetes存活、就绪探针不仅有探测,还有决策能力。
这里我们的k8s就绪探测使用策略出现了问题:
探测到webapp弱依赖impala有问题,就下线了整个webapp服务,应该只探测强依赖,强依赖有问题,才表明容器未就绪,这也是就绪探针的初衷。
本文转载自网络,原文链接:https://mp.weixin.qq.com/s/vlOUg46B5bcmToX-fjavJQ...
9月17日,2020云栖大会上,阿里云正式发布工业大脑3.0。 阿里云智能资深产品专家...
查看表结构,sbtest1有主键、k_1二级索引、i_c二级索引 CREATE TABLE `sbtest1` ...
中国最?好的一朵云飘进了华瑞银行。阿里云将进一步助力华瑞银行All in Cloud。 -...
在TOP云(zuntop.com)科技租赁过服务器的站长都知道独立服务器在价格上比VPS主...
一、PostgreSQL行业位置 一 行业位置 首先我们看一看RDS PostgreSQL在整个行业当...
定义 this是函数运行时自动生成的内部对象,即调用函数的那个对象。(不一定很准...
2020年对于云计算行业来说是突破性的一年,因为公共云供应商增加了收入,而疫情...
最近,DevOps的采用导致了企业计算的重大转变。除无服务器计算,动态配置和即付...
很长时间没有更新原创文章了,但是还一直在思考和沉淀当中,后面公众号会更频繁...