開發者必備的 GKE 簡介
Google Kubernetes Engine (GKE) 是 Google Cloud 的代管 Kubernetes 服務。在 PCD 考試中，當工作負載需要黏著的 Pod 身分、Service Mesh 層級的細緻流量控制、附著於特定 Pod 的有狀態儲存，或是 Kubernetes 原生的 Operator 時，GKE 就是標準答案。考試不會考你 kubelet 的調校細節，而是測試你能否選對模式（Autopilot 還是 Standard）、能否正確設定身分（用 Workload Identity 取代靜態金鑰）、能否讓 Pod 在重啟後真的活下來（探查機制），以及面對眼前的失敗模式時能否選對自動擴展器（HPA、VPA 或 Cluster Autoscaler）。
本指南會走過每一個開發者面對的介面：叢集模式選擇、Workload Identity、liveness/readiness/startup 探查、三種自動擴展器的分層、ConfigMap/Secret/Secret Manager CSI 模式、Ingress 與 Gateway API、StatefulSet 行為、Backup for GKE、Multi-Cluster Ingress、GKE Sandbox (gVisor)、Dataplane V2 (Cilium eBPF)、區域與單區叢集，以及 Image Streaming。
白話文解釋
三個類比能在你深入 API 介面前先抓住 GKE 的精髓。
類比 1：Autopilot 與 Standard 像住飯店與買房子
GKE Standard 像買房子：你擁有土地（節點），自己挑家電（機器類型），自己決定何時粉刷（節點升級），就算你出國睡別處還是要繳稅（閒置節點照計費）。GKE Autopilot 像住飯店套房：你告訴櫃台需要幾張床（Pod 的 resource requests），員工負責水電、暖氣與保全。你按 Pod 的每秒用量付費——只付你真正睡的部分。你不能重新配線整棟建築，也不能在住宿中把套房改成獨棟房屋。同理，現有叢集無法就地在 Autopilot 與 Standard 之間切換，必須建立新模式的叢集，再把工作負載遷移過去。
類比 2：Workload Identity 是訪客識別證，不是萬能鑰匙
把 service account JSON 金鑰寫死在程式裡，等同於把整棟大樓的萬能鑰匙影印貼在每台筆電上。一台筆電遺失，整棟大樓就淪陷。Workload Identity 則是訪客識別證系統：每個 Pod 的 Kubernetes ServiceAccount (KSA) 透過 annotation 綁到 Google ServiceAccount (GSA)，GKE metadata server 會發給該 Pod 一張短效權杖，授權範圍只限於該 GSA。Pod 從頭到尾都沒看過任何私鑰。要撤銷權限只需要改一條 IAM 政策，不必全機隊輪換金鑰。
類比 3：探查機制是機場的三種不同健康檢查
Startup probe（啟動探查）像航空公司問「你登機完成了嗎？」——在漫長的初始啟動期間執行一次，並在通過前讓其他探查靜音。Readiness probe（就緒探查）像登機門地勤問「這架飛機現在可以載客嗎？」——失敗時 Pod 會從 Service 的負載平衡器中移除但不會被殺掉，因為可能只是 GC 暫停。Liveness probe（存活探查）像空服員問「駕駛艙裡還有人活著嗎？」——失敗時 kubelet 會殺掉容器並重啟，因為這個程序已無法恢復。把它們搞混是 GKE 設定錯誤最常見的考點：在漫長啟動期設定會失敗的 liveness probe 會讓 Pod 進入無止盡的當機循環。
Autopilot 與 Standard
GKE 有兩種運作模式。選對是新專案的第一個決策，也是最可能出現在考試裡的題目。
Autopilot 為你管理什麼
Autopilot 全權管理每個節點：佈建、機器類型選擇、作業系統、安全修補、升級與節點池的合適化。你只需要宣告 Pod（含明確的 resources.requests），Google 按 Pod 的 vCPU/記憶體/暫存儲存每秒計費。沒有節點 SSH 入口，系統命名空間上不能跑 DaemonSet，也不能執行特權容器——Autopilot 預設就強化了安全姿態（Shielded GKE Nodes、強制 Workload Identity、沒有 kubelet 憑證輪換的介面可以搞砸）。
Standard 給你的彈性
Standard 把節點池 API 開放給你。你挑機器類型（e2-standard-4、n2-highmem-8、附 GPU 的 a2-highgpu-1g），設定節點數或自動擴展上下限，在 Container-Optimized OS 與 Ubuntu 之間選擇，掛載 Local SSD，允許特權容器，跑系統 DaemonSet（Datadog 代理、自訂 CNI 輔助元件），調整 kubelet 旗標。代價是每個節點不論 Pod 密度高低都要照小時計費。
模式轉換的陷阱
你無法在 Autopilot 與 Standard 之間切換現有叢集。gcloud container clusters create-auto 與 gcloud container clusters create 都會產生模式不可變的叢集。要遷移就得建立目標模式的新叢集，透過 GitOps 或 kubectl apply 套用工作負載，再用 Multi-Cluster Ingress 或 DNS 切換流量。請在一開始就規劃好——考試題目問「如何切換」時，標準答案就是「建立新叢集並遷移」。
如何選擇
新建的微服務、Web API、批次工作，或任何你想把維運面縮到最小的場景，選 Autopilot。需要 GPU、TPU、Local SSD、Windows Server 節點、特權 DaemonSet（早期的 Istio sidecar 注入器是一例，現在 Autopilot 已透過 Istio Operator 原生支援）、為授權軟體加上自訂節點 taint，或為了記憶體密集的單租戶工作負載做嚴格的每節點裝箱時，才選 Standard。
Workload Identity
Workload Identity 是 GKE 上 Pod 呼叫 Google Cloud API 的唯一官方推薦方式，完全取代「把 service account JSON 金鑰塞進 Secret」這種老派模式。
KSA → GSA 綁定機制
運作機制：某個命名空間 prod 下的 KSA 加上 annotation iam.gke.io/gcp-service-account: [email protected]，再透過 GSA 上的 IAM policy binding 把它綁到 principal serviceAccount:my-project.svc.id.goog[prod/my-ksa]。當 Pod 使用這個 KSA 時，GKE metadata server 會攔截對 metadata.google.internal 的呼叫，回傳由連結 GSA 鑄造的短效 OAuth 權杖。整個叢集裡沒有任何金鑰檔案存在。
如何啟用
在 Autopilot 上 Workload Identity 預設啟用。在 Standard 上需要在建立叢集時加 --workload-pool=PROJECT_ID.svc.id.goog，並在每個節點池加 --workload-metadata=GKE_METADATA。Metadata server 以 DaemonSet 形式運行，只有當呼叫的 Pod 之 KSA 已正確綁定時才會回傳權杖。
IAM 綁定指令
gcloud iam service-accounts add-iam-policy-binding \
[email protected] \
--role=roles/iam.workloadIdentityUser \
--member="serviceAccount:my-project.svc.id.goog[prod/my-ksa]"
光靠 KSA 上的 annotation 是不夠的，兩邊都得設定。
Workload Identity 是 GKE Pod 存取 Google Cloud API（BigQuery、GCS、Pub/Sub、Spanner）唯一安全的方式。把靜態 service account 金鑰掛載成 Secret 是考試陷阱的反模式：無法在不重新部署的情況下輪換、會透過容器自省外洩、生命週期長於 Pod。Annotation 鍵值正是 iam.gke.io/gcp-service-account，大小寫與連字號都不能錯。
Pod 探查機制：Liveness、Readiness、Startup
Kubernetes 內建三種探查。搞混它們是最常見的 Pod 當機循環原因，而且很難診斷。
Liveness Probe（存活探查）
Liveness probe 在啟動完成後持續執行。若連續失敗 failureThreshold 次，kubelet 會殺掉容器並重啟。只有在不可恢復的情況才該使用：執行緒死結、應用無法自癒的連線池耗盡、無止盡的 GC 迴圈。如果只因為下游短暫變慢就讓 liveness probe 回 500，會造成連鎖故障——Pod 自己殺自己，替換上來的 Pod 也失敗，等於是自己製造一場故障。
Readiness Probe（就緒探查）
Readiness probe 控制 Pod 的 IP 是否出現在 Service Endpoints 物件中。失敗時流量會停止導入；通過時流量會恢復。Pod 不會被殺。Readiness 用在短暫的狀況：部署後的快取暖機、正在退避某個下游限流、正在進行 GC 暫停。大多數應用該倚賴 readiness probe；liveness probe 該保守設定。
Startup Probe（啟動探查）
Startup probe 在 Pod 啟動時執行一次，並在它運作期間讓 liveness 與 readiness 停擺。這解決了 JVM 暖機的痛點：一個需要 90 秒才啟動的應用，會被任何依照穩態延遲設定的激進 liveness probe 弄死。設成 failureThreshold: 30, periodSeconds: 10（5 分鐘寬限）後，kubelet 會等應用真正啟動再套用嚴格的 liveness 規則。
探查類型
三種探查接受相同的探查處理器：httpGet（路徑、port、scheme、選用 headers）、tcpSocket（port）、exec（容器內執行的指令）、以及較新的 grpc（port + service）。HTTP 服務用 httpGet，gRPC 用 grpc（從 Kubernetes 1.24 起原生支援），exec 盡量少用，因為每次探查都會 fork 一個程序。
把 startupProbe.failureThreshold * periodSeconds 設成觀測到的 P99 冷啟動時間至少 2 倍。需要 45 秒暖機的 Pod 就該給大約 90 秒的啟動寬限。同時把 terminationGracePeriodSeconds: 30 配上，讓優雅關閉有時間排空進行中的請求。
HPA、VPA 與 Cluster Autoscaler
GKE 有三種獨立的自動擴展器，各自解決不同問題。它們可以組合使用，但你得先知道每一個移動的是哪個維度。
Horizontal Pod Autoscaler (HPA)
HPA 根據指標改變 Pod 的副本數量。預設指標是 CPU 用量相對於 resources.requests.cpu——當目標設成 50%、requests.cpu=500m 時，HPA 會試圖把每個 Pod 的平均 CPU 維持在 250m 上下，超過就增加副本。HPA 也支援記憶體、Cloud Monitoring 提供的自訂指標（透過 Custom Metrics Adapter），以及外部指標（Pub/Sub 佇列深度、Cloud Tasks 積壓）。透過 HorizontalPodAutoscaler 資源以 minReplicas、maxReplicas、metrics 設定。
Vertical Pod Autoscaler (VPA)
VPA 根據觀測到的用量改變 Pod 的 CPU 與記憶體 requests。它有三種模式：Off（只給建議）、Initial（在 admission 時設定 requests，之後不動）、Auto（觀測值漂移時驅逐並用新 requests 重建 Pod）。VPA 對於你還抓不準理想 request 尺寸的工作負載最有用——長尾批次工作、輸入大小變化莫測的 ML 推論。不要讓 VPA Auto 與 HPA 同時作用於 CPU/記憶體：兩者會互打。官方支援的搭配是 HPA 跑自訂指標（佇列深度）+ VPA Auto 跑 CPU/記憶體。
Cluster Autoscaler
Cluster Autoscaler 改變節點池內的節點數量。當有 Pod 因為沒節點容得下而 Pending 時，自動擴展器會佈建新節點。當節點低度使用超過 --scale-down-unneeded-time（預設 10 分鐘）時，會排空並移除節點。Autopilot 上這是自動的；Standard 上你要為每個節點池加 --enable-autoscaling --min-nodes=N --max-nodes=M。
三種自動擴展器移動的是三件不同的事：HPA = Pod 變多、VPA = Pod 變大、Cluster Autoscaler = 節點變多。在 Autopilot 上你只需要想 HPA 與 VPA，因為節點是隱形的。在 Standard 上三者層層疊加：HPA 加 Pod，Pod 變成 Pending，Cluster Autoscaler 加節點。只有在非資源指標上才可以把 VPA Auto 與 HPA 並用。
ConfigMap、Secret 與 Secret Manager CSI Driver
GKE 提供三種把組態注入 Pod 的方式。Secret Manager CSI driver 是目前推薦處理敏感值的現代化途徑。
ConfigMap
ConfigMap 存放非敏感的 key/value 資料，可掛載成環境變數或檔案。更新 ConfigMap 後，掛載的檔案大約 60 秒內會自動傳播，Pod 不必重啟——適合可調參數。它不會在 etcd 預設加密以外提供額外加密，且 kubectl get configmap -o yaml 會把全部內容曝光。
原生 Secret
Kubernetes 的 Secret 資源是 base64 編碼，並非加密。預設儲存於 etcd，GKE 會用 Google 管理金鑰加密落地。啟用 Application-layer Secrets Encryption 後，GKE 會用你掌控的 Cloud KMS 金鑰加密 Secret。輪換時必須 kubectl apply 新的 Secret 物件，並重啟 Pod 或仰賴（最終一致的）projected volume 更新。
Secret Manager CSI Driver
推薦的模式：把機密存進 Secret Manager，透過 Secret Store CSI Driver 的 Secret Manager CSI provider 掛載進 Pod。Pod 看到的是 /secrets/my-key 這樣的檔案；Secret Manager 負責輪換、稽核日誌、IAM 與版本鎖定。CSI driver 透過 Workload Identity 對 Secret Manager 認證——沒有靜態金鑰、沒有 Kubernetes Secret 物件、沒有 etcd 曝險。
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
name: db-creds
spec:
provider: gke
parameters:
secrets: |
- resourceName: "projects/PROJECT/secrets/db-password/versions/latest"
path: "db-password"
正式環境的任何認證請優先使用 Secret Manager CSI driver + Workload Identity 而非原生 Kubernetes Secret。這個組合給你 Secret Manager 的版本歷史、IAM 驅動的存取控制、Cloud KMS 後盾加密，以及不必重新部署 Pod 就能完成的輪換。只有對於不值得 CSI 開銷的短效不透明 token 才考慮原生 Secret。
Ingress 與 Gateway API
GKE 支援兩種南北向流量 API。Gateway API 是現代化的後繼者，Ingress 仍然可用但功能上限較低。
GKE Ingress
GKE Ingress 是最早的 Kubernetes Ingress 實作，背後是 Google Cloud Load Balancing。annotation kubernetes.io/ingress.class: gce 會佈建外部 HTTPS Load Balancer，gce-internal 則佈建內部版本。支援路徑與主機名稱路由、Google 管理 SSL 憑證（networking.gke.io/managed-certificates）、Cloud Armor 政策、IAP 整合與 Cloud CDN。屬於單一叢集；多叢集版本要走 Multi-Cluster Ingress。
Gateway API
Gateway API 是 Kubernetes 上游 Ingress 的繼任者：模型更豐富，分成三層資源——GatewayClass（提供者層級）、Gateway（單一負載平衡器實體）、以及附在它上面的 HTTPRoute/TCPRoute/TLSRoute。GKE Gateway controller 提供幾種 GatewayClass 選項：gke-l7-global-external-managed、gke-l7-regional-external-managed、gke-l7-rilb（內部）、gke-l7-gxlb（多叢集）。Gateway API 原生支援進階流量管理——加權路由、依 header 路由、流量鏡像——這些在 Ingress 要靠自訂 annotation 才能勉強做到。
何時選哪個
單一叢集、簡單 HTTPS 路由加管理憑證，就用 Ingress。需要多叢集拓撲、流量切分部署（canary），或任何你會想伸手拿 Istio VirtualService 但其實用不到完整服務網格的場景，就用 Gateway API。
StatefulSet 用於資料庫與有狀態工作負載
GKE 上多數工作負載是無狀態 Deployment。例外是 StatefulSet，這是資料庫、佇列以及需要黏著身分的叢集系統的正確基元。
StatefulSet 提供的保證
StatefulSet 中的每個 Pod 都有穩定的 metadata.name（mysql-0、mysql-1、mysql-2），並透過 headless Service 取得穩定 DNS 名稱。Pod 依序建立與刪除（先 0、再 1、再 2；刪除時順序反向）。每個 Pod 透過 volumeClaimTemplate 取得自己的 PersistentVolumeClaim——終身綁定該 Pod，能在 Pod 重建後存活。
儲存後盾
一般工作負載用 Persistent Disk（pd-balanced、pd-ssd），IOPS 密集的資料庫用 Hyperdisk，需要共享 NFS 存取就用 Filestore CSI。在 GKE Standard 上可掛 Local SSD 取得高吞吐臨時暫存空間——但 Local SSD 為易失性，節點被刪就消失，絕對不要拿來當主資料庫磁碟。
先想代管服務
在動手用 StatefulSet 自架 MySQL 或 PostgreSQL 前，先問問是否 Cloud SQL、Spanner、Memorystore 或 AlloyDB 已能滿足需求。在 GKE 上自架資料庫意味著你得自己處理備份、修補、複寫與故障切換。在 PCD 考試裡，只要題目允許使用代管資料庫，就優先選代管服務；StatefulSet 該是答案的情境是工作負載真的需要某種沒有代管版本的資料庫（Cassandra、ScyllaDB、自訂 Elasticsearch）。
Backup for GKE
Backup for GKE 是官方支援用來備份叢集狀態與 PersistentVolume 資料的工具。獨立計費並支援跨區還原。
它會備份什麼
BackupPlan 會擷取你指定的命名空間範圍與叢集範圍 Kubernetes 物件（Deployment、Service、ConfigMap、Secret、CRD），加上使用 pd.csi.storage.gke.io 驅動程式之 PersistentVolume 的內容。備份可以排程（cron 語法）、設定保留期，並用 Cloud KMS 金鑰加密。
還原範圍
RestorePlan 定義要還原的內容：整個叢集、某個命名空間，或依 label 篩選的子集合。對應的 Restore 資源執行單次還原。跨區還原讓你能把 us-central1 的備份還原到 europe-west1 的叢集——這正是考試 DR 題目的標準答案。
Backup for GKE 中的資源，定義要備份什麼（哪些命名空間、是否包含 volume 資料）、多久備份一次、保留多久。每個 BackupPlan 會產出一系列不可變的 Backup 資源。來源：About Backup for GKE。
Multi-Cluster Ingress 與機隊管理
當工作負載橫跨多區多個 GKE 叢集執行時，Multi-Cluster Ingress (MCI) 是把流量分送到各後端叢集的單一全球負載平衡器。
MCI 如何運作
把叢集註冊到一個機隊（fleet，舊名 Anthos environ），指定其中一個叢集為 config cluster，並在該叢集上套用 MultiClusterIngress 與 MultiClusterService 資源。MCI 控制器會佈建一個全球外部 HTTPS Load Balancer，backend bucket 指向各成員叢集的 Network Endpoint Group (NEG)。流量會透過 Google premium tier 網路自動導向最近的健康叢集。
何時使用
需要在區域故障時還能存活的全球低延遲面向使用者服務，用 MCI。如果服務只跑單一區域而你能接受冷切換的故障時間，單叢集 Ingress 就夠了。
Fleet Identity
機隊成員關係也啟用了 Fleet Workload Identity，把 Workload Identity 模型延伸到整個機隊——us-cluster 與 eu-cluster 上的工作負載都可以用機隊身分池冒充同一個 GSA，簡化多區 IAM。
GKE Sandbox (gVisor)
GKE Sandbox 在容器外再加一層隔離，用來執行不可信任的程式碼。
gVisor 做的事
gVisor 是一個使用者空間核心，攔截容器發出的系統呼叫，並用 Go 重新實作，拒絕危險的呼叫。主機核心永遠不會看到沙箱化容器發出的原生系統呼叫，攻擊面大幅縮小。代價是依照系統呼叫組合不同，會帶來 5%~30% 的效能損耗。
如何啟用
在 Standard 上建立節點池時加 --sandbox=type=gvisor。Pod 透過 spec.runtimeClassName: gvisor 加入沙箱。Autopilot 用同一個 runtimeClassName annotation 即可；Google 會自動把 Pod 放到具備 gVisor 能力的節點上。
何時使用
多租戶 SaaS 上跑客戶提供的程式碼、執行任意建置步驟的 CI/CD job runner，或在平台上編譯使用者上傳的原始碼，這些場景就用 Sandbox。不要用在受信任的第一方工作負載上——效能損耗是實在的，效益則是零。
Dataplane V2 (Cilium eBPF)
Dataplane V2 用 Cilium 搭配 eBPF 取代舊版 kube-proxy + iptables 的資料平面。
改變了什麼
Service IP 查詢、NetworkPolicy 強制執行，以及 Pod 之間連線的追蹤，全部從 iptables 規則（在超過約 5000 個 service 時規模就崩潰）移到附在核心網路堆疊上的 eBPF 程式。結果是高 service 數量下延遲更低、透過 hubble 取得實際可視性（flow log），以及更強的 NetworkPolicy 支援，包括 iptables 表達不出的 FQDN 為基礎的 egress policy。
如何啟用
新叢集要加 --enable-dataplane-v2。一旦啟用就無法回退。新版本的 Autopilot 預設使用 Dataplane V2。考試效益：「我有 10,000 個 service 而 kube-proxy 快撐不住」與「我需要在 GKE 上做 FQDN 為基礎的 egress policy」這兩個情境的答案就是 Dataplane V2。
Dataplane V2 也啟用了 Network Policy logging 與 Hubble UI 的流量視覺化——這些功能原本要裝 Istio 才有。如果題目問你如何在 GKE 上不靠服務網格觀察 Pod 對 Pod 流量，答案就是 Dataplane V2 + Hubble。
區域叢集與單區叢集
GKE 叢集有兩種可用性形態，會影響控制平面與資料平面的韌性。
單區叢集（Zonal Cluster）
單區叢集在單一可用區內只有一個控制平面副本。該可用區故障時，API server 不可用；既有的 Pod 還會繼續執行，但你無法部署、擴展或自癒。節點可以橫跨同區多個可用區（--node-locations），但控制平面是單點故障。單區叢集較便宜，適合開發與測試環境。
區域叢集（Regional Cluster）
區域叢集在區域內橫跨三個可用區運行三個控制平面副本，前端有區域 ILB。失去一個可用區時 API 仍可用。區域叢集中的節點池預設會分散到三個可用區，因此單一可用區故障最多移除三分之一的資料平面。正式環境工作負載預設就該選區域。
成本取捨
區域叢集要為三個控制平面副本付費，單區只付一個。每個帳單帳號的第一個單區叢集免費；之後不論單區或區域都按每叢集每小時費率計費。正式環境沒有折衷空間——SLA 只有區域叢集享有 99.95%。
Image Streaming
拉一個大型容器映像可能要好幾分鐘。Image Streaming 讓 Pod 在映像完全下載前就能啟動。
運作原理
啟用 Image Streaming 時，GKE 把容器的 root 檔案系統掛載成由 Artifact Registry 後援的遠端 FUSE 檔案系統。容器第一次讀取某個檔案時才會抓取它。一個 4 GB 的映像，啟動時若只觸碰 200 MB 的檔案，可以從幾分鐘縮短到幾秒就啟動。
啟用與限制
Standard 上要每個節點池加 --enable-image-streaming。Autopilot 自動使用 Image Streaming。映像必須位於 Artifact Registry（舊的 gcr.io registry 不支援）。對於沒有受益的映像（小映像、啟動時就要碰所有檔案的映像），Image Streaming 不會增加成本但也沒益處——Google 廣泛啟用它的原因是最壞情境也只是與傳統拉取打平。
對於每個任務都會起新 Pod 的批次工作，Image Streaming 能把冷啟動從 90 秒降到 10 秒以內。搭配 Artifact Registry 的虛擬儲存庫讓多個團隊共用基底層，並用漏洞掃描確保進入正式環境的映像 SBOM 乾淨。
常見問題 (FAQs)
Q1：可以把現有 Standard 叢集就地轉成 Autopilot 嗎？
A1：不行。叢集模式在建立時就決定且不可變。官方支援的遷移路徑是：建立新的 Autopilot 叢集，透過 GitOps 或 kubectl apply 套用 manifest，驗證後用 Multi-Cluster Ingress 或 DNS 切換流量。要遷移 PersistentVolume 資料最快的方式是 Backup for GKE 加上還原到新叢集。
Q2：什麼時候用 VPA Auto，什麼時候用 HPA？
A2：負載突發、副本數量該即時反應時用 HPA——大多數 Web API 就是這樣。負載穩定但你最初的 resources.requests 設定是猜的、且工作負載可以容忍 VPA 重新調整時偶爾的 Pod 重啟，就用 VPA Auto。不要把 VPA Auto 與 HPA 用在同一個資源上（兩者都看 CPU）：它們會互打。官方支援的組合是 HPA 跑自訂指標（佇列深度）+ VPA Auto 跑 CPU/記憶體。
Q3：實務上 liveness probe 與 readiness probe 差在哪？
A3：Liveness probe 失敗會殺掉容器。Readiness probe 失敗會把 Pod 從 Service 負載平衡器移除但讓它繼續活著。Readiness probe 該設得激進（下游一慢就快速失敗）、liveness probe 該保守（只有真正死結時才失敗）。對於啟動慢的應用，配上 failureThreshold 寬鬆的 startup probe，避免 liveness 殺掉健康但還在暖機的 Pod。
Q4：如何在不重新部署 Pod 的情況下輪換資料庫認證？
A4：把認證存進 Secret Manager，透過 Secret Manager CSI driver 掛載，並在 SecretProviderClass 設定 auto-rotation: true（透過 projected volume 同步間隔）。會重新讀取認證檔案的 Pod 程序會自動拿到新值。如果應用會在啟動時把認證快取在記憶體裡，那就需要重啟——這種情況下做滾動式重啟即可，仍比重發 Kubernetes Secret 再套用 manifest 便宜。
Q5：為什麼我的 Pod 一部署完就卡在 CrashLoopBackOff？
A5：四個最常見原因：(1) liveness probe 設太激進，在應用完成暖機前就殺掉容器——加 startup probe；(2) 映像有拉到，但容器離開是因為沒綁 $PORT——檢查容器日誌；(3) GSA 上缺少 IAM 綁定使 Workload Identity 鑄不到權杖——檢查 gcloud iam service-accounts get-iam-policy；(4) resource requests 太低使 OOM killer 開火——kubectl describe pod 看有沒有 OOMKilled。
Q6：新專案該選 GKE Ingress 還是 Gateway API？
A6：新建工作負載優先選 Gateway API——這是 Kubernetes 官方欽定的繼任者，原生支援加權路由與流量切分，多叢集故事透過 gke-l7-gxlb 更完整。只在你維護既有 manifest、需要僅 Ingress 才有的功能（某個特定 annotation），或你的工具鏈還沒跟上 Gateway API 時才繼續用 Ingress。
Q7：Backup for GKE 實際上備份了什麼？
A7：BackupPlan 擷取 Kubernetes API 物件（你選取的命名空間範圍與叢集範圍資源），加上使用 pd.csi.storage.gke.io 驅動程式之 PersistentVolume 的內容。它不會備份位於叢集外的資料（Cloud SQL、GCS、Spanner）——這些服務請用它們自身的備份工具。還原可以指向同一叢集、同區域的另一叢集，或為了 DR 指向另一個區域的叢集。