最近需要写一个脚本，一次部署所有POD，测试中发现，有部分POD启动后由于连接依赖服务失败，而导致自身不能正常工作，使用kubelet get po查到的状态也是runing,使用netstat -anp |grep LISTEN ,查询到端口并没有监听。所以想，在app启动异常、并没能启动自身的端口的时候，自动重启一次POD。而k8s已经实现了这个功能，经测试，已经完全解决了我们的问题。以下参考网上的文档，做了一个总结：
  首先将一下关于K8S对于POD监控的两个探针

Liveness Probes

Kubernetes健康检查被分成 liveness和readiness probes。liveness probes是用来检测你的应用程序是否正在运行。通常情况下，你的程序一崩溃，Kubernetes就会看到这个程序已经终止，然后重启这个程序。但是liveness probes的目的就是捕捉到当程序还没有终止，还没有崩溃或者还没陷入死锁的情况。
例如：定义 TCP liveness probe

    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20
这里的意思是在pod创建15s后每隔20s检测8080端口是否正在使用

Readiness Probes

Readiness Probes跟liveness probes十分相似，只有失效检测的结果是不一样的。Readiness Probes是用来检查你的应用程序是否可以为通信服务。这跟liveness有些微妙的不同。比如，你的应用程序取决于数据库与memcached。如果上面两个都在良好状态，为你的应用提供通信，然后你就可以说这两个都是你的应用的“readiness”。

如果你的应用的readness probe运行失败，那么pod就会从组成service的端点被删除。这样的话，没有准备好的pods就不会有流量通信通过Kubernetes服务发现机制来发送给他们。

例如：定义 TCP readiness probe

    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
这里的意思同上，唯一的不同的意思是表明当前pod可以接受由服务发现导过来的流量了

Liveness Probes 和 Readiness Probes 可以一起使用：

apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
  - name: goproxy
    image: k8s.gcr.io/goproxy:0.1
    ports:
    - containerPort: 8080
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

Probe中有很多精确和详细的配置，通过它们您能准确的控制liveness和 readiness 检查：

initialDelaySeconds：容器启动后第一次执行探测是需要等待多少秒。
periodSeconds：执行探测的频率。默认是10秒，最小1秒。
timeoutSeconds：探测超时时间。默认1秒，最小1秒。
successThreshold：探测失败后，最少连续探测成功多少次才被认定为成功。默认是 1。对于 liveness必须是 1。最小值是 1。
failureThreshold：探测成功后，最少连续探测失败多少次才被认定为失败。默认是 3。最小值是 1。

总结

所以，大家在使用k8s的时候部署deployment或者ds的时候一定要做pod的监控，因为pod常常是不可预计的，所以我们想要它们按照我们想要的方式运行就需要我们手动的指定pod成功启动的标准，更多资料可以参考：

https://k8smeetup.github.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

http://dockone.io/article/1386