Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to make a virtual ip jump to another control plane when the node where the virtual ip is located is notReady? #800

Open
HuaJFrame opened this issue Mar 30, 2024 · 2 comments

Comments

@HuaJFrame
Copy link

Is your feature request related to a problem? Please describe.
Whether or not to support virtual ip jumps to other nodes when the control plane is notReady for some special reason.

Describe the solution you'd like
After control plane A, which holds the virtual IP, is notReady, the virtual ip jumps to control plane B or C.

Describe alternatives you've considered
I am simulating a network shutdown scenario and kube-vip is working fine. I would like to have some configurations to control the jump conditions for the virtual IP, such as node not ready, network disconnected, and so on.

  1. When the jump condition is that the node is notReady
    Node not ready and network disconnection will make the virtual ip jump to other nodes.
  2. When the node network is disconnected at the time of the jump condition
    • Virtual ip does not jump when node is not ready.
    • Virtual ip jumps when the network is disconnected.

Additional context

Kubernetes version: v1.27.3
Container Runtimes: cri-dockerd 0.3.4
kube-vip version:  v0.6.3

Or is it possible that the functionality already exists because my version of kube-vip is not the latest?
Here is the manifest for my static pod for bube-vip.

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  name: kube-vip
  namespace: kube-system
spec:
  containers:
  - args:
    - manager
    env:
    - name: vip_arp
      value: "true"
    - name: port
      value: "6443"
    - name: vip_interface
      value: ens33
    - name: vip_cidr
      value: "32"
    - name: cp_enable
      value: "true"
    - name: cp_namespace
      value: kube-system
    - name: vip_ddns
      value: "false"
    - name: svc_enable
      value: "true"
    - name: svc_leasename
      value: plndr-svcs-lock
    - name: vip_leaderelection
      value: "true"
    - name: vip_leasename
      value: plndr-cp-lock
    - name: vip_leaseduration
      value: "5"
    - name: vip_renewdeadline
      value: "3"
    - name: vip_retryperiod
      value: "1"
    - name: address
      value: 192.168.44.100
    - name: prometheus_server
      value: :2112
    image: ghcr.io/kube-vip/kube-vip:v0.6.3
    imagePullPolicy: IfNotPresent
    name: kube-vip
    resources: {}
    securityContext:
      capabilities:
        add:
        - NET_ADMIN
        - NET_RAW
    volumeMounts:
    - mountPath: /etc/kubernetes/admin.conf
      name: kubeconfig
  hostAliases:
  - hostnames:
    - kubernetes
    ip: 127.0.0.1
  hostNetwork: true
  volumes:
  - hostPath:
      path: /etc/kubernetes/admin.conf
    name: kubeconfig
status: {}
@jusch23
Copy link

jusch23 commented Apr 11, 2024

Similar to the problem described here, I have also observed that the vip does not jump to another control plane host when the apiserver on the host currently holding the vip is down but kube-vip is running. I would expect one of the running apiservers to take over the leader lease and assign the vip, but this does not happen. Compared to a haproxy/keepalived setup, this could be achieved by configuring an apiserver health check script within keepalived on the node. An apiserver failure would then result in a lower priority of the instance within the keepalived cluster and a vip jump to a working apiserver. Is this possible with kube-vip?

My context:
Kubernetes version: v1.27.10
Container Runtimes: containerd 1.6.28
kube-vip version: v0.7.2

@lubronzhan
Copy link
Contributor

Currently it's not possible since kube-vip use leaderelection package to achieve active-standby mode HA. Only when the leader failed to acquire leader -- talking to apiserver to update lease, other follower could acquire the leader by claim the lease.

But an improvement could be made is to add a node controller or a process to watch for current node's status, if current node is not ready for example 1 minute, fatal exit, then other pod could try acquire the leader. Just need be care with how much time should the kube-vip decide to exit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants