쿠버네티스(Kubernetes)에서 네임스페이스(Namespace)는 클러스터 안의 리소스들을 논리적으로 분리하여 관리할 수 있도록 해주는 가상 구역입니다. 네임스페이스를 활용하면 여러 팀 혹은 프로젝트가 하나의 클러스터를 공유하면서도, 서로의 리소스가 충돌하지 않도록 구분하고 접근 권한을 세분화할 수 있습니다.

1. 네임스페이스의 필요성

  1. 리소스 충돌 방지
    • 여러 사용자나 팀이 동일한 이름의 디플로이먼트, 서비스 등을 생성할 수 있는데, 네임스페이스가 없으면 이름 충돌이 발생할 수 있습니다.
    • 네임스페이스를 사용하면 myproject/deployment1, yourproject/deployment1처럼 서로 다른 네임스페이스에서 동일한 리소스 이름을 가질 수 있습니다.
  2. 접근 권한 및 자원 할당 분리
    • 각 네임스페이스별로 RBAC(Role-Based Access Control)를 적용하거나 리소스 쿼터(Resource Quota)를 설정할 수 있습니다.
    • 예: 개발 팀 A는 teamA 네임스페이스에서만 작업 가능, 리소스 사용량(CPU/메모리)을 일정 수준으로 제한 등
  3. 프로젝트/환경 분리
    • 프로덕션, 스테이징, 테스트 환경을 한 클러스터에서 운용할 때, 네임스페이스를 달리하여 쉽게 구분할 수 있습니다.
    • 여러 프로젝트가 공유 클러스터를 쓰는 경우에도 프로젝트별 네임스페이스로 구분해 운영 가능합니다.

2. 네임스페이스 기본 사용법

  1. 기본 네임스페이스

    • default: 아무 설정 없이 생성된 리소스가 들어가는 기본 네임스페이스
    • kube-system: 쿠버네티스 내부 컴포넌트가 동작하는 리소스들이 위치
    • kube-public: 클러스터 내에서 공개되어야 하는 정보가 위치(일반적으로 잘 사용하진 않음)
    • kube-node-lease: 노드 heartbeat 정보를 저장하는 데 사용(1.14 이후 추가됨)
  2. 네임스페이스 생성 
     kubectl create namespace my-namespace

    혹은 매니페스트를 통한 생성

     apiVersion: v1
 kind: Namespace
 metadata:
   name: my-namespace

  3. 네임스페이스 확인

     kubectl get namespaces

  4. 특정 네임스페이스로 리소스 생성

    • 커맨드 라인에서:

        kubectl apply -f my-deployment.yaml --namespace=my-namespace

    • 매니페스트에서 직접 지정:

        apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: my-deployment
    namespace: my-namespace

  5. 현재 네임스페이스 변경

    • kubectl config set-context --current --namespace=my-namespace
    • 이후에는 별도로 -n 옵션을 쓰지 않아도 my-namespace가 기본으로 적용됩니다.

3. 네임스페이스와 리소스 접근 권한(RBAC)

  • 쿠버네티스 RBAC는 롤(Role)과 롤바인딩(RoleBinding)을 통해 “누가 어떤 네임스페이스에서 어떤 리소스를 할 수 있는가”를 정의합니다.

  • 예:

      kind: Role
  apiVersion: rbac.authorization.k8s.io/v1
  metadata:
    namespace: my-namespace
    name: developer-role
  rules:
    - apiGroups: [""]        # core API 그룹(파드, 서비스 등)
      resources: ["pods"]
      verbs: ["get", "watch", "list", "create", "delete"]
    • developer-role은 my-namespace 안에서 파드 관련 작업을 할 수 있습니다.

4. 네임스페이스와 리소스 쿼터(Resource Quota)

  • ResourceQuota를 이용하면 네임스페이스별로 CPU, 메모리, 스토리지, 오브젝트(파드, 서비스, 레플리카셋 등) 개수 등의 사용량을 제한할 수 있습니다.

  • 예:

      apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: my-namespace-quota
    namespace: my-namespace
  spec:
    hard:
      pods: "10"
      requests.cpu: "4"
      requests.memory: "8Gi"
      limits.cpu: "8"
      limits.memory: "16Gi"
    • 해당 네임스페이스에서는 최대 10개의 파드를 생성할 수 있고, CPU/메모리 사용량도 설정 범위 내로 제한됩니다.

