[kubernetes] 쿠버네티스 논리적 공간 관리 (멀티테넌시) 네임스페이스

오늘 다뤄볼 주제는 쿠버네티스(Kubernetes, K8s)를 운영하면서 반드시 마주하게 되는, 그리고 효율적인 클러스터 관리를 위한 필수 개념인 **‘네임스페이스(Namespace)’**입니다.

쿠버네티스 클러스터는 수많은 오브젝트(Pod, Service, Deployment 등)가 얽혀 작동하는 복잡한 생태계입니다. 이 생태계를 무작위로 방치하면 관리 불가능한 상태가 됩니다. 이때 질서를 부여하고 논리적인 울타리를 쳐주는 역할이 바로 네임스페이스입니다.

본 포스팅에서는 네임스페이스의 개념부터, 왜 필요한지, 그리고 직접 실습을 통해 어떻게 활용하고 제어하는지 상세히 알아보겠습니다.

 

이전에 학습한 [kubernetes] 쿠버네티스 배포 전략 완벽 가이드: 롤링 업데이트부터 카나리 배포까지 알아보기

 

---

1. 쿠버네티스 네임스페이스란 무엇인가?

쿠버네티스 공식 문서의 정의를 빌리자면, 네임스페이스는 단일 클러스터 내의 리소스 그룹을 격리하는 메커니즘입니다.

더 쉽게 이해하기 위해 컴퓨터의 ‘폴더(디렉토리)’ 구조를 떠올려 봅시다. 하나의 하드디스크(클러스터) 안에 여러 개의 폴더(네임스페이스)를 만들고, 각 폴더 안에 서로 다른 프로젝트 파일(오브젝트)들을 정리하는 것과 같습니다.

핵심 특징

1. 논리적 격리: 물리적인 하드웨어 격리가 아닌, 쿠버네티스 컨트롤 플레인 수준에서의 논리적인 구분입니다.
2. 이름 충돌 방지: 서로 다른 네임스페이스 안에서는 동일한 이름의 오브젝트(예: frontend-pod)를 생성할 수 있습니다.
3. 범위(Scope) 제공: 대부분의 쿠버네티스 리소스(Pod, Service 등)는 특정 네임스페이스에 속합니다. (Node, PersistentVolume 같은 클러스터 레벨 리소스는 제외)

---

2. 네임스페이스의 시각적 이해: 아키텍처

글로만 설명하면 이해가 어려울 수 있으니, 네임스페이스가 클러스터 내에서 어떻게 구분되어 있는지에 대한 이미지 입니다.

 

하나의 커다란 물리적 쿠버네티스 클러스터 안에 Default, Dev, Prod라는 세 개의 네임스페이스가 논리적으로 구분되어 있다고 할 때,

• Default: 기본적으로 사용되는 공간입니다.
• Dev: 개발 팀이나 개발 환경 리소스를 모아둡니다. frontend-v1, backend-v1 파드가 실행 중입니다.
• Prod: 운영 환경 리소스가 위치합니다. 동일한 이름의 frontend-v2, backend-v2가 존재할 수 있으며, 이는 Dev 네임스페이스와 완전히 격리되어 있습니다.

쿠버네티스 API 서버는 이 네임스페이스 경계를 인식하여, 사용자가 특정 네임스페이스의 리소스만 조회하거나 제어하도록 권한을 관리(RBAC)하고, 리소스 쿼타(Resource Quotas)를 통해 각 네임스페이스가 사용할 수 있는 자원의 총량을 제한할 수 있습니다.

---

3. Hands-on: 네임스페이스 실습

이제 실제 쿠버네티스 환경(kubectl)에서 네임스페이스를 어떻게 생성하고, 사용하고, 관리하는지 단계별로 실습해 보겠습니다.

기본 준비

• 작동하는 쿠버네티스 클러스터 (Minikube, Kind, GKE, EKS 등)
• kubectl CLI 도구 설치 및 설정 완료

3.1. 기본 네임스페이스 조회

먼저 클러스터 생성 시 기본적으로 존재하는 네임스페이스들을 확인합니다.

Bash

# 네임스페이스 목록 조회
kubectl get namespaces

 

[테스트 결과]

Plaintext

NAME              STATUS   AGE
default           Active   1d
kube-node-lease   Active   1d
kube-public       Active   1d
kube-system       Active   1d

• default: 사용자 리소스의 기본 공간.
• kube-system: 쿠버네티스 자체 시스템 리소스(DNS, 네트워킹 등)가 실행되는 중요한 공간.
• kube-public: 모든 사용자(인증되지 않은 사용자 포함)가 읽을 수 있는 리소스를 위한 공간.

3.2. 새로운 네임스페이스 생성

새로운 프로젝트나 환경을 위한 네임스페이스를 생성해 봅니다. 두 가지 방법이 있습니다.

방법 1: 명령형 명령(CLI) 사용

Bash

# 'it-blog-demo'라는 이름의 네임스페이스 생성
kubectl create namespace it-blog-demo

 

