폐쇄망(Air-Gapped) 환경에서의 Kubernetes 클러스터 아키텍처

외부 인터넷이 완전히 차단된 환경에서도(Air_Gapped) Kubernetes 클러스터를 안정적으로 운영하려면 단순히 클러스터를 설치하는 것만으로는 부족하다.
운영체제 패키지, 컨테이너 이미지, 백업·복구, 모니터링 체계까지 내부망 내에서 완전하게 순환하도록 설계해야 한다.

아래의 구성은 실제 폐쇄망(Air-Gapped) 환경에서 적용 가능한 Kubernetes 클러스터 아키텍처의 예시다.

1. 전체 구조 개요

이 아키텍처는 보안 경계를 명확히 나눈 3계층 구조로 구성된다.

• DMZ : 외부 사용자와 내부망 사이의 완충지대
• 내부망 (Internal Network): Kubernetes 클러스터, 저장소, 모니터링 시스템 위치
• 망연계 구간: DMZ와 내부망 간의 제한적 데이터 교환 통로

외부 사용자는 직접 내부망으로 접근할 수 없으며,
망연계 솔루션을 통해서만 필요한 파일(패키지, 이미지, 백업 등)이 이동한다.

2. 구성 요소별 설계

(1) DMZ 구간

• Frontend Web Server (Nginx / Apache)
  외부 사용자가 접근할 수 있는 유일한 지점이다.
  외부 요청은 DMZ의 웹 서버에서 1차 처리되고, 내부망으로 직접 연결되지 않는다.
  망연계 솔루션을 통해서만 내부 시스템과 데이터가 교환된다.
• 망연계 솔루션
  외부망과 내부망 간의 단방향 또는 양방향 전송을 통제한다.
  주로 파일 기반 전송(SFTP, 전용 게이트웨이 등) 형태로 운영되며,
  Kubernetes 운영 시에는 컨테이너 이미지, 패키지, 백업 파일의 반입·반출에 활용될수 있다.

(2) 내부망 (Air-Gapped Zone)

폐쇄망 환경에서의 핵심 구성은 모두 내부망에 존재한다.
여기서는 외부 연결 없이도 완전한 운영이 가능해야 한다.

⦿ Kubernetes Cluster

• 인터넷 연결 없이 완전 독립적으로 동작.
• 모든 이미지는 내부 Nexus 저장소에서 Pull.
• 구성요소:
  • etcd: 클러스터 상태 저장소
  • Velero: 리소스 및 PV 백업
  • Nexus Repository: 이미지 및 패키지 저장소
  • Zabbix Agent: 리소스 및 애플리케이션 모니터링

⦿ Nexus Repository

Kubernetes의 모든 의존성 관리의 중심이다.
외부 인터넷을 대신하여 내부에서 필요한 패키지와 이미지를 제공한다.

외부망에서 주기적으로 최신 버전을 미러링한 후,
망연계 구간을 통해 또는 물리매체(usb등) 를 이용해 내부 Nexus로 반입하는 형태로
운영된다.
이 과정을 통해 폐쇄망에서도 최신 보안 패치 및 이미지 배포가 가능하다.

⦿ Storage (Ceph / NFS)

Pod의 Persistent Volume(PV), Velero 백업 파일, etcd 스냅샷 등
모든 지속 데이터가 저장되는 스토리지 계층이다.
고가용성을 위해 Ceph을 권장하며, 단순 파일 공유 수준이라면 NFS도 가능하다.

⦿ Velero / etcdctl

• Velero: Kubernetes 리소스 및 PV를 포함한 백업 수행.
• etcdctl: etcd의 상태를 별도로 백업하여 Velero 복구 실패 시 대비.
• 두 백업 모두 NFS/Ceph 등 외부 스토리지에 저장된다.
• 복구 시에는 Velero restore → etcd snapshot 순으로 진행한다.

(3) 모니터링 및 알림 체계

⦿ Zabbix Server

• Kubernetes 내부가 아닌 외부 독립 서버에 배치하여 장애시에도 동작 가능.
• 주요 모니터링 항목:
  • 클러스터 노드별 리소스 (CPU, Memory, Disk)
  • Pod별 리소스 사용량
  • Application Metric (HTTP Response, 에러율 등)
• 데이터 수집은 Zabbix Agent2와 API Polling을 혼합해 구성한다.

⦿ Alarm Notification

• 외부 메일 서버나 외부 챗봇을 사용하지 않는다.
• 내부망에서만 접근 가능한 SMTP 또는 Mattermost를 이용한다.
• 알림 정책은 Zabbix에서 직접 제어하며,
  외부로 정보가 유출되지 않도록 내부 네트워크에 한정된다.

3. 백업 및 복구 전략

폐쇄망 환경에서는 인터넷을 통한 원격 백업이 불가능하므로
클러스터 내 백업 자동화 + 내부 스토리지 이중화가 핵심이다.

복구 순서:
① Velero restore → ② etcd snapshot 복원
이 조합으로 리소스 복구와 상태 복원을 동시에 처리할 수 있다.

4. 패키지 및 이미지 공급 체계

폐쇄망에서는 인터넷이 차단되어 있기 때문에
운영체제 및 애플리케이션의 모든 의존성을 내부에서 공급해야 한다.

1. 외부망에서 최신 패키지 및 이미지 미러링 수행
   • Docker Hub / Helm Repo / PyPI / apt/yum mirror 등
2. 망연계 솔루션 또는 물리매체(usb..) 통해 내부 Nexus로 전송
3. Kubernetes 및 애플리케이션은 내부 Nexus만 사용

이 과정을 통해 모든 노드와 Pod는 외부망 없이도
업데이트, 배포, 확장을 수행할 수 있다.

5. 설계 근거 요약

1. 명확한 네트워크 경계
   DMZ → 망연계 → 내부 FW → 내부망의 단계적 구조로 보안 구분.
2. 단일 공급망 관리
   Nexus로 패키지, 이미지, Helm 차트, Python 패키지를 통합 관리.
3. 이중 백업 체계
   Velero + etcdctl 조합으로 리소스와 상태를 모두 보존.
4. 모니터링 독립성 확보
   Zabbix를 클러스터 외부에 두어 장애 복원력 확보.
5. 내부 전용 알림 채널
   SMTP/Mattermost 기반의 폐쇄형 알림 체계 유지.

6. 결론

폐쇄망 환경의 Kubernetes는 “인터넷이 없는 클라우드”라고 할 수 있다.
외부에 의존하지 않고도 배포, 모니터링, 복구가 가능한 구조여야 한다.

🛠 마지막 수정일: 2025.10.14