2020 kubernetes讲座（上）-CKA考试指南（九）容器探针Probe

时间：2023-06-28 01:00:01 | 来源：网站运营

时间：2023-06-28 01:00:01 来源：网站运营

2020 kubernetes讲座（上）-CKA考试指南（九）容器探针Probe：

什么是探针

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

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

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

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

Kubelet 可以选择是否执行在容器上运行的三种探针执行和做出反应：

• livenessProbe：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到重启策略的影响。如果容器不提供存活探针，则默认状态为 Success。
• readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success。
• startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探测(startup probe)，则禁用所有其他探测，直到它成功为止。如果启动探测失败，kubelet 将杀死容器，容器服从其重启策略进行重启。如果容器没有提供启动探测，则默认状态为成功Success。

PodSpec 中有一个 restartPolicy 字段，可能的值为 Always、OnFailure 和 Never。默认为 Always。 restartPolicy 适用于 Pod 中的所有容器。restartPolicy 仅指通过同一节点上的 kubelet 重新启动容器。失败的容器由 kubelet 以五分钟为上限的指数退避延迟（10秒，20秒，40秒…）重新启动，并在成功执行十分钟后重置。Pod一旦绑定到一个节点，他将永远不会重新绑定到另一个节点。

该什么时候使用探针?

• liveness probe
  
  如果容器中的进程能够在遇到问题或不健康的情况下自行崩溃，则不一定需要存活探针; kubelet 将根据 Pod 的restartPolicy 自动执行正确的操作。如果您希望容器在探测失败时被杀死并重新启动，那么请指定一个存活探针，并指定restartPolicy 为 Always 或 OnFailure。
  
  
• readiness probe
  
  如果要仅在探测成功时才开始向 Pod 发送流量，请指定就绪探针。在这种情况下，就绪探针可能与存活探针相同，但是 spec 中的就绪探针的存在意味着 Pod 将在没有接收到任何流量的情况下启动，并且只有在探针探测成功后才开始接收流量。 如果希望容器能够自行维护，您可以指定一个就绪探针，该探针检查与存活探针不同的端点。 需要注意的是，如果只想在 Pod 被删除时能够拒绝连接（drain request），则不一定需要使用就绪探针；在删除 Pod 时，Pod 会自动将自身置于未完成状态，无论就绪探针是否存在。当等待 Pod 中的容器停止时，Pod 仍处于未完成状态。
  
  

定义探针

• 定义存活的命令（liveness）
  
  许多长时间运行的应用程序最终会过渡到断开的状态，除非重新启动，否则无法恢复。Kubernetes 提供了存活探测器来发现并补救这种情况。
  
  在这篇练习中，会创建一个 Pod，其中运行一个基于 k8s.gcr.io/busybox 镜像的容器。下面是这个 Pod 的配置文件。
  
  apiVersion: v1kind: Podmetadata: labels: test: liveness name: liveness-execspec: containers: - name: liveness image: k8s.gcr.io/busybox args: - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 livenessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 5 periodSeconds: 5在这个配置文件中，可以看到 Pod 中只有一个容器。periodSeconds 字段指定了 kubelet 应该每 5 秒执行一次存活探测。initialDelaySeconds 字段告诉 kubelet 在执行第一次探测前应该等待 5 秒。kubelet 在容器内执行命令 cat /tmp/healthy 来进行探测。如果命令执行成功并且返回值为 0，kubelet 就会认为这个容器是健康存活的。如果这个命令返回非 0 值，kubelet 会杀死这个容器并重新启动它。
  
  当容器启动时，执行如下的命令：
  
  /bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"这个容器生命的前 30 秒， /tmp/healthy 文件是存在的。所以在这最开始的 30 秒内，执行命令 cat /tmp/healthy 会返回成功码。30 秒之后，执行命令 cat /tmp/healthy 就会返回失败码。
  
  创建 Pod：
  
  $ kubectl apply -f https://k8s.io/examples/pods/probe/exec-liveness.yaml在 30 秒内，查看 Pod 的事件：
  
  $ kubectl describe pod liveness-exec输出结果显示还没有存活探测器失败：
  
  FirstSeen LastSeen Count From SubobjectPath Type Reason Message--------- -------- ----- ---- ------------- -------- ------ -------24s 24s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker023s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox"23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox"23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined]23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e35 秒之后，再来看 Pod 的事件：
  
  $ kubectl describe pod liveness-exec在输出结果的最下面，有信息显示存活探测器失败了，这个容器被杀死并且被重建了。
  
  FirstSeen LastSeen Count From SubobjectPath Type Reason Message--------- -------- ----- ---- ------------- -------- ------ -------37s 37s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker036s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox"36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox"36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined]36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e2s 2s 1 {kubelet worker0} spec.containers{liveness} Warning Unhealthy Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory再等另外 30 秒，检查看这个容器被重启了：
  
  $ kubectl get pod liveness-exec输出结果显示 RESTARTS 的值增加了 1。
  
  NAME READY STATUS RESTARTS AGEliveness-exec 1/1 Running 1 1m
