ヘルスチェック

サービス・メッシュでヘルス・チェックを使用します。

Kubernetesでは、ヘルス・チェックは有効性、準備および起動プローブを使用して定義されます。kubeletはプローブを実行します。たとえば、HTTPまたはHTTPSプローブでは、kubeletは、構成されたプローブで指定されたアドレスに対してHTTP呼び出しを行います。通常、ポッド内で実行されているアプリケーション・コンテナのアドレスが使用されます。

サービス・メッシュなしでlivenessプローブのヘルス・チェックを実行するKubernetesアプリケーションの大まかな図。サポートされているのは、HTTPプロトコルのみです。アプリケーションはコンテナに接続します。 — 図1.Health ChecksパートI

サービス・メッシュでは、オペレータは、アプリケーションのヘルス・チェックに加えてプロキシのヘルス・チェックを実行するプロキシ・コンテナにHTTPプローブを変更します。

サービス・メッシュでlivenessプローブのヘルス・チェックを実行するKubernetesアプリケーションの大まかな図。HTTPプロトコルのみがサポートされています。アプリケーションはサービス・メッシュに接続します。ただし、サービス・メッシュ・プロキシがチェックをインターセプトし、別のアプリケーション・コンテナでチェックを実行します。 — 図2.サービス・メッシュ・パートIIによるヘルス・チェック

現在、サービス・メッシュはkubeletからプロキシへのHTTP接続のみをサポートしています。元のプローブがHTTPSまたはTCPの場合、サービス・メッシュは、kubeletからプロキシ・コンテナにHTTPを使用するようにプローブを書き換えます。プロキシは、元のプローブ設定に基づいて、プロキシから宛先エンドポイントへのHTTPおよびHTTPSヘルス・チェックをサポートします。他のタイプのプローブ(tcpSocket、grpcなど)が見つかった場合、それらは暗黙的に無視されます。プロキシは、プロキシ関連のヘルス・チェックおよびアプリケーション関連のヘルス・チェックを引き続き実行します。

ヘルス・チェックの例

例: HTTP Livenessおよび起動プローブの構成

ratings-v1.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ratings-v1
  namespace: bookinfo-demo
  labels:
    app: ratings
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ratings
      version: v1
  template:
    metadata:
      namespace: bookinfo-demo
      labels:
        app: ratings
        version: v1
      annotations:
        servicemesh.oraclecloud.com/proxy-log-level: debug
    spec:
      serviceAccountName: bookinfo-ratings
      containers:
        - name: ratings
          image: iad.ocir.io/idwul7vntmtk/istio/examples-bookinfo-ratings-v1:1.16.2
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 8080
          securityContext:
            runAsUser: 1000
         livenessProbe:
           initialDelaySeconds: 2
           periodSeconds: 5
           httpGet:
             path: /health
             port: 9080
         startupProbe:
           httpGet:
             path: /health
             port: 9080
           failureThreshold: 30
           periodSeconds: 5

ヘルス・チェック・プローブは、spec:template:spec:livenessProbeおよびspec:template:spec:startupProbeで定義されます。仮想デプロイメント・リスナーのヘルス・チェック・エンドポイントにも、この仕様で使用されるポートを定義してください。

httpHeadersフィールドまたはhostフィールド、またはhttpGetフィールドのプローブにホスト名が定義されていません。したがって、リクエストのデフォルトは、ratings-v1コンテナが実行されているポッドのIPアドレスになります。kubeletは、起動時にhttp://podipaddress:9080/healthに到達しようとします。ここでstartupProbeが構成されているため、アプリケーションの準備は最大150 (30*5)秒です。起動プローブが成功しない場合、コンテナはポッドのrestartPolicyに従って150秒後に強制終了します。

startupProbeが定義されているため、http://podipaddress:9080/healthエンドポイントが2xxレスポンスを返すまで、livenessProbeは起動中も無効のままです。正常な起動をポストすると、livenessプローブがアクティブになり、最初の遅延が2秒後にhttp://podipaddress:9080/healthエンドポイントから5秒ごとに2xxレスポンスがチェックされます。ヘルス・チェックに失敗すると、kubeletはコンテナを強制終了して再起動します。

メッシュ化されたシナリオでは、リクエストはkubeletからプロキシ・コンテナに、アプリケーション・コンテナにフローします。スキームが定義されていないため、両方のプローブはデフォルトでHTTPスキームを使用します。

例: ratingsコンテナのHTTPS livenessProbeの構成

ratings-v1.yaml (一部)

livenessProbe:
  initialDelaySeconds: 2
  periodSeconds: 5
  httpGet:
    host: ratings # Defaults to podIpaddress, Can be defined in httpHeaders field as well
    path: /health # Defaults to /
    port: 9080
    scheme: https # Defaults to http if not defined
    httpHeaders:
      - name: Accept
        value: application/json

この構成では、kubeletはhttps://ratings:9080/healthエンドポイントに到達しようとします。ヘルス・チェックの図で説明したように、メッシュ・プロキシはこのリクエストをインターセプトし、スキームをHTTPに変更します。さらに、プロキシはプロキシから宛先エンドポイントへのHTTPSリクエストを開始します。つまり、kubeletからProxyコンテナはHTTPです。ratingsコンテナへのプロキシ・コンテナはHTTPSです。このプローブが成功すると、ポッドはライブとしてマークされます。プローブ・スキームの同様のリライトは、リクエストがTCPプローブで、プロキシ・コンテナへのkubeletがHTTPの場合に発生します。

例: 評価コンテナのGRPC livenessProbeの構成