作者:小码甲 2020-09-15 08:46:26
云计算 最近一两个月生产K8s集群频繁出现短时503 Service Temporarily Unavailable,还不能主动复现,相当郁闷,压力山大。
让客户满意是我们工作的目标,不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户,将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴,公司提供的服务项目有:域名申请、网页空间、营销软件、网站建设、平舆网站维护、网站推广。
本文转载自微信公众号「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
(nameof(ImpalaHealthCheck), tags: new[] { "readyz" }) - .AddCheck
(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服务,应该只探测强依赖,强依赖有问题,才表明容器未就绪,这也是就绪探针的初衷。
当前标题:Kubernetes探针踩坑记
文章源于:http://www.csdahua.cn/qtweb/news21/108521.html
网站建设、网络推广公司-快上网,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 快上网