在之前的文章中, 介绍了搭建好的#minikube#环境,如果你现在还没有一个可用的minikube环境, 那么可以去该篇文章中直接下载;

在之前的文章中, 先后介绍了如何从源代码开始构建一个Node.js应用和Spring Boot 应用, 并且部署到Kubernetes 中(这个Kubernetes 环境主要是之前建好的#minikube#) , 现在我们开始进一步深入的学习Kubernetes, 用一个个可以实际运行的例子的形式, 深入理解#Kubernetes#的概念以及原理.

在#动手动脑学Kubernetes#系列教程中, 我们展示了Kubernetes的基本用法

在第一篇里, 学习了Pod的基本知识;

在第二篇里, 学习了标签(Label)的语法, 使用Label来选择和过滤Kubernetes 资源;

在第三篇里, 介绍了Deployment的使用, 介绍了Deployment与Replica Set、Pod的关系, 并展示了如何进行应用的版本回滚;

在第四篇里, 介绍了Service的使用,使用Replication Controller创建Pod, 并创建Service, 展示了从Service 调用应用的方法; 随后又展示了扩展 Pod的数量为2, 比较了Service和之前的不同, 基本展示了Cluster IP 类型的Service的基本用法.

在第五篇里, 介绍了Namespace的使用, 除了创建,列出系统的Namespace之外, 还说明Namespace 如何对资源进行隔离, 建立Development, Staging, Production等环境的方法.

在第六篇里, 介绍了Service Discovery的使用, 讲解了如何检查Kube-dns, 如何检查和使用Service的FQDN等知识, 对Kubernetes的DNS 系统有整体的理解.

在第七篇里, 介绍了Port Forwards, 端口转发的用法, 在本地程序开发的时候, 使用端口转发可以简化本地测试的工作, 同时介绍了其他几种本地端口转发的用法.

在这篇中,我们将介绍Probe探针, 也就是用来做Health Check, 了解探针的基本用法, 继续愉快地学习吧!

为了验证Pod中的容器是否健康,并且可以对外提供服务，Kubernetes提供了多种健康检查机制。 健康检查, 在Kubernetes 中称之为probes, 中文名称为探针,由kubelet执行，用来决定何时重新启动容器（对于livenessProbe），而且Service(服务)和Deployment(部署)都使用probes 来用于确定关联的Pod是否应该接收流量（对于ReadinessProbe）。

接下来，我们将重点介绍HTTP的健康状况检查。 请注意，应用程序开发人员有责任公开一个可以检查的URL(/health)，kubelet可以使用该URL来确定容器是否正常（并可能已准备就绪）。

从镜像开始

下面我们首先创建一个Pod, 并暴露一个/health端口, 状态返回码为HTTP 200.

Github网址:

https://raw.githubusercontent.com/hintcnuie/kbe/main/specs/healthz/pod.yaml

文件内容:

apiVersion: v1
kind: Pod
metadata:
  name: hc
spec:
  containers:
  - name: sise
    image: quay.io/openshiftlabs/simpleservice:0.5.0
    ports:
    - containerPort: 9876
    livenessProbe:
      initialDelaySeconds: 2
      periodSeconds: 5
      httpGet:
        path: /health
        port: 9876

创建:

$ kubectl apply -f https://raw.githubusercontent.com/hintcnuie/kbe/main/specs/healthz/pod.yaml
pod/hc created

注意,我们在上面的Pod 定义里面, 增加了如下一段:

    livenessProbe:
      initialDelaySeconds: 2
      periodSeconds: 5
      httpGet:
        path: /health
        port: 9876

这一段的意思是, Kubernetes在Pod 初始化之后2秒钟, 之后每隔5秒钟, 会调用GET 请求, 最后面两行是Kubernetes 访问的端口和网址.

查看健康检查信息

下面我们来查看一下健康状态信息.

先调用一下这个/health端口:

$ kubectl exec hc -- curl http://localhost:9876/health
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    17  100    17    0     0   3202      0 --:--:-- --:--:-- --:--:--  3400{"healthy": true}

再来看看详细情况:

$ kubectl describe pod hc
Name:         hc
Namespace:    default
Priority:     0
Node:         localhost.localdomain/10.0.2.15
Start Time:   Sat, 13 Mar 2021 14:54:32 +0000
Labels:       <none>
Annotations:  <none>
Status:       Running
IP:           172.17.0.10
IPs:
  IP:  172.17.0.10
Containers:
  sise:
    Container ID:   docker://27bc4c032d91cbe71cd85b6d3b9105700e9917946b5d0332b2d7989c3e7fdf8f
    Image:          quay.io/openshiftlabs/simpleservice:0.5.0
    Image ID:       docker-pullable://quay.io/openshiftlabs/simpleservice@sha256:72bfe1acc54829c306dd6683fe28089d222cf50a2df9d10c4e9d32974a591673
    Port:           9876/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Sat, 13 Mar 2021 14:54:33 +0000
    Ready:          True
    Restart Count:  0
    Liveness:       http-get http://:9876/health delay=2s timeout=1s period=5s #success=1 #failure=3
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-q77th (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  default-token-q77th:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-q77th
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                 node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  21m   default-scheduler  Successfully assigned default/hc to localhost.localdomain
  Normal  Pulled     21m   kubelet            Container image "quay.io/openshiftlabs/simpleservice:0.5.0" already present on machine
  Normal  Created    21m   kubelet            Created container sise
  Normal  Started    21m   kubelet            Started container sise

可以看到, 跟之前的Describe 命令不一样的是, 这个Pod 的最后面, 增加了一些Event 信息:

Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  21m   default-scheduler  Successfully assigned default/hc to localhost.localdomain
  Normal  Pulled     21m   kubelet            Container image "quay.io/openshiftlabs/simpleservice:0.5.0" already present on machine
  Normal  Created    21m   kubelet            Created container sise
  Normal  Started    21m   kubelet            Started container sise

上面这个Pod 的健康状态是好的,下面来模拟一个有问题的Pod.

"坏"的Pod 健康检查

下面我们来创建一个'坏'的Pod, 这个Pod里面的程序, 在访问的时候, 会在1~4秒之间随机挑选一个数值,当挑选出这个数值之后, 应用就会在该时间段(秒)内不返回HTTP 200, 也就是说应用看起来像是出错了一样.

先来看看这个Pod的定义.

Github地址:

https://raw.githubusercontent.com/hintcnuie/kbe/main/specs/healthz/badpod.yaml

文件内容:

apiVersion: v1
kind: Pod
metadata:
  name: badpod
spec:
  containers:
  - name: sise
    image: quay.io/openshiftlabs/simpleservice:0.5.0
    ports:
    - containerPort: 9876
    env:
    - name: HEALTH_MIN
      value: "1000"
    - name: HEALTH_MAX
      value: "4000"
    livenessProbe:
      initialDelaySeconds: 2
      periodSeconds: 5
      httpGet:
        path: /health
        port: 9876

可以看到, 在这个文件里面多了两个环境变量, 程序通过这两个min 和max 的值来控制不返回健康代码的时间段.

创建:

$ kubectl apply -f https://raw.githubusercontent.com/hintcnuie/kbe/main/specs/healthz/badpod.yaml
pod/badpod created
$ kubectl get pods 
NAME                                    READY   STATUS    RESTARTS   AGE
badpod                                  1/1     Running   0          43s
hc                                      1/1     Running   1          13h

检查下这个badpod的事件信息:

$ kubectl describe pod badpod
Name:         badpod
Namespace:    default
Priority:     0
Node:         localhost.localdomain/10.0.2.15
Start Time:   Sun, 14 Mar 2021 04:03:10 +0000
Labels:       <none>
Annotations:  <none>
Status:       Running
IP:           172.17.0.11
IPs:
  IP:  172.17.0.11
Containers:
  sise:
    Container ID:   docker://e0393fcc79e00caf0c0bc7c49730249141e2a6adc79ceab5d3b8a65dd82405b1
    Image:          quay.io/openshiftlabs/simpleservice:0.5.0
    Image ID:       docker-pullable://quay.io/openshiftlabs/simpleservice@sha256:72bfe1acc54829c306dd6683fe28089d222cf50a2df9d10c4e9d32974a591673
    Port:           9876/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Sun, 14 Mar 2021 04:06:54 +0000
    Last State:     Terminated
      Reason:       Error
      Exit Code:    137
      Started:      Sun, 14 Mar 2021 04:06:09 +0000
      Finished:     Sun, 14 Mar 2021 04:06:54 +0000
    Ready:          True
    Restart Count:  5
    Liveness:       http-get http://:9876/health delay=2s timeout=1s period=5s #success=1 #failure=3
    Environment:
      HEALTH_MIN:  1000
      HEALTH_MAX:  4000
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-q77th (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  default-token-q77th:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-q77th
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                 node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason     Age                    From               Message
  ----     ------     ----                   ----               -------
  Normal   Scheduled  4m13s                  default-scheduler  Successfully assigned default/badpod to localhost.localdomain
  Normal   Killing    2m30s (x3 over 4m)     kubelet            Container sise failed liveness probe, will be restarted
  Normal   Pulled     2m (x4 over 4m13s)     kubelet            Container image "quay.io/openshiftlabs/simpleservice:0.5.0" already present on machine
  Normal   Created    2m (x4 over 4m13s)     kubelet            Created container sise
  Normal   Started    2m (x4 over 4m13s)     kubelet            Started container sise
  Warning  Unhealthy  115s (x10 over 4m10s)  kubelet            Liveness probe failed: Get "http://172.17.0.11:9876/health": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

z在最后一行, 可以看到在probe检查的时候, 发现了一次失败. 再查看一次, 会发现kubelet 已经开始采取行动,重启了容器:

Events:
  Type     Reason     Age                     From               Message
  ----     ------     ----                    ----               -------
  Normal   Scheduled  7m15s                   default-scheduler  Successfully assigned default/badpod to localhost.localdomain
  Normal   Killing    5m32s (x3 over 7m2s)    kubelet            Container sise failed liveness probe, will be restarted
  Normal   Pulled     5m2s (x4 over 7m15s)    kubelet            Container image "quay.io/openshiftlabs/simpleservice:0.5.0" already present on machine
  Normal   Created    5m2s (x4 over 7m15s)    kubelet            Created container sise
  Normal   Started    5m2s (x4 over 7m15s)    kubelet            Started container sise
  Warning  Unhealthy  4m57s (x10 over 7m12s)  kubelet            Liveness probe failed: Get "http://172.17.0.11:9876/health": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
  Warning  BackOff    2m9s (x5 over 2m47s)    kubelet            Back-off restarting failed container

还可以通过kubectl get pods的状态, 来检查Pod的健康状态:

$ kubectl get pods
NAME                                    READY   STATUS             RESTARTS   AGE
badpod                                  0/1     CrashLoopBackOff   6          9m8s
hc                                      1/1     Running            1          13h
$ kubectl get pods
NAME                                    READY   STATUS             RESTARTS   AGE
badpod                                  1/1     Running            9          16m
hc                                      1/1     Running            1          13h

查看两次, 能看到badpod 的RESTARTS, 也就是重启次数, 已经很多了, 而且在第一次的时候还能看到badpod 的状态是CrashLoopBackOff, 那么什么是CrashLoopBackOff呢?

CrashLoopBackOff 是Pod 里面的一种事件, CrashloopBackOff意味着有一个pod开始，崩溃，再次开始，然后再次崩溃。

Pod 规范里面有一个restartPolicy字段，restartPolicy是指在同一个节点(Node)上的kubelet重新启动容器的策略, 其可能的值包括Always，OnFailure和Never，这个值适用于Pod中的所有容器。, 默认值为Always;因此，如果把这个pod重新安排在其他节点上，则重新启动计数就会重置。

失败的容器会被由kubelet重启启动, 启动的时间是指数级退避延迟(back-off delay), 指数级别退避延迟就是指, 第一次会延迟10s,第二次20s，第三次40s,等等, 最多五分钟; 并且在成功执行十分钟后重置。

试试readinessProbe

上一个例子里面, 用的是livenessProbe, 现在我们来看看readinessProbe的用法吧.

一个readinessProbe，它可以以相同的方式配置，但具有不同的用例和语义：它用于检查容器在容器中的启动阶段(start-up)。 想象一个容器从外部存储（例如S3）或需要初始化某些表的数据库中加载一些数据。 在这种情况下，您要发信号通知容器何时可以为交通服务。

先来看看Pod:

Github地址:

https://raw.githubusercontent.com/hintcnuie/kbe/main/specs/healthz/ready.yaml

文件内容:

apiVersion: v1
kind: Pod
metadata:
  name: ready
spec:
  containers:
  - name: sise
    image: quay.io/openshiftlabs/simpleservice:0.5.0
    ports:
    - containerPort: 9876
    readinessProbe:
      initialDelaySeconds: 10
      httpGet:
        path: /health
        port: 9876

创建Pod:

$ kubectl apply -f https://raw.githubusercontent.com/hintcnuie/kbe/main/specs/healthz/ready.yaml
pod/ready created
$ kubectl get pods ready
NAME    READY   STATUS    RESTARTS   AGE
ready   1/1     Running   0          16s

来看一下这个Pod 的状态:

Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  default-token-q77th:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-q77th
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                 node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age    From               Message
  ----    ------     ----   ----               -------
  Normal  Scheduled  7m11s  default-scheduler  Successfully assigned default/ready to localhost.localdomain
  Normal  Pulled     7m11s  kubelet            Container image "quay.io/openshiftlabs/simpleservice:0.5.0" already present on machine
  Normal  Created    7m11s  kubelet            Created container sise
  Normal  Started    7m11s  kubelet            Started container sise

从条件(Condition)里可以看到ContainersReady和PodScheduled都变成True.

操作部分就写到这里, 下面我们来学习一下Kubernetes Probe 相关的知识.

Kubernetes 容器探针

Probe 是由 kubelet 对容器执行的定期诊断。 要执行诊断，kubelet 调用由容器实现的 Handler （处理程序）。有三种类型的处理程序：

• ExecAction： 在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
• TCPSocketAction： 对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开，则诊断被认为是成功的。
• HTTPGetAction： 对容器的 IP 地址上指定端口和路径执行 HTTP Get 请求。如果响应的状态码大于等于 200 且小于 400，则诊断被认为是成功的。

我们上面的例子,用的就是HTTPGetAction类型的探针.

每次探测都将获得以下三种结果之一：

• Success（成功）：容器通过了诊断。
• Failure（失败）：容器未通过诊断。
• Unknown（未知）：诊断失败，因此不会采取任何行动。

针对运行中的容器，kubelet 可以选择是否执行以下三种探针，以及如何针对探测结果作出反应：

• livenessProbe--存活探测器：指示容器是否正在运行。如果存活态探测失败，则 kubelet 会杀死容器， 并且容器将根据其重启的策略决定未来。如果容器不提供存活探针， 则默认状态为 Success。

kubelet 使用存活探测器来知道什么时候要重启容器。 例如，存活探测器可以捕捉到死锁（应用程序在运行，但是无法继续执行后面的步骤）。 这样的情况下重启容器有助于让应用程序在有问题的情况下更可用。

容器重启的策略, 这就是我们上面说的restartPolicy字段:

Pod 规范里面有一个restartPolicy字段，restartPolicy是指在同一个节点(Node)上的kubelet重新启动容器的策略, 其可能的值包括Always，OnFailure和Never，这个值适用于Pod中的所有容器。, 默认值为Always;因此，如果把这个pod重新安排在其他节点上，则重新启动计数就会重置。

• readinessProbe--就绪探测器：指示容器是否准备好为请求提供服务。如果就绪态探测失败， 端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。 初始延迟之前的就绪态的状态值默认为 Failure。 如果容器不提供就绪状态探针，则默认状态为 Success。

有时候，应用程序会暂时性的不能提供通信服务。 例如，应用程序在启动时可能需要加载很大的数据或配置文件，或是启动后要依赖等待外部服务。 在这种情况下，既不想杀死应用程序，也不想给它发送请求。 Kubernetes 提供了就绪探测器来发现并缓解这些情况。 容器所在 Pod 上报还未就绪的信息，并且不接受通过 Kubernetes Service 的流量。

当一个 Pod 里面的所有容器都准备好了，才能把这个 Pod 看作就绪了。 这种信号的一个用途就是, 控制哪一个 Pod 作为 Service 的后端。 在 Pod 还没有准备好的时候，会从 Service 的负载均衡器中被剔除的。

• startupProbe--启动探测器: 指示容器中的应用是否已经启动。如果提供了启动探针，则所有其他探针都会被 禁用，直到此探针成功为止。如果启动探测失败，kubelet 将杀死容器，而容器依其 重启策略进行重启。 如果容器没有提供启动探测，则默认状态为 Success。

有时候，会有一些现有的应用程序在启动时需要较多的初始化时间。 要不影响对引起探测死锁的快速响应，这种情况下，设置存活探测参数是要技巧的。 技巧就是使用一个命令来设置启动探测，针对HTTP 或者 TCP 检测，可以通过设置 failureThreshold * periodSeconds 参数来保证有足够长的时间应对糟糕情况下的启动时间。

kubelet 使用启动探测器可以知道应用程序容器什么时候启动了。 如果配置了这类探测器，就可以控制容器在启动成功后再进行存活性和就绪检查， 确保这些存活、就绪探测器不会影响应用程序的启动。 这可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被杀掉。

下面是一个慢启动容器的启动探测器的例子：

ports:
- name: liveness-port
  containerPort: 8080
  hostPort: 8080

livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 1
  periodSeconds: 10

startupProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 30
  periodSeconds: 10

幸亏有启动探测，应用程序将会有最多 5 分钟(30 * 10 = 300s) 的时间来完成它的启动。 一旦启动探测成功一次，存活探测任务就会接管对容器的探测，对容器死锁可以快速响应。 如果启动探测一直没有成功，容器会在 300 秒后被杀死，并且根据 restartPolicy 来设置 Pod 状态。

配置探测器

Probe 有很多配置字段，可以使用这些字段精确的控制存活和就绪检测的行为：

• initialDelaySeconds：容器启动后要等待多少秒后存活和就绪探测器才被初始化，默认是 0 秒，最小值是 0。
• periodSeconds：执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1。
• timeoutSeconds：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。
• successThreshold：探测器在失败后，被视为成功的最小连续成功数。默认值是 1。 存活和启动探测的这个值必须是 1。最小值是 1。
• failureThreshold：当探测失败时，Kubernetes 的重试次数。 存活探测情况下的放弃就意味着重新启动容器。 就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。

看了这么多容器的探针, 探针实际上就是对容器的状态的判断和检测, 因此下面我们来学习下容器的状态, 注意, 这个不是Pod的状态,而是Pod 里面的容器的状态

容器(Container)状态和回调

Kubernetes 会跟踪 Pod 中每个容器的状态，就像它跟踪 Pod 总体上的阶段一样。 你可以使用容器生命周期回调 来在容器生命周期中的特定时间点触发事件。

一旦调度器将 Pod 分派给某个节点，kubelet 就通过 容器运行时 开始为 Pod 创建容器。 容器的状态有三种：Waiting（等待）、Running（运行中）和 Terminated（已终止）。

要检查 Pod 中容器的状态，你可以使用 kubectl describe pod <pod 名称>。 其输出中包含 Pod 中每个容器的状态。

每种状态都有特定的含义：

• Waiting （等待）

如果容器并不处在 Running 或 Terminated 状态之一，它就处在 Waiting 状态。 处于 Waiting 状态的容器仍在运行它完成启动所需要的操作：例如，从某个容器镜像 仓库拉取容器镜像，或者向容器应用 Secret 数据等等。 当你使用 kubectl 来查询包含 Waiting 状态的容器的 Pod 时，你也会看到 Reason 字段，其中给出了容器处于等待状态的原因。

Kubernetes在启动容器之前, 会触发一个PostStart回调函数, 这个回调在容器被创建之后立即被执行。 但是，不能保证回调会在容器入口点（ENTRYPOINT）之前执行, 而且这个回调里面没有参数传递给处理程序。

• Running（运行中）

Running 状态表明容器正在执行状态并且没有问题发生。 如果配置了 postStart 回调，那么该回调已经执行且已完成。 如果你使用 kubectl 来查询包含 Running 状态的容器的 Pod 时，你也会看到 关于容器进入 Running 状态的信息。

• Terminated（已终止）

处于 Terminated 状态的容器已经开始执行并且或者正常结束或者因为某些原因失败。 如果你使用 kubectl 来查询包含 Terminated 状态的容器的 Pod 时，你会看到 容器进入此状态的原因、退出代码以及容器执行期间的起止时间。

如果容器配置了 preStop 回调，则该回调会在容器进入到Terminated 状态之前执行。

好了, 本篇内容就介绍到这里.

回顾

本篇文章中介绍了Kubernetes中探针的使用, 并介绍了存货探针和就绪探针的基本使用方法, 并在最后介绍了Pod中的三种探针的定义, 以及使用场景.

探针是维护应用程序的重要方法, 也是在Kubernetes里面检测Pod中应用程序存活的重要工具, 需要在开发阶段就提供好对应的接口,并且公开返回码, 这有利于后期应用程序在Kubernetes 中的维护.

学习不能停止!