配置探测¶

对 Knative 探测的一般理解¶

重要的是要注意，Knative 探测与 Kubernetes 探测不同。原因之一是 Knative 试图最小化冷启动时间，因此探测的间隔远高于 Kubernetes 的间隔。

一般的探测架构如下所示

probing-overview

用户可以选择在 KnativeService CR 中定义就绪/存活和/或启动探测。
存活和启动探测由 Kubelet 直接针对相应的容器执行。
另一方面，就绪探测由 Knative 重写，以便由 Queue-Proxy 容器执行。
Knative 从多个地方执行探测（例如，激活器、net-* 控制器和 Queue-Proxy），以确保整个网络堆栈已配置并就绪。与普通 Kubernetes 相比，Knative 使用更快的探测间隔（称为积极探测），以缩短 Pod 已经启动并运行时的冷启动时间，而 Kubernetes 本身尚未反映这种就绪性。
当用户未定义探测时，Knative 将为主要用户容器定义默认就绪探测。它将检查 Knative 服务的流量端口上的 TCP 套接字。
Knative 还将为 Queue-Proxy 容器本身定义就绪探测。Queue-Proxy 的健康端点会聚合所有来自其针对所有用户容器（主容器 + 边车）重写的就绪探测的结果。对于聚合状态，Queue-Proxy 将并行调用每个容器的就绪探测，等待其响应（或超时），并将聚合结果报告回 Kubernetes。

一旦 Queue-Proxy 探测返回成功响应，并且 Knative 网络层重新配置完成，Knative 将认为 Pod 健康且已准备好提供流量。

注意

请记住，Knative 可能会认为您的 Pod 健康且已准备好，而 Kubernetes 仍然认为它没有准备好，反之亦然。Deployment 和 Pod 状态不会反映 Knative 中的状态。要完全检查 Knative 所看到的状态，您必须检查 Knative 对象层次结构（例如，Service、Configuration、Revision、PodAutoscaler、ServerlessService、Route、Ingress）上的所有条件。

配置自定义探测¶

注意

如果您在 Knative 服务中使用多个容器，请确保启用多容器探测。

您可以在 Knative 服务中定义就绪和存活探测，方法与在 Kubernetes 中相同

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: runtime
  namespace: default
spec:
  template:
    spec:
      containers:

      - name: first-container
        image: <your-image>
        ports:
          - containerPort: 8080
        readinessProbe:
          httpGet:
            port: 8080 # you can also check on a different port than the containerPort (traffic-port)
            path: "/health"
        livenessProbe:
          tcpSocket:
            port: 8080
        startupProbe:
          httpGet:
            port: 8080
            path: "/"

      - name: second-container
        image: <your-image>
        readinessProbe:
          httpGet:
            port: 8089
            path: "/health"
        livenessProbe:
          tcpSocket:
            port: 8089
        startupProbe:
          httpGet:
            port: 8080
            path: "/"

支持的探测类型有

httpGet
tcpSocket
exec
grpc

注意

请注意，Knative 也会进行一些默认设置（使用 HTTP 检查检查流量端口上的就绪性）以及额外的验证，以使积极探测正常工作。

警告

由于 Queue-Proxy 容器不会重写或检查定义的存活探测，因此重要的是要了解 Kubernetes 可以并且会重新启动特定容器，一旦存活探测失败。确保将与您定义为存活探测的相同检查也包含为就绪探测，以确保 Knative 了解 Pod 中的故障容器。否则，您可能会发现，由于存活探测失败导致容器重启期间可能会出现连接错误。

进度截止日期和启动探测¶

重要的是要了解，Knative 有一个截止日期，在此截止日期之前，Knative 服务应该最初启动（或推出）。这被称为进度截止日期。当使用启动探测时，用户必须确保将进度截止日期设置为大于启动探测所需最大时间的数值。为此，请考虑 initialDelaySeconds、success/failureThreshold、periodSeconds 和 timeoutSeconds 的配置。否则，启动探测可能永远不会在进度截止日期到达之前通过，并且服务将永远无法成功启动。然后，Knative 服务将在服务对象的状态中标记此信息

[
  {
    "lastTransitionTime": "2024-06-06T09:28:01Z",
    "message": "Revision \"runtime-00001\" failed with message: Initial scale was never achieved.",
    "reason": "RevisionFailed",
    "status": "False",
    "type": "ConfigurationsReady"
  }
]