GKE 網路已知問題

本頁列出 GKE 網路的已知問題。本頁面適用於管理基礎技術基礎架構生命週期的管理員和架構師，以及在未達到服務水準目標 (SLO) 或應用程式失敗時，回應快訊和頁面的管理員和架構師。

如要依產品版本篩選已知問題，請從下列下拉式選單中選取篩選條件。

選取 GKE 版本：

或者，搜尋你的問題：

已識別的版本 已修正的版本 問題和解決方法
1.36 正在修正

如果 GKE 叢集的 Windows Server 節點集區執行 1.36 版，可能會發生下列任一情況：

  • 工作負載的傳出網路連線失敗。
  • 重要的系統 Pod (例如 pdcsi-node-windows 和 gke-metrics-agent-windows) 持續以 CrashLoopBackOff 狀態重新啟動。

如果叢集使用第 4 層內部負載平衡器，但未啟用 GKE 子集，或使用舊版目標集區或執行個體群組的外部直通式網路負載平衡器，就會發生這個問題。在 GKE 1.36 中，Compute Engine 客體代理程式預設會在 Windows Server 上啟用 CorePlugin，並將負載平衡器虛擬 IP (VIP) 位址直接動態繫結至主機網路介面卡 (vEthernet (Ethernet))，做為次要 /32 位址。傳送至 VIP 的傳出流量會回送至主機並遭到捨棄，而傳送至 GKE 控制層 (Kubernetes API 伺服器) 或 Google Cloud 中繼資料伺服器 (169.254.169.254) 的傳出連線會間歇性選取次要 VIP 做為來源 IP 位址，導致連線逾時。

解決方法：

如要解決這個問題，請採取下列任一方法：

  • 啟用 L4 子設定 (建議用於內部負載平衡器)：將 gke.googleapis.com/subsetting: "true" 註解新增至內部 LoadBalancer Service 規格，然後重新建立或執行 Windows 節點的滾動式重新啟動，清除現有的次要 IP 位址： 
    apiVersion: v1
kind: Service
metadata:
  name: SERVICE_NAME
  annotations:
    cloud.google.com/load-balancer-type: "Internal"
    gke.googleapis.com/subsetting: "true"
spec:
  type: LoadBalancer
  • 使用以後端服務為基礎的外部負載平衡器：如要進行外部負載平衡，請將以目標集區為基礎的舊版服務，遷移至以後端服務為基礎的外部負載平衡器。
  • 使用節點開機指令碼停用訪客代理程式 IP 位址轉送功能：使用自訂節點開機指令碼，在 C:\Program Files\Google\Compute Engine\instance_configs.cfg 檔案的 [NetworkInterfaces] 區段下方新增 ip_forwarding = false 鍵/值組合，然後重新啟動 GCEGuestAgent 服務： 
    $configFile = "C:\Program Files\Google\Compute Engine\instance_configs.cfg"
if (Test-Path $configFile) {
    Add-Content -Path $configFile -Value "`r`n[NetworkInterfaces]`r`nip_forwarding = false"
    Restart-Service -Name GCEGuestAgent -Force
}
  • 延後 Windows 節點集區升級：將 Windows 節點集區保留在 GKE 1.34 或 1.35，直到修正後的 Windows 節點映像檔推出。
InferencePool Helm 資訊套件 1.1.0 版

在 InferencePool Helm 圖表的 v1.1.0 版本中，系統可能會忽略 --set inferencePool.targetPortNumber 旗標，並將目標通訊埠編號預設為 8000。如果模型伺服器監聽其他通訊埠 (例如 SGLang 的 30000)，這個預設通訊埠編號會導致轉送問題。


解決方法：

安裝後，請驗證通訊埠：

kubectl get inferencepool POOL_NAME -o jsonpath='{.spec.targetPorts}' \
    --context=CLUSTER_CONTEXT

如果通訊埠不正確，請先修補 InferencePool 自訂資源，再匯出：

kubectl patch inferencepool POOL_NAME --type=merge \
    -p '{"spec":{"targetPorts":[{"number":TARGET_PORT}]}}' \
    --context=CLUSTER_CONTEXT
1.33、1.34、1.35
  • 1.33.11-gke.1137000 以上版本
  • 1.34.6-gke.1154000 以上版本
  • 1.35.0-gke.3047000 以上版本

