使用场景
概述章节提到了 LVS、keepalived 对和 Kubernetes。本章详细介绍最常见的部署模式——每种都是端到端的。
HAVIP 部分每次都相同，因此值得一次说明：在您实例所在的子网内创建一个 HAVIP，然后让您的故障转移软件指向该地址。 无需挂载步骤。下面每一节都聚焦于围绕 HAVIP 的软件特定配置。
场景 1 —— 内核负载均衡器（LVS）调度器对
您要做的： 您将 LVS——内核的 IPVS 负载均衡器——作为自己的负载均衡层运行。两个调度器实例共享同一个服务 VIP；主调度器将到达的连接分发到一组真实服务器。如果主调度器故障，备用调度器必须接管 VIP，使虚拟服务继续运行。
部署方式：
在调度器所在的子网内创建一个 HAVIP。该地址即为 LVS 服务 VIP——客户端访问的目标。
在两个调度器上运行 keepalived。其 VRRP 实例跟踪 HAVIP；keepalived 的
virtual_server块承载 IPVS 配置，因此持有 VIP 的调度器同时也是配置 IPVS 的调度器。将真实服务器置于同一 VPC 内，并按本地化部署方式选择 IPVS 转发模式（DR、NAT 或 tunnel）——HAVIP 管理的是哪个调度器为主，与真实服务器路径无关。
对于面向公网的 LVS，将 EIP 绑定到 HAVIP。对于内部 LVS——后端调用共享虚拟服务——保持私有即可。
!!! note "两层职责，相互独立" HAVIP 提供调度器故障转移；IPVS 提供面向真实服务器的流量分发。两者相互独立——不要指望 HAVIP 做任何分发，也不要指望 IPVS 自行抵御调度器丢失。
场景 2 —— 数据库主备故障转移
您要做的： 您运行一个数据库——PostgreSQL、MySQL——一个主节点配一个或多个副本。应用必须连接到一个单一稳定的地址，该地址始终指向当前的主节点。集群管理工具（Patroni、repmgr、MHA、Orchestrator）在主节点死亡时提升某个副本；地址必须跟随该提升。
部署方式：
在数据库子网中创建一个 HAVIP。将所有应用连接串都指向它——绝不要指向某个具体的数据库实例。
在每个数据库实例上运行 keepalived（或您集群管理工具自己的 VIP 钩子）。
将 VIP 持有权与主节点角色而非实例存活性绑定：当前主节点持有 HAVIP；副本保持释放状态。最干净的接线方式是让集群管理工具的提升回调来升降 keepalived 状态。
故障转移时，集群管理工具提升某个副本，该实例随即声明 HAVIP。应用使用相同地址重连，落到新的主节点上。
保持私有——应用服务器位于 VPC 内部。
!!! warning "VIP 迁移前必须 fence 旧主节点" 数据库 VIP 绝不能同时被两个实例持有——那是带写入的脑裂。请由集群管理工具的提升决策驱动 VIP 持有权，并确保被降级的主节点在新主节点接管之前先释放地址（或被 fence）。仅靠 VRRP 优先级并不构成 fence 机制。
场景 3 —— 反向代理 / API 网关对
您要做的： 您在后端之前运行一对反向代理或 API 网关——HAProxy、Nginx、Envoy。由于它们是无状态的，任一实例都能承担所有流量；您希望有一个统一的入口地址，并在一台故障时瞬时切换。
部署方式：
在代理所在的子网中创建一个 HAVIP——它就是这个唯一的入口地址。
在两个代理实例上运行 keepalived，VRRP 都指向该 HAVIP。
健康检查代理进程或其监听端口，使运行中实例上的卡死代理能够释放 VIP，而不是黑洞掉流量。
面向公网？将 EIP 绑定到 HAVIP。仅内部使用（客户端是 VPC 内的其他服务）？保持私有即可。
!!! note "主备模式，而非双主模式" HAVIP 每次只将流量送至一个实例，因此这是主备模式——备用代理在故障转移前处于空闲状态。由于代理是无状态的，抢占通常无害：让恢复的实例重新接管 VIP 几乎没有成本。如果您需要两个代理同时服务，那需要负载均衡器，或者两个 HAVIP 通过 DNS 拆分。
场景 4 —— 自建网关设备（NAT / 防火墙）
您要做的： 您将自建的 NAT 网关、防火墙或路由设备作为一对实例运行。VPC 内的其他实例将该设备作为其默认网关或下一跳。网关地址必须能抵御设备故障，否则后端所有实例将同时失去网络连通性。
部署方式：
在通过设备路由的实例所在的子网中创建一个 HAVIP。该 HAVIP 即为下一跳地址。
将受保护实例的默认路由（或相关路由条目）指向该 HAVIP。
在两个设备实例上运行 keepalived。持有者拥有 HAVIP，执行 NAT / 转发；故障转移时备用实例接管网关地址。
在两个设备上启用 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 绑定到对应 HAVIP，将某个 Service 暴露到公网；集群内部端点保持私有。
!!! note "每个独立 VIP 都对应一个 HAVIP" 控制平面端点与每个 LoadBalancer 类型 Service 都是独立的地址，具备独立的故障转移——请为每个分配独立的 HAVIP。不要尝试将多个角色复用到同一个上。
最后更新于