쿠버네티스 실습: 멀티 테넌트 SaaS 아키텍처 — 팀별 리소스 격리, 청구, 정책기반 자동화

쿠버네티스 실습: 멀티 테넌트 SaaS 아키텍처 — 팀별 리소스 격리, 청구, 정책기반 자동화

이전 글에서는 AI 기반 자율 확장(AIOps + KEDA + Kubecost + Cluster Autoscaler) 를 통해
워크로드 부하를 예측하고 자율적으로 확장·축소하는 지능형 비용 최적화 인프라를 구축했습니다.

이번 글은 그 위 단계로, 실제 SaaS 서비스를 운영할 때 필수적인 Multi-Tenant Kubernetes Architecture를 실습합니다.
즉, “한 클러스터에서 여러 고객(또는 팀)이 공존하되, 각자의 리소스·보안·비용·배포 정책이 독립적으로 관리되는 구조”를 구현합니다.

---

1) 목표

“단일 쿠버네티스 클러스터에서 여러 팀(또는 고객)이 안전하게 공존하며,
각 테넌트별로 자원·보안·비용·정책을 자동으로 분리하는 SaaS 환경을 구축한다.”

---

2) 전체 아키텍처

[Global Cluster]
   ├── Namespace (tenant-a)
   │     ├── NetworkPolicy / ResourceQuota / LimitRange
   │     ├── ArgoCD Project (tenant-a)
   │     ├── Kubecost Tenant View
   │     └── Vault Secret Scope
   │
   ├── Namespace (tenant-b)
   │     ├── 동일 구조
   │
   └── Istio Gateway + Ingress + Policy Mesh (Global)

핵심 구성 요소

구성 요소 역할

Namespace	논리적 테넌트 격리 단위
NetworkPolicy	네트워크 간 접근 차단
ResourceQuota / LimitRange	CPU·메모리 사용량 제한
ArgoCD Project	테넌트별 배포 관리
Kubecost	비용 분리·청구
Vault / OPA / Kyverno	보안·정책 통제
Istio Gateway	트래픽 라우팅 및 인증

---

3) 테넌트 네임스페이스 구조

예시: 두 팀(team-a, team-b)이 동일 클러스터 내 공존

kubectl create namespace team-a
kubectl create namespace team-b

---

4) 리소스 격리 정책

반응형

resource-quota.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    pods: "50"

limit-range.yaml

apiVersion: v1
kind: LimitRange
metadata:
  name: tenant-a-limit
  namespace: team-a
spec:
  limits:
  - default:
      cpu: 500m
      memory: 512Mi
    defaultRequest:
      cpu: 200m
      memory: 256Mi
    type: Container

→ 각 테넌트는 CPU/메모리/Pod 수를 초과할 수 없음.

---

5) 네트워크 정책으로 트래픽 격리

networkpolicy.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-tenant
  namespace: team-a
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector: {}
      namespaceSelector:
        matchLabels:
          tenant: team-a

→ team-a 네임스페이스의 Pod만 서로 통신 가능.

---

6) Vault로 Secret 스코프 분리

Vault의 policy.hcl 예시:

path "secret/data/team-a/*" {
  capabilities = ["read", "create", "update"]
}
path "secret/data/team-b/*" {
  capabilities = ["deny"]
}

→ 각 테넌트는 자신에게 허용된 Secret만 접근 가능.

---

7) ArgoCD Project로 배포 분리

argocd-project.yaml

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-a
  namespace: argocd
spec:
  destinations:
  - namespace: team-a
    server: https://kubernetes.default.svc
  sourceRepos:
  - 'https://github.com/company/tenant-a-repo.git'
  clusterResourceWhitelist:
  - group: '*'
    kind: '*'

→ 각 팀은 자신 전용 Git 레포지토리에서만 배포 가능.

---

8) Kubecost로 테넌트별 비용 분리

Kubecost의 Helm values 예시:

kubecostProductConfigs:
  multiClusterMode: false
  aggregation: namespace

Grafana Dashboard 예시:

• Namespace별 일일 비용
• 테넌트별 CPU/메모리 소비율
• 예산 초과 알림

→ team-a와 team-b의 클러스터 사용 비용을 정확히 분리 및 청구.

---

9) Istio Gateway를 통한 트래픽 라우팅

istio-gateway.yaml

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: tenant-gateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - "a.app.example.com"
    - "b.app.example.com"
    port:
      number: 80
      name: http
      protocol: HTTP

