쿠버네티스를 막 시작하면 모든 리소스를 default 네임스페이스에 그냥 던지게 됩니다. 그러다 서비스가 늘면 "이걸 어떻게 나눠야 하지?"라는 질문에 부딪힙니다. 네임스페이스(namespace)는 한 클러스터 안을 논리적으로 쪼개는 칸막이입니다. 칸막이를 잘못 그으면 권한·자원·이름이 뒤엉키고, 잘 그으면 운영이 단순해집니다. 핵심은 "무엇을 기준으로 나눌까"입니다.
네임스페이스가 실제로 격리하는 것
먼저 오해를 풀어야 합니다. 네임스페이스는 이름 충돌을 막고, 권한(RBAC)과 자원 할당(ResourceQuota)의 단위를 제공하지만, 네트워크는 기본적으로 격리하지 않습니다. 같은 클러스터라면 네임스페이스가 달라도 Pod끼리 통신이 됩니다. 네트워크를 막으려면 NetworkPolicy를 따로 걸어야 합니다.
| 네임스페이스가 나누는 것 | 나누지 않는 것 |
|---|---|
| 리소스 이름 (같은 이름 Service 공존) | 네트워크 통신 (NetworkPolicy 필요) |
| RBAC 권한 범위 | 노드(물리 자원 자체) |
| ResourceQuota / LimitRange | 클러스터 단위 리소스(노드, PV) |
분리 기준 1 — 환경별 (가장 흔함)
dev, staging, prod처럼 환경으로 나누는 방식입니다. 같은 앱이 환경마다 다른 설정·자원으로 떠야 할 때 깔끔합니다.
kubectl create namespace dev
kubectl create namespace staging
kubectl create namespace prod
kubectl get pods -n prod
prod에만 엄격한 ResourceQuota와 제한적 RBAC를 거는 식으로 환경별 정책 차등이 쉬워집니다.
분리 기준 2 — 팀·도메인별
조직이 커지면 team-payments, team-search처럼 팀 단위로 나눕니다. 각 팀에 자기 네임스페이스의 권한만 주면 서로의 리소스를 건드리지 못합니다.
apiVersion: v1
kind: ResourceQuota
metadata:
name: team-quota
namespace: team-payments
spec:
hard:
requests.cpu: "4"
requests.memory: 8Gi
pods: "20"
언제 무엇을 쓰나
소규모(서비스 < 10개, 단일 팀)면 환경별 분리만으로 충분합니다. 팀이 여럿이고 권한을 분리해야 하면 "환경 × 팀" 조합도 흔합니다(예: payments-prod). 다만 클러스터 자체를 환경별로 분리(dev 클러스터 / prod 클러스터)하는 편이 안전한 경우도 있습니다 — prod 사고가 dev로 번지지 않으니까요. 네임스페이스는 "한 클러스터 안" 분리, 클러스터 분리는 "물리적" 분리라는 점을 구분하세요.
요점 정리
- 네임스페이스는 이름·권한·자원의 칸막이지, 네트워크 방화벽이 아니다.
- 입문 단계는 환경별(
dev/staging/prod) 분리로 시작하면 된다. - 팀이 늘면 팀별 네임스페이스 + RBAC + ResourceQuota로 권한·자원을 격리한다.
- prod의 진짜 격리가 필요하면 네임스페이스가 아니라 클러스터 분리를 검토한다.
네임스페이스를 직접 만들고 RBAC·ResourceQuota를 걸어 보며 격리를 체감하는 실습은 쿠버네티스 트랙에서 할 수 있습니다 — 회원가입 없이 무료로.