存活指针的作用

对于在生产中运行的pod， 一定要定义一个存活探针。没有探针的话，Kubenetes无法知道你的应用是否还活着。只要进程还在运行， Kubemetes会认为容器是健康的。存活探针可以告诉k8s容器是不健康的。

简易的存活探针仅仅检查了服务器是否响应。虽然这看起来可能过于简单， 但即使是这样的存活探针也可以创造奇迹，因为如果容器内运行的web服务器停止响应HTTP请求，它将重启容器。 与没有存活探针相比，这是一项重大改进，而且在大多数情况下可能已足够。

但为了更好地进行存活检查， 需要将探针配置为请求特定的URL路径（例如/health), 并让应用对内部运行的所有重要组件执行状态检查，以确保它们都没有终止或停止响应。

存活探针不应消耗太多的计算资源，并且运行不应该花太长时间 。默认情况下，探测器执行的频率相对较高，必须在一秒之内执行完毕。 一个过重的探针会大大减慢容器运行。

---

使用案例

apiVersion: v1
kind: Pod
metadata:
  name: kubia-liveness
spec:
  containers:
  - name: kubia
    image: luksa/kubia-unhealthy
    livenessProbe:
      httpGet:
        path: /
        port: 8080
      # k8s会在第一次探测前等待15
      initialDelaySeconds: 15

kubia-unhealthy该镜像会自动在访问第5次以后报错500。

Liveness: http-get http://:8080/ delay=0s timeout=1s period=10s #success=1 #failure=3

• delay0s表示容器启动后立即探测
• timeout 容器必须在1s内响应
• period 容器每10s探测一次
• failure 连续3次失败后重启

---

总结要点

• 保持探针轻量
• 无须在探针中实现重试循环
• 编写供探针使用的接口（例如：/health）

容器的重启由节点上的Kubelet执行，所以如果节点异常终止，它将无法执行任何操作。为了确保应用程序在另一个节点上重启，需要使用ReplicationController或类似机制管理pod。