HAProxy 기반 쿠버네티스 고가용성 로드 밸런서 구축 가이드
게시:
쿠버네티스 환경에서 고가용성(High Availability, HA)은 시스템 안정성의 핵심 요소입니다. 특히 여러 컨트롤 플레인 노드로 구성된 클러스터에서는 API 서버에 대한 트래픽을 효과적으로 분산할 수 있는 로드 밸런서가 필수적입니다. 이 가이드에서는 HAProxy를 사용하여 쿠버네티스 고가용성 로드 밸런싱 환경을 구성하는 방법을 설명합니다.
테스트 환경
· 단일 LB(Bastion) 노드 + Control-Plane 3대 + Worker 2대 (총 6노드)
· Ubuntu 24.04 LTS (GCP Virtual Machune)
· HAProxy 2.9.x(기본 레포지터리)
· 간단한 테스트 클러스터용 예시입니다. 운영 환경에서는 LB ≥ 2대 + Keepalived를 권장합니다.
HA 아키텍처 개요
쿠버네티스 HA 클러스터에서 로드 밸런서는 다음과 같은 중요한 역할을 수행합니다.
- 단일 진입점 제공: 여러 컨트롤 플레인 노드에 대한 단일 접속 지점 제공
- 트래픽 분산: API 서버로 들어오는 요청을 여러 노드로 분산하여 부하 균형 유지
- 장애 감지: 비정상 노드를 감지하고 트래픽 전송 중단
- 무중단 운영: 일부 컨트롤 플레인 노드에 장애가 발생해도 클러스터 운영 지속
1. 모든 노드에 /etc/hosts 등록
네트워크 DNS 인프라가 없는 환경에서도 노드 간 일관된 이름 해석이 가능하도록 모든 노드에 호스트 정보를 등록합니다. 이는 노드 간 통신과 HAProxy 설정에서 일관성을 보장합니다.
sudo vim /etc/hosts
# --- 예시 ---
10.128.0.34 bastion
10.128.0.35 control-plain-1
10.128.0.36 control-plain-2
10.128.0.37 control-plain-3
10.128.0.38 worker-1
10.128.0.39 worker-2
검증 방법
각 노드에서 호스트명 해석과 네트워크 연결성을 확인합니다.ping -c 3 control-plain-1모든 노드 간 통신이 원활해야 클러스터가 정상적으로 동작합니다.
2. Load Balancer 노드(Bastion) 설정
2-1. HAProxy 개요
HAProxy는 TCP/HTTP 기반 애플리케이션을 위한 고성능 로드 밸런서로, 쿠버네티스 API 서버 앞단에서 다음과 같은 기능을 제공합니다.
- L4/L7 로드 밸런싱: TCP(L4) 또는 HTTP(L7) 수준에서 트래픽 분산
- 고성능: 단일 프로세스 이벤트 기반 모델로 높은 처리량과 낮은 지연시간 제공
- 헬스 체크: 주기적인 상태 확인으로 장애 노드 자동 감지 및 제외
- 세션 유지: 필요시 동일 클라이언트를 같은 서버로 라우팅
2-2. HAProxy 설치
패키지 관리자를 통해 HAProxy를 설치하고 기존 설정을 백업합니다.
sudo apt-get update
sudo apt-get install -y haproxy
# 기본 설정 백업
sudo mv /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak
2-3. HAProxy 설정 파일 작성
사용하는 HAProxy 설정은 크게 global, defaults, frontend, backend 섹션으로 구성됩니다.
sudo vim /etc/haproxy/haproxy.cfg
# ---------- /etc/haproxy/haproxy.cfg ----------
global
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
stats timeout 30s
user haproxy
group haproxy
daemon
defaults
log global
mode tcp # L4(TCP) 로드밸런싱
option tcplog
option dontlognull
timeout connect 5000
timeout client 50000
timeout server 50000
# --- Kubernetes API 서버 프런트엔드 ---
frontend k8s_api
bind 0.0.0.0:6443 # 외부에서 6443/TCP 수신
mode tcp
option tcplog
default_backend k8s_api_backend
# --- Control-Plane 노드 백엔드 ---
backend k8s_api_backend
mode tcp
balance roundrobin # 라운드로빈 부하 분산
option tcp-check # TCP 헬스체크
server master-1 10.128.0.35:6443 check fall 3 rise 2
server master-2 10.128.0.36:6443 check fall 3 rise 2
server master-3 10.128.0.37:6443 check fall 3 rise 2
# ----------------------------------------------
설정 파일 구성요소 설명
- global: HAProxy 프로세스 전체에 적용되는 기본 설정
- defaults: 모든 프록시에 적용되는 기본값
mode tcp: L4 로드 밸런싱 사용 (쿠버네티스 API 서버는 HTTPS)timeout: 연결/클라이언트/서버 타임아웃 설정
- frontend: 클라이언트 연결을 수신하는 설정
bind 0.0.0.0:6443: 모든 인터페이스에서 6443 포트 수신default_backend: 트래픽을 전달할 백엔드 지정
- backend: 실제 서버 정의 및 로드 밸런싱 알고리즘 설정
balance roundrobin: 각 서버에 순차적으로 요청 분배option tcp-check: TCP 연결로 서버 가용성 확인check fall 3 rise 2: 3번 실패 시 비정상으로 간주, 2번 성공 시 정상으로 복귀server: 각 API 서버 노드 정의
프로덕션 운영 구성 예시
운영 환경에서는 다음과 같은 설정을 통해 안정성과 성능을 개선해볼 수 있습니다.frontend k8s_api bind 0.0.0.0:6443 mode tcp option tcplog default_backend k8s_api_backend backend k8s_api_backend mode tcp balance source # 클라이언트 IP 기반 고정 세션 stick-table type ip size 100k expire 30m # 세션 테이블 정의 stick on src # 소스 IP 기반 매핑 option httpchk GET /readyz # L7 상세 헬스체크 http-check expect status 200 # 200 응답 시 정상으로 판단 server master-1 10.128.0.35:6443 check ssl verify none fall 3 rise 2 server master-2 10.128.0.36:6443 check ssl verify none fall 3 rise 2 server master-3 10.128.0.37:6443 check ssl verify none fall 3 rise 2
- 세션 유지 (Sticky Sessions): 동일 클라이언트는 항상 동일 서버로 연결
- L7 헬스체크: API 서버의
/readyz엔드포인트로 더 정확한 상태 확인- SSL 검증 옵션: SSL 인증서 검증 설정
2-4. 설정 검증 & 서비스 관리
HAProxy 설정을 적용하기 전에 구문 오류를 검사하고, 서비스를 시작합니다.
# 구문 검사
sudo haproxy -c -f /etc/haproxy/haproxy.cfg
# 재시작 및 부팅 자동실행
sudo systemctl restart haproxy
sudo systemctl enable haproxy
# 상태 확인
systemctl status haproxy --no-pager
3. 부하 분산 메커니즘
HAProxy는 다양한 로드 밸런싱 알고리즘을 지원합니다.
- roundrobin: 순차적으로 요청을 분배 (기본 설정)
- source: 클라이언트 IP 기반 분배, 세션 유지에 유용
- leastconn: 가장 연결 수가 적은 서버로 우선 분배
- uri: URI 기반 분배 (HTTP 모드에서만 가능)
본 설정에서는 roundrobin을 사용해 세 개의 API 서버에 균등하게 요청을 분산합니다.
헬스 체크와 장애 감지
HAProxy는 설정된 체크 방식에 따라 각 백엔드 서버의 상태를 주기적으로 확인합니다.
- TCP 체크: 단순 TCP 연결 성공 여부 확인
- HTTP 체크: 지정된 URL에 HTTP 요청을 보내 응답 코드 확인
fall과 rise 파라미터는 다음을 의미합니다.
fall 3: 연속 3번 실패 시 서버를 비정상으로 표시rise 2: 연속 2번 성공 시 서버를 정상으로 복귀
이를 통해 일시적 네트워크 불안정으로 인한 오탐지를 방지합니다.
4. 다음 단계
쿠버네티스 클러스터 구성을 위한 다음 단계는 다음과 같습니다. 자세한 내용은 GCP에 VM으로 직접 쿠버네티스 클러스터 구축하는 방법를 참고하세요.
- 컨트롤 플레인 초기화:
kubeadm init --control-plane-endpoint=Bastion:6443 --upload-certs명령으로 첫 번째 마스터 노드 초기화 - 추가 컨트롤 플레인 구성: 생성된 조인 토큰을 사용해 나머지 컨트롤 플레인 노드 추가
- 워커 노드 조인: 워커 노드 조인 토큰으로 워커 노드 추가
운영 환경 고려사항
- 로드 밸런서 고가용성: 최소 2대의 로드 밸런서와 Keepalived (VRRP)를 구성하여 단일 장애점 제거
- 세션 지속성: API 서버 호출의 일관성을 위해 세션 유지 설정 고려
- SSL 종료: 필요에 따라 HAProxy에서 SSL 종료 구성
- 모니터링: HAProxy 통계 Prometheus 통합으로 모니터링 강화
결론
이 가이드에서는 HAProxy를 사용하여 쿠버네티스 컨트롤 플레인에 대한 고가용성 로드 밸런서를 구성하는 방법을 살펴보았습니다. 적절한 로드 밸런싱 구성은 쿠버네티스 클러스터의 안정성과 가용성을 크게 향상시킬 수 있습니다. 운영 환경에서는 로드 밸런서 자체의 고가용성도 반드시 고려해야 합니다.
댓글남기기