GCPReady：表示 Google Cloud 已準備好所有必要資源。 Google Cloud 資源佈建程序期間發生的錯誤會反映在 GCPReady 條件的狀態中。
DPV2Ready：表示資料路徑程式設計的狀態，例如資料路徑已準備就緒並完成程式設計，可允許設定的持續性 IP 位址建立網路連線。
Ready：表示您的持續性 IP 位址設定有效且可正常運作。只要您已將應用程式設定為使用這些 IP 位址，就能透過這些位址連線至 Pod。如果前述三項條件也都是 True，這項條件就會設為 True。
回應模式
反應模式會決定系統在連結至持續性 IP 位址的 Pod 發生變更時的行為，例如跨節點移動，或是可使用新建立的相符 Pod 時。即使 Pod 發生變化，您也可以使用反應模式，確保持續可用的 IP 位址。
反應模式包括：
ReadyCondition
在「ReadyCondition」ReadyCondition模式中，持續性 IP 位址系統會優先考量 Pod 健康狀態。只有符合指定標籤且通過 Kubernetes 健康狀態探查的 Pod，才會獲得持續性 IP 位址，這表示 Pod 的 Ready 狀態為 True。如果應用程式必須確保接收持續性 IP 位址的 Pod 已完全準備好處理傳入和傳出流量，這個模式就是理想選擇。
存在
「Exists」模式會優先考量 Pod 的存在狀態。如果 Pod 符合設定中的標籤，且已排定在叢集中的特定節點上執行，則會附加持續性 IP 位址。這表示 Pod 存在，且有指定的執行位置。如果快速指派永久 IP 位址比嚴格的就緒狀態更重要，或是處於開發和測試等環境，即時連線可能比完整的應用程式健康狀態更重要，就非常適合使用這個模式。
StatefulSets
StatefulSets 是 Kubernetes 工作負載類型，專為需要穩定 ID 和永久儲存空間的應用程式設計。StatefulSet 中的 Pod 名稱可預測 (例如：my-app-0、my-app-1)。
部署作業
Deployment 是一種 Kubernetes 工作負載，用於管理無狀態應用程式，其中的 Pod 通常可互換。Deployment 中的 Pod 名稱無法完全預測。
用途
對於在 GKE 和 GKE Enterprise 上執行網路相關應用程式的網路和安全防護服務供應商，GKE Pod 的永久 IP 位址可解決多種用途。
GKE Pod 的永久 IP 位址可解決下列用途：
控管 NAT：將持續性 IP 位址指派給執行網路功能的 Pod，即可精細控管用於傳出流量的來源 IP 位址。方便您整合專屬的 NAT 邏輯。
專屬 IP 位址集區：專屬 IP 位址可讓您將特定位址與個別 5G Core Pod 配對，確保與特定供應商軟體的相容性。
可靠的流量流動：由於回程流量必須透過相同的網路功能傳回，因此持續性 IP 位址可確保外部系統辨識並回應正確的 Pod，不會中斷通訊。
優點
GKE Pod 的永久 IP 位址可帶來下列優點：
外部身分：如果為 Pod 指派外部永久 IP 位址，外部系統就能持續連線至該 Pod，即使 Pod 在叢集內重新啟動或移動也一樣。這項功能適用於需要外部可探索端點的服務。
可靠的通訊：如果應用程式依附於具有特定 IP 位址的其他資源，則可使用持續性 IP 位址可靠地建立連線。對於具有硬式編碼 IP 位址依附元件的舊版系統或應用程式，持續性 IP 位址非常重要。
舊版遷移：舊版遷移可協助遷移在轉換程序中需要特定 IP 位址的應用程式。
自備 IP 位址 (BYOIP)：BYOIP 可讓您在 GKE 叢集中使用自己擁有的特定 IP 位址範圍，維持控制權。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-07-30 (世界標準時間)。"],[],[],null,["# About persistent IP addresses for Pods\n\n[Standard](/kubernetes-engine/docs/concepts/choose-cluster-mode)\n\n*** ** * ** ***\n\nThis page explains how you can achieve reliable communication by directly\nassigning one or more persistent (static) IP addresses to specific Pods within\nyour Google Kubernetes Engine (GKE) clusters.\n\nIn certain cases, where you are running a custom Network Address Translation\n(NAT) solution, you might want a static persistent IP address for both outgoing\nand incoming connections, either when the NAT solution initiates the connection\nor when it receives it. You might also want to have control over the IP\naddresses allocated to the application for managing how it interacts with other\nsystems or how it handles specific types of requests based on your business\nrequirements.\n\nBy default, the Pod uses its interface IP addresses for egressing traffic.\nInterface IP addresses change when the Pod restarts or gets moved. To have more\ncontrol over routing communication, you can configure persistent IP addresses\nmanually for your Pods in GKE.\n\nThese IP addresses can be either external IP addresses to communicate over the\ninternet or internal IP addresses to communicate within your Google Cloud\nnetwork. You can either use Google-provided IP addresses or bring your own IP\naddresses (BYOIP).\n\nBy configuring persistent IP addresses for Pods in GKE, you can\nmap application and business logic to allow specific Pods to send and receive\ntraffic to or from any of the persistent IP addresses.\n\nThe following diagram illustrates how a Pod with multiple network interfaces can\nuse a Persistent IP address from a secondary network while still communicating\non the default network:\nMulti network architecture\n\nTerminology and concepts\n------------------------\n\nThis page uses the following concepts:\n\n**Gateway classes**\n\n*Gateway classes*, which manage your persistent IP address assignments, come in the following classes:\n\n- **gke-persistent-regional-external-managed** for external IP addresses\n- **gke-persistent-regional-internal-managed** for internal\n (Google Cloud-only) IP addresses\n\n Gateway classes work within specific regions. Gateway classes offer\n basic IP address management and are focused on Layer 3 (L3) network routing.\n\n**Gateway objects**\n\n*Gateway objects* serve as the central point for managing and configuring\npersistent IP addresses. Gateway objects in GKE manage a pool\nof persistent IP addresses. They list these addresses and define rules for how\nthese IP addresses can be assigned to `GKEIPRoute`.\n\n**Listener**\n\nA *Listener* is a part of your GKE Gateway configuration that\ncontrols which Pods across Gateway namespaces can use the persistent IP\naddresses held by the Gateway. The Listener lets you customize access for\nflexibility and security. Each Listener needs a unique name and lets you filter\naccess by namespace (all, label-based, or only the Gateway's namespace).\n\n**GKEIPRoute Object**\n\nThe *GKEIPRoute* object is a custom resource which you configure to\nassign a persistent IP address to a specific Pod in your GKE\ncluster. You can use the status section of the `GKEIPRoute` object to monitor\nyour persistent IP address setup, which provides key information through the\nfollowing fields:\n\n- **Pod**\n\n The *Pod* field shows you the exact name of the Pod linked to the persistent\n IP addresses. A single Pod can use multiple persistent IP addresses.\n- **Conditions**\n\n The *Conditions* field informs whether your external IP address setup is\n working correctly and can also help diagnose issues if your configuration is\n not valid. There are four conditions:\n - **`Accepted`:** Denotes if the `GKEIPRoute` resource specification is valid. If your configuration has errors, the `Accepted` condition is `False` with a reason.\n - **`GCPReady`:** Denotes that Google Cloud has prepared all necessary resources. Errors during the Google Cloud resource provisioning process are reflected in the `GCPReady` condition's status.\n - **`DPV2Ready`:** Denotes the status of datapath programming, such as the datapath is ready and programmed to allow network connections on the configured persistent IP addresses.\n - **`Ready`:** Denotes that your persistent IP address setup is valid and functional. The Pods can be reached on the persistent IP addresses provided you have configured your application to use it. This is set to `True` when all the other three preceding conditions are also `True`.\n\n**Reaction Modes**\n\n*Reaction Modes* determine how the system behaves when the Pod linked to a\npersistent IP address undergoes changes, such as moving across nodes or when a\nnewly-created matching Pod becomes available. You can use reaction modes to\nkeep your persistent IP addresses usable even as your Pods change.\n\nReaction modes are one of:\n\n- **ReadyCondition**\n\n In *ReadyCondition* mode, the persistent IP address system prioritizes Pod\n health. The persistent IP address system only assigns IP addresses to Pods\n that match your specified labels and have passed Kubernetes health probes,\n signaling their `Ready` status as `True`. This mode is ideal for\n applications where it's crucial that the Pod receiving the persistent IP\n address is fully prepared to handle incoming and outgoing traffic.\n- **Exists**\n\n The *Exists* mode prioritizes the presence of a Pod. The persistent IP\n address attaches to a Pod if that Pod matches the labels in your\n configuration and has been scheduled onto a specific node in your cluster.\n This means the Pod exists and has a designated place to run. This mode is\n well-suited for scenarios where rapid assignment of the persistent IP\n address takes priority over strict readiness, or in environments like\n development and testing where immediate connectivity might be more important\n than full application health.\n\n**StatefulSets**\n\n*StatefulSets* are a type of Kubernetes workload designed for applications that\nneed stable identifiers and persistent storage. Pods within a StatefulSet have\npredictable names (For example: my-app-0, my-app-1).\n\n**Deployments**\n\n*Deployments* are a type of Kubernetes workload for managing stateless\napplications where Pods are generally interchangeable. Pod names within\nDeployments aren't fully predictable.\n\nUse cases\n---------\n\nPersistent IP addresses for GKE Pods address several use cases\nfor network and security service providers running network-related applications\non GKE and GKE Enterprise.\n\nPersistent IP addresses for GKE Pods address the following use\ncases:\n\n- **Control over NAT:** By assigning persistent IP addresses to Pods running network functions, you get granular control over the source IP addresses used for outbound traffic. This lets you to integrate your proprietary NAT logic.\n- **Dedicated IP address pools:** Dedicated IP addresses let you to match specific addresses to individual 5G Core Pods, ensuring compatibility with specialized vendor software.\n- **Reliable Traffic Flows:** Since return traffic needs to be routed back through the same network function, persistent IP addresses ensure that external systems recognize and respond to the correct Pod without breaks in communication.\n\nBenefits\n--------\n\nPersistent IP addresses for GKE Pods provide you the following\nbenefits:\n\n- **External Identity:** If you give a Pod an external persistent IP address, external systems can consistently reach that Pod, even if it gets restarted or moved within the cluster. This is helpful for services that need a externally discoverable endpoint.\n- **Reliable Communication:** Applications that depend on other resources with specific IP addresses can reliably establish connections using persistent IP addresses. Persistent IP addresses are important for legacy systems or applications with hardcoded IP address dependencies.\n- **Legacy migrations**: Legacy migrations can assist in migrating applications that rely on having specific IP addresses during the transition process.\n- **BYOIP**: BYOIP lets you maintain control over specific IP address ranges you already own by using them within your GKE clusters.\n\nWhat's next\n-----------\n\n- [Control communication with persistent IP addresses on GKE\n Pods](/kubernetes-engine/docs/how-to/setup-persistent-ip-addresses-on-gke-pods)\n- Read [About multi-network support for Pods](/kubernetes-engine/docs/concepts/about-multinetwork-support-for-pods)\n- Read [Set up multi-network support for Pods](/kubernetes-engine/docs/how-to/setup-multinetwork-support-for-pods)"]]
