nginx 与 keepalived 在云原生中并非天然适配，需谨慎引入：kubernetes 已内置 service、ingress 等机制替代其核心功能；keepalived 因依赖 vrrp 和宿主机网络栈，仅适用于边缘网关或跨集群入口等特定场景，且须运行在 hostnetwork 模式下并绑定物理网卡。
Nginx 与 Keepalived 在云原生集群中并非天然适配，而是需谨慎评估、有选择地引入。它们在传统高可用架构中表现成熟，但在 Kubernetes 等云原生环境中，其角色和部署方式已发生实质性转变。
云原生环境弱化了 Keepalived 的核心价值
Kubernetes 原生提供 Service（尤其是 LoadBalancer 和 NodePort 类型）、Ingress Controller、EndpointSlice 等机制，已内建服务发现、健康检查、流量分发与故障转移能力。Keepalived 依赖的 VRRP 协议需直接操作宿主机网络栈（如绑定物理网卡、发送组播包），这与容器网络（CNI 插件如 Calico/Flannel）存在冲突；多数云平台（如阿里云、腾讯云、AWS）也不允许用户私自广播 VRRP 报文。因此，在标准 K8s 集群中，Keepalived 通常仅用于裸金属或边缘节点的“入口网关前置层”，而非集群内部组件。
Nginx 更常以 Ingress Controller 形式存在，而非独立负载均衡器
云原生中，Nginx 不再作为独立反向代理进程部署，而是封装为 nginx-ingress-controller（官方维护的 Helm Chart 或 Operator）。它监听 Kubernetes API 中的 Ingress 资源，动态生成并热重载 nginx.conf，自动同步后端 Pod 的 Endpoint 变化。此时 Nginx 的配置管理、扩缩容、TLS 终止均由 K8s 控制平面驱动，不再依赖手动维护 upstream 列表或静态 IP。
典型适配场景与落地建议
- 边缘/混合云出口网关：在 K8s 集群边缘节点（如 Bare Metal Worker）部署 Nginx + Keepalived，对外暴露 VIP，承接来自 IDC 或传统网络的流量，再转发至集群 Ingress Controller。此时 Keepalived 保障的是“最后一公里”的接入高可用。
- 多集群统一入口：跨多个 K8s 集群时，可在顶层部署一组 Nginx + Keepalived 实例，基于 DNS 或 Anycast 将请求路由到不同集群的 Ingress 入口，实现灾备切换。
- 替代方案优先级：若目标是集群内部服务高可用，应优先使用 Service + Headless Service + StatefulSet；若需七层路由，选用 ingress-nginx、Traefik 或 APISIX；若需四层高可用，可考虑 MetalLB（L2/BGP 模式）替代 Keepalived。
关键注意事项
- Keepalived 必须运行在 hostNetwork 模式下，且需明确指定 interface（如 eth0），不能绑定到 CNI 创建的虚拟网卡。
- Nginx 进程需禁用 daemon 模式（daemon off;），配合 Kubernetes 生命周期管理（preStop + readinessProbe）。
- 健康检查脚本（如 chk_nginx.sh）应检测的是 nginx-ingress-controller 的 /healthz 端点，而非本地 nginx 主进程。
- VIP 地址必须与云平台允许的弹性公网 IP 或私网段兼容，避免 ARP 冲突或被安全组拦截。
不复杂但容易忽略——适配的本质不是“把旧组件搬进去”，而是让 Nginx 和 Keepalived 各自退守到云原生架构中仍有不可替代价值的位置。
