プロービングの設定¶

Knativeプロービングの一般的な理解¶

KnativeのプロービングはKubernetesのプロービングとは異なることに注意することが重要です。その理由の1つは、Knativeがコールドスタート時間を最小限に抑えようとするため、Kubernetesよりもはるかに高い間隔でプロービングを行うことです。

一般的なプロービングアーキテクチャは次のようになります。

probing-overview

ユーザーは、必要に応じてKnativeService CRでReadiness/Livenessプローブおよび/またはStartupプローブを定義できます。
LivenessプローブとStartupプローブは、Kubeletによって対応するコンテナに対して直接実行されます。
一方、ReadinessプローブはKnativeによって書き換えられ、Queue-Proxyコンテナによって実行されます。
Knativeは、(例：アクティベーター、net-*コントローラー、Queue-Proxyから)様々な場所でプロービングを行い、ネットワークスタック全体が構成され、準備ができていることを確認します。通常のKubernetesと比較して、Knativeはより高速な(積極的なプロービングと呼ばれる)プロービング間隔を使用して、Podが既に起動して実行されている間のコールドスタート時間を短縮します。一方、Kubernetes自体は、その準備状況をまだ反映していません。
ユーザーがプローブを定義しない場合、KnativeはプライマリユーザーコンテナのデフォルトのReadinessプローブを定義します。KnativeサービスのトラフィックポートでTCPソケットをチェックします。
Knativeは、Queue-Proxyコンテナ自体のReadinessプローブも定義します。Queue-Proxyのヘルスエンドポイントは、すべてのユーザーコンテナ(プライマリ+サイドカー)の書き換えられたReadinessプローブからのすべての結果を集約します。集約されたステータスについて、Queue-Proxyは各コンテナのReadinessプローブを並列に呼び出し、応答(またはタイムアウト)を待って、集約された結果をKubernetesに報告します。

Queue-Proxyプローブが成功応答を返し、Knativeネットワーキング層の再構成が完了すると、KnativeはPodが正常でトラフィックを提供できる状態であると認識します。

注記

KnativeがPodを正常で準備完了と認識しているのに対し、Kubernetesはまだそうではないと考えている場合や、その逆の場合があることに注意してください。DeploymentとPodのステータスは、Knativeのステータスを反映しません。Knativeが認識するステータスを完全に確認するには、Knativeのオブジェクト階層(例：Service、Configuration、Revision、PodAutoscaler、ServerlessService、Route、Ingress)のすべての条件を確認する必要があります。

カスタムプローブの設定¶

注記

Knative Serviceで複数のコンテナを使用している場合は、マルチコンテナプロービングを有効にする必要があります。

Kubernetesと同じ方法で、Knative ServiceにReadinessプローブとLivenessプローブを定義できます。

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コンテナは、定義されたLivenessプローブを書き換えたり、チェックしたりしないため、Livenessプローブが失敗すると、Kubernetesは特定のコンテナを再起動できることに注意することが重要です。KnativeがPod内の失敗しているコンテナを認識できるように、Livenessプローブとして定義したものと同じチェックをReadinessプローブにも含めるようにしてください。そうでない場合、Livenessプローブの失敗によってコンテナの再起動中に接続エラーが発生する可能性があります。

進行期限とStartupプローブ¶

Knative Serviceが最初に起動（またはロールアウト）するまでの期限があることを理解しておくことが重要です。これは進行期限と呼ばれます。Startupプローブを使用する場合、ユーザーは、進行期限がStartupプローブにかかる最大時間よりも高い値に設定されていることを確認する必要があります。これについては、initialDelaySeconds、success/failureThreshold、periodSeconds、timeoutSecondsの設定を考慮してください。そうでない場合、進行期限に達する前にStartupプローブが成功する可能性がなく、サービスは正常に起動しません。Knative Serviceは、これをServiceオブジェクトのステータスにマークします。

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