Pod 啟動時間

本節說明 Cloud Service Mesh 常見的 Pod 啟動時間問題，以及如何解決這些問題。如需其他協助，請參閱取得支援。

Pod 啟動和 Envoy 設定同步

在某些 Cloud Service Mesh 和 Istio 環境中，Pod 啟動期間會發生常見問題，涉及應用程式就緒性和 Envoy 代理程式設定之間的同步處理。這個問題是由於應用程式容器和 Envoy 附加元件同時啟動所致。應用程式可能會在 Envoy 代理程式完成初始化並從控制平面接收設定之前，傳送就緒信號。這會導致競爭狀態，也就是傳入要求會導向未設定的 Envoy 代理程式，而該代理程式尚未準備好接收任何流量。由於沒有側載程式可轉送任何流量，因此可能會導致在應用程式啟動初期階段，要求遭到捨棄、誤導或處理不當。

緩解策略

以下各節將說明可緩解此問題的方法。

全域網格設定：holdApplicationUntilProxyStarts

第一個選項是在 Istio mesh 設定中設定 holdApplicationUntilProxyStarts: true。請注意，這項功能預設為關閉。這個標記會新增鉤子，延遲應用程式啟動，直到 Pod 的 Proxy 準備好接受流量為止。

新增設定可消除這項競爭，但如果先前未啟用，可能會導致新 Pod 的應用程式就緒時間延遲。

完備性探測

另一種解決方案是實作就緒探測器，同時納入應用程式和 Envoy 健康檢查。完備性探測會在 Pod 準備好接受流量時通知 Kubernetes。重要的是，就緒探針邏輯不應只驗證應用程式的就緒狀態，也應驗證 Envoy 代理程式的狀態。您可以查詢 Envoy 的管理員端口，瞭解其健康狀態。結合這兩項檢查後，Kubernetes 會在應用程式和 Envoy 都已完全初始化及設定完成前，防止流量導向至 pod。

這種做法更具彈性，可支援更複雜的啟動和就緒邏輯，但代價是會增加複雜度。

使用下列程式碼建立 healthcheck.sh 檔案：

#!/bin/sh
APP_HEALTH=$(curl -s -o /dev/null -w "%{http_code}" \
  http://localhost:8080/health)
ENVOY_HEALTH=$(curl -s -o /dev/null -w "%{http_code}" \
  http://localhost:9901/ready)

if [[ "$APP_HEALTH" -eq 200 && "$ENVOY_HEALTH" -eq 200 ]]; then
  exit 0
else
  exit 1
fi

將 IP/port 替換為應用程式容器和 Envoy 的 IP/port。

以下 YAML 檔案會定義使用先前建立的指令碼的測試就緒性：

apiVersion: v1
kind: Pod
metadata:
  name: my-app-with-envoy
spec:
  containers:
  - name: application
    <…>
    readinessProbe:
      initialDelaySeconds: 15
      periodSeconds: 10
      failureThreshold: 3
      exec:
        command:
        - /healthcheck.sh # using the script
  - name: envoy
    <…>

後續步驟