2.1. 시스템 구성
물리 구성도
OPENMARU COP는 사용자 트래픽을 외부 로드밸런서를 통해 클러스터 내부로 라우팅하는 구조를 가지며, 전체 구성은 다음과 같습니다.
계층별 구성
| 계층 | 구성 요소 | 역할 |
|---|---|---|
| 접근 계층 | 로드밸런서(L4/L7) | 외부 트래픽 진입점, TLS 종료, K8s API 프록시 |
| 관리 계층 | Bastion | 설치 자동화, DevOps 도구, NFS 스토리지 호스팅 |
| Control Plane | Master 노드 3식 | API Server, etcd, Controller Manager, Scheduler |
| Data Plane | Worker 노드 N식 | 애플리케이션 워크로드(Pod) 실행 |
| Infra 계층(선택) | Infra 노드 | 모니터링, CI/CD 등 인프라성 워크로드 전용(Enterprise 아키텍처에서 구성) |
| 스토리지 계층 | NFS / Local Path Provisioner | 동적 볼륨 프로비저닝 |
⚠️ 참고: 운영 환경에서는 별도의 물리/클라우드 L4·L7 로드밸런서 사용을 기본으로 합니다. Bastion에 내장된 HAProxy는 별도 로드밸런서가 없는 환경이거나 설치 초기 구성을 위해 활용하는 구성 요소입니다. Bastion HAProxy를 그대로 운영에 사용하는 경우, Bastion은 물리적으로 단일 서버이므로 장애 시 클러스터 API 접근 및 서비스 진입점 전체가 중단되는 단일 장애점(SPOF) 이 될 수 있다는 점에 유의하십시오.
Bastion 서버 구성
Bastion 서버는 설치/운영 관리와 DevOps 도구를 호스팅하는 중앙 관리 서버로, 다음 서비스로 구성됩니다.
| 서비스 | 역할 | 포트 | 실행 방식 |
|---|---|---|---|
| Docker Engine | 컨테이너 런타임 | - | systemd |
| DNS (BIND) | 내부 DNS 서비스 | 53 | systemd |
| NFS Server | 공유 스토리지(/data/nfsshare) | 2049 | systemd |
| Chrony | 시간 동기화 | 123 | systemd |
| HAProxy | 로드밸런서 | 6443, 443, 80 | systemd |
| GitLab | 소스 코드 관리 | 1080, 1022 | Docker |
| Jenkins | CI 서버 | 18080, 18022 | Docker |
| Harbor | 컨테이너 레지스트리 | 8443 | Docker |
| Nexus | 아티팩트 저장소 | 8081 | Docker |
| ChartMuseum | Helm Chart 저장소 | 8181 | Docker |
| MariaDB | 샘플 애플리케이션 테스트용 DB | 3306 | Docker |
Bastion에는 Ansible 자동화 도구도 함께 설치되어 클러스터 전체 노드에 대한 구성·업그레이드·운영 작업의 실행 지점 역할을 수행합니다.
RKE2 클러스터 구성
OPENMARU COP의 Kubernetes 클러스터는 RKE2 배포판을 기반으로 하며, Control Plane과 Data Plane으로 구분됩니다.
| 항목 | 값 |
|---|---|
| 배포판 | RKE2 |
| CNI | Canal (Calico + Flannel) |
| 보안 프로파일 | CIS 벤치마크 |
| 컨테이 너 런타임 | containerd |
| 이미지 GC 임계치 | High 80% / Low 60% |
네임스페이스 구조
| 네임스페이스 | 용도 |
|---|---|
kube-system | Kubernetes 시스템 컴포넌트 |
openmaru-cop | OPENMARU COP Console |
openmaru-sso | Keycloak SSO, LLDAP |
openmaru-observ | MSAP Observability (메트릭/로그/알림) |
openmaru-apm | MSAP APM |
cert-manager | 인증서 관리 |
argocd | ArgoCD GitOps 배포 |
nfs-provisioner | NFS 동적 프로비저닝 |
local-path-storage | Local Path 동적 프로비저닝 |
gpu-operator | NVIDIA GPU Operator (GPU 노드 구성 시) |
openmaru-cronhpa | CronHPA 컨트롤러 |
openmaru-vllm | vLLM/CogentAI (AI/GPU 워크로드 구성 시) |
네트워크 토폴로지
Ingress 처리 경로는 다음과 같습니다.
ℹ️ 참고: OPENMARU COP는 클러스터 내부 Ingress Controller로 기본적으로 HAProxy Ingress Controller를 사용합니다. NGINX Ingress Controller도 옵션으로 선택할 수 있으나, 커뮤니티
ingress-nginx프로젝트가 유지보수 종료(2026년 3월 이후 신규 릴리스·보안 패치 없음)된 상태이므로 특별한 이유가 없다면 기본값인 HAProxy Ingress Controller 사용을 권장합니다.
SSO 인증은 다음과 같은 흐름을 따릅니다.
고가용성(HA) 아키텍처
- 로드밸런서: Round-Robin 방식으로 Master 노드의 API Server(
:6443)에 헬스체크 기반 부하 분산 - etcd: Master 3노드 구성 시 Raft 합의 알고리즘 기반, Quorum 2/3, 최대 1개 노드 장애까지 허용
- etcd 백업: 정기적인 스냅샷 자동 백업이 설정되어 있어야 하며, 실제 백업 실행/보관 절차는 5.1. 장애 처리 가이드 - Master 백업본으로 복원(etcd)를 참고하십시오.
장애 시나리오별 영향
| 시나리오 | 영향 |
|---|---|
| Master 노드 2개 이상 동시 장애 | Quorum 상실로 클러스터 제어 기능 중단(애플리케이션 Pod는 계속 동작하나 신규 배포/변경 불가) |
| Master 노드 1개 장애 | Quorum 유지, 클러스터 정상 동작(HA로 자동 대응) |
| Worker 노드 장애 | 해당 노드의 Pod가 Ready 상태였다면 자동 재스케줄링(PDB/리소스 여유에 따라 일부 지연 가능), 애플리케이션 가용성에 일시적 영향 가능 |
| Bastion 장애 | (Bastion 내장 HAProxy를 로드밸런서로 사용 중인 경우) 클러스터 API/서비스 진입점 전체 접근 불가. GitLab/Jenkins/Harbor/Nexus 등 Bastion 호스팅 DevOps 도구도 함께 중단(신규 빌드/배포 불가, 기존 실행 중인 애플리케이션은 계속 동작) |
⚠️ 주의: Master 노드는 항상 홀수(3, 5 등)로 구성해야 하며, 최소 2개 이상 정상 상태를 유지해야 클러스터가 정상 동작합니다.