🔒 내부용 · 비배포 (포트폴리오에는 일반화 버전만 공개)
0한눈에
- 대상: 데이터 수집용 Kubernetes 클러스터 (기존 IDC 단일 사이트).
- 확장: IDC 컨트롤 플레인·노드 + In-house 워커 노드 2대(
ih-crawl) → 하이브리드 클러스터.
- 핵심 제약: IDC ↔ In-house 직접 접근이 NAT로 차단 → WireGuard 터널 + NAT 구성으로 우회.
1왜 확장했나
기존 수집 클러스터는 IDC 단일 사이트에서만 운영되어 자원 확장과 가용성에 한계가 있었다. In-house 서버를 활용해 자원을 늘리려면 클러스터를 멀티 사이트로 넓혀야 했다. 다만 IDC와 In-house 사이는 NAT로 직접 접근이 막혀 있어, 단순히 노드를 추가할 수 없는 환경이었다.
2구성 토폴로지
- IDC: 컨트롤 플레인 + 기존 노드 (
data-crawl, 211.x / 212.x 대역).
- In-house: 워커 노드 2대 (
ih-crawl, 172.30.x 대역) — 수집 워크로드 담당.
- 두 사이트를 WireGuard 터널로 연결하고 NAT를 구성해, IDC 컨트롤 플레인이 In-house 워커를 관리하도록 합류.
3진행 순서
- WireGuard 터널 + NAT 구성으로 IDC ↔ In-house 경로 확보 (NAT 우회)
- In-house 워커 노드 2대(
ih-crawl)를 기존 IDC 클러스터에 합류
- 트러블슈팅: Git-Sync 실패 해소(재시도 한계 조정), In-house 노드
Init:Error 해소
- 전체 클러스터 안정화 후 구성·서버 토폴로지를 아키텍처·런북으로 문서화
NAT로 직접 접근이 막힌 환경에서는 노드 합류·Git-Sync 등 클러스터 내부 통신이 터널을 거치므로, 재시도/타임아웃 동작이 단일 사이트와 다르게 나타난다. Git-Sync 재시도 한계 조정과 Init:Error 해소가 안정화의 핵심이었다.
4온보딩 포인트
- 클러스터는 이제 IDC(컨트롤 플레인·노드) + In-house(워커 2대) 하이브리드 구조. 사이트 간 통신은 WireGuard 터널을 경유.
- In-house 노드 이슈 디버깅 시 터널 상태 → NAT → 노드 상태(
Init:Error) → Git-Sync 순으로 점검.
- 구성·토폴로지는 아키텍처 문서와 런북에 정리되어 있으니 먼저 참고.
5공개(포트폴리오)와의 차이
공개 버전(human/portfolio/items/k8s-hybrid-cluster.html)은 호스트명(ih-crawl, data-crawl)·IP 대역(211.x / 212.x / 172.30.x) 등 내부 식별자를 제거하고, 일반 기술어(Kubernetes / WireGuard / NAT / Git-Sync)와 문제·접근·임팩트 중심으로 일반화했다. 이 내부 문서는 본인 참고/온보딩용. (역할: 데이터파트 파트리더, 2026-01부터 주도)