关于《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-2.3镜像方案为什么要做多个layer》；
- 《设置非root账号不用sudo直接执行docker命令》；
- 《开发阶段，将SpringBoot应用快速部署到K8S》；
SpringBoot容器探针系列文章简介
为了让应用更适应容器化环境，SpringBoot2.3版本推出了新的探针技术，《掌握SpringBoot-2.3的容器探针》系列旨在与您一起学习和实践这些新技术，分为三个阶段： - 基础篇：即本文，对容器探针的相关知识点进行梳理和学习；
- 深入篇：继续深入学习探针相关的知识点；
- 实战篇：将springboot应用部署在kubernetes环境，并使用最新的探针技术；
探针特性的官方信息
- 如下图红框所示，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是否将外部请求调度到此容器上，这可是个很实用的功能！
还需要继续深入
面对上述三个问题您是否会感慨：看似简单的容器探针技术，想要用好还需掌握更多知识，接下来的文章中咱们一起努力吧，从知识覆盖到实战操练，终究会掌握这门实用技术；
欢迎访问我的GitHub
- 地址：https://github.com/zq2599/blog_demos
- 内容：原创文章分类汇总，及配套源码，涉及Java、Docker、K8S、DevOPS等
