Kubernetes 探针如何工作

本文需要 JavaScript 本文中的演示需要 JavaScript 才能运行。我知道这不是你想听的，我很抱歉。如果您因此不想继续阅读，也没有什么不好的感觉。不过，演示非常酷。我将向您展示，真正向您展示，探针在 Kubernetes 中是如何工作的。它们如何使您的应用程序更具弹性，以及如何帮助您防止可避免的错误。比如需要几个小时才能恢复的重启循环，以及在推出期间丢弃请求。本文中的每个交互式演示都使用 webernetes ，这是我将 Kubernetes 移植到 TypeScript 的部分内容。它包含超过 100,000 行移植的 Kubernetes Go 代码，可在浏览器中运行模拟集群。我针对 k3s 验证了这些演示的行为，并设法在 Kubernetes 中发现了一个错误！稍后会详细介绍。 3 种类型的探头及其用途。如何配置和组合它们。常见的错误配置是如何失败的。探针如何影响部署速度。将此部分添加为书签 没有探针的 pod 我想使用单个容器运行 pod。这是它的清单， pod-a.yaml : 1 apiVersion : "v1" 2 kind : "Pod" 3 元数据 : ⋯ 4 name : "pod-a" 5 spec : ⋯ 6 个容器 : ⋯ 7 - name : "app" ⋯ 8 image : "my-app:latest" 这个镜像 my-app:latest 在监听端口之前会花费几秒钟的时间进行初始化8080。当您单击“重新启动”向容器发送信号时，您将看到下面的内容，导致容器崩溃并由 Kubernetes 启动备份。您可以随时暂停或重置任何演示。 node-1 重置集群 暂停集群 0/2 重新启动容器 尚未完成。第一次崩溃后，容器立即重新启动。第二次之后，Kubernetes 在再次启动之前对其施加 CrashLoopBackOff。默认情况下，此延迟为 10 秒，每次崩溃时延迟加倍，最多等待 5 分钟。我在这个演示中将其缩短为 3 秒。在这两种情况下，Kubernetes 在容器启动时就认为它已就绪，尽管我们知道它还没有就绪。它仍在执行启动工作，并且不在端口 8080 上侦听。接下来我将添加 pod-b ，它每 2 秒向 pod-a 发送一个请求。在整篇文章中，您可以将 pod-b 视为客户端流量的任何来源：入口控制器、负载均衡器、服务间请求等。如果在下面的演示中在请求正在进行时重新启动 pod-a，则该请求将失败。 node-1 重置集群 暂停集群 从您重新启动容器的那一刻起，直到其启动工作完成，即使容器被视为就绪，请求也会失败！这不是我想要的。我需要 Kubernetes 知道 pod-a 何时准备好接收流量。为此，Kubernetes 为我们提供了探针。探针是发送到容器的定期检查以确定其运行状况。它们分为三种类型： 启动探针确定容器内的应用程序是否已启动。就绪探针确定我的应用程序是否准备好接收流量。活性探针确定我的应用程序是否需要重新启动。听起来启动探针最适合我在上面的演示中向您展示的问题，所以让我们从这里开始。将此部分添加为书签 启动探针 下面，我在 pod-a.yaml 中添加了一个启动探针： 1 apiVersion : "v1" 2 kind : "Pod" 3 metadata : ⋯ 4 name : "pod-a" 5 spec : ⋯ 6Containers : ⋯ 7 - name : "app" ⋯ 8 image : "my-app:latest" 9startupProbe : ⋯ 10 httpGet : ⋯ 11 path : "/startup" 12 port : 8080 13 periodSeconds : 1 14 failureThreshold : 5 这是一个 httpGet 探针，向端口 8080 上的 pod 发送 GET /startup 请求。状态代码 200-399 视为成功。这种情况每 periodSeconds 秒发生一次，并且允许在 Kubernetes 终止容器之前连续失败 failureThreshold 次。这让我的容器大约需要 5 秒的时间来完成其启动工作。 Kubernetes 还支持 tcpSocket 、 exec 和 grpc 探针。它们建立 TCP 连接、在容器内运行命令或调用 gRPC 运行状况检查协议来建立容器运行状况。您可以在 Kubernetes 文档中阅读有关它们的信息。我将在这篇文章中使用 httpGet。探针由称为 kubelet 的进程发送。集群中的每个节点都有自己的 kubelet，kubelet 的工作是确保每个节点运行并探测正确的 pod。当您在下面重新启动 pod-a 时，它现在显示为 NotReady 。 Kubernetes 现在知道 pod-a 尚未初始化。仅在第一次启动探测成功后才变为 Ready。 node-1 重置集群 暂停集群 0/2 重新启动容器 尚未完成。 NotReady 是具有启动探针的容器的 pod 的默认设置。然而，即使没有准备好，pod-b 仍然会向 pod-a 发送请求，并且这些请求在容器启动期间仍然会失败。这是因为我已将 pod-b 配置为直接向 pod-a 的 IP 地址发送请求，这绕过了就绪机制。关于 NotReady 我撒了一点谎 从技术上讲，Kubernetes 没有 NotReady 条件，它有一个 Ready c