104. 네임스페이스 (K8s Namespace) - 논리적 클러스터 가상 분할망

⚠️ 이 문서는 서버 100대가 묶인 거대한 1개의 쿠버네티스 클러스터 안에 개발팀, 테스트팀, 운영팀이 모두 함께 파드를 띄워대다가 서로의 파드 이름을 덮어쓰거나 남의 부서 서버를 지워버리는 끔찍한 내전을 막기 위해, **물리적인 서버 기계는 100대 그대로 놔둔 채 허공에 투명한 '유리 벽(논리적 격리)'을 세워 마치 3개의 독립된 클러스터가 있는 것처럼 쪼개고, 각 방마다 CPU/RAM 한도(Quota)를 줘서 가둬버리는 '네임스페이스(Namespace)'**를 다룹니다.

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

  1. 본질: 쿠버네티스라는 거대한 운동장 하나를 십자 선을 그어 '개발용 방', '운영용 방'으로 쪼개어주는 '논리적인 폴더(디렉토리)' 개념이다.
  2. 가치: 부서마다 비싼 K8s 클러스터를 따로따로 10개씩 사줄 필요가 없다(비용 절약). 하나의 클러스터 안에서 dev 네임스페이스와 prod 네임스페이스를 파두면, 개발팀이 실수로 kubectl delete all을 쳐도 운영망(prod) 파드는 머리털 하나 다치지 않는 완벽한 울타리가 쳐진다.
  3. 기술 체계: 이름 충돌(Naming Collision)을 막아주고, 각 방마다 쓸 수 있는 램과 CPU의 밥그릇 크기를 제한하는 **ResourceQuota(자원 할당량)**를 걸 수 있으며, 며칠 전 배운 **RBAC(권한 통제)**와 결합하여 "A팀은 A방만 볼 수 있다"는 완벽한 멀티 테넌시(Multi-tenancy)를 구축하는 핵심 뼈대다.

Ⅰ. 원룸의 재앙: 네임스페이스가 없는 야생의 클러스터

한 지붕 아래 10명의 개발자가 칼을 들고 뛰어다닌다.

  1. 이름 충돌 (Naming Collision)의 저주:
    • 네임스페이스를 안 만들면 모든 파드와 서비스는 K8s의 기본 거실인 default 네임스페이스에 다 때려 박힌다.
    • 영업팀 개발자 A가 frontend-pod라는 이름으로 파드를 띄웠다.
    • 다음 날 재무팀 개발자 B가 아무 생각 없이 똑같은 이름인 frontend-pod를 띄웠다.
    • K8s는 "어? 이미 있는 이름이네? 네가 덮어쓸래(또는 에러 뿜음)?" 라며 충돌을 낸다. 팀이 10개면 이 이름 싸움 때문에 하루 종일 주먹다짐이 일어난다.
  2. 자원 독식의 횡포 (No Limits):
    • 100GB 램을 가진 클러스터 거실에 데이터팀이 빅데이터 분석 파드를 하나 띄웠다. 이 멍청한 파드가 혼자서 램 99GB를 미친 듯이 다 빨아먹어 버렸다.
    • 정작 가장 중요한 대국민 웹 서버(영업팀 파드)가 램 1GB를 할당받지 못해 Out Of Memory(OOM) 에러를 내며 뻗어버리고 회사가 멈춘다. 거실에 칸막이(할당량)를 안 쳐놔서 생긴 재앙이다.

📢 섹션 요약 비유: 회사 건물 전체를 칸막이 하나 없는 1,000평짜리 '통 원룸(Default Namespace)'으로 쓰는 짓입니다. 영업팀 직원이 문서를 놔두면 재무팀 직원이 그 위에 자기 밥그릇을 올려놓아 덮어쓰기(이름 충돌)가 일어납니다. 게다가 에어컨 구멍이 1개인데 회장님(빅데이터 파드)이 혼자 바람을 다 쐬고 독점해 버려 일반 직원(웹 서버)은 쪄 죽습니다(자원 독식). 끔찍한 무법지대입니다.

Ⅱ. 유리 벽의 마법: 논리적 격리와 자원 할당 (ResourceQuota)

