kube-vip 完全指南：架构、核心机制与关键特性解析（下）

斯普信专业组2026-04-29 10:08

文章目录

#作者：程宏斌

组件部署

kube-vip可以通过多种方式部署，具体取决于您的使用场景和现有的Kubernetes基础架构：

静态Pod部署：主要与kubeadm配合使用，以实现控制平面的高可用性

DaemonSet部署：与各种Kubernetes发行版（例如k3s/RKE）一起使用

容器部署：直接部署kube-vip容器

部署方式对比

对比维度 StaticPod（静态Pod） DaemonSet 容器直接运行（docker/nerdctl）

主要使用场景 ControlPlane高可用 Service LoadBalancer+Control PlaneHA 测试/非标准环境

部署时机 集群初始化阶段（bootstrap） 集群运行后 任意时间

是否依赖APIServer 不依赖 依赖 不依赖

Bootstrap阶段可用 可用 不可用 可用

是否需要RBAC 基本不需要 需要 不需要

是否支持ServiceLB 不适合 推荐 不适合

是否支持ControlPlaneHA 强烈推荐 支持 可用但不规范

配置方式 环境变量 环境变量+annotations 启动参数

更新方式 手动替换manifest kubectlrollout滚动更新 手动停止/重启容器

自愈能力 kubelet托管 Kubernetes控制器托管 依赖容器运行时

升级便利性 中等 高 低

生产环境推荐度（控制面） 强力推荐 推荐 不推荐

生产环境推荐度（ServiceLB） 推荐 强力推荐 不推荐

DaemonSet-yaml展示

RBAC

复制代码 
[root@k8s-node1 ~]# cat kube-vip-rbac.yaml 
apiVersion: v1
kind: ServiceAccount
metadata:
  name: kube-vip
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  name: system:kube-vip-role
rules:
  - apiGroups: [""]
    resources: ["services/status"]
    verbs: ["update"]
  - apiGroups: [""]
    resources: ["services", "endpoints"]
    verbs: ["list","get","watch", "update"]
  - apiGroups: [""]
    resources: ["nodes"]
    verbs: ["list","get","watch", "update", "patch"]
  - apiGroups: ["coordination.k8s.io"]
    resources: ["leases"]
    verbs: ["list", "get", "watch", "update", "create"]
  - apiGroups: ["discovery.k8s.io"]
    resources: ["endpointslices"]
    verbs: ["list","get","watch", "update"]
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["list"]

---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: system:kube-vip-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:kube-vip-role
subjects:
- kind: ServiceAccount
  name: kube-vip
  namespace: kube-system

DaemonSet

复制代码 
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: kube-vip-ds
  namespace: kube-system
  labels:
    app.kubernetes.io/name: kube-vip-ds
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: kube-vip-ds
  updateStrategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app.kubernetes.io/name: kube-vip-ds
    spec:
      hostNetwork: true
      serviceAccountName: kube-vip
      terminationGracePeriodSeconds: 60
      nodeSelector:
        node-role.kubernetes.io/control-plane: ""
      tolerations:
        - operator: Exists
      containers:
        - name: kube-vip
          image: ghcr.io/kube-vip/kube-vip:v1.0.3
          imagePullPolicy: IfNotPresent
          args:
            - manager
            - --controlplane
            - --services
            - --bgp
            - --leaderElection      # 关键：启用 Leader Election
          env:
            - name: NODE_IP
              valueFrom:
                fieldRef:
                  fieldPath: status.hostIP
            # 基础网络配置
            - name: vip_interface
              value: enp1s0
            - name: vip_subnet
              value: "32"
            - name: address
              value: "192.168.131.135"
            - name: port
              value: "6443"
            - name: cp_enable
              value: "true"
            - name: cp_namespace
              value: kube-system
            - name: svc_enable
              value: "true"
            - name: svc_leasename
              value: plndr-svcs-lock
            # BGP 配置
            - name: bgp_enable
              value: "true"
            - name: bgp_routerid
              valueFrom:
                fieldRef:
                  fieldPath: status.hostIP
            - name: bgp_as
              value: "65000"
            - name: bgp_peeraddress
              value: "192.168.131.132"
            - name: bgp_peeras
              value: "65000"
            - name: bgp_peerpass
              value: "pass1"
            - name: bgp_peeraddress_1
              value: "192.168.131.133"
            - name: bgp_peeras_1
              value: "65000"
            - name: bgp_peerpass_1
              value: "pass2"
            - name: bgp_peeraddress_2
              value: "192.168.131.134"
            - name: bgp_peeras_2
              value: "65000"
            - name: bgp_peerpass_2
              value: "pass3"
            - name: vip_cleanup
              value: "true"
            - name: vip_arp
              value: "false"
            - name: dns_mode
              value: first
            - name: dhcp_mode
              value: ipv4
            - name: prometheus_server
              value: ":2112"
            - name: vip_leaseduration #租约有效时间
              value: "5"
            - name: vip_renewdeadline #续约时间限制
              value: "3"
            - name: vip_retryperiod #重试间隔
              value: "1"
          lifecycle:
            preStop:
              exec:
                command:
                  - /bin/sh
                  - -c
                  - |
                    VIP="192.168.131.135/32"
                    INTERFACE="enp1s0"
                    if ip addr show ${INTERFACE} | grep -q "${VIP%/*}"; then
                      ip addr del ${VIP} dev ${INTERFACE}
                    fi
                    sleep 1
          securityContext:
            privileged: true
            capabilities:
              add:
                - NET_ADMIN
                - NET_RAW
              drop:
                - ALL
          resources:
            requests:
              memory: "64Mi"
              cpu: "50m"
            limits:
              memory: "128Mi"
              cpu: "100m"

