Kubernetes探针踩坑记

作者：小码甲 2020-09-15 08:46:26

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

让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：域名申请、网页空间、营销软件、网站建设、平舆网站维护、网站推广。

本文转载自微信公众号「Dotnet Plus」，可以通过以下二维码关注。转载本文请联系Dotnet Plus公众号。

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(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://cdbrznjsb.com/article/dpcpses.html