방법 2: 선언형 YAML 파일 사용 (권장)

my-namespace.yaml 파일을 작성합니다.

YAML

apiVersion: v1
kind: Namespace
metadata:
  name: it-blog-hands-on

Bash

# YAML 파일을 통해 생성
kubectl apply -f my-namespace.yaml

[테스트 결과] kubectl get namespaces를 다시 실행하면 새로운 네임스페이스들이 활성화된 것을 확인할 수 있습니다.

3.3. 특정 네임스페이스에 리소스 생성

이제 우리가 만든 it-blog-demo 네임스페이스 안에 Nginx 파드를 하나 생성해 보겠습니다.

Bash

# --namespace (또는 -n) 옵션을 사용하여 네임스페이스 지정
kubectl run demo-nginx --image=nginx -n it-blog-demo

3.4. 네임스페이스 범위의 리소스 조회

파드를 생성했으니 조회해 봅시다. 그냥 조회하면 나오지 않습니다.

Bash

# 기본(default) 네임스페이스에서 조회 (결과 없음 또는 다른 파드)
kubectl get pods

# 우리가 생성한 it-blog-demo 네임스페이스에서 조회
kubectl get pods -n it-blog-demo

 

[테스트 결과]

Plaintext

NAME         READY   STATUS    RESTARTS   AGE
demo-nginx   1/1     Running   0          30s

정확히 우리가 지정한 울타리 안에서 파드가 잘 작동하고 있습니다.

3.5. 네임스페이스 삭제와 주의사항

프로젝트가 끝나서 네임스페이스를 삭제하면 어떻게 될까요?

Bash

# 네임스페이스 삭제
kubectl delete namespace it-blog-demo

[테스트 결과] 삭제 명령을 내리면 demo-nginx 파드를 포함하여 it-blog-demo 네임스페이스 안에 존재하던 모든 리소스가 함께 삭제됩니다. 이 과정은 비동기적으로 일어나며, 완료될 때까지 네임스페이스의 상태가 Terminating으로 표시될 수 있습니다.

주의: 운영 환경에서 네임스페이스 삭제는 매우 신중해야 합니다. 실수로 kube-system을 삭제하거나 운영 중인 서비스의 네임스페이스를 삭제하면 치명적인 장애로 이어집니다.

---

4. 실무 인사이트: 네임스페이스 활용 모범 사례 (Best Practices)

네임스페이스는 단순히 리소스를 나누는 것을 넘어, 클러스터의 보안, 안정성, 비용 관리와 직결됩니다. 실무에서 적용할 수 있는 몇 가지 인사이트를 공유합니다.

4.1. 환경 및 팀 단위 격리

가장 흔하고 효과적인 방법입니다.

• dev, staging, prod처럼 배포 환경별로 네임스페이스를 분리하여 운영 실수(예: 개발 환경 삭제하려다 운영 환경 삭제)를 방지합니다.
• 대규모 조직에서는 team-a, team-b처럼 팀별로 공간을 할당하여 책임 소재를 명확히 합니다.

4.2. 리소스 쿼타(ResourceQuotas) 활용

특정 네임스페이스가 클러스터의 모든 자원(CPU, Memory)을 독점하는 것을 방지해야 합니다. ResourceQuota 오브젝트를 사용하면 각 네임스페이스별로 사용할 수 있는 자원의 상한선을 정의할 수 있습니다. 이는 안정적인 클러스터 운영의 필수 요소입니다.

4.3. RBAC (역할 기반 접근 제어)와 결합

네임스페이스는 RBAC의 기본 단위입니다. "A팀은 dev 네임스페이스에만 파드를 생성할 수 있고, prod 네임스페이스는 읽기만 가능하다"와 같은 세밀한 권한 관리를 네임스페이스 기반으로 설정합니다.

4.4. 네트워크 정책(NetworkPolicies)

기본적으로 쿠버네티스의 모든 파드는 네임스페이스와 상관없이 서로 통신할 수 있습니다. 하지만 보안이 중요하다면 NetworkPolicy를 사용하여 네임스페이스 간의 트래픽을 격리하거나 허용하는 룰을 적용해야 합니다. (예: prod 네임스페이스는 dev의 접근을 차단).

---

마무리

오늘은 쿠버네티스의 핵심 개념인 네임스페이스에 대해 이론, 구조, 그리고 실습까지 깊이 있게 다뤄봤습니다.

네임스페이스는 단순한 폴더가 아닙니다. 멀티테넌시(Multi-tenancy) 환경을 구현하고, 클러스터의 안정성과 보안을 확보하며, 효율적인 리소스 관리를 가능하게 하는 가장 기초적이고 강력한 도구입니다.

오늘 습득한 내용을 바탕으로 여러분의 클러스터에 질서를 부여하고 모범 사례를 적용해 보시길 바랍니다. 더욱 안정적이고 효율적인 쿠버네티스 운영에 큰 도움이 될 것입니다.