104. K8s 네임스페이스 (Namespace) - 논리적 분할과 격리

핵심 인사이트 (3줄 요약)

본질: 쿠버네티스 네임스페이스 (Kubernetes Namespace)는 단일 물리 클러스터 내에서 자원과 오브젝트를 논리적으로 분할하여 가상의 경계를 생성하는 격리 메커니즘이다.

가치: 다수의 팀이나 애플리케이션이 동일한 클러스터를 공유할 때 발생하는 이름 충돌 (Naming Collision)을 방지하고, 하드웨어 중복 투자를 막아 비용 효율성을 극대화한다.

판단 포인트: 완전한 보안 격리가 필요한 멀티 테넌시 (Multi-Tenancy) 환경에서는 네임스페이스만으로는 부족하며, RBAC (Role-Based Access Control) 및 네트워크 정책 (Network Policy)과 결합해야 실질적인 테넌트 격리가 완성된다.

Ⅰ. 개요 및 필요성

네임스페이스 (Namespace)는 쿠버네티스라는 거대한 컨테이너 오케스트레이션 플랫폼 내부를 논리적으로 쪼개는 '가상 클러스터' 단위다. 기본적으로 K8s는 모든 자원을 default 네임스페이스에 할당하지만, 조직 규모가 커지고 다양한 서비스가 올라가면 단일 공간 관리에 한계가 발생한다.

이 개념이 없다면 서로 다른 부서가 동일한 이름의 파드 (Pod)나 서비스 (Service)를 배포할 때 충돌이 발생하거나 덮어쓰기되는 대참사가 일어난다. 또한, 특정 팀의 애플리케이션이 클러스터의 전체 CPU와 메모리를 독식하여 다른 핵심 서비스가 OOM (Out Of Memory)으로 죽어버리는 자원 탈취 문제가 발생한다. 따라서 논리적 공간을 분리하여 각자의 샌드박스를 제공하는 네임스페이스가 필수적이다.

📢 섹션 요약 비유: 네임스페이스는 1,000평짜리 텅 빈 원룸 층에 가상의 방음 유리벽을 세우는 것과 같다. 벽이 없으면 서로 소음과 물건 배치가 엉키지만, 유리벽을 세우면 한 지붕 아래에서도 각 부서가 독립적인 사무실을 가진 것처럼 평화로워진다.

Ⅱ. 아키텍처 및 핵심 원리

네임스페이스는 단순한 디렉터리 역할을 넘어, K8s 자원 관리의 강력한 바운더리로 작동한다. 네임스페이스별로 자원 한도 (Resource Quota)를 설정하여 특정 네임스페이스가 클러스터 전체 자원을 고갈시키지 않도록 방어한다.

┌──────────────────────────────────────────────────────────────┐
│           Kubernetes 단일 물리 클러스터 (Node 1~N)           │
├──────────────────────────────────────────────────────────────┤
│ ┌──────────────────────┐ ┌───────────────────────────────┐ │
│ │  Namespace: dev      │ │      Namespace: prod          │ │
│ │                      │ │                               │ │
│ │  [Pod: frontend]     │ │  [Pod: frontend]              │ │
│ │  (Quota: CPU 2, M 4G)│ │  (Quota: CPU 10, M 32G)       │ │
│ │                      │ │                               │ │
│ │ ⛔ 이름 충돌 없음!   │ │ ⛔ dev의 자원 독식 차단!      │ │
│ └──────────────────────┘ └───────────────────────────────┘ │
└──────────────────────────────────────────────────────────────┘

이 다이어그램은 물리적 서버 노드들이 하나의 거대한 자원 풀로 묶여 있지만, 그 위에 씌워진 네임스페이스가 논리적인 칸막이와 자원 한계선을 긋고 있음을 보여준다.

네임스페이스의 핵심 제어 기능은 두 가지다. 첫째, 자원 할당량 (ResourceQuota)을 통해 네임스페이스 내에서 생성될 수 있는 총 CPU, 메모리, 볼륨 크기를 제한한다. 둘째, 리밋 레인지 (LimitRange)를 통해 파드 하나당 요구할 수 있는 기본 자원 요청량과 최대 제한을 강제한다. 이 두 가지가 결합되어야 진정한 '통제된 가상 클러스터'가 된다.

📢 섹션 요약 비유: 네임스페이스는 사무실 공간을 나누는 것을 넘어, 각 방에 들어가는 전기와 수도의 '두꺼비집 한도'를 정해두는 것과 같다. 한 방에서 에어컨을 10대 틀어도 전체 건물 전기가 나가는 대신 그 방의 차단기만 내려간다.

Ⅲ. 비교 및 연결

쿠버네티스 격리 체계는 논리적 격리인 네임스페이스와 물리적 격리인 다중 클러스터 (Multi-Cluster) 접근법으로 나뉜다.

항목	네임스페이스 (Namespace) 격리	다중 클러스터 (Multi-Cluster) 격리
격리 수준	논리적 (소프트 멀티 테넌시)	물리적 (하드 멀티 테넌시)
비용 및 자원	리소스 효율성 높음 (단일 컨트롤 플레인)	자원 중복 및 인프라 비용 큼
관리 복잡도	RBAC/네트워크 통제 설정이 복잡함	클러스터가 많아져 운영 부담 증가
보안 경계	커널이나 호스트 탈취 시 전체 위험 노출	완벽히 분리되어 연쇄 피해 차단

