很久没写了,关于 Kubernetes 就绪探测的帖子早就该来了。如果你还没有在Kubernetes Liveness Probes上查看这篇文章的第一部分,我建议你查看一下。在这篇文章中,我们将主要关注 Readiness Probe 以及如何使用它来监控应用程序的运行状况。

如前所述,Kubernetes 提供了3 种不同类型的健康检查来监控应用程序的状态:

• 活体探针

• 准备探针

• 启动探针

当您使用云应用程序时,您可能会遇到应用程序的一个或多个实例可能尚未准备好为任何请求提供服务的情况。在这种情况下,您最好不希望将流量路由到这些实例。其中一些场景包括但不限于:

• 您的一个应用程序实例可能正在定期执行批处理操作——例如读取大型 SQL 表并将结果写入 S3

• 您的应用程序实例可能在启动时将数据从数据库加载到缓存中,并且您不希望它们在填充缓存之前提供任何流量

• 如果某些相关服务出现故障,您可能不希望您的应用程序提供任何流量——例如,如果您有一个处理 Amazon S3 中文件的图像处理服务,您可能希望停止将任何流量定向到您的如果 S3 本身已关闭,则提供图像处理服务。

注意:在上述情况下,建议配置您的就绪探测,以便能够区分依赖服务不可用和延迟问题。例如,如果 S3 的延迟增加了 100 毫秒,您不希望您的服务停止处理请求。

在上面提到的大多数场景中,您不想杀死应用程序,但也不想向它发送请求。 Kubernetes 提供就绪探测来检测和缓解这些情况。您的应用程序可以使用就绪探测来告诉 Kubernetes 目前它还没有准备好接受任何流量。

根据 Kubernetes 文档:

kubelet 使用就绪探测来了解容器何时准备好开始接受流量。当 Pod 的所有容器都准备好时,就认为 Pod 准备好了。此信号的一种用途是控制哪些 Pod 用作服务的后端。当 Pod 未准备好时,它会从服务负载均衡器中移除

这实质上意味着当针对应用程序的特定 pod 的就绪探测失败时,Kubernetes 会从服务映射中删除该 pod 并停止向其转发任何流量。

就绪探针的解剖结构

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: readiness
  name: readiness-exec
spec:
  containers:
  - name: readiness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

如果查看 yaml 的readinessProbe部分,可以看到 kubelet 对/tmp/healthy文件执行了cat操作。如果文件存在并且 cat 操作成功,则命令返回退出状态 0,并且 kubelet 认为容器可用并准备好接受流量。另一方面,如果命令返回非零退出状态,kubelet 会从 Service/LoadBalancer 中删除容器,直到就绪探测再次成功。在它再次开始返回成功之前,不会将任何流量转发到此容器。

initialDelaySeconds参数告诉 kubelet 在执行第一次就绪检查之前应该等待 5 秒。这确保了容器在启动时不会被认为处于不可用状态。在初始延迟之后,kubelet 每 5 秒执行一次就绪检查,由periodSeconds字段定义。

除了通用命令之外,还可以在 TCP 和 HTTP 端点上定义 Readiness 探针,如果您正在开发 Web 应用程序,这将特别有用。

TCP 就绪探测

apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
  - name: goproxy
    image: k8s.gcr.io/goproxy:0.1
    ports:
    - containerPort: 8080
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

这种就绪探测基本上是端口检查。如果您想检查 Web 应用程序上的特定端口是否响应,这是要走的路。

HTTP 就绪探测

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: readiness
  name: readiness-http
spec:
  containers:
  - name: readiness
    image: k8s.gcr.io/readiness
    args:
    - /server
    readinessProbe:
      httpGet:
        path: /readiness
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

对于 HTTP 就绪探测,kubelet 轮询容器的端点,由 yaml 中的路径和端口参数定义。如果端点返回成功状态代码,则认为容器是健康的。

任何大于或等于 200 且小于 400 的代码都表示成功。任何其他代码表示失败

结论

在这篇文章中,我们研究了您可能不希望应用程序实例可用于服务请求的某些场景,以及 Kubernetes Liveness Probe 如何帮助您有效识别和缓解此类场景。保持健康并保持关注。

快乐编码!干杯:)