啟用 GKE Dataplane V2 的叢集，可能會發生間歇性連線失敗或執行中 Pod 的 DNS 解析問題。這個問題是由 cilium-agent (anetd) 啟動程序中的競爭狀況所造成。

如果 cilium-agent 暫時無法使用，cilium-cni 外掛程式可能會將現有 Pod 的端點刪除要求排入佇列。如果代理程式在成功初始化或重新建立 Pod 的端點後，處理這些過時的刪除事件，代理程式會錯誤地刪除有效的 CiliumEndpoint。因此，受影響的 Pod 會失去網路身分和轉送設定，導致流量遭到捨棄。這項問題通常會導致 DNS 失敗，因為 eBPF ipcache 會誤將目的地視為未受管理。受影響的 Pod 可能會進入 CrashLoopBackOff 狀態。


解決方法：

如要緩解這個問題，請手動刪除受影響的 Pod，或在發生問題的節點上重新啟動 anetd Pod。這樣做會強制重新建立缺少的 CiliumEndpoint，並還原連線。

解決方法：

advanceddatapath 元件 33.7.36 以上版本已包含修正程式。如要解決這個問題，請將叢集升級至「Fixed version(s)」(已修正版本) 欄中列出的任一版本。
1.29、1.30、1.31、1.32、1.33 1.34

刪除 FQDN 網路政策後，anetd Pod 中的 cilium-agent 容器會停止運作

如果叢集已啟用 GKE Dataplane V2，cilium-agent 容器可能會暫時停止運作，導致必須在資料層中程式化的事件需要較長的協調時間。這是因為刪除 FQDN 網路政策時，發生空指標取消參照。

刪除 FQDN 網路政策會觸發這個問題。發生問題時，anetd Pod 中的 Cilium-agent 容器會傳回類似下列的錯誤訊息： panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x33e237d]


解決方法：

如要解決這個問題，請不要刪除 FQDN 政策，而是修補政策，確保沒有任何 Pod 受到政策影響：

      kubectl patch fqdnnetpol -n namespace policy-name --patch '
      spec:
        podSelector:
          matchLabels:
            miss: me
      '

解析度

將叢集升級至 1.34 版本
1.28、1.29、1.30、1.31、1.32、1.33

在採用 GKE Dataplane V2 的節點上，Pod IP 位址外洩

如果叢集已啟用 GKE Dataplane V2，節點上的 Pod IP 位址可能會用盡。這個問題是由容器執行階段錯誤所造成，當 Pod 在建立期間發生暫時性 CNI 錯誤時，可能會洩漏分配的 IP 位址。

當 GKE 叢集節點升級至或建立為下列任一 GKE 版本時，就會觸發這個問題：

  • 1.33 以上版本
  • 1.32 以上版本
  • 1.31.2-gke.1115000 以上版本
  • 1.30.8-gke.1051001 以上版本
  • 1.29.10-gke.1059000 以上版本
  • 1.28.15-gke.1024000 以上版本

發生這個問題時，排定在受影響節點上的新 Pod 無法啟動，並會傳回類似以下的錯誤訊息：failed to assign an IP address to container。


解決方法：

如要緩解這個問題，您可以將緩解 DaemonSet 套用至叢集，清除外洩的 IP 資源：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: cleanup-ipam-dir
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: cleanup-ipam
  template:
    metadata:
      labels:
        name: cleanup-ipam
    spec:
      hostNetwork: true
      securityContext:
        runAsUser: 0
        runAsGroup: 0
        seccompProfile:
          type: RuntimeDefault
      automountServiceAccountToken: false
      containers:
      - name: cleanup-ipam
        image: gcr.io/gke-networking-test-images/ubuntu-test:2022@sha256:6cfbdf42ccaa85ec93146263b6e4c60ebae78951bd732469bca303e7ebddd85e
        command:
        - /bin/bash
        - -c
        - |
          while true; do
          for hash in $(find /hostipam -iregex '/hostipam/[0-9].*' -mmin +10 -exec head -n1 {} \; ); do
          hash="${hash%%[[:space:]]}"
          if [ -z $(ctr -n k8s.io c ls | grep $hash | awk '{print $1}') ]; then
          grep -ilr $hash /hostipam
          fi
          done | xargs -r rm
          echo "Done cleaning up /var/lib/cni/networks/gke-pod-network at $(date)"
          sleep 120s
          done
        volumeMounts:
        - name: host-ipam
          mountPath: /hostipam
        - name: host-ctr
          mountPath: /run/containerd
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - ALL
      volumes:
      - name: host-ipam
        hostPath:
          path: /var/lib/cni/networks/gke-pod-network
      - name: host-ctr
        hostPath:
          path: /run/containerd
