扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
这篇文章主要介绍“Kubernetes踩坑举例分析”,在日常操作中,相信很多人在Kubernetes踩坑举例分析问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”Kubernetes踩坑举例分析”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!
创新互联公司2013年开创至今,先为井冈山等服务建站,井冈山等地企业,进行企业商务咨询服务。为井冈山企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。
最近一两个月生产K8s集群频繁出现短时503 Service Temporarily Unavailable,还不能主动复现,相当郁闷,压力山大。
HTTP 5xx响应状态码用于定义服务端错误。
500 Internal Server Error:所请求的服务器遇到意外的情况并阻止其执行请求,通常针对单个请求,整个站点有时还是提供服务。 502 Bad Gateway Error 暗示 连接链路中某个服务器下线或者不可用; 503 Service Unavailable 意味着托管您的应用程序的实际Web服务器上存在问题。
impala连接问题
,大数据运维同事排查到
webapp发起impala的请求与impala集群时钟未对齐,导致webapp impalaODBC Driver连不上impala集群;进入k8s集群节点,确实部分节点的时钟对齐服务未启动,不定时出现比北京时间慢2,3分钟的情况,这个确实可以解释时间差导致的impala连接认证失败。
impala连接问题
,此处大数据同事未能定位具体原因,暂时定义为
偶发/抖动?
故障现场每次只有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连接,验证猜想。
bugfix不是我正向推断出来的,而是纯靠经验推演出来的,倒不是有明确推断思路,也算给大家提前踩坑了。
docker的健康检查只能探测,Kubernetes存活、就绪探针不仅有探测,还有决策能力。
这里我们的k8s就绪探测使用策略出现了问题:
探测到webapp弱依赖impala有问题,就下线了整个webapp服务,应该只探测强依赖,强依赖有问题,才表明容器未就绪,这也是就绪探针的初衷。
强烈建议根据webapp结构合理设置探针和探针参数,避免不切实际的健康检查失败导致的频繁重启或服务下线。
到此,关于“Kubernetes踩坑举例分析”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注创新互联网站,小编会继续努力为大家带来更多实用的文章!
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流