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
<…>