GCPReady：表示 Google Cloud 已准备所有必要的资源。 Google Cloud 资源预配过程中的错误会体现在 GCPReady 条件的状态中。
DPV2Ready：表示数据路径编程的状态，例如数据路径已准备就绪并已编程以允许在配置的永久性 IP 地址上进行网络连接。
Ready：表示您的永久性 IP 地址设置有效且正常运行。只要您已将应用配置为使用永久性 IP 地址，就可以通过该地址访问 Pod。当所有其他三个前置条件也为 True 时，此字段设置为 True。
回应模式
“回应模式”决定了当链接到永久性 IP 地址的 Pod 发生变化时（例如跨节点移动或新创建的匹配 Pod 可用时）系统的行为。您可以使用回应模式来确保您的永久性 IP 地址始终可用，即使您的 Pod 发生变化。
反应模式包括：
ReadyCondition
在 ReadyCondition 模式下，永久性 IP 地址系统会优先考虑 Pod 健康状况。永久性 IP 地址系统仅将 IP 地址分配给匹配您指定的标签且已通过 Kubernetes 健康探测的 Pod，发出信号来表明其 Ready 状态为 True。此模式非常适合那些需要接收永久性 IP 地址的 Pod 完全准备好处理传入和传出流量的应用。
Exists
Exists 模式会优先考虑 Pod 的存在。如果 Pod 与配置中的标签匹配且已被安排到集群中的特定节点上，则永久性 IP 地址将关联到该 Pod。这意味着 Pod 存在且具有指定的运行位置。此模式非常适合快速分配永久性 IP 地址优先于严格就绪的场景，或者即时连接可能比完整的健康运行状况更重要的环境，例如开发环境和测试环境。
StatefulSets
StatefulSets 是一种 Kubernetes 工作负载，专为需要稳定标识符和永久性存储空间的应用而设计。StatefulSet 中的 Pod 具有可预测的名称（例如：my-app-0、my-app-1）。
部署
Deployment 是一种用于管理无状态应用的 Kubernetes 工作负载，其中 Pod 通常可以互换。Deployment 中的 Pod 名称不是完全可预测的。
使用场景
GKE Pod 的永久性 IP 地址适合在 GKE 和 GKE Enterprise 上运行网络相关应用的网络和安全服务提供商的多种使用场景。
GKE Pod 的永久性 IP 地址适合以下使用场景：
通过 NAT 进行控制：通过为运行网络功能的 Pod 分配永久性 IP 地址，您可以对用于出站流量的来源 IP 地址进行精细控制。这样，您就可以集成专有 NAT 逻辑。
专用 IP 地址池：借助专用 IP 地址，您可以将特定地址与各个 5G 核心 Pod 匹配，从而确保与专用供应商软件兼容。
可靠的流量：由于返回流量需要通过相同的网络功能路由回来，永久性 IP 地址可确保外部系统识别并响应正确的 Pod，而不会中断通信。
优势
GKE Pod 的永久性 IP 地址具有以下优势：
外部身份：如果为 Pod 提供外部永久性 IP 地址，则即使该 Pod 重启或在集群内移动，外部系统也可以持续访问该 Pod。这对于需要外部可发现的端点的服务非常有用。
可靠通信：依赖具有特定 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"]],["最后更新时间 (UTC)：2025-09-03。"],[],[],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)"]]