5. 주의 사항

  1. 네임스페이스로 분리되지 않는 리소스

    • 노드(Node), PersistentVolume, ClusterRole, 클러스터 전체로 작동하는 설정 등은 클러스터 스코프를 가지므로 네임스페이스에 귀속되지 않습니다.
    • 이들은 kubectl get 시에도 네임스페이스 없이 확인해야 하며, RBAC도 ClusterRole/ClusterRoleBinding을 사용합니다.

  2. 네임스페이스 삭제 시 리소스도 삭제

    • 네임스페이스를 삭제하면 그 안에 있는 모든 리소스(파드, 서비스, 디플로이먼트 등)도 함께 삭제됩니다.
    • Production 환경에서 네임스페이스를 함부로 삭제하지 않도록 주의해야 합니다.

  3. 네임스페이스의 개수

    • 너무 많은 네임스페이스를 생성하면 관리 복잡도가 상승할 수 있으므로, 보통은 팀·프로젝트·환경 단위로 적절히 분리합니다.

6. 요약

  • 네임스페이스(Namespace)는 쿠버네티스 클러스터 내 리소스를 논리적으로 분할하여 이름 충돌 방지, 접근 제어, 자원 할당 제한 등을 쉽게 해줍니다.
  • 기본으로 default, kube-system, kube-public 등의 네임스페이스가 있으며, 필요에 따라 사용자가 새 네임스페이스를 생성해 쓸 수 있습니다.
  • RBAC와 ResourceQuota를 활용해 네임스페이스별 보안/자원 정책을 따로 적용할 수 있어, 팀 단위 혹은 프로젝트 단위 운영에 큰 이점을 제공합니다.
  • 네임스페이스를 적절히 구분함으로써, 여러 사용자와 애플리케이션이 하나의 클러스터를 안전하고 효율적으로 공유할 수 있습니다.

7. 크로스 네임스페이스 네트워크 통신

기본적으로 쿠버네티스에서는 네임스페이스 경계를 넘어 서비스 간 통신이 가능합니다. 다른 네임스페이스의 서비스에 접근할 때는 <service>.<namespace>.svc.cluster.local 형식의 FQDN을 사용합니다.

# 같은 네임스페이스 내 서비스 접근
http://my-service:8080

# 다른 네임스페이스의 서비스 접근 (FQDN 방식)
http://my-service.production.svc.cluster.local:8080

# 간략 표기
http://my-service.production:8080

NetworkPolicy로 크로스 네임스페이스 통신 제어

# production 네임스페이스의 DB에 monitoring 네임스페이스에서만 접근 허용
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-monitoring-namespace
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: monitoring   # 네임스페이스 레이블로 선택
    ports:
    - protocol: TCP
      port: 5432

8. 레이블(Label)과 셀렉터(Selector)

레이블은 쿠버네티스 리소스에 붙이는 키-값 메타데이터입니다. 셀렉터는 레이블을 기반으로 리소스를 선택·필터링하는 조건식입니다.

레이블 규칙

metadata:
  labels:
    app: web-frontend          # 애플리케이션 이름
    version: "v2.1.0"          # 버전
    environment: production    # 환경
    team: platform             # 담당 팀
    tier: frontend             # 계층 (frontend, backend, database)

셀렉터 활용 예시

# Service에서 레이블로 파드 선택
apiVersion: v1
kind: Service
metadata:
  name: web-service
  namespace: production
spec:
  selector:
    app: web-frontend          # 이 레이블을 가진 파드로 트래픽 전달
    environment: production
  ports:
  - port: 80
    targetPort: 8080

# kubectl에서 레이블 셀렉터 사용
kubectl get pods -l app=web-frontend,environment=production

# 레이블 추가/수정
kubectl label pod my-pod version=v2.2.0 --overwrite

# 레이블로 리소스 일괄 삭제
kubectl delete pods -l environment=test

# 네임스페이스에 레이블 추가 (NetworkPolicy 참조용)
kubectl label namespace monitoring kubernetes.io/metadata.name=monitoring

권장 레이블 표준 (app.kubernetes.io)

레이블 예시 값 설명
app.kubernetes.io/name web-server 앱 이름
app.kubernetes.io/version 1.0.0 앱 버전
app.kubernetes.io/component frontend 컴포넌트 역할
app.kubernetes.io/part-of my-platform 상위 시스템
app.kubernetes.io/managed-by helm 관리 도구

참고 자료

댓글남기기

참고