MLSQL针对K8s增加liveness和readiness 探针

2.1.0-SNAPSHOT 及以上版本可用

系统运行中，最怕的就是僵而不死，亦或是进程活着，但已经对外失去了真实的服务能力,这些都属于liveness的范畴。

僵而不死在现阶段的计算机体系中，唯一解决方案是连接超时后直接认为对方死了。典型的比如Java进程一直 处于full GC状态，虽然进程还在，但其实已经僵死。K8s可以检测超时后，迅速的认为他死掉，然后重启。

进程活着，也能访问，不超时，但依然可能失去服务能力。比如对于MLSQL而言，可能MLSQL Driver活的的好好的，也能处理请求，但是内部的SparkContext挂了（失去了对所有executor分发任务的能力），这个时候系统已经无法正确的完成外部提交的任务了,所以我们认为他的liveness应该是处于Down的状态，需要让k8s检测到，并且迅速的重启。

第二个是readiness问题，一个非常典型的情况是，虽然服务已经对外打开了http端口，但其实初始化还没完成。此时，如果有请求过来，要么被阻塞，要么可能导致系统初始化异常。我们需要告诉K8s,啥时候我是ready的，可以把请求分发给我了。

为此，MLSQL 专门为K8s提供上述两种探针接口。

Liveness探针

对应接口为

http://.../health/liveness

如果处于可用状态，返回200,结果如下：

// 20201029141025
// http://127.0.0.1:9003/health/liveness

{
  "status": "UP",
  "components": {
    "livenessProbe": {
      "status": "UP"
    }
  }
}

如果系统不可用，返回500,结果如下：

// 20201029141025
// http://127.0.0.1:9003/health/liveness

{
  "status": "DOWN",
  "components": {
    "livenessProbe": {
      "status": "DOWN"
    }
  }
}

Readiness探针

对应接口为

http://..../health/readiness

如果已经初始化完成，处于可用状态，返回200,结果如下：

// 20201029141214
// http://127.0.0.1:9003/health/readiness

{
  "status": "IN_SERVICE",
  "components": {
    "readinessProbe": {
      "status": "IN_SERVICE"
    }
  }
}

如果系统还未初始化完成，返回503,结果如下：

// 20201029141214
// http://127.0.0.1:9003/health/readiness

{
  "status": "OUT_OF_SERVICE",
  "components": {
    "readinessProbe": {
      "status": "OUT_OF_SERVICE"
    }
  }
}