로드밸런서

마스터(컨트롤 플레인) 노드가 여러 대일 때, API 서버 트래픽을 분산 처리하고 장애 노드를 자동으로 우회하는 기능입니다.

설정값

qks_load_balancer_enabled: true
qks_load_balancer_fqdn: "k8s.{{ kube_default_domain }}"   # 예: k8s.aila.quantumcns.ai
qks_vip_manager_enabled: false

설치 흐름

./install.sh ubuntu k8s.yaml
  └─ qks_load_balancer_enabled: true 이므로 import_playbook: plays/qks-load-balancer.yaml 호출
       └─ 마스터 노드마다 각각 독립적으로 실행:
            1. HAProxy 설정 파일 생성      /etc/qks/qks-load-balancer.conf
            2. 스태틱 파드 매니페스트 생성  /etc/kubernetes/manifests/qks-load-balancer.yaml
            3. 그 노드의 kubelet이 매니페스트를 감지해 자동으로 HAProxy 컨테이너 기동

설치 내용

• qks-system 네임스페이스에 qks-load-balancer Pod(HAProxy), 마스터 노드마다 하나씩
• 8443 포트로 들어온 요청을 마스터 전체의 6443(API 서버)으로 분산

설치 확인

kubectl get pods -n qks-system | grep load-balancer

마스터 대수만큼(이 환경은 3개) Running이어야 합니다.

어느 경로로 접속 중인지 확인

grep server: ~/.kube/config

https://<qks_load_balancer_fqdn>:8443(예: https://k8s.aila.quantumcns.ai:8443)로 되어 있어야 합니다 — 이게 API 서버(6443) 포트가 아니라 로드밸런서가 듣는 포트(8443)라는 뜻이라, kubectl 명령을 쓸 때마다 이미 로드밸런서를 거쳐가고 있다는 걸 확인하는 것입니다.

실제 장애 상황 테스트 — 마스터 하나가 죽어도 접속이 유지되는지

임의의 마스터(예: m02) 한 대를 골라 API 서버를 잠시 내립니다:

# m02에서
sudo mv /etc/kubernetes/manifests/kube-apiserver.yaml /tmp/kube-apiserver.yaml.bak

다른 마스터(예: m01)에서 여전히 정상 응답하는지 확인합니다:

kubectl get nodes

모든 노드가 정상 조회되면(에러 없이), 죽은 마스터를 로드밸런서가 자동으로 우회하고 있다는 뜻입니다.

복구:

# m02에서
sudo mv /tmp/kube-apiserver.yaml.bak /etc/kubernetes/manifests/kube-apiserver.yaml

kubectl get pods -n kube-system -o wide | grep m02 | grep apiserver

재기동 직후 잠깐 0/1(준비 중)로 보일 수 있으나, 몇 초 후 1/1 Running으로 복구됩니다.

알려진 제약사항 — 첫 번째 마스터(기본 m01)는 여전히 단일 장애점

진짜 이중화(어느 마스터가 죽어도 접속 주소 자체가 살아있는 마스터로 자동 이동)를 하려면 qks_vip_manager_enabled: true로 Keepalived 기반 가상 IP(VIP)를 활성화해야 합니다. 다만 OpenStack 등 클라우드 환경에서는 네트워크가 기본적으로 VIP의 동작 방식(ARP 기반 IP 이전)을 스푸핑으로 간주해 차단하는 경우가 많아, 클라우드 쪽 네트워크 설정(OpenStack이라면 Neutron의 allowed_address_pairs)이 추가로 필요할 수 있습니다 — 이 저장소의 기본 Terraform 구성에는 이 설정이 포함되어 있지 않아, VIP 활성화 전 별도 확인이 필요합니다.

다음 단계