1.31、1.32、1.33
  • 1.33.1-gke.1107000 以上版本
  • 1.32.8-gke.1108000 以上版本

使用舊版網路的叢集發生 Ingress 和 Service 負載平衡器中斷

與舊版網路不相容，導致使用 Ingress 或 Service 部署的 GKE 代管負載平衡器後端中斷連結。這會導致負載平衡器沒有任何有效的後端，進而導致傳送至這些負載平衡器的所有傳入要求遭到捨棄。

這個問題會影響使用舊版網路且版本為 1.31 以上的 GKE 叢集。

如要找出使用舊版網路的 GKE 叢集，請執行下列指令：

    gcloud container clusters describe CLUSTER_NAME --location=LOCATION --format="value(subnetwork)"

如果叢集使用舊版網路，這個指令會輸出空白內容。

解決方法：

舊版網路已淘汰一段時間，因此建議您將舊版網路遷移至虛擬私有雲網路。方法是轉換含有 GKE 叢集的舊版網路。如果目前無法執行這項遷移作業，請與 Cloud Customer Care 團隊聯絡。
1.30、1.31、1.32
  • 1.30.10-gke.1070000 以上版本
  • 1.31.5-gke.1068000 以上版本
  • 1.32.1-gke.1002000 以上版本

新建立的節點不會新增至第 4 層內部負載平衡器

為內部 LoadBalancer 服務建立的 Google Cloud 負載平衡器，可能會遺漏後端執行個體群組中新建立的節點。

如果叢集縮減至零個節點，然後又擴充至一或多個節點，這個問題就會最明顯。

解決方法：

  • 啟用 GKE 子集，並重新建立 Service。

    注意：GKE 子集設定啟用後即無法停用。

  • 建立另一個內部 LoadBalancing Service。同步處理後，受影響服務的執行個體群組也會修正。同步處理完成後，即可移除新的 Service。
  • 新增 node.kubernetes.io/exclude-from-external-load-balancers 標籤，然後從其中一個節點移除該標籤。
  • 在叢集中新增節點。Service 開始運作後，您就可以移除節點。
1.31、1.32
  • 1.31.7-gke.1158000 以上版本
  • 1.32.3-gke.1499000 以上版本

storedVersions 從 CRD 狀態中移除，導致 Gateway API 發生問題

GKE 中的 Kube-Addon-Manager 會錯誤地從 gateway、httpRoute、gatewayClass 和 referenceGrant 等 Gateway API CRD 的狀態中移除 v1alpha2 storedVersion。即使叢集仍有以 v1alpha2 格式儲存的 CRD 執行個體，也會發生這個問題。如果 GKE 叢集版本升級時未啟用 storedVersions，Gateway API 呼叫就會失敗。失敗的呼叫也可能導致實作 Gateway API 的控制器中斷。

如果叢集符合下列所有條件，可能會有風險：

  • 叢集已啟用 Gateway API。
  • 您曾在過去任何時間點安裝 v1alpha2 版本的 Gateway API CRD。
  • 叢集使用的 GKE 版本受到影響。

解決方法：

建議您延後升級叢集，直到問題解決為止。

或者，如需升級叢集版本，請務必將所有受影響 Gateway API CRD 的儲存空間版本更新為 v1beta1。以下範例會更新 gatewayClass CRD：

  1. 檢查是否存在 v1alpha2 儲存空間版本： 
    kubectl get crd gatewayclasses.gateway.networking.k8s.io -ojsonpath="{.status.storedVersions}"
  2. 在叢集的所有 GatewayClass 資源上執行下列指令，將儲存空間版本調整為 v1beta1： 
    kubectl annotate gatewayclass gateway-class-name bump-storage-version="yes"
  3. 移除 v1alpha2 儲存空間版本，並將儲存空間版本設為 v1beta1：
    kubectl patch customresourcedefinitions gatewayclasses.gateway.networking.k8s.io --subresource='status' --type='merge' -p '{"status":{"storedVersions":["v1beta1"]}}'
  4. 照常執行升級作業。
