쿠버네티스 (Kubernetes) 주요 용어 네임스페이스(Namespace)

쿠버네티스(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를 활용해 네임스페이스별 보안/자원 정책을 따로 적용할 수 있어, 팀 단위 혹은 프로젝트 단위 운영에 큰 이점을 제공합니다.
• 네임스페이스를 적절히 구분함으로써, 여러 사용자와 애플리케이션이 하나의 클러스터를 안전하고 효율적으로 공유할 수 있습니다.