[KCSA]멀티 테넌시(Multi-tenancy)란

🔑 멀티 테넌시(Multi-tenancy)란?

• 한 클러스터를 여러 사용자/조직/고객이 함께 사용하는 것
• 클러스터를 나눠 쓰면 비용이 절약되고 관리도 간편하지만
  → 보안, 공정한 자원 분배, 소음 문제(노이즈 네이버) 같은 이슈 발생 가능

---

🎯 두 가지 주요 유형

유형 설명

Multi-Team	하나의 조직 내 여러 팀이 클러스터 공유 → 각 팀은 kubectl, GitOps 등으로 직접 리소스 제어
Multi-Customer (SaaS)	여러 고객을 위한 앱 인스턴스를 같은 클러스터에서 운영 → 고객은 클러스터에 직접 접근하지 않음

---

🧩 테넌트(Tenant)란?

• Multi-Team: 보통 "팀"이 테넌트
• Multi-Customer: 보통 "고객" 단위가 테넌트
• 혼합도 가능: 예) SaaS 회사가 내부 팀도 공유하고, 고객별 워크로드도 운영

---

🧱 격리 수준에 따른 멀티 테넌시

격리 수준 설명

Soft Tenancy	신뢰 기반, 완벽한 격리 없음 (예: 같은 네임스페이스 공유 등)
Hard Tenancy	서로 신뢰하지 않음, 강력한 격리 필요 → 보안, 자원 독립 필수 (ex. 고객 간 격리)

---

🛠️ 격리 기술 정리

1️⃣ 컨트롤 플레인(Control Plane) 격리

✅ 네임스페이스 (Namespace)

• API 리소스 격리를 위해 가장 기본적인 방법
• 네임스페이스마다 이름 중복 허용, 자체 보안 정책 적용 가능
• RBAC, 리소스 쿼터, 네트워크 정책 등과 함께 써야 효과적
• HNC(Hierarchical Namespace Controller)를 쓰면 네임스페이스 계층화도 가능

✅ RBAC 최소 권한

• 테넌트는 자신에게 필요한 네임스페이스에만 접근해야 함
• 권한이 너무 크면 → 네임스페이스 세분화 추천

✅ 리소스 쿼터 (ResourceQuota)

• 테넌트가 너무 많은 Pod, ConfigMap 등 생성 못 하도록 제한
• "시끄러운 이웃(Noisy Neighbor)" 문제 예방
• limits, requests 설정 필수!

---

2️⃣ 데이터 플레인(Data Plane) 격리

✅ 네트워크 격리

• 기본은 모든 Pod끼리 통신 가능 → 위험함
• → NetworkPolicy로 네임스페이스 간 통신 차단 + DNS 허용
• 네임스페이스 라벨을 활용해 정책 세분화 가능
• 고급: Service Mesh(mTLS, L7 policy) 사용 가능

⚠️ CNI 플러그인이 NetworkPolicy를 지원해야 적용됨!

✅ 스토리지 격리

• PersistentVolumeClaim(PVC)은 네임스페이스 기반 → 격리 가능
• PersistentVolume은 클러스터 전체 리소스라 주의
• StorageClass를 테넌트별로 분리하거나 ReclaimPolicy를 Delete로 설정!

✅ 샌드박스 실행 (Untrusted 코드일 때)

• gVisor, Kata Containers 등 활용
  → 컨테이너를 별도 VM 또는 사용자 공간 커널에서 실행

✅ 노드 격리 (Node Isolation)

• 테넌트별 노드 분리 → 다른 테넌트와 같은 노드에 Pod 안 띄움
• Taints + Tolerations, NodeAffinity 활용
• 비용 예측 및 요금 분리하기도 쉬움

---

⚙️ 기타 고려사항

🧮 API 우선순위 & 공정성

• API 요청에 우선순위를 두어 중요한 요청을 먼저 처리
• 보통 SaaS 고객이 직접 API 접근할 때 사용

🧊 QoS tiers

• 네트워크, 스토리지, Pod 우선순위로 QoS 등급 설정
  • 무료 vs 유료 사용자 분리 가능

🌐 DNS 격리

• CoreDNS 설정으로 네임스페이스 간 서비스 이름 조회 제한 가능

---

🤖 Operators

• 여러 인스턴스 자동 관리하는 컨트롤러 (예: 데이터베이스)
• 멀티 테넌시 환경에서는:
  • 테넌트 네임스페이스 안에서 리소스 생성하도록 제한
  • 샌드박싱, 노드 격리 등 격리 설정 가능해야 함

---

🔀 구현 방법 2가지

방식 설명

네임스페이스 per 테넌트	가장 일반적, 리소스 비용 적고 쉬움 → 단, 네임스페이스 아닌 리소스(CRD, Webhook)는 격리 어려움
가상 컨트롤 플레인 per 테넌트	각 테넌트에 API 서버 등 컨트롤 플레인 제공 → 거의 독립적인 클러스터처럼 동작 → 예: vcluster, Kamaji, CAPN 등 사용 가능

---

✅ 결론 요약

항목 권장 방법

격리 기본	네임스페이스 per 테넌트 + RBAC 최소 권한
자원 통제	리소스 쿼터, limits, requests
네트워크	NetworkPolicy, Service Mesh
스토리지	PVC로 격리, StorageClass 활용
고급 격리	노드 격리, 샌드박싱, 가상 컨트롤 플레인
관리 도구	HNC, Kyverno, Gatekeeper, Capsule, vcluster 등