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 Guest Agent 會在 Windows Server 上預設啟用 CorePlugin，並將負載平衡器虛擬 IP (VIP) 位址直接動態繫結至主機網路介面卡 (vEthernet (Ethernet))，做為次要 /32 位址。傳送至 VIP 的輸出流量會迴圈回到主機並遭到捨棄，而傳送至 GKE 控制層 (Kubernetes API 伺服器) 或 Cloud de Confiance by S3NS 中繼資料伺服器 (169.254.169.254) 的輸出連線，會間歇性地選取次要 VIP 做為來源 IP 位址，導致連線逾時。

解決方法：

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

  • 啟用 L4 子設定 (建議用於內部負載平衡器)：將 gke.googleapis.com/subsetting: "true" 註解新增至內部 LoadBalancer 服務規格，然後重新建立或執行 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
  • 使用以後端服務為基礎的外部負載平衡器：如要進行外部負載平衡，請將以目標集區為基礎的舊服務遷移至以後端服務為基礎的外部負載平衡器。
  • 使用節點開機指令碼停用 Guest Agent 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 custom 資源，再匯出：

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 的叢集可能會發生間歇性連線失敗或 DNS 解析問題，導致 Pod 無法執行。這個問題是由 cilium-agent (anetd) 啟動程序期間的競爭狀況所造成。

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


解決方法：

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

解決方法：

修正程式已納入 advanceddatapath 元件 33.7.36 以上版本。如要解決這個問題，請將叢集升級至「已修正版本」欄中列出的其中一個版本。
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 和服務負載平衡器中斷問題

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

如果 GKE 叢集使用舊網路，且版本為 1.31 以上，就會受到這個問題影響。

如要找出使用舊版網路的 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 層內部負載平衡器

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

如果叢集縮放為零個節點，然後再縮放回一或多個節點，這個問題就會最明顯。

解決方法：

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

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

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

因從 CRD 狀態移除 storedVersions 而導致 Gateway API 發生問題

GKE 中的 Kube-Addon-Manager 會錯誤地從 Gateway API CRD (例如 gateway、httpRoute、gatewayClass 和 referenceGrant) 的狀態中移除 v1alpha2 storedVersion。即使叢集仍有以 v1alpha2 格式儲存的 CRD 執行個體，仍會發生這個問題。如果未升級 storedVersions 就升級 GKE 叢集版本，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，且 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

如果 GKE 叢集是在 1.31 或 1.32 版中建立，且版本介於 1.32 和 1.32.3-gke.1170000 之間，就會受到這個問題影響。根本原因是維護已分配 Cilium ID 集合的記憶體內資料結構，未與 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

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

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

解決方法：

從具有獨立 NEG 註解的服務中移除通訊埠時，也需要更新註解，移除相關通訊埠。
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 解析問題

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

網路政策因連線追蹤查詢錯誤而捨棄連線

如果叢集已啟用 GKE Dataplane V2，當用戶端 Pod 使用服務或內部直通網路負載平衡器的虛擬 IP 位址連線至自身時，由於資料平面中的 conntrack 查閱作業不正確，回覆封包不會識別為現有連線的一部分。也就是說，限制 Pod 輸入流量的網路政策，在封包上強制執行時發生錯誤。

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

解決方法：

如要解決這個問題，請在服務資訊清單中將 port 和 containerPort 設定為相同值。
1.27、1.28
  • 1.28.3-gke.1090000 以上版本
  • 1.27.11-gke.1097000 以上版本

髮夾連線流程的封包捨棄

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

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

解決方法：

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

  • 為在 Pod 中執行的應用程式啟用 TCP 重複使用 (保持連線)，該應用程式可能會使用 Service 與自身通訊。這樣可防止發出 TCP FIN 標記，並避免洩漏 conntrack 項目。
  • 使用短期連線時，請使用 Proxy 負載平衡器 (例如 Gateway) 公開 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 或服務的 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 個、每個節點的可分配 vCPU 數量為 1 個或更少，以及已啟用網路政策。這是因為 CPU 資源不足。

解決方法：

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

控制層升級期間，區域叢集上的多叢集閘道 (MCG) 中斷

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

解決方法：

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

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

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

當 GKE 對部署工作負載執行滾動式更新時，這個問題會導致負載平衡器向流量回報 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 健康狀態檢查，而非容器原生負載平衡器。容器原生負載平衡有自己的負載平衡健康狀態檢查。