• 定义就绪探针readiness
  
  有时候，应用程序会暂时性的不能提供通信服务。例如，应用程序在启动时可能需要加载很大的数据或配置文件，或是启动后要依赖等待外部服务。在这种情况下，既不想杀死应用程序，也不想给它发送请求。Kubernetes 提供了就绪探测器来发现并缓解这些情况。容器所在 Pod 上报还未就绪的信息，并且不接受通过 Kubernetes Service 的流量。
  
  就绪探测器的配置和存活探测器的配置相似。唯一区别就是要使用 readinessProbe 字段，而不是 livenessProbe 字段。
  
  readinessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 5 periodSeconds: 5HTTP 和 TCP 的就绪探测器配置也和存活探测器的配置一样的。
  
  就绪和存活探测可以在同一个容器上并行使用。两者都用可以确保流量不会发给还没有准备好的容器，并且容器会在它们失败的时候被重新启动。
  
  

Probe的配置选项

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

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

HTTP 探测器可以在 httpGet 上配置额外的字段：

• host：连接使用的主机名，默认是 Pod 的 IP。也可以在 HTTP 头中设置 “Host” 来代替。
• scheme ：用于设置连接主机的方式（HTTP 还是 HTTPS）。默认是 HTTP。
• path：访问 HTTP 服务的路径。
• httpHeaders：请求中自定义的 HTTP 头。HTTP 头字段允许重复。
• port：访问容器的端口号或者端口名。如果数字必须在 1 ～ 65535 之间。

对于 HTTP 探测，kubelet 发送一个 HTTP 请求到指定的路径和端口来执行检测。除非 httpGet 中的 host 字段设置了，否则 kubelet 默认是给 Pod 的 IP 地址发送探测。如果 scheme 字段设置为了 HTTPS，kubelet 会跳过证书验证发送 HTTPS 请求。大多数情况下，不需要设置host 字段。这里有个需要设置 host 字段的场景，假设容器监听 127.0.0.1，并且 Pod 的 hostNetwork 字段设置为了 true。那么 httpGet 中的 host 字段应该设置为 127.0.0.1。可能更常见的情况是如果 Pod 依赖虚拟主机，你不应该设置 host 字段，而是应该在 httpHeaders 中设置 Host。



对于一次 TCP 探测，kubelet 在节点上（不是在 Pod 里面）建立探测连接，这意味着你不能在 host 参数上配置 service name，因为 kubelet 不能解析 service name。

Pod readiness（1.14 stable）

可以把外部的回复信息或者信号注入到我们的应用当中，使用Pod readiness。我们需要在Pod的spec文件中定义readinessGates，并且在其中定义一些条件，供kubelet来判定pod是否就绪。



readinessGates会根据status.condition的状态来判定，如果kubernetes不能够在pod中找到status.conditons中的字段，而condition的默认状态是False



例如：



kind: Pod...spec: readinessGates: - conditionType: "www.example.com/feature-1"status: conditions: - type: Ready # a built in PodCondition status: "False" lastProbeTime: null lastTransitionTime: 2018-01-01T00:00:00Z - type: "www.example.com/feature-1" # an extra PodCondition status: "False" lastProbeTime: null lastTransitionTime: 2018-01-01T00:00:00Z containerStatuses: - containerID: docker://abcd... ready: true...

为了方便大家学习，请大家加我的微信，我会把大家加到微信群（微信群的二维码会经常变）和qq群821119334，问题答案云原生技术课堂，有问题可以一起讨论

• 个人微信

640.jpeg

• 腾讯课堂640-20200506145837072.jpeg
  
  
• 微信公众号640-20200506145842007.jpeg
  
  
• 专题讲座
  
  

2020 CKA考试视频 真题讲解 https://www.bilibili.com/video/BV167411K7hp



2020 CKA考试指南 https://www.bilibili.com/video/BV1sa4y1479B/



2020年 5月CKA考试真题 https://mp.weixin.qq.com/s/W9V4cpYeBhodol6AYtbxIA