[k8s] kube-vip

쿠버네티스를 고가용성으로 구성한다고 했을때, 걸리는 것 중 하나가 이것이다.
"그러면 kube API 엔드포인트는 어떻게 HA를 보장하는가?"

결국 쿠버 내 일부 리소스들도 kube API에 쏴서 이런저런 동작을 처리하거나 하는데, 쿠버의 일부 하위 시스템들은 이걸 HA 기반으로 처리하기가 어렵다.

control plane 노드가 3개 있다고 하면 어느 노드에 찔러야 할까? 노드가 하나 죽으면 다른 노드로 어떻게 옮겨야할까?
일반적인 Pod들은 자체적인 kubernetes.default.svc 서비스 계층을 통해서 이걸 자동으로 처리해주는데, 서비스를 쓸 수 없는 kube-proxy(혹은 CNI), kubelet, kube agent들은 그 혜택을 누리지 못해서 엔드포인트 노드가 뻗으면 통신을 하지 못한다.

이 문제를 해결하는 도구 중 하나가 kube-vip다.
별도의 LB를 신뢰성 높은 계층에 구축해도 되지만, 이건 합의 기반으로 control plane 노드들이 자체적으로 리더를 뽑고 선택을 할 수 있게 한다. 그리고 해당 리더 노드가 API 엔드포인트가 된다.
이러면 가상 내부 IP를 통해 특정 노드가 죽더라도, 가상 IP를 통해서 다른 노드가 완장을 잡고 통신을 할 수 있게 해준다.

기존 k3s에 설치하기

먼저 VIP로 사용할 IP를 정해야한다.
LAN 내에서 ARP 기반으로 진짜 존재하는 것처럼 동작할 것이므로, 망 내에서 고유해야 한다.
난 192.168.88.250로 적당히 잡았다.

그리고 다음과 같이 리소스를 생성한다.

kubectl apply -f https://kube-vip.io/manifests/rbac.yaml
kubectl apply -f kube-vip-ds.yaml # 아래 파일

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: kube-vip-ds
  namespace: kube-system
  labels:
    app.kubernetes.io/name: kube-vip-ds
spec:
  selector:
    matchLabels:
      name: kube-vip-ds
  template:
    metadata:
      labels:
        name: kube-vip-ds
    spec:
      hostNetwork: true
      serviceAccountName: kube-vip
      nodeSelector:
        node-role.kubernetes.io/control-plane: "true"
      tolerations:
        - operator: Exists
          effect: NoSchedule
      containers:
        - name: kube-vip
          image: ghcr.io/kube-vip/kube-vip:v1.2.4
          args: [manager]
          env:
            - { name: vip_arp,            value: "true" }
            - { name: port,               value: "6443" }
            - { name: vip_cidr,           value: "32" }
            - { name: cp_enable,          value: "true" }
            - { name: cp_namespace,       value: kube-system }
            - { name: vip_leaderelection, value: "true" }
            - { name: vip_leaseduration,  value: "15" }
            - { name: vip_renewdeadline,  value: "10" }
            - { name: vip_retryperiod,    value: "2" }
            - { name: address,            value: "가상IP" }
          securityContext:
            capabilities:
              add: [NET_ADMIN, NET_RAW]

방금 VIP로 쓰기로 결정한걸 저기 주소에 박으면 된다.
그리고 control plane 노드에만 자동으로 실행되게 했다.

저걸 다 띄우고, control plane 노드의 에이전트 파일을 전부 열어서, tls-san 목록에 방금 VIP를 전부 추가한다.

그리고 tls 목록에 VIP를 추가하고 재부팅해준다.
나중에 control plane으로 노드를 추가할 때도 항상 VIP를 추가로 넣어줘야 한다.

그리고 이렇게 통신이 되면 네트워크는 잘 엮인 것이다.
이 다음에, cilium을 쓴다면 cilium 세팅도 VIP를 가리키도록 하면 되는데, 그건 하단에 정리해놨다.

그리고 control plane이 아닌 워커 노드들도 VIP를 가리키도록 바꿔준다.
그래야 노드 하나 뻗었을때도 통신이 유지된다.

sudo sed -i 's|https://192.168.88.202:6443|https://192.168.88.250:6443|' /etc/systemd/system/k3s-agent.service.env

sudo systemctl daemon-reload
sudo systemctl restart k3s-agent

Cilium에 VIP 적용 (with helm)

Cilium을 CNI로 쓸 경우에 해당되는 부분이다. 그리고 helm으로 설치해놨다고 가정한다.

serviceHost를 VIP로 바꿔주고

helm upgrade cilium cilium/cilium -n kube-system \
  --version 1.20.2 \
  -f cilium/values.yaml

kubectl -n kube-system rollout restart ds/cilium
kubectl -n kube-system rollout status ds/cilium

재설치한다.

그렇게 해서 이 값이 VIP로 나오면 잘 된 것이다.

kubectl -n kube-system exec ds/cilium -- sh -c 'echo "KUBERNETES_SERVICE_HOST=$KUBERNETES_SERVICE_HOST"'

참조
https://kube-vip.io/docs/usage/k3s/
https://kube-vip.io/
https://medium.com/@siddharthsid533/how-i-got-kube-vip-working-with-my-k3s-cluster-without-breaking-things-668100703d5c