소프트 멀티 테넌시 (Soft Multi-Tenancy) 환경인 사내 개발/운영 분리에는 네임스페이스가 적합하다. 반면, 완전히 신뢰할 수 없는 외부 고객들에게 KaaS (Kubernetes as a Service)를 제공하는 하드 멀티 테넌시 (Hard Multi-Tenancy) 환경에서는 클러스터 자체를 물리적으로 분리하거나 샌드박스 컨테이너 기술을 도입해야 한다.

📢 섹션 요약 비유: 네임스페이스가 아파트 한 채의 방을 나누어 쓰는 '셰어하우스'라면, 다중 클러스터는 아예 '옆 건물'을 따로 지어서 입주시키는 것과 같다. 프라이버시 수준과 월세(비용)의 트레이드오프다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서 단일 K8s 클러스터를 설계할 때, "어디까지 네임스페이스로 분리할 것인가?"가 핵심 의사결정 포인트다.

체크리스트

자원 통제: 네임스페이스 생성 시 ResourceQuota와 LimitRange가 필수로 매핑되었는가? (미설정 시 Noisy Neighbor 문제 발생)
권한 구속: RBAC의 RoleBinding을 통해 특정 팀의 접근 권한이 해당 네임스페이스 안으로만 제한되었는가? (ClusterRoleBinding 남발 금지)
네트워크 격리: 네트워크 정책 (Network Policy)을 적용하여 네임스페이스 간의 무분별한 트래픽(예: dev망에서 prod망 DB 접근)을 차단했는가?

안티패턴

모든 서비스와 리소스를 default 네임스페이스에 무분별하게 배포하여 얽히게 만드는 설계.
네임스페이스로 격리했다면서 Network Policy를 열어두어 서로 마음껏 API 호출이 가능하게 방치하는 보안 결함.
📢 섹션 요약 비유: 네임스페이스는 방을 쪼개는 것일 뿐, 자물쇠 역할을 하지 않는다. 방을 나눈 뒤 자물쇠(RBAC)를 달고, 문틈(Network Policy)을 막지 않으면 여전히 하나의 통원룸이나 다름없다.

Ⅴ. 기대효과 및 결론

네임스페이스를 철저하게 설계하고 적용하면, 비싼 쿠버네티스 인프라를 수십 개의 팀이 안전하게 공유할 수 있어 클라우드 운영 비용이 극적으로 절감된다. 또한, 논리적 경계를 기반으로 CI/CD (Continuous Integration/Continuous Deployment) 파이프라인의 배포 타겟을 명확히 할 수 있어 자동화의 안정성을 보장한다.

다만, 네임스페이스는 완벽한 보안 격리벽이 아니라는 한계가 있다. 따라서 쿠버네티스의 네임스페이스는 "가장 효율적인 논리적 분할의 시작점"으로 활용하되, 진정한 테넌시 격리를 위해서는 RBAC, 쿼터, 네트워크 제어를 층층이 결합하는 아키텍처적 완성도가 반드시 수반되어야 한다.

📢 섹션 요약 비유: 훌륭한 건축가는 단순히 벽만 세우지 않는다. 각 방의 전력 한도를 정하고(Quota), 출입증을 제한하며(RBAC), 환기구(Network Policy)까지 통제해야 진정한 멀티 테넌트 빌딩이 완성된다.

📌 관련 개념 맵

개념	연결 포인트
RBAC (Role-Based Access Control)	특정 네임스페이스 내에서만 권한을 유효하게 만드는 통제 시스템
ResourceQuota	네임스페이스 단위의 컴퓨팅 자원 및 오브젝트 개수 상한선
Network Policy	네임스페이스 간(Inter-Namespace) 트래픽 흐름을 허용/차단하는 방화벽
CaaS (Container as a Service)	퍼블릭 클라우드가 고객에게 네임스페이스 기반으로 가상 클러스터를 분양하는 모델

📈 관련 키워드 및 발전 흐름도

Default Namespace 혼재 (자원 독식, 충돌)
    │
    ▼
논리적 분할 도입: K8s Namespace
    │
    ▼
자원 및 권한 통제: ResourceQuota, RBAC 적용
    │
    ▼
네트워크 보안 격리: Network Policy
    │
    ▼
클러스터 플릿 관리: Multi-Cluster, vCluster (가상 클러스터)

이 흐름도는 단순한 논리적 폴더 구분에서 시작해, 자원, 권한, 네트워크 제어를 거쳐 완전한 가상 클러스터 기술로 진화하는 쿠버네티스의 테넌트 격리 과정을 보여준다.

👶 어린이를 위한 3줄 비유 설명

넓은 운동장에 네임스페이스라는 투명한 '유리벽'을 세워서 1반과 2반의 체육 시간을 나눠주는 거예요.
유리벽이 있으니까 1반 친구가 던진 공이 2반 친구 머리에 맞는 일(이름 충돌)이 없어져요.
선생님이 각 반마다 쓸 수 있는 줄넘기 개수(ResourceQuota)도 딱 정해주니까 누구 하나가 다 독차지할 수 없답니다!