1.32
  • 1.32.3-gke.1170000 以上版本

新的 Pod 無法初始化，卡在 ContainerCreating 狀態

無法建立新的 Pod，且卡在 ContainerCreating 狀態。發生這個問題時，服務容器會記錄下列內容：

Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "[sandbox-ID]": plugin type="cilium-cni" failed (add): unable to create endpoint: Cilium API client timeout exceeded

這個問題會影響 1.32 至 1.32.3-gke.1170000 之前的 GKE 叢集，這些叢集是在 GKE 1.31 或 1.32 版建立。根本原因是，維護已分配 Cilium 身分集合的記憶體內資料結構，未正確與 Kubernetes API 伺服器狀態同步。

如要確認建立叢集時使用的 GKE 版本，請使用下列指令查詢 initialClusterVersion 資源：

  gcloud container clusters describe [cluster_name] --location [location] --format='value(initialClusterVersion)'

如果 GKE 叢集已啟用記錄功能，cilium-agent 容器會使用下列查詢，在 Logs Explorer 中記錄 unable to resolve identity: timed out waiting for cilium-operator to allocate CiliumIdentity for key 訊息：

   resource.type="k8s_container"
   resource.labels.container_name="cilium-agent"

解決方法：

暫時的緩解方法是重新啟動控制層。只要將控制層升級至目前執行的版本，即可達成這個目的：

  gcloud container clusters upgrade [cluster_name] --location [location] --cluster-version=[version] --master
1.27,1.28,1.29,1.30,1.31

從 Service 移除通訊埠後，NEG 控制器會停止管理端點

如果 NEG 控制器設為建立 Service 的獨立 NEG，且其中一個設定的通訊埠後來從 Service 中移除，NEG 控制器最終會停止管理 NEG 的端點。除了使用者建立獨立 NEG 註解的 Service 之外，這也會影響 GKE Gateway、MCI 和 GKE 多叢集閘道參照的 Service。

解決方法：

從含有獨立 NEG 註解的 Service 移除通訊埠時，也必須更新註解，移除相關通訊埠。
1.28

閘道 TLS 設定錯誤

我們發現，在執行 GKE 1.28.4-gke.1083000 版的叢集中，為閘道設定 TLS 時會發生問題。這會影響使用 SSLCertificate 或 CertificateMap 的 TLS 設定。如果您要升級含有現有閘道的叢集，系統將無法更新閘道。如果是新的閘道，系統不會佈建負載平衡器。這個問題將在日後的 GKE 1.28 修補程式版本中修正。
1.27,1.28,1.29
  • 1.26.13-gke.1052000 以上版本
  • 1.27.10-gke.1055000 以上版本
  • 1.28.6-gke.1095000 以上版本
  • 1.29.1-gke.1016000 以上版本

間歇性連線建立失敗

控制層版本為 1.26.6-gke.1900 以上版本的叢集，可能會間歇性發生連線建立失敗的問題。

失敗機率很低，而且不會影響所有叢集。症狀出現幾天後，失敗情形應該會完全停止。

1.27,1.28,1.29
  • 1.27.11-gke.1118000 以上版本
  • 1.28.7-gke.1100000 以上版本
  • 1.29.2-gke.1217000 以上版本

Container-Optimized OS 的 DNS 解析問題

在 GKE 叢集上執行的工作負載 (節點以 Container-Optimized OS 為基礎) 可能會發生 DNS 解析問題。
1.28 1.28.3-gke.1090000 以上版本

網路政策因連線追蹤查詢不正確而捨棄連線

如果叢集已啟用 GKE Dataplane V2，當用戶端 Pod 使用 Service 或內部直通式網路負載平衡器的虛擬 IP 位址連線至自身時，由於資料層中的 conntrack 查詢不正確，回覆封包不會被視為現有連線的一部分。這表示限制 Pod 輸入流量的網路政策，不正確地對封包強制執行。

