Istio Service MeshにおけるlivenessProbeとreadinessProbeのカスタム設定する際の問題と対処方法

1. 背景

KubernetesのlivenessProbeとreadinessProbeの設定が意図せずオーバーライドされる問題に遭遇した。
この現象は、Istio Service Meshが有効にされている環境で発生した。

2. 原因

Istioの公式ドキュメントによれば、IstioはmTLSが有効化されている場合にヘルスチェックのリクエストが失敗する問題、および、TCPプローブが常にオープン状態になってしまう問題を解消するため、自動的にlivenessProbeとreadinessProbeをリライトをしてるようです。

Istio solves both these problems by rewriting the application PodSpec readiness/liveness probe, so that the probe request is sent to the sidecar agent.

Health Checking of Istio Services

実際のIstioによるリライト後のlivenessProbeの設定

livenessProbe:
  httpGet:
    path: /app-health/sample-app/livez
    port: 15020
  initialDelaySeconds: 5
  periodSeconds: 5

3. 対応策

対応策として、Deploymentに sidecar.istio.io/rewriteAppHTTPProbers: "false"
アノテーションを付与することで、自動的なProbeの書き換えを無効にすることができる。
これにより、KubernetesのlivenessProbeとreadinessProbeの設定はIstioによってオーバーライドされず、カスタムで設定したliveness/readinessの設定を反映することができる。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-app
spec:
  selector:
    matchLabels:
      app: sample-app
  template:
    metadata:
      labels:
        app: sample-app
      annotations:
        sidecar.istio.io/rewriteAppHTTPProbers: "false"
    spec:
      containers:
      - name: app
        image: your-container-image
        ports:
        - containerPort: 3000
        livenessProbe:
          httpGet:
            path: /
            port: 3000
          initialDelaySeconds: 5
          periodSeconds: 5