从Kubernetes的探针到DevOps( 二 ) _Kubernetes

尽管像 Spring 这样的开发框架，已经提供了探针相关的功能，开发可能配置一下就能完成，但实际情况往往并不简单。例如 spring 文档说了：

The “liveness” Probe should not depend on health checks for external systems.

意思就是 liveness 探针不应当依赖外部系统的状态，但实际上有时这个外部系统的定义未必那么笃定；也可能我们的应用无法从某个外部系统的故障中恢复，所以即使是外部系统，我们可能也会将其纳入到 liveness 探针需要检查的范畴。
而且，很有可能我们不能一次做好这个事情，需要在结合实际出现的问题进行调整。如果开发没有参与运维，或者中间的沟通不畅，亦或者没把这件是当做自己的事情，这个探针的问题未必能简单的解决。
其实群里人家问的是探针的参数问题，但其实这些参数只是控制故障能多快的暴露出来，如果应用的探针本身就有问题，这些参数设置的再精妙都没有意义。我觉得这是许多团队的一种工作状态：我们部门自己能搞定的尽量不要依赖别的团队。例如，要是我能找到一个可观测工具，直接给我定位哪个pod出问题，那我还找什么开发。
实际上呢？太难了，做这样包治百病的工具太难了。不过，根据许多人的选择，我们知道这可能比让 Dev 和 Ops 高效的配合起来更简单，至少没那么绝望吧。
谨以本文给大家一个例子，希望大家能够互相体谅，保持一点 DevOps 的精神，高层领导也能意识到这个问题，看看怎么解决。再就是看看平台工程，是不是可以建设一个好的平台，让开发能够更轻松的直面这个问题，毕竟自己写的程序最了解。
参考

[1] 链式反应和级联故障:https://www.bilibili.com/video/BV13Q4y1K7FU/
[2] 2.9.2. Application lifecycle and Probes states:https://docs.spring.io/spring-boot/docs/2.4.1/reference/html/production-ready-features.html#production-ready-kubernetes-probes-external-state
[3] 探针对于伸缩的意义和一些参数说明https://yylives.cc/2023/02/25/kubernetes-probes-and-why-they-matter-for-autoscaling/

【从Kubernetes的探针到DevOps】