멀티 테넌시
멀티 테넌시 (Multi-tenancy)
이 페이지는 클러스터 멀티 테넌시를 위한 구성 옵션과 모범 사례의 개요를 제공해요.
클러스터 공유는 비용을 절감하고 관리를 단순화해요. 하지만 보안, 공정성, noisy neighbor 관리 같은 과제도 생겨요. 클러스터는 다양한 방식으로 공유될 수 있고, 이 모든 공유 유형을 총칭해 멀티 테넌시라고 흔히 부릅니다.
Kubernetes는 최종 사용자나 테넌트의 일급 개념을 갖고 있지 않지만, 다양한 테넌시 요구를 관리하는 여러 기능을 제공해요.
사용 사례
일반적으로 Kubernetes 클러스터의 멀티 테넌시는 두 가지 큰 범주로 나뉘어요.
여러 팀 (Multiple teams)
흔한 형태는 조직 내 여러 팀이 클러스터를 공유하는 것이에요. 각 팀은 하나 이상의 워크로드를 운영하고, 이 워크로드들은 서로 및 다른 클러스터의 워크로드와 통신할 필요가 많아요. 팀 간에는 어느 정도 신뢰가 있지만, RBAC, quota, 네트워크 정책 같은 Kubernetes 정책이 안전하고 공정하게 공유하는 데 필수적이에요.
여러 고객 (Multiple customers)
다른 주요 형태는 SaaS(SaaS as a Service) 벤더가 고객을 위해 워크로드의 여러 인스턴스를 실행하는 방식이에요. 이 시나리오에서는 고객이 클러스터에 접근할 수 없고, Kubernetes는 벤더만 사용해 워크로드를 관리해요. 비용 최적화가 핵심이고, Kubernetes 정책으로 워크로드를 서로 강하게 격리해요.
용어
테넌트 (Tenants)
"테넌트"에 대한 단일 정의는 없어요. multi-team 사용에서는 테넌트는 보통 팀이고, multi-customer 사용에서는 테넌트는 단일 워크로드를 공유하는 사용자 그룹이에요. 같은 조직이 상황에 따라 두 정의를 모두 쓸 수도 있어요.
격리 (Isolation)
Kubernetes 클러스터는 Kubernetes 소프트웨어를 실행하는 컨트롤 플레인과, 테넌트 워크로드가 Pod로 실행되는 워커 노드(data plane)로 구성돼요. 테넌트 격리는 컨트롤 플레인과 데이터 플레인 양쪽에 적용될 수 있어요.
"하드(hard)" 멀티 테넌시는 테넌트가 서로 신뢰하지 않는 강한 격리를, "소프트(soft)" 멀티 테넌시는 약한 격리를 의미해요. 하지만 이 용어는 단일 정의가 없으므로, "hardness"/"softness"를 광범위한 스펙트럼으로 이해하는 게 좋아요.
극단적인 경우 클러스터 공유를 아예 포기하고 테넌트별 전용 클러스터를 할당하는 게 더 쉬울 수도 있어요. 강한 격리의 이점은 여러 클러스터 관리의 비용·복잡성과 비교해 평가해야 해요.
컨트롤 플레인 격리
컨트롤 플레인 격리는 서로 다른 테넌트가 서로의 Kubernetes API 리소스에 접근하거나 영향을 미치지 못하게 하는 것을 보장해요.
네임스페이스 (Namespaces)
Namespace는 단일 클러스터 내 API 리소스 그룹을 격리하는 메커니즘이에요.
- 네임스페이스 내 객체 이름은 다른 네임스페이스의 이름과 겹칠 수 있어요. 테넌트는 다른 테넌트가 하는 일을 고려하지 않고 리소스 이름을 지을 수 있어요.
- 많은 Kubernetes 보안 정책이 네임스페이스로 범위가 한정돼요. RBAC Roles와 Network Policies가 네임스페이스 범위 리소스예요.
멀티 테넌트 환경에서 네임스페이스는 테넌트의 워크로드를 논리적이고 구분되는 관리 단위로 분리해요. 흔한 관행은 같은 테넌트가 운영하는 여러 워크로드도 각각 자신의 네임스페이스에 격리하는 것이에요.
접근 통제 (Access controls)
컨트롤 플레인 격리에서 가장 중요한 유형은 인가(authorization)예요. 각 테넌트가 필요한 네임스페이스에만 적절한 접근을 갖도록 보장해야 해요. 이를 "최소 권한 원칙(Principle of Least Privilege)"이라고 불러요.
RBAC가 사용자와 워크로드(서비스 계정) 모두에 대해 인가를 강제하는 데 흔히 쓰여요. Roles와 RoleBindings는 네임스페이스 수준에서 접근 통제를 강제해요. 정책이 사용자에게 필요한 것보다 더 많은 권한을 부여하면, 해당 네임스페이스를 더 세분화된 네임스페이스로 리팩터링해야 한다는 신호일 수 있어요.
쿼터 (Quotas)
멀티 테넌트 환경에서는 Resource Quotas로 테넌트 워크로드의 리소스 사용을 관리할 수 있어요. 쿼터는 테넌트가 생성할 수 있는 API 리소스 수(예: Pod 수, ConfigMap 수)를 제한해 공정성을 보장하고 noisy neighbor 문제를 피하려고 해요. 테넌트를 네임스페이스에 매핑하면 클러스터 관리자가 테넌트가 클러스터 리소스를 독점하거나 컨트롤 플레인을 압도하지 못하게 할 수 있어요.
테넌트별 가상 컨트롤 플레인
다른 형태의 컨트롤 플레인 격리로 Kubernetes 확장을 사용해 각 테넌트에 가상 컨트롤 플레인을 제공하는 방법이 있어요. worker 노드는 모든 테넌트가 공유하며, 테넌트가 접근할 수 없는 Kubernetes 클러스터(보통 super-cluster 또는 host-cluster라 함)로 관리돼요. 테넌트의 컨트롤 플레인은 기본 컴퓨팅 리소스와 직접 연결되지 않으므로 가상 컨트롤 플레인이라 불러요.
가상 컨트롤 플레인은 보통 Kubernetes API server, controller manager, etcd 데이터 저장소로 구성돼요. 테넌트별 전용 컨트롤 플레인을 사용하면 모든 테넌트가 하나의 API 서버를 공유할 때의 격리 문제(noisy neighbor, 정책 오설정의 폭발 반경, webhook·CRD 같은 클러스터 범위 객체 충돌) 대부분이 해결돼요. 다만 테넌트별 컨트롤 플레인을 실행·유지하는 비용이 들고, 데이터 플레인의 격리 문제(노드 수준 noisy neighbor, 보안 위협)는 별도로 해결해야 해요.