→ 각 테넌트별 도메인/서브도메인 라우팅 설정.

---

10) 정책 기반 자동화 (OPA + Kyverno)

예시: 테넌트가 Root 권한을 가진 Pod를 생성하려 하면 차단

tenant-policy.rego

package tenant.security

default allow = false

allow {
  input.metadata.namespace == "team-a"
  not input.spec.securityContext.privileged
}

→ Kyverno와 함께 적용하면,
모든 테넌트 배포에 자동 보안 검증이 추가됩니다.

---

11) 운영 자동화

• AIOps + Kubecost 연동
  • 테넌트별 부하 예측 + 비용 패턴 분석
  • 비효율 리소스 자동 축소
• ArgoCD Sync Policy
  • 각 팀의 배포 파이프라인 독립 자동화
• Slack / Webhook 통합
  • 예산 초과, 정책 위반, 리소스 초과 실시간 경고

---

12) 실제 운영 시나리오

상황 시스템 동작

team-a CPU 과다 사용	KEDA가 Pod 축소, Cluster Autoscaler 감축
team-b 네트워크 침입 시도	NetworkPolicy + Falco 즉시 차단
team-a Pod Root 실행 시도	OPA/Kyverno 정책으로 배포 거부
예산 초과 예측	Kubecost + AIOps Slack 알림
신규 고객 추가	Namespace + ArgoCD Project 자동 생성

---

13) 정리

• Namespace 기반 격리: CPU/메모리/네트워크 분리
• Vault / OPA / Kyverno: 보안 정책 통합
• ArgoCD: 테넌트별 배포 자동화
• Kubecost + AIOps: 비용/자원 예측 관리
• 결과:
  하나의 클러스터로 다수의 SaaS 고객을 안전하게 운영하는
  “Self-Service Multi-Tenant Kubernetes Platform” 완성

---

다음 글에서는 이 아키텍처를 기반으로
테넌트별 사용자 인증 및 API Key 발급 시스템 (NestJS + OIDC + Redis + Gateway 연동) 을 구축하여
SaaS 구독형 API 플랫폼 형태의 완전한 서비스 모델을 완성하겠습니다.

---

 

쿠버네티스,멀티테넌트,SaaS,Namespace,ArgoCD,Kubecost,OPA,Kyverno,보안정책,클라우드비용,K8s실습

 

✅ 참고할 최신 자료

• Kubernetes 공식 문서의 멀티테넌시 개요: Namespace, 리소스 격리, 권한 관리 등의 개념이 정리되어 있습니다. (Kubernetes)
• vCluster / Capsule 등 하드 멀티테넌시 도구에 대한 논의: 단순한 네임스페이스 분리만으론 충분치 않다는 실무 의견들이 있습니다. (Reddit)
• Kubecost 등 비용 가시화 툴을 통한 테넌트별 청구 및 모니터링 사례도 다양한 글로 나와 있습니다. (예: 과금/청구 분리 필요성) (Reddit)
• 클라우드 제공자(예: Azure Kubernetes Service)에서 멀티테넌시 설계 가이드라인. (Microsoft Learn)

---

⚠️ 보완/강화 제안

아래 항목을 보완하면 글의 깊이와 실무감이 더 높아집니다:

• 격리 수준의 구분: 네임스페이스 기반(soft multi-tenancy) vs 클러스터/노드 기반(hard multi-tenancy)의 차이와 장단점을 조금 더 명확히 설명하는 것이 좋습니다.
• 테넌트 온보딩 및 자동화 흐름: “신규 고객 추가 → Namespace 생성 → 리소스제한 세팅 → Argo CD Project 생성” 등의 자동화 스크립트 또는 파이프라인 흐름을 추가하면 현실감이 올라갑니다.
• 비용 청구 및 모니터링 설계: 단순히 리소스 격리가 아니라 “테넌트별 리소스 사용량 집계 → 비용 산정 → 알림/예산 초과 대응”까지 흐름을 넣으면 좋습니다.
• 보안 정책 / 접근 제어: 각 테넌트 간 격리뿐 아니라 플랫폼 운영자가 각 테넌트에 대해 정책 템플릿을 만들어 자동 배포하는 방식(예: Kyverno / OPA)을 설명하면 더 완성도 있습니다.
• 운영 고려사항: 많은 테넌트를 하나 클러스터에 운영할 경우 “노이즈 네이버(noisy neighbor) 문제”, “네임스페이스 수 증가에 따른 API 성능” 등의 리스크도 언급하면 현실감이 더해집니다.

---