组件对比

概念对比

维度 Keepalived kube-vip
核心作用 基于VRRP做VIP漂移 通过ARP或BGP做VIP漂移，集成K8s
技术类型 独立守护进程 Kubernetes DaemonSet
协议 VRRP（虚拟路由冗余协议） ARP/BGP
VIP漂移方式 VRRP协议广播+GARP ARP广播或BGP宣告
集成度 独立于K8s 完全与K8s集成
健康检查 内置脚本、外部程序 可通过leaderElection+K8sAPI健康感知

原理对比

维度 Keepalived kube-vip
L2/L3支持 L2（VRRP+ARP） L2(ARP)/L3(BGP)
VIP漂移原理 VRRP协议选举MASTER+广播GARP ARP广播/BGP路由更新
选主方式 VRRPpriority+preempt Kubernetes leader Election
健康感知 外部脚本触发VIP漂移 K8sAPI控制leader Election

Kubernetes集群适用性

维度 Keepalived kube-vip
控制面HA 可实现，但需单独管理 原生支持control-planeHA
Service LoadBalancer 需额外配置 支持LoadBalancer类型服务
Ingress VIP 可以，但需健康检查脚本 可直接绑定IngressController
集群节点规模 可支持，但广播域大需注意 小到100+节点都适合（ARP或BGP模式）
与Calico/CNI集成 需额外配置 可直接与CalicoBGP配合

运维&可扩展性

维度 Keepalived kube-vip
运维复杂度 高，需要管理进程+配置文件 低，K8s原生管理
容器化/云平台适配 不天然支持，需要宿主机权限 原生容器化，适合云平台
升级维护 独立升级，可能影响VIP 随K8s DaemonSet升级
网络侵入性 高，直接操作网卡、发送GARP 低，容器网络或Node网络即可
扩展性 受VRRP限制（广播域大时注意） 高，可跨子网（BGP）
多VIP/多服务支持 每个VIP配置一个实例或多个VIP 单kube-vip可以管理多个VIP（DaemonSet）
日志与监控 独立管理，需要额外收集 K8s原生可集成Prometheus/logging
交换机操作 不需要 需要配置 BGP 邻居

适用场景对比

场景 Keepalived kube-vip
单机房、小规模集群 适合 适合
100+节点集群 适合（广播注意） 适合（ARP或BGP）
多子网/Spine-Leaf 不适合、较复杂 适合、BGP模式
云原生/容器化平台 不适合、需要宿主机 适合、原生容器化
控制面HA 适合 适合（原生支持）
Service/IngressVIP 不适合、需额外配置 适合、原生支持
大规模业务流量 适合（lvs、haproxy） 不适合（专注控制面）

总结建议

在当前磐基环境中，该VIP不仅用于Kubernetes 控制面（API Server）高可用访问，同时磐基门户访问流量和监控数据采集也通过该VIP进行访问。在这种情况下，VIP已经不仅是Kubernetes 控制面的访问入口，而是承担了多类业务流量入口的角色。

基于这一实际使用场景，建议优先选择Keepalived作为VIP高可用方案，原因如下：

  1. 更适合承载混合业务流量
    Keepalived本身是通用高可用组件，适用于Kubernetes与非Kubernetes服务混合访问的场景。当VIP同时承载门户访问、监控数据采集等业务流量时，Keepalived的稳定性和成熟度更具优势。
  2. 健康检查能力更灵活
    Keepalived支持通过脚本进行精细化健康检测，可以根据实际业务情况（如 API Server、端口状态、进程状态等）灵活控制VIP漂移，提高可用性。
  3. 与传统网络组件兼容性更好
    在需要结合LVS、反向代理或其他网络组件时，Keepalived的集成能力更成熟，也更符合传统高可用架构的设计方式。
  4. 避免Kubernetes组件异常影响VIP
    kube-vip通常运行在Kubernetes体系内（DaemonSet 或Static Pod），当 Kubernetes节点或组件异常时，可能间接影响VIP服务。而Keepalived运行在操作系统层，独立于Kubernetes，可靠性更高。

综合建议

如果VIP仅用于Kubernetes API Server高可用，推荐使用kube-vip，部署简单且与Kubernetes原生集成良好。

但在磐基当前环境中，VIP同时承载门户访问和监控流量，属于多业务共享入口场景，建议使用Keepalived作为VIP高可用组件，以获得更好的稳定性、可控性和扩展能力。

相关推荐
斯普信专业组4 天前
kube-vip 完全指南：架构、核心机制与关键特性解析（上）
架构·kube-vip
AKA小徐1 年前
超简单，使用Kube-Vip实现K8s高可用VIP详细教程
linux·kubernetes·kube-vip
热门推荐
01GitHub 镜像站点02近期有什么ai的新消息，新动态？ 2026.4月032026年4月AI大事件深度解读：大模型竞争进入“深水区“042026年AI编程工具终极横评：Cursor vs Claude Code vs Copilot05Codex 接入 DeepSeek API 完整配置文档06【AI】2026 年具身智能模型和世界模型总结07在Windows 11上安装Docker的踩坑记录08零基础教你claude code 接入 deepseek V4092026年AI前瞻：量子AI、具身智能与科学发现的新纪元10VSCode + Copilot下：配置并使用 DeepSeek