关于k8s中对于SpringBoot应用TCP类型的就绪探针不准确的问题发现

在K8s中我们知道可以使用Exec或TCP或HTTP对应用进行就绪探针检测和存活检测、以便K8s可以对应用进行平滑更新、升级、关停等。最近在K8s中部署SpringBoot应用，使用TCP 8080(应用端口)进行就绪探针检测，在更新应用时发现了一个问题。

由于该应用启动时间比较长，大概60s，K8s设定每15秒进行一次TCP就绪探针检测，发现进行应用更新过程中，新版本还未完全启动时便kill掉了老版本，导致应用出现大概35秒的时间不可用，使用kubectl get pod -w观察过程如下：

使用TCP Socket进行就绪探测：

NAME                                       READY   STATUS            RESTARTS   AGE
configcenter-6776d8df57-rx9jh              0/2     PodInitializing   0          13s
configcenter-88b79dbf9-k8fqr               2/2     Running           0          97m
configcenter-6776d8df57-rx9jh              0/2     Running           0          14s
configcenter-6776d8df57-rx9jh              1/2     Running           0          15s
configcenter-6776d8df57-rx9jh              2/2     Running           0          25s
configcenter-88b79dbf9-k8fqr               2/2     Terminating       0          97m
configcenter-88b79dbf9-k8fqr               0/2     Terminating       0          97m
configcenter-88b79dbf9-k8fqr               0/2     Terminating       0          97m
configcenter-88b79dbf9-k8fqr               0/2     Terminating       0          97m

可以发现新版本在25秒时状态已经变为Running状态，紧接着旧版本就处于Terminating状态，而实际上应用启动需要耗时60秒。这就出现了新版本还未真正就绪就杀死了旧版本Pod导致应用短时不可用现象。

使用HTTP进行就绪探测：

NAME                                       READY   STATUS            RESTARTS   AGE
configcenter-6776d8df57-rx9jh              2/2     Running           0          6m38s
configcenter-5c86fb6b57-fndqw              0/2     PodInitializing   0          2s
configcenter-5c86fb6b57-fndqw              0/2     Running           0          14s
configcenter-5c86fb6b57-fndqw              1/2     Running           0          15s
configcenter-5c86fb6b57-fndqw              2/2     Running           0          65s
configcenter-6776d8df57-rx9jh              2/2     Terminating       0          8m7s
configcenter-6776d8df57-rx9jh              0/2     Terminating       0          8m13s
configcenter-6776d8df57-rx9jh              0/2     Terminating       0          8m14s
configcenter-6776d8df57-rx9jh              0/2     Terminating       0          8m14s

发现这个问题后改为HTTP进行就绪探测，可以从上面的新旧版本Pod切换状态观察可以看出这次就是正常的，新版本在65秒时才是Running状态已经完全就绪，这时再杀死旧Pod已经完全没问题了。

原因猜测

没有深究这个问题，但是根据经验应该可以猜出大致问题所在：SpringBoot在启动过程中先启动了内置的Tomcat打开了应用8080端口，此时外部其实可以通过TCP进行连接这个端口了，而我们的Web应用还未就绪，HTTP请求也还进不来各种API服务还未提供。

总结

在K8s中部署SpringBoot应用，对应用进行就绪探针检测尽量使用HTTP类型更为准确，可以在应用中自己写一个/healthz接口（Google推荐这个接口名），或者可以通过加入监控包Prometheus提供默认的Http接口（xxx:8081/actuator/health）。

另外，如果项目出现OOM异常，使用TCP探针K8s也是无法检测到进行重启容器的。