這個問題的影響取決於為 Service 設定的 Pod 數量。舉例來說，如果 Service 有 1 個後端 Pod，連線一律會失敗。如果 Service 有 2 個後端 Pod，連線失敗率為 50%。

解決方法：

如要緩解這個問題，請將 Service 資訊清單中的 port 和 containerPort 設為相同的值。
1.27,1.28
  • 1.28.3-gke.1090000 以上版本
  • 1.27.11-gke.1097000 以上版本

髮夾連線流程的封包捨棄

如果叢集已啟用 GKE Dataplane V2，當 Pod 使用 Service 建立與自身的 TCP 連線，導致 Pod 同時是連線的來源和目的地時，GKE Dataplane V2 eBPF 連線追蹤功能會錯誤追蹤連線狀態，導致 conntrack 項目外洩。

如果連線元組 (通訊協定、來源/目的地 IP 和來源/目的地通訊埠) 外洩，使用相同連線元組的新連線可能會導致傳回的封包遭到捨棄。

解決方法：

請使用下列其中一種解決方法：

  • 為在 Pod 中執行的應用程式啟用 TCP 重複使用 (持續連線) 功能，該應用程式可能會使用 Service 與自身通訊。這樣可以防止系統發出 TCP FIN 旗標，並避免洩漏 conntrack 項目。
  • 使用短期連線時，請透過 Proxy 負載平衡器 (例如閘道) 公開 Pod，以便公開 Service。這會導致連線要求的目的地設為負載平衡器 IP 位址，進而防止 GKE Dataplane V2 對回送 IP 位址執行 SNAT。
早於 1.31.0-gke.1506000 1.31.0-gke.1506000 以上版本

GKE 多網路中的裝置類型網路因網路名稱過長而失敗

叢集建立失敗，並顯示下列錯誤：

error starting very-long-string-that-exceeds-character-limit-gpu-nic0 device plugin endpoint: listen unix /var/lib/kubelet/plugins_registry/networking.gke.io.networks_very-long-string-that-exceeds-character-limit-gpu-nic0.sock: bind: invalid argument

解決方法：

裝置類型網路物件名稱的長度上限為 41 個半形字元。系統會組合每個 UNIX 網域通訊端的完整路徑，包括對應的網路名稱。Linux 對通訊端路徑長度有限制 (107 個位元組以下)。考量目錄、檔案名稱前置字元和 .sock 副檔名後，網路名稱長度上限為 41 個字元。
1.27、1.28、1.29、1.30
  • 1.30.4-gke.1282000 以上版本
  • 1.29.8-gke.1157000 以上版本
  • 1.28.13-gke.1078000 以上版本
  • 1.27.16-gke.1342000 以上版本

控制層升級後，hostPort Pod 發生連線問題

如果叢集已啟用網路政策，hostPort Pod 可能會發生連線問題。此外，新建立的 Pod 可能需要額外 30 到 60 秒才能準備就緒。

當叢集的 GKE 控制層升級至下列任一 GKE 版本時，就會觸發這個問題

  • 1.30 至 1.30.4-gke.1281999
  • 1.29.1-gke.1545000 至 1.29.8-gke.1156999
  • 1.28.7-gke.1042000 至 1.28.13-gke.1077999
  • 1.27.12-gke.1107000 至 1.27.16-gke.1341999

解決方法：

GKE 控制層升級後，立即升級或重新建立節點。
1.31、1.32
  • 1.32.1-gke.1729000 以上版本
  • 1.31.6-gke.1020000 以上版本

在同一節點上執行的 Pod 之間，UDP 流量中斷

如果叢集已啟用節點內瀏覽功能，在相同節點上執行的 Pod 之間，UDP 流量可能會中斷。

當 GKE 叢集節點升級至或建立為下列任一 GKE 版本時，就會觸發這個問題：

  • 1.32.1-gke.1729000 以上版本
  • 1.31.6-gke.1020000 以上版本

受影響的路徑是透過 Hostport 或 Service，在同一節點上的 Pod 對 Pod UDP 流量。

解析度

將叢集升級至下列其中一個修正版本：

  • 1.32.3-gke.1927000 以上版本
  • 1.31.7-gke.1390000 以上版本
1.28、1.29、1.30、1.31

如果叢集的節點總數少於 3 個，且 vCPU 不足，Calico Pod 的健康狀態會不良

