26Y06m2
DevOps 조직이 선언적(GitOps)으로 관리하는 애플리케이션 영역과 사용자가 포탈(Workbench)을 통해 온디맨드로 생성하는 샌드박스/분석 영역이 공존하는 복합 멀티테넌트 환경에서의 네임스페이스(Namespace) 관리 마스터 가이드 및 Best Practice입니다.
6,000명 단위의 사용자 인터페이스와 대규모 클러스터를 안정적으로 지탱하려면, Workbench가 네임스페이스를 생성하는 시점에 보안, 자원, 네트워크 격리 정책이 단 1초의 공백도 없이 패키지로 자동 주입(Provisioning)되도록 아키텍처 가드레일을 치는 것이 핵심입니다.
1. 네임스페이스 명명 규칙 및 분리 표준 (Naming Convention)
두 트랙의 관리 주체와 목적이 완전히 다르므로, 쿠버네티스 RBAC 및 모니터링 그룹화를 위해 접두사(Prefix)를 이용해 물리적 영역을 엄격히 격리해야 합니다.
- DevOps 생성 영역 (Application / Shared Infra):
- 규격:
<영역>-<도메인/서비스>-<환경> - 예시:
app-finops-prod,infra-aistor-prod,shared-starrocks-mgmt - 관리 방식: Bitbucket ➡️ ArgoCD 기반의 완전 선언적 GitOps 제어
- Workbench 생성 영역 (User Personal Sandbox):
- 규격:
usr-<팀/부서>-<사번/계정명>(또는wb-접두사 사용) - 예시:
usr-analytics-honggd,usr-platform-kimsb - 관리 방식: Workbench 백엔드 API 또는 Admission Controller 기반의 명령형 자동 프로비저닝
2. Workbench 네임스페이스 생성 시 패키지 자동 주입 (Automation Guardrails)
사용자가 Workbench에서 "나만의 작업 공간 생성"을 누를 때, 백엔드 엔진은 단지 kind: Namespace만 생성해서는 안 됩니다. 해당 네임스페이스 내부에 다음 4대 핵심 오브젝트를 한 세트(Bundle)로 묶어서 동시에 배포해야 합니다. Workbench 백엔드 API에 템플릿화해 두거나, Kyverno 같은 Mutation 어드미션 컨트롤러를 도입하여 자동화하십시오.
① 리소스 가드레일: ResourceQuota & LimitRange
6,000명의 유저가 자율적으로 파드를 띄우기 때문에, 기동 즉시 클러스터 자원 고갈(Starvation)을 막는 쿼터가 강제 적용되어야 합니다.
- ResourceQuota (네임스페이스 총량 제한): Workbench 유저에게는 엄격한 기본 샌드박스 쿼터(예: CPU 4Core, Memory 16Gi, PV Capacity 100Gi)를 부여하고, 이를 초과하는 대형 분산 연산(Spark 대규모 배치 등)은 별도의 승인 절차를 통해 쿼터를 확장해 주는 방식을 취합니다.
- LimitRange (컨테이너 단위 기본값 주입): 사용자가 파드 배포 시 Request/Limit 설정을 누락하더라도, 플랫폼이 정의한 안전한 기본값(Default)이 자동으로 인젝션되도록 보장합니다. (예: 설정을 안 하면 자동으로 CPU Request 0.5 / Memory 1Gi 주입)
② 네트워크 벽: NetworkPolicy
Workbench 네임스페이스는 기본적으로 "모든 타인으로부터의 인바운드 차단(Default Deny Isolation)" 정책이 적용되어야 합니다.
- 동작 설계:
usr-analytics-honggd네임스페이스 내부의 파드는 옆자리usr-analytics-lee파드와 통신할 수 없으며, DevOps가 관리하는app-계열의 내부 마이크로서비스를 직접 찌를 수 없도록 차단합니다. - 화이트리스트 허용: 오직 사내 공통 원천 저장소인 AIStor(MinIO) 서비스 노선과 StarRocks 등의 공유 데이터 레이크하우스 엔드포인트로의 아웃바운드(Egress) 통신만 명시적으로 허용합니다.
③ 권한 통제: RBAC (RoleBinding)
Workbench에서 로그인을 수행한 사용자(Keycloak OIDC 연동 계정 등)에게 해당 네임스페이스 내부에서만 왕처럼 군림할 수 있는 권한을 부여합니다.
- 동작 설계: 쿠버네티스 내장 클러스터롤인
admin또는edit롤을 오브젝트 스토리지 생성 시 유저 계정과RoleBinding으로 결합합니다. - 가드레일: 해당 유저는 자기 네임스페이스 안에서는 자유롭게 파드를 띄우고 지울 수 있지만, 옆 네임스페이스를 조회하거나 클러스터 레벨 자산(Node, PV, CustomResourceDefinition 등)을 변경하는 행위는
ClusterRoleBinding이 없으므로 API 서버 단에서 원천 차단됩니다.
3. Workbench 환경을 위한 세부 거버넌스 가이드라인 (Playbook)
가이드 1. 유휴 자산 자동 회수 정책 (Inactivity TTL)
데이터 사이언티스트나 분석가들은 워크벤치에서 Jupyter Notebook이나 가설 검증용 Spark 파드를 띄워놓고 퇴근하거나 방치하는 경우가 매우 많습니다. 이는 대규모 노드 환경에서 자원 파편화와 유휴 손실의 주범이 됩니다.
- 해결 제어: Workbench 백엔드에 시계열 커널 감시 루틴을 두거나 커스텀 크론잡을 배치하여, 최근 48시간 동안 CPU/Memory 실효 활용률이 0.05% 미만인
usr-계열 네임스페이스는 내부 워크로드를 자동으로 Downscaling(Replica 0) 하거나 배치를 종료하고 메신저로 경고를 날리는 자동 회수 메커니즘을 정착시키십시오.
가이드 2. 공유 스토리지 및 공통 시크릿(Secret) 동기화 전략
에어갭 내부 저장소(AIStor, Bitbucket 등)에 접근하기 위한 공통 Credential(접속 키 토큰, SSL 인증서 등)을 모든 유저 네임스페이스에 복사해 주는 작업은 관리적 오버헤드이자 보안 취약점입니다.
- Best Practice: * 방법 A: Vault의 Vault Agent Injector 아키텍처를 도입하여, 파드가 뜰 때 유저가 시크릿을 직접 가지고 있지 않아도 어노테이션 기반으로 Vault에서 토큰을 동적으로 주입받게 만듭니다.
- 방법 B: 쿠버네티스 오픈소스 툴인
Kubed (Secret Syncer)를 도입하여, DevOps가 마스터 네임스페이스에 시크릿을 생성하고 어노테이션(kubed.appscode.com/sync: "")을 달아두면 새로 생성되는 모든usr-네임스페이스로 공통 시크릿이 실시간 복제되도록 파이프를 뚫어둡니다.
가이드 3. 스토리지(PV) 고갈 방지를 위한 전용 StorageClass 배정
사용자들이 워크벤치 안에서 대용량 원천 Parquet를 로컬 디스크로 무분별하게 다운로드받다가 노드의 Root 디스크를 고갈시키는 사고를 방지해야 합니다.
- Best Practice: Workbench 전용 네임스페이스에는 로컬 디스크 격리 및 용량 제어가 엄격하게 작동하는 전용
StorageClass만 사용하도록 제한하고,ResourceQuota명세에requests.storage총량을 명확히 묶어두어 한 테넌트의 폭주가 물리 스토리지 풀 전체를 다운시키는 시나리오를 방어하십시오.
4. 핵심 요약: DevOps 통제 매트릭스
| 관리 대상 요소 | DevOps 생성 영역 (app-) | Workbench 생성 영역 (usr-) |
|---|---|---|
| 생성 주체 | DevOps 엔지니어 | Workbench 플랫폼 API (무인 자동화) |
| 형태 | 선언적 매니페스트 (GitOps) | 템플릿 기반 동적 바인딩 |
| ResourceQuota | 도메인 스펙별 맞춤형 산정 | 엄격한 표준 기본 샌드박스 쿼터 적용 |
| LimitRange | 애플리케이션 특성별 수동 최적화 | 엄격한 가드레일용 Default값 강제 주입 |
| NetworkPolicy | 서비스 간 메쉬 통신 허용 | 외부 통신 완전 차단 (오직 인프라만 허용) |
| 보안 인증 | 서비스 어카운트 및 Vault 연동 | OIDC 유저 계정 1:1 맵핑 RoleBinding |
| 생명 주기 | 서비스 종료 시까지 영구 유지 | TTL 정책 적용 (유휴 시 자원 자동 회수) |