유리 벽을 세워 방을 쪼개고, 방마다 에어컨 파워를 제한해 둔다.

  1. 논리적 분할 (Virtual Clusters):
    • 클러스터에 kubectl create namespace dev, namespace prod 두 개의 투명한 유리 벽 방을 파낸다.
    • 이제 영업팀은 자기가 띄우는 모든 파드 뒤에 -n dev 라는 꼬리표를 달아 dev 방에만 던져 넣는다.
    • 영업팀이 dev 방에 frontend-pod를 띄우고, 재무팀이 prod 방에 똑같은 이름 frontend-pod를 띄워도 K8s는 완벽하게 허용한다. 방(폴더)이 다르기 때문에 이름 충돌(Conflict)이 0%로 사라진다.
  2. ResourceQuota (밥그릇 쪼개기):
    • 시스템 관리자의 강력한 철퇴다. 각 네임스페이스 문 앞에 '용량 제한 딱지(Quota)'를 붙여버린다.
    • dev 네임스페이스 딱지: "이 방 안에서 떠 있는 모든 파드의 램 총합은 절대 20GB를 넘을 수 없다!"
    • 데이터팀이 dev 방에서 99GB짜리 빅데이터 파드를 띄우려 하면? 쿠버네티스가 방어막을 친다. "이 방 할당량(20GB) 초과! 파드 생성 금지(Pending)!"
    • 이 쿼터(Quota) 덕분에 특정 개발팀의 파드가 미쳐 날뛰어도 다른 부서의 네임스페이스(운영망) 생태계는 100% 쾌적하게 보호받는 완벽한 자원 격리(Resource Isolation)가 달성된다.

📢 섹션 요약 비유: 1,000평짜리 원룸에 방음이 완벽한 유리 벽(네임스페이스)을 쳐서 10개의 독립된 부서 방을 쪼개준 것입니다. 1번 방(Dev) 안에서 꽹과리를 치고 책상 배열을 맘대로(이름 충돌 방지) 바꿔도 2번 방(Prod)에서는 전혀 보이지 않습니다. 게다가 관리자는 1번 방의 두꺼비집에 차단기(ResourceQuota)를 달아놔서, 1번 방 직원들이 에어컨을 10대 틀어 전기(RAM)를 20kW 이상 빨아먹으려 하면 딱 그 방만 두꺼비집이 퍽 내려가고, 남은 9개 방의 전기는 평화롭게 유지되는 소름 돋는 자원 통제 시스템입니다.

Ⅲ. 멀티 테넌시 (Multi-Tenancy)와 RBAC의 융합

방을 쪼갰으면, 방 키(Key)도 다르게 복사해서 줘야 한다.

  1. 물리적 분리의 극악한 낭비:
    • 대기업이나 은행은 과거에 "보안이 털리면 안 되니, 무조건 1개 팀당 1개의 진짜 쿠버네티스(물리 서버 10대짜리)를 통째로 1개씩 따로 사줘라!" 라고 돈지랄(물리적 분리)을 했다.
    • 10개 팀이면 서버가 100대나 필요하고 마스터 노드가 10벌이나 돌아가니 돈 낭비와 관리 지옥이 열렸다.
  2. 멀티 테넌시(Soft Multi-Tenancy)의 구현:
    • 똑똑한 클라우드 아키텍트는 서버 100대짜리 초거대 쿠버네티스 딱 **1개(Single Cluster)**만 둔다.
    • 그리고 부서 10개에 맞춰 네임스페이스 10개를 뚫는다.
    • **어제 배운 RBAC(권한 통제)**를 찰떡같이 융합한다. "A팀 김 대리(ServiceAccount)의 권한(Role)은 오직 namespace: A팀 안에서만 작동하도록 구속시켜라!"
  3. 가상 클러스터의 궁극적 완성:
    • 김 대리가 아침에 출근해 kubectl get pods를 치면, 100대 서버 중 오직 자기 A팀 방에 있는 파드 3개만 화면에 뜬다. 김 대리 입장에서는 자기가 마치 혼자서 작고 귀여운 A팀 전용 쿠버네티스를 통째로 독점해서 쓰고 있는 듯한 완벽한 '착각(가상화)'에 빠진다.
    • 하나의 거대한 쇳덩어리 아파트(클러스터)를 완벽하게 분할된 수십 개의 원룸(멀티 테넌트)으로 쪼개어 가입자에게 분양하는 퍼블릭 클라우드 서비스(CaaS)의 핵심 비법이 바로 이 네임스페이스와 RBAC의 환상적인 콤비플레이다.

📢 섹션 요약 비유: 큰 회사에서 10개 부서에게 강남에 있는 사옥 건물을 통째로 1채씩 10채를 따로 사주는 것(물리적 클러스터 분리)은 돈이 썩어나는 재벌이나 하는 짓입니다. 훌륭한 건물주(아키텍트)는 63빌딩 딱 1채(단일 K8s 클러스터)만 엄청 크게 지어놓고, 층마다 부서별 문(네임스페이스)을 달아줍니다. 그리고 직원들 사원증(RBAC)에 "영업팀은 3층 문만 열리고, 다른 층 버튼은 엘리베이터에서 눌리지도 않는다"라고 보안 세팅을 걸어둡니다. 직원들은 63빌딩을 쓰지만 철저히 남의 층을 건드릴 수 없는, 한 지붕 수십 가족의 완벽한 셰어하우스(멀티 테넌시) 공간 마법입니다.