应用上云CKE（Kubernetes）探针配置指南

应用上云CKE（Kubernetes）探针配置指南

CKE Kubernetes

通过CKE，我们可以在联通统一资源池上，创建个人或项目独占的Kubernetes集群，拥有自己的虚拟网络和存储。基于该云环境来建设云原生的应用。

对于一个已经开发完善的应用程序或通用组件，我们如何充分利用云平台的能力，以面向云原生的方式来部署上云？除基本的cpu、内存外，Kubernetes还提供了一个很好的特性：Probe (探针)，以此我们可以利用较好的云平台自身的功能来保障应用的可持续服务和自动化部署运行的能力。

1. 探针目的

平台基于用户配置的检测方法(包括频率, 次数)，来观察应用的状态，以此判断应用是否正常运行或服务。当应用检测失败，即判定不能正常服务时，进入重启流程。此时根据重启策略，进行应用的重新调度部署。

因为应用部署需要的配置文件、环境变量、可执行文件及依赖库等均已具备，部署和启动已无需人工干预。

2. 探针类型

Kubernetes新版，从1.18开始，正式具备了三种探针：* liveness probe: 存活探针, 用来检测应用是否正常运行，是否是否僵死无响应 * readiness probe: 就绪探针, 用来检测应用是否具备对外提供服务, 比如一个后端应用，但数据库不具备时，通常情况下后端无法对外提供服务。* startup probe: 启动探针, 用来检测应用是否初始化启动完成。

其中存活探针和就绪探针，在应用的整个运行生命周期中，都会不间断运行。启动探针则只在应用启动时运行，并且探测成功后，由存活探针和就绪探针接管。

存活探针也可以起到检测服务是否启动完成的作用，但由于存活探针不仅是在启动时运行，在其他时间也运行。如果配置的检测周期时间短，则可能会存在启动尚未完成，就判定探测失败。如果配置时间过长，不健康服务的检测周期则变长，导致故障的恢复时间变长。

如Kafka的多个Broker，其中某个失败，需要重新调度，在进程运行后，需要内部先同步其他Borker的数据，只有同步完成后，才能对外提供服务。但同步的时间，根据数据量的不同，并不能恒定在某个具体的值。采用存活探针，配某个具体的值都不合适。

其他Redis等有状态的应用、或启动需要做时间不确定的数据加载、初始化的应用都类似如此。

因此, Kubernetes 在v1.16推出了startup启动探针，在启动探针的检测成功前, 存活探针和就绪探针并不会运行。

3.探针的检测方式

Kubernetes与CCS服务一样，具备三种检测方式：

• Command模式：在容器内执行指定命令, 需要容器镜像中具备该命令, 当命令执行完成后退出时, 返回码为0则判定检测成功

• TCP模式：暂不支持UDP，对容器IP地址上的，指定端口执行TCP链接检测，当链接成功，即端口被监听时，判定检测成功

• HTTP Get模式：对容器IP地址（或指定host）上的指定端口和路径，执行http get请求。如果http响应的状态码在大于等于200并小于400，则判定为成功。如果状态码是3xx，则重定向次数不能大于10次(参见代码：https://github.com/kubernetes/kubernetes/blob/1e11e4a2108024935ecfcb2912226cedeafd99df/pkg/probe/http/http.go#L145)

4.探针检测的结果

• Success：检测完成且判定成功，根据类型决定下一步

• Failed: 检测完成且判定失败, 根据失败次数进行后一步工作

• Unknown: 检测未完成, 不会采取任何行为

• Warning: 内部使用，逻辑上成功，但包含额外debug信息

参见: https://github.com/kubernetes/kubernetes/blob/v1.19.3/pkg/probe/probe.go

1. 启动探针在指定的失败次数后，将根据restartPolicy策略(默认为：Always)，重新设置pod状态，重新调度或标记为Failed。在检测成功后，将停止检测，并启动存活探针和就绪探针。

2. 存活探针在失败指定次数后，将重启容器。

3. 就绪探针在失败指定次数后，service等上层或网关将停止API流量的分配。

如果各探针在pod定义时，未进行配置，则默认为成功。在容器崩溃、异常退出时，Kubernetes依然会重新启动改容器。

5. 探针配置

通用配置

• initialDelaySeconds: 容器启动后要等待多少秒后，探针才初始化开始进行检测, 默认值0，最小值0

• periodSeconds：探针执行的间隔周期，单位秒，默认值10，最小值1

• successThreshold：在检测失败后，判定成功的检测次数。默认值1，最小值1。存活探针和启动探针，值为1

• failureThreshold：在检测成功后，判定失败的检测次数。默认值3，最小值1。

• timeoutSeconds：探针执行的超时时间，默认值1，最小值1

样例：

startupProbe: httpGet: path:/health port: 8080 failureThreshold: 30 periodSeconds:10livenessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 5 periodSeconds:5readinessProbe: tcpSocket: port: 8080 initialDelaySeconds: 5 periodSeconds:10

6. 探针的最佳实践

对于服务类应用程序：

* 如果是无状态应用程序，可以简单的配置端口是否监听，即用基于tcpSocket的启动探针，先判断容器是否正常启动，然后用存活探针,一般是httpGet判断不含业务服务的接口是否正常，最后用httpGet来判定某个业务接口是否正常, 如果正常则承载业务流量。

* 如果是有状态应用程序，可以通过exec方式，来检测应用是否初始化完成，达到可以对外服务的状态, 在此之后进行存活探针和就绪探针的检测。在构建容器镜像时，需要注意容器内具备对应的命令。启动探针的间隔时间可以设置的短一些，检测次数可以设置的长一些。这样既可以保障启动完成，又可以快速进入存活和就绪探针的检测。