做园区门户网站的需求分析,网站标题title,南宁seo外包服务,wordpress cms主题1. 荒腔走板最近一两个月生产K8s集群频繁出现短时503 Service Temporarily Unavailable#xff0c;还不能主动复现#xff0c;相当郁闷#xff0c;压力山大。HTTP 5xx响应状态码用于定义服务端错误。500 Internal Server Error#xff1a;所请求的服务器遇到意外的情况并阻… 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、弱依赖于impalaimpala即使连不上只是不能查站点sso订单相关的写入操作应该还可用。回想起前几天看到的k8s探针糟糕我们的就绪探针好像探测了impala// ASP.NetCore上暴露的的探测逻辑impala mongodb
services.AddHealthChecks().AddCheckImpalaHealthCheck(nameof(ImpalaHealthCheck), tags: new[] { readyz }).AddCheckMongoHealthCheck(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服务应该只探测强依赖强依赖有问题才表明容器未就绪这也是就绪探针的初衷。强烈建议根据webapp结构合理设置探针和探针参数避免不切实际的健康检查失败导致的频繁重启或服务下线。干货周边也很重要 硬核技能k8s初体验 Docker-HealthCheck指令探测ASP.NET Core容器健康状态 Kubernetes Liveness and Readiness Probes
