1.概要
我遇到的问题主要是，在部署的时候老的pod都是正常的，但是新部署的pod由于参数等配置错了，其实启动是有问题的。但是新的pod在启动3秒以后就把老的pod给干掉了，错误判断属于正常启动，然后几秒以后新的pod又挂了，导致运维的时候出现服务无法访问的情况。
同时当你使用 Kubernetes 的时候，有没有遇到过 Pod 在启动后一会就挂掉然后又重新启动这样的恶性循环？你有没有想过 Kubernetes 是如何检测 pod 是否还存活？虽然容器已经启动，但是 Kubernetes 如何知道容器的进程是否准备好对外提供服务了呢？让我们通过 Kubernetes 官网的这篇文章 Configure Liveness and Readiness Probes，来一探究竟。
本文将展示如何配置容器的存活和可读性探针。
2.探针类型
2.1. liveness probe（存活探针）
Kubelet 使用 liveness probe（存活探针）来确定何时重启容器。例如，当应用程序处于运行状态但无法做进一步操作，liveness 探针将捕获到 deadlock，重启处于该状态下的容器，使应用程序在存在 bug 的情况下依然能够继续运行下去（谁的程序还没几个 bug 呢）。
2.2. readiness probe（就绪探针）
Kubelet 使用 readiness probe（就绪探针）来确定容器是否已经就绪可以接受流量。只有当 Pod 中的容器都处于就绪状态时 kubelet 才会认定该 Pod 处于就绪状态。该信号的作用是控制哪些 Pod 应该作为 service 的后端。如果 Pod 处于非就绪状态，那么它们将会被从 service 的 load balancer 中移除。
最关键的是，一个新的pod处于就绪状态以后，老的pod就会被杀掉，所以就绪状态前需要确保真的就绪
3.探针配置参数
Probe 中有很多精确和详细的配置，通过它们你能准确的控制 liveness 和 readiness 检查：
initialDelaySeconds：容器启动后第一次执行探测是需要等待多少秒。periodSeconds：执行探测的频率。默认是 10 秒，最小 1 秒。timeoutSeconds：探测超时时间。默认 1 秒，最小 1 秒。successThreshold：探测失败后，最少连续探测成功多少次才被认定为成功。默认是 1。对于 liveness 必须是 1。最小值是 1。failureThreshold：探测成功后，最少连续探测失败多少次才被认定为失败。默认是 3。最小值是 1。
4.配置实例
4.1. liveness probe（存活探针）
- deployment配置
等待30s再开始检测是否重启
- restart以后情况
可以看到新启动的pod在3秒内就已经running并且就绪状态(1/1)；这样的话老的pod就被关闭了；但是实际上，新的pod是有问题的，连接不上consul
存活探针设置为30以后，迭代式启动的等待时间就延长了，本来先要起来一个pod，然后30s等待存活，只有这个进程活了才能启动下一个pod,两个pod相差大概40s：
4.2. readiness probe（就绪探针）
- deployment配置
等待30s再开始检测就绪
exec必须配置，不然没有效果
- restart以后情况
由于新的pod是有问题的，连接不上consul，所以当然是不希望能取代已经正常的老的pod；可以看到就绪探针起到效果了，37s的时候还没有就绪，因为内部已经报错了，连接consul异常；这样就导致了一直重启。
这也是我要的状态：新的pod留够缓冲时间来判断是否正常，如果30s还没有正常启动，那么就有问题了
5.http探针配置
