掌握SpringBoot-2.3的容器探针:基础篇
欢迎访问我的GitHub
- 地址:https://github.com/zq2599/blog_demos
- 内容:原创文章分类汇总,及配套源码,涉及Java、Docker、K8S、DevOPS等
关于《SpringBoot-2.3容器化技术》系列
《SpringBoot-2.3容器化技术》系列,旨在和大家一起学习实践2.3版本带来的最新容器化技术,让咱们的Java应用更加适应容器化环境,在云计算时代依旧紧跟主流,保持竞争力;
全系列文章分为主题和辅助两部分,主题部分如下:
- 《体验SpringBoot(2.3)应用制作Docker镜像(官方方案)》;
- 《详解SpringBoot(2.3)应用制作Docker镜像(官方方案)》;
- 《掌握SpringBoot-2.3的容器探针:基础篇》;
- 《掌握SpringBoot-2.3的容器探针:深入篇》;
- 《掌握SpringBoot-2.3的容器探针:实战篇》;
- 辅助部分是一些参考资料和备忘总结,如下:
SpringBoot容器探针系列文章简介
为了让应用更适应容器化环境,SpringBoot2.3版本推出了新的探针技术,《掌握SpringBoot-2.3的容器探针》系列旨在与您一起学习和实践这些新技术,分为三个阶段:
探针特性的官方信息
-
如下图红框所示,2.3版本的容器探针特性早在预览版(v2.3.0.M4)就已经发布:
-
如今v2.3.0.RELEASE已发布,可以放心的学习和使用该特性了,首先把基础知识点列出来,确保准备工作OK;
知识点整理
下面是掌握探针技术所需的基础知识,也是本文的主要内容:
- kubernetes的存活探针livenessProbe;
- kubernetes的就绪探针readinessProbe;
- SpringBoot的actuator;
接下来逐个学习,有了这些知识积累,我们才能更好的阅读官方资料,开发适合自己业务场景的探针;
kubernetes的存活探针livenessProbe
- kubernetes的探针涉及的内容是很多的,这里只提和SpringBoot相关的部分;
- kubelet 使用存活探针livenessProbe来知道什么时候要重启容器;
- 下图是kubernetes官网的存活探针示例,几个关键参数已经做了详细说明:
- 可见如果我们的SpringBoot应用发布到kubernetes环境,只要应用还健康,livenessProbe对应的地址就要能响应200-400的返回码;
kubernetes的就绪探针readinessProbe
- 有时候,应用程序会暂时性的不能提供通信服务。例如,应用程序在启动时可能需要加载很大的数据或配置文件,或是启动后要依赖等待外部服务。在这种情况下,既不想杀死应用程序,也不想给它发送请求。Kubernetes 提供了就绪探测器来发现并缓解这些情况。容器所在 Pod 上报还未就绪的信息,并且不接受通过 Kubernetes Service 的流量。
- 就绪探测器的配置和存活探测器的配置相似,唯一区别就是要使用 readinessProbe字段,而不是 livenessProbe 字段;
- 简单的说,就绪探针正常的容器,k8s就认为是可以对外提供服务的,相应的请求也会被调度到该容器上来;
SpringBoot的actuator
- 简单来说,actuator是用来帮助用户监控和操作SprinBoot应用的,这些监控和操作都可以通过http请求实现,如下图,http://localhost:8080/actuator/health 地址返回的是应用的健康状态:
- 下面是常用的actuator地址,访问不同的地址可以得到不同的信息:
- 在SpringBoot-2.3版本中,actuator新增了两个地址:/actuator/health/liveness和/actuator/health/readiness,前者用作kubernetes的存活探针,后者用作kubernetes的就绪探针;
画外音:SpringBoot的探针技术就这点东西?
- 文章看到这里,您可能觉得索然无味:所谓的容器探针特性如此简单,新增两个actuator地址留给kubernetes的存活和就绪探针用,只要这两个地址响应正常,kubernetes就判定该容器正常;
- 大多数时候,上述结论并无不妥,SpringBoot官方给出的推荐配置如下图,我们只要照搬即可:
- 冷静下来仔细思考,有三个问题似乎没有解决:
-
首先,SpringBoot为kubernetes提供了两个actuator项,但是那些并未部署在kubernetes的SringBoot应用呢?用不上这两项也要对外暴露这两个服务地址吗?
-
其次,就绪探针是什么时候开始返回200返回码的?应用启动阶段,业务服务可能需要一段时间才能正常工作,就绪探针要是提前返回了200,那k8s就认为容器可以正常工作了,这时候把外部请求调度过来是无法正常响应的,所以搞清楚就绪探针的状态变化逻辑很重要;
-
最后,也是最重要的一点:有的场景下,例如外部依赖服务异常、本地全局异常等情况下,业务不想对外提供服务,等到问题解决后业务又可以对外提供服务了,如果此时我们能自己写代码控制就绪探针的返回码,那就做到了控制kubernetes是否将外部请求调度到此容器上,这可是个很实用的功能!
还需要继续深入
面对上述三个问题您是否会感慨:看似简单的容器探针技术,想要用好还需掌握更多知识,接下来的文章中咱们一起努力吧,从知识覆盖到实战操练,终究会掌握这门实用技术;