如果叢集符合下列所有條件，就無法排定 calico-typha 和 calico-node Pod：節點總數少於 3 個、每個節點有 1 個或更少的可分配 vCPU，以及啟用網路政策。這是因為 CPU 資源不足。

解決方法：

  • 縮減至至少 3 個節點集區，每個集區有 1 個節點，使用 1 個可分配的 vCPU。
  • 將單一節點集區的大小調整為至少 3 個節點，並分配 1 個 vCPU。
  • 在單一節點的節點集區中，使用至少有 2 個可分配 vCPU 的機器類型。

控制層升級期間，可用區叢集的多叢集閘道 (MCG) 服務中斷

在 GKE 可用區叢集上使用多叢集閘道 (MCG) 的部署作業，可能會在導致控制層重新啟動的事件 (例如叢集升級) 期間發生中斷，並出現「503」錯誤。這是因為 MCG 仰賴舊版機制探索網路端點群組 (NEG)，當可用區叢集中的節點在控制層重新啟動期間暫時無法使用時，該機制會誤報後端數量為零。這會導致負載平衡器移除所有後端，造成流量遺失。

解決方法：

  • 建議您從可用區 GKE 叢集遷移至區域性 GKE 叢集。區域叢集具備高可用性的控制層，可避免單點故障，因此在升級或重新啟動時不會發生這個問題。

在某些情況下，readiness gate 可能會在 Ingress 健康狀態檢查回報健康狀態良好之前，傳回「偽陽性」的就緒狀態，並在 Ingress 物件上產生類似下列的錯誤事件：

NEG is not attached to any BackendService with health checking. Marking condition "cloud.google.com/load-balancer-neg-ready" to True.

GKE 對 Deployment 工作負載執行滾動式更新時，這個問題會導致負載平衡器向流量回報 503 錯誤 (failed_to_pick_backend)。

如果 Pod 數量 (例如 2 個) 遠少於 NEG 數量，發生這種競爭狀況的風險就會增加。系統會為每個區域建立 NEG，每個可用區一個 NEG，通常會產生三個 NEG。如果 Pod 數量相對較多，在滾動式更新開始前，每個 NEG 都有多個 Pod，則不太可能觸發這個競爭狀況。

解決方法：

如要避免這種競爭狀況，最好的方法是在網路端點群組中加入更多後端。請務必設定滾動式更新策略，確保至少有 1 個 Pod 隨時在運作。舉例來說，如果只有 2 個 Pod 正常運作，設定範例如下：

strategy:
   type: RollingUpdate
   rollingUpdate:
     maxUnavailable: 0
     maxSurge: 1

上述範例僅供參考。您必須根據多項因素 (例如副本數量) 更新策略。

GKE 每兩分鐘會對容器原生負載平衡器執行垃圾收集。如果在負載平衡器完全移除前刪除叢集，則須手動刪除負載平衡器的 NEG。

解決方法：

請執行下列指令來查看專案裡的 NEG：

gcloud compute network-endpoint-groups list

在指令輸出中，找出相關的 NEG。

如要刪除 NEG，請執行下列指令，並將 <var>NEG_NAME</var> 替換為 NEG 的名稱：

gcloud compute network-endpoint-groups delete <var>NEG_NAME</var>

如果叢集使用 Pod 就緒回饋功能管理工作負載推出作業，就不會發生這個問題。將工作負載部署至叢集或更新現有工作負載時，容器原生負載平衡器傳播新端點所需的時間，可能會比完成工作負載推出作業的時間更長。


解決方法：

將工作負載的 minReadySeconds 和 terminationGracePeriodSeconds 值設為 60 秒以上，確保服務不會因工作負載推出而中斷。

  • terminationGracePeriodSeconds 會在 Pod 排定刪除後等待連線終止，讓 Pod 正常關閉。
  • minReadySeconds 會在 Pod 建立後新增延遲時間。

您可能會預期容器原生負載平衡器會遵循 Pod readinessProbe 中的 initialDelaySeconds 設定，但 readinessProbe 是由 kubelet 實作，且 initialDelaySeconds 設定控制的是 kubelet 健康狀態檢查，而非容器原生負載平衡器。容器原生負載平衡有專屬的負載平衡健康狀態檢查。