Rancher Single에서 RKE2 3-Node HA 구성 전환 및 장애 복구 대응 정리

Rancher Single에서 RKE2 3-Node HA 구성 전환 및 장애 복구 대응

기존 Docker 기반 Single Rancher 환경은 Rancher 관리 서버 자체에 장애가 발생할 경우 관리 서비스에 영향을 받을 수 있다. 이를 개선하기 위한 방안으로 RKE2 3-Node 기반 Rancher HA 구조를 구성하고, 각 Rancher Node를 서로 다른 가상화 호스트에 분산 배치하는 방안을 고려할 수 있다.

구성 방향
기존 Docker Single Rancher → RKE2 3-Node → Rancher HA → LB/VIP 단일 접속 구조

1. AS-IS / TO-BE 구성

구분	AS-IS	TO-BE
Rancher 구성	Docker 기반 Single	RKE2 기반 HA
Node	Single Server	3-Node
접속 구조	단일 Rancher 서버 접속	LB/VIP를 통한 단일 접속점
장애 대응	단일 서버 장애 영향 존재	잔여 정상 Node를 통한 서비스 지속 구조
가상화 배치	단일 VM 중심	Rancher Node VM 분산 배치

2. Rancher HA 구성도

외부 사용자는 Rancher Node에 직접 접근하는 대신 LB 또는 VIP를 통해 접속한다. LB 뒤에는 3개의 RKE2 Node를 배치하고 각 Node에서 Rancher 서비스를 구성한다.

                    [ Administrator ]
                           │
                           │ HTTPS
                           ▼
                    ┌─────────────┐
                    │   LB / VIP  │
                    └──────┬──────┘
                           │
             ┌─────────────┼─────────────┐
             │             │             │
             ▼             ▼             ▼
        ┌─────────┐   ┌─────────┐   ┌─────────┐
        │ RKE2 #1 │   │ RKE2 #2 │   │ RKE2 #3 │
        │ Rancher │   │ Rancher │   │ Rancher │
        └────┬────┘   └────┬────┘   └────┬────┘
             │             │             │
             └─────────────┼─────────────┘
                           │
                      RKE2 Cluster
                           │
                  Rancher HA Service


        [ESXi Host #1] [ESXi Host #2] [ESXi Host #3]
              │              │              │
           VM #1          VM #2          VM #3

핵심 설계 방향: Rancher Node VM을 가능한 한 서로 다른 ESXi Host에 분산 배치하여 단일 물리 Host 장애가 Rancher HA 전체 장애로 확대되는 위험을 줄인다.

3. Rancher HA 전환 흐름

기존 환경을 즉시 제거하는 방식보다 신규 HA 환경을 먼저 구축하고 검증한 뒤 접속 경로를 전환하는 방식으로 계획하는 것이 Rollback 경로를 확보하기 쉽다.

기존 Docker Rancher  →  Backup  →  신규 RKE2 3-Node 구축  →  Rancher HA 구성/복원  →  LB/VIP 전환  →  검증  →  기존 환경 정리

1. 기존 Rancher 환경 및 관리 대상 Cluster 현황 확인
2. 기존 환경 Backup 및 복구 방안 확보
3. 신규 VM 3대 생성 및 Host 분산 배치
4. RKE2 3-Node Cluster 구성
5. Rancher HA 환경 구성
6. 기존 Rancher 데이터 및 관리 환경 복원
7. 관리 대상 Kubernetes Cluster 연결 상태 검증
8. LB/VIP 및 DNS 접속 경로 전환
9. 서비스 정상 여부 확인
10. Rollback 기간 종료 후 기존 Docker Rancher 정리

4. 장애 복구 대응

HA 구성에서는 단순히 Rancher를 여러 개 실행하는 것뿐 아니라 Pod, RKE2 Node, VM, 물리 Host 등 장애 발생 위치에 따라 복구 방식을 구분해야 한다.

장애 유형	영향	대응 방안
Rancher Pod 장애	해당 Pod 서비스 중단	Kubernetes의 컨트롤러에 의해 Rancher Pod가 다시 생성되도록 하고 Replica 상태와 서비스 Endpoint를 확인한다.
RKE2 Node 1대 장애	해당 Node에서 실행 중인 워크로드 영향	정상 Node 상태와 etcd 상태를 확인하고, 장애 Node 복구 후 Cluster 정상 재합류 여부를 점검한다.
Rancher VM 장애	해당 VM의 RKE2 Node 사용 불가	VM 또는 OS 장애 원인을 복구한 후 RKE2 서비스와 Cluster Node 상태를 확인한다.
ESXi Host 장애	해당 Host에 위치한 VM 영향	Rancher Node VM을 서로 다른 ESXi Host에 분산 배치하여 단일 Host 장애 영향을 최소화한다.
LB 장애	Rancher 접속 경로 장애	LB 자체 이중화 또는 VIP HA 구조를 구성하여 Rancher Node가 정상이어도 접속점 장애로 서비스가 중단되는 상황을 방지한다.
전환 과정 장애	신규 Rancher 접속 또는 관리 기능 이상	신규 환경 검증이 완료될 때까지 기존 Rancher 환경을 유지하여 문제가 발생할 경우 기존 접속 경로로 Rollback할 수 있도록 한다.

5. Node 장애 시 동작 구조

정상 상태

             [ 정상 상태 ]

        VM #1      VM #2      VM #3
          ●          ●          ●
          │          │          │
          └──────────┼──────────┘
                     ▼
                 Rancher HA

1개 Node 장애 발생

             [ Node 장애 ]

        VM #1      VM #2      VM #3
          X          ●          ●
                     │          │
                     └────┬─────┘
                          ▼
                    정상 Node 운영
                          │
                          ▼
                     Node 복구
                          │
                          ▼
                     ●    ●    ●
                       정상화

장애 발생 시 우선 정상 Node와 Rancher 서비스 상태를 확인하고, 장애 Node 복구 후 RKE2 및 etcd Cluster 상태가 정상으로 복귀했는지 검증하는 절차가 필요하다.

6. 장애 복구 절차

실제 장애 대응은 장애 위치를 먼저 식별한 후 계층별로 상태를 확인하는 것이 중요하다.

장애 감지  →  장애 범위 확인  →  정상 Node 확인  →  서비스 지속 여부 확인  →  장애 Node 복구  →  Cluster 재합류 확인  →  HA 정상화

1. LB/VIP를 통한 Rancher 접속 가능 여부 확인
2. RKE2 Node 상태 확인
3. Rancher Pod 및 Replica 상태 확인
4. etcd Cluster 상태 확인
5. 장애 VM 및 ESXi Host 상태 확인
6. 장애 원인 제거 및 Node 복구
7. RKE2 Cluster 재합류 상태 확인
8. Rancher 관리 대상 Cluster 연결 상태 확인
9. 전체 HA 구성 정상화 확인

7. 설계 시 핵심 확인사항

• Node 분산: Rancher Node VM 3대를 가능한 한 서로 다른 ESXi Host에 배치
• 접속점 이중화: Rancher만 HA로 구성하고 LB가 Single이면 LB가 새로운 SPOF가 될 수 있으므로 LB/VIP 구조도 함께 검토
• DNS: 사용자가 개별 Node IP가 아닌 Rancher 서비스 FQDN으로 접근하도록 구성
• Backup: 전환 전 기존 Rancher의 Backup 및 복구 가능 여부 확인
• Rollback: 신규 환경 정상 검증 전까지 기존 Docker Rancher 환경 유지
• 모니터링: RKE2 Node, etcd, Rancher Pod, LB 상태를 함께 모니터링

8. 최종 구성 요약

기존 Docker 기반 Single Rancher 환경을 RKE2 3-Node 기반 Rancher HA 구조로 전환하면 Rancher 관리 플랫폼을 단일 서버에 의존하는 구조에서 분산된 구조로 변경할 수 있다.

특히 Rancher Node VM을 서로 다른 ESXi Host에 분산하고, 사용자 접속 경로에는 LB/VIP를 배치하면 Rancher Pod, VM 또는 단일 Host 장애가 발생했을 때 정상 구성 요소를 이용해 관리 서비스를 지속할 수 있는 기반을 마련할 수 있다.

전환 과정에서는 기존 환경을 바로 폐기하지 않고 신규 HA 환경 선 구축 → 복원 및 검증 → LB/VIP 전환 → 안정화 확인 → 기존 환경 정리 순서로 진행하여 장애 발생 시 Rollback할 수 있는 경로를 확보하는 것이 중요하다.

FAQ

Rancher HA를 구성하면 Node 한 대가 장애 나도 사용할 수 있나?

3-Node RKE2 구조에서는 단일 Node 장애 상황을 고려할 수 있다. 다만 실제 서비스 지속 여부는 etcd 상태, Rancher Replica 상태, LB Health Check 및 장애가 발생한 구성 요소에 따라 함께 확인해야 한다.

Rancher VM 3대를 같은 ESXi Host에 배치해도 되나?

논리적으로 구성할 수 있더라도 해당 ESXi Host 장애 시 여러 Rancher Node가 동시에 영향을 받을 수 있다. HA 목적이라면 가상화 계층에서도 VM을 서로 다른 Host에 분산하는 구성이 적합하다.

LB도 이중화해야 하나?

Rancher Node만 HA로 구성하고 LB가 단일 장비 또는 단일 인스턴스라면 LB 장애가 전체 접속 장애로 이어질 수 있다. 따라서 전체 서비스 가용성을 고려한다면 LB/VIP 계층의 HA도 함께 검토해야 한다.