> For the complete documentation index, see [llms.txt](https://docs.console.zenlayer.com/welcome/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.console.zenlayer.com/welcome/cn/elastic-compute/01-overview/04-use-cases.md).

# 使用场景

[概述](/welcome/cn/elastic-compute/01-overview.md)章节提到了 LVS、keepalived 对和 Kubernetes。本章详细介绍最常见的部署模式——每种都是端到端的。

HAVIP 部分每次都相同，因此值得一次说明：**在您实例所在的子网内创建一个 HAVIP，然后让您的故障转移软件指向该地址。** 无需挂载步骤。下面每一节都聚焦于围绕 HAVIP 的软件特定配置。

![三种 HAVIP 部署：数据库对、反向代理对、网关对](/files/3YOkESDqXZ6u5YiAL8uD)

***

## 场景 1 —— 内核负载均衡器（LVS）调度器对

**您要做的：** 您将 LVS——内核的 IPVS 负载均衡器——作为自己的负载均衡层运行。两个**调度器**实例共享同一个服务 VIP；主调度器将到达的连接分发到一组真实服务器。如果主调度器故障，备用调度器必须接管 VIP，使虚拟服务继续运行。

**部署方式：**

1. 在调度器所在的子网内创建一个 HAVIP。该地址即为 **LVS 服务 VIP**——客户端访问的目标。
2. 在两个调度器上运行 keepalived。其 VRRP 实例跟踪 HAVIP；keepalived 的 `virtual_server` 块承载 IPVS 配置，因此持有 VIP 的调度器同时也是配置 IPVS 的调度器。
3. 将真实服务器置于同一 VPC 内，并按本地化部署方式选择 IPVS 转发模式（DR、NAT 或 tunnel）——HAVIP 管理的是*哪个调度器为主*，与真实服务器路径无关。
4. 对于面向公网的 LVS，将 [EIP](/welcome/cn/elastic-compute/01-overview/03-eip.md) 绑定到 HAVIP。对于内部 LVS——后端调用共享虚拟服务——保持私有即可。

!!! note "两层职责，相互独立" HAVIP 提供**调度器**故障转移；IPVS 提供面向**真实服务器**的流量分发。两者相互独立——不要指望 HAVIP 做任何分发，也不要指望 IPVS 自行抵御调度器丢失。

***

## 场景 2 —— 数据库主备故障转移

**您要做的：** 您运行一个数据库——PostgreSQL、MySQL——一个主节点配一个或多个副本。应用必须连接到一个单一稳定的地址，该地址始终指向*当前的*主节点。集群管理工具（Patroni、repmgr、MHA、Orchestrator）在主节点死亡时提升某个副本；地址必须跟随该提升。

**部署方式：**

1. 在数据库子网中创建一个 HAVIP。将所有应用连接串都指向它——绝不要指向某个具体的数据库实例。
2. 在每个数据库实例上运行 keepalived（或您集群管理工具自己的 VIP 钩子）。
3. 将 VIP 持有权与**主节点角色**而非实例存活性绑定：当前主节点持有 HAVIP；副本保持释放状态。最干净的接线方式是让集群管理工具的提升回调来升降 keepalived 状态。
4. 故障转移时，集群管理工具提升某个副本，该实例随即声明 HAVIP。应用使用相同地址重连，落到新的主节点上。
5. 保持私有——应用服务器位于 VPC 内部。

!!! warning "VIP 迁移前必须 fence 旧主节点" 数据库 VIP 绝不能同时被两个实例持有——那是带*写入*的脑裂。请由集群管理工具的提升决策驱动 VIP 持有权，并确保被降级的主节点在新主节点接管之前先释放地址（或被 fence）。仅靠 VRRP 优先级并不构成 fence 机制。

***

## 场景 3 —— 反向代理 / API 网关对

**您要做的：** 您在后端之前运行一对反向代理或 API 网关——HAProxy、Nginx、Envoy。由于它们是无状态的，任一实例都能承担所有流量；您希望有一个统一的入口地址，并在一台故障时瞬时切换。

**部署方式：**

1. 在代理所在的子网中创建一个 HAVIP——它就是这个唯一的入口地址。
2. 在两个代理实例上运行 keepalived，VRRP 都指向该 HAVIP。
3. 健康检查**代理进程或其监听端口**，使运行中实例上的卡死代理能够释放 VIP，而不是黑洞掉流量。
4. 面向公网？将 [EIP](/welcome/cn/elastic-compute/01-overview/03-eip.md) 绑定到 HAVIP。仅内部使用（客户端是 VPC 内的其他服务）？保持私有即可。

!!! note "主备模式，而非双主模式" HAVIP 每次只将流量送至一个实例，因此这是主备模式——备用代理在故障转移前处于空闲状态。由于代理是无状态的，**抢占通常无害**：让恢复的实例重新接管 VIP 几乎没有成本。如果您需要两个代理同时服务，那需要[负载均衡器](/welcome/cn/elastic-compute/load-balancing.md)，或者两个 HAVIP 通过 DNS 拆分。

***

## 场景 4 —— 自建网关设备（NAT / 防火墙）

**您要做的：** 您将自建的 NAT 网关、防火墙或路由设备作为一对实例运行。VPC 内的其他实例将该设备作为其**默认网关**或下一跳。网关地址必须能抵御设备故障，否则后端所有实例将同时失去网络连通性。

**部署方式：**

1. 在通过设备路由的实例所在的子网中创建一个 HAVIP。该 HAVIP 即为**下一跳地址**。
2. 将受保护实例的默认路由（或相关路由条目）指向该 HAVIP。
3. 在两个设备实例上运行 keepalived。持有者拥有 HAVIP，执行 NAT / 转发；故障转移时备用实例接管网关地址。
4. 在两个设备上启用 IP 转发，并保持防火墙 / NAT 规则集完全一致——任一实例都可能成为持有者。

!!! warning "HAVIP 迁移的是地址，而非连接状态" NAT 转换表和防火墙连接跟踪条目位于实例本身，而非 HAVIP。故障转移后，新持有者的状态表为空，因此现有连接可能被重置——除非您的设备自行复制状态（例如使用 `conntrackd`）。HAVIP 保证*地址*存活；让*连接*存活是您软件的职责。

***

## 场景 5 —— Kubernetes 控制平面与 Service VIP

**您要做的：** Kubernetes 需要在两处稳定的 VIP：控制平面节点共享的单一 API server 端点，以及在 VPC 网络上暴露的 `LoadBalancer` 类型 Service 地址。

**部署方式：**

* **控制平面端点。** 在控制平面节点所在的子网中创建一个 HAVIP，并将其用作集群的 `controlPlaneEndpoint`。在控制平面节点上运行 kube-vip（或 keepalived）；持有 HAVIP 的节点对外提供 API server 服务，VIP 在节点故障时迁移。
* **Service 地址。** 对于 L2 模式部署——MetalLB 的 L2 模式，或 kube-vip 的 ARP 模式——该机制由当前承载 Service IP 的节点通过免费 ARP 进行通告。**每个 Service IP 分配一个 HAVIP**；子网对广播/多播的支持正是让这些 ARP 通告生效的关键。
* 通过将 [EIP](/welcome/cn/elastic-compute/01-overview/03-eip.md) 绑定到对应 HAVIP，将某个 Service 暴露到公网；集群内部端点保持私有。

!!! note "每个独立 VIP 都对应一个 HAVIP" 控制平面端点与每个 `LoadBalancer` 类型 Service 都是独立的地址，具备独立的故障转移——请为每个分配独立的 HAVIP。不要尝试将多个角色复用到同一个上。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.console.zenlayer.com/welcome/cn/elastic-compute/01-overview/04-use-cases.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.