4.6.1 设置 exec 探针

exec 类型的探针通过在目标容器中执行由用户自定义的命令来判断容器的健康状态，若命令状态返回值为0则表示“成功”通过检测，其他值均为“失败”状态。“spec.containers.livenessProbe.exec” 字段用于定义此类检测，它只有一个可用属性“command”，用于指定要执行的命令。下面是定义在资源清单文件 liveness-exec.yaml 中的示例：

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec
  labels:
    test: liveness-exec
spec:
  containers:
  - name: liveness-exec-demo
    image: busybox
    args: ["/bin/sh", "-c", "touch /tmp/healthy; sleep 60; rm -rf /tmp/healthy; sleep 600"]
    livenessProbe:
      exec:
        command: ["test", "-e", "/tmp/healthy"]

上面的清单文件中定义了一个 Pod 对象，基于 busybox 镜像启动一个运行 touch /tmp/healthy; sleep 60; rm -rf /tmp/healthy; sleep 600 命令的容器，此命令在容器启动时创建 /tmp/healthy 文件，并于 60 秒之后将其删除。存活性运行探针“test -e /tmp/healthy” 命令检查 /tmp/healthy 文件的存在性，若文件存在则返回状态码0，表示成功通过测试。

首先，执行类似如下的命令，创建 Pod 对象 liveness-exec：

**[terminal]
**[delimiter $ ]**[command kubectl apply -f liveness-exec.yaml]
pod/liveness-exec created

在60秒之内使用 “kubectl describe pods/liveness-exec” 查看其详细信息，其存活性探测不会出现错误。而超过60秒之后，再次运行“kubectl describe pods/liveness-exec” 查看其详细信息可以发现，存活性探测出现了规章，并且间隔更长一段时间之后再查看甚至还可以看到容器重启的相关信息。

Events:
  Type     Reason     Age                  From                              Message
  ----     ------     ----                 ----                              -------
  Normal   Scheduled  5m24s                default-scheduler                 Successfully assigned default/liveness-exec to kube-node-2.localdomain
  Normal   Pulling    90s (x3 over 5m23s)  kubelet, kube-node-2.localdomain  Pulling image "busybox"
  Normal   Pulled     90s (x3 over 5m22s)  kubelet, kube-node-2.localdomain  Successfully pulled image "busybox"
  Normal   Created    90s (x3 over 5m22s)  kubelet, kube-node-2.localdomain  Created container liveness-exec-demo
  Normal   Started    90s (x3 over 5m22s)  kubelet, kube-node-2.localdomain  Started container liveness-exec-demo
  Warning  Unhealthy  1s (x9 over 4m21s)   kubelet, kube-node-2.localdomain  Liveness probe failed:
  Normal   Killing    1s (x3 over 4m1s)    kubelet, kube-node-2.localdomain  Container liveness-exec-demo failed liveness probe, will be restarted

另外，输出信息的 “Containers” 一段中还清晰的显示了容器健康状态检测及状态变化的相关信息：容器当前处于“Running”状态，但前一次是为 “Terminated”，原因是退出码为 137 的错误信息，它表示进程是被外部信号所终止的，。137 事实上是由两部分数字之和生成的：128+signum，其中 signum 是导致进程终止的信号的数字标识，9表示SIGKILL，这意味着进程被强制终止的：

Containers:
  liveness-exec-demo:
    Container ID:  docker://ed245e553dd6a98f6e19a001420196a54886593ad1804752385d6763f8760bc3
    Image:         busybox
    Image ID:      docker-pullable://busybox@sha256:24fd20af232ca4ab5efbf1aeae7510252e2b60b15e9a78947467340607cd2ea2
    Port:          <none>
    Host Port:     <none>
    Args:
      /bin/sh
      -c
      touch /tmp/healthy; sleep 60; rm -rf /tmp/healthy; sleep 600
    State:          Running
      Started:      Fri, 06 Dec 2019 12:05:36 +0800
    Last State:     Terminated
      Reason:       Error
      Exit Code:    137
      Started:      Fri, 06 Dec 2019 12:03:36 +0800
      Finished:     Fri, 06 Dec 2019 12:05:36 +0800
    Ready:          True
    Restart Count:  4
    Liveness:       exec [test -e /tmp/healthy] delay=0s timeout=1s period=10s #success=1 #failure=3

待容器重启完成后再次查看，容器已经处于正常运行状态，直到文件再次被删除，存活性探测失败而重启。从下面的命令显示可以看出，liveness-exec 在 13 分钟内已然重启了 6 次：

**[terminal]
**[delimiter $ ]**[command kubectl get pods liveness-exec]
NAME            READY   STATUS    RESTARTS   AGE
liveness-exec   1/1     Running   6          13m

需要特别说明的是，exec 指定的命令运行于容器中，会消耗容器的可用资源配额，另外，考虑到探针操作的效率本身等因素，探针操作的命令应该尽可能简单和轻量。