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 && mongodb
services.AddHealthChecks()
.AddCheck<ImpalaHealthCheck>(nameof(ImpalaHealthCheck), tags: new[] { "readyz" })
.AddCheck<MongoHealthCheck>(nameof(MongoHealthCheck), tags: new[] { "readyz" });