今天差点因为一个YAML文件把我的血压送走。你说这年头，K8S用了这么久，居然还能有人犯这种低级错误，真让人怀疑他是不是把YAML当成了薛定谔的猫，写之前都不知道里面是个什么东西。
事情是这样的，早上接到监控告警，一个关键业务的Pod时不时地消失，然后又自动拉起来，就像得了间歇性失忆症。开始我还以为是节点资源不足，或者OOM Killer又出来搞事情了。结果登上去一看，CPU、内存都稳得很，日志里也没有OOM的痕迹。
这就有点意思了。Pod自己反复重启，那肯定得查探一下Deployment或者StatefulSet的配置。结果不看不知道，一看吓一跳。这位“大神”写的YAML文件，简直就是行为艺术。
我先不说他缩进乱得像狗啃的一样，光是那个livenessProbe和readinessProbe的配置，就能让人原地去世。他大概是觉得健康检查不重要，直接把initialDelaySeconds设置成了3600秒，periodSeconds设置成了7200秒。
好家伙，这是要让Pod启动一个小时之后再开始检查，而且每两个小时才检查一次？ 这Pod要是真出了问题，估计早就被用户骂上天了，还等着你来检查？更离谱的是，他还把failureThreshold设置成了9999。这是什么概念？意思是这个Pod得挂掉近一万次，才会被认为是不健康的？
我当时就想问问他，是不是觉得Pod有九条命？
我毫不客气地把他的YAML文件扔进了垃圾桶，然后自己重新写了一份。initialDelaySeconds改成了5秒，periodSeconds改成了10秒，failureThreshold设置成3。这样一来，Pod启动后5秒就开始健康检查，每10秒检查一次，如果连续三次检查失败，就会被认为是不健康的，然后K8S就会自动重启Pod。
改完之后，问题立刻解决了。Pod再也没有无故消失，业务也恢复了正常。
这件事告诉我一个深刻的道理：K8S的配置，特别是健康检查这种关键配置，绝对不能想当然。livenessProbe和readinessProbe的配置，直接关系到应用的可用性和稳定性。如果配置不合理，不仅不能及时发现问题，反而会掩盖问题，甚至引发更严重的故障。
记住，健康检查的目的是为了在问题发生时，能够快速定位和解决问题，而不是为了让问题变得更加隐蔽。对于这类配置，一定要深思熟虑，结合应用的实际情况进行设置，不能随便拍脑袋决定。
技术结论：
livenessProbe和readinessProbe的配置直接影响Pod的可用性。initialDelaySeconds应该根据应用的启动时间设置，periodSeconds应该根据应用的健康状况变化频率设置，failureThreshold应该根据应用的容错能力设置。永远不要想当然，要根据实际情况进行调整。YAML文件不是艺术品，它是生产力工具，写之前先搞清楚每个参数的含义。
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-container
image: my-image:latest
ports:
- containerPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
successThreshold: 1
readinessProbe:
httpGet:
path: /readyz
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
successThreshold: 1