13. Core Concepts - Namespace

이 글은 아래 자료를 참고하여 작성되었습니다.

Udemy [Certified Kubernetes Administrator (CKA) with Practice Tests]

 

1. 네임스페이스란?

쿠버네티스에서 네임스페이스는 클러스터 내 리소스를 논리적으로 분리하는 데 사용된다. 이를 통해 여러 프로젝트, 팀 또는 환경을 하나의 클러스터에서 독립적으로 관리할 수 있다. 네임스페이스는 리소스 간 충돌을 방지하고 자원의 효과적인 격리를 제공한다.

• 네임스페이스는 '집'에 비유할 수 있다. 각 집은 고유한 규칙과 자원을 가지고 있으며, 집 내부에서는 서로 이름만으로 소통하지만, 다른 집의 구성원을 부를 때는 성까지 포함한 전체 이름을 사용해야 한다.
• 기본적으로 네임스페이스는 리소스를 그룹화하고, 서로 다른 환경에서 독립적으로 관리할 수 있게 해 준다.

 

2. 기본 네임스페이스

쿠버네티스 클러스터가 생성될 때, 몇 가지 네임스페이스가 자동으로 생성된다. 이 네임스페이스들은 쿠버네티스의 기본적인 동작을 보장하며, 사용자가 실수로 시스템 리소스에 접근하는 것을 방지한다.

• default: 사용자가 별도로 네임스페이스를 지정하지 않으면 모든 리소스가 기본적으로 여기에 생성된다.
• kube-system: 쿠버네티스가 내부적으로 사용하는 리소스가 여기에 속한다. 네트워킹, DNS 등 클러스터 운영에 필수적인 서비스가 위치한다.
• kube-public: 공용 리소스가 저장되는 네임스페이스로, 모든 사용자가 접근할 수 있는 리소스가 여기에 생성된다.

 

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

작은 클러스터에서는 기본 네임스페이스에서만 작업해도 문제가 없지만, 규모가 커져서 여러 팀, 프로젝트가 클러스터를 공유할 때는 네임스페이스를 사용하는 것이 필수적이다.

3-1. 네임스페이스의 주요 기능

• 리소스 구분 및 이름 충돌 방지: 같은 클러스터에서 동일한 이름의 리소스를 여러 개 생성하고 싶다면, 각각의 리소스를 별도의 Namespace에 배치하면 된다. 그렇게 하면 이름 충돌을 피하면서 리소스를 관리할 수 있다.
• 접근 제어: Kubernetes의 Role-Based Access Control (RBAC) 시스템을 사용하여 Namespace 단위로 사용자의 접근 권한을 관리할 수 있다. 이를 통해 각 팀이나 프로젝트는 자신들의 Namespace에서만 리소스를 생성하거나 관리할 수 있고, 다른 팀의 리소스에는 접근할 수 없게 권한을 제한할 수 있다.
• 리소스 할당과 제한: Namespace는 클러스터 자원의 사용량을 제한하는 리소스 쿼터(Resource Quota) 기능을 지원한다. CPU, 메모리, 스토리지 등의 리소스를 특정 Namespace에 할당하고, 그 안에서 사용할 수 있는 리소스를 제한할 수 있다. 이를 통해 각 팀이나 애플리케이션이 과도한 리소스를 사용하는 것을 방지하고, 클러스터 자원을 보다 효율적으로 분배할 수 있다.

3-2. 네임스페이스 사용예시

• 다중 팀 환경: 대기업에서 하나의 Kubernetes 클러스터를 여러 팀이 사용한다고 할 때, 개발 팀, 운영 팀, QA 팀 등 다양한 팀에서 각각 자신들의 애플리케이션과 리소스를 관리하게 되고, 이때 동일한 리소스 이름을 사용할 가능성이 있다. 각 팀에 dev-team, ops-team, qa-team이라는 별도의 Namespace를 할당하여 팀별로 독립된 리소스 공간을 제공하면 리소스 간 충돌이 방지되고, 각 팀의 리소스가 구분되어 관리된다.
• 환경 구분: 네임스페이스를 사용하면 개발, 테스트, 운영 등 각 환경을 별도의 영역으로 나눌 수 있다. dev, test, staging, prod 등의 Namespace를 각각 만들어, 애플리케이션이 배포되는 환경에 따라 리소스를 분리하여 관리할 수 있다. 이는 환경별로 독립적인 리소스 할당과 관리, 운영을 가능하게 하고, 프로덕션 환경의 리소스가 개발이나 테스트 환경에 영향을 받지 않도록 한다.

 

4. 네임스페이스 간 리소스 접근

네임스페이스 내에서는 리소스들이 서로를 간단한 이름으로 참조할 수 있다. 하지만 다른 네임스페이스에 있는 리소스를 참조할 때는 전체 이름을 사용해야 한다.

• 네임스페이스 내의 리소스는 [서비스이름]만으로 접근이 가능하다.
• 다른 네임스페이스의 리소스에 접근할 때는 [서비스이름].[네임스페이스].svc.cluster.local 형식을 사용한다.
• 쿠버네티스는 클러스터 내부에서 서비스 간 통신을 쉽게 할 수 있도록 사용자가 서비스를 생성하면 자동으로 [서비스이름].[네임스페이스].svc.cluster.local 형식의 DNS 레코드(DNS entry)를 생성해 준다. 개발자는 이 DNS 레코드를 직접 만들거나 설정할 필요가 없다.

 

5. 네임스페이스의 한계

• Namespace는 네트워크 격리 기능을 제공하지 않는다: 같은 클러스터 내의 여러 Namespace에 있는 pod들은 기본적으로 서로 통신할 수 있다. 네트워크 격리가 필요할 경우, Network Policy를 추가적으로 설정하여 네트워크 트래픽을 제어해야 한다. 
• Namespace는 클러스터 간 자원 격리 기능을 제공하지 않는다: Namespace는 하나의 클러스터 내에서만 논리적인 구분을 제공하는 기능으로, 여러 클러스터 간에는 Namespace가 적용되지 않는다. 즉, 클러스터 간에 같은 이름을 가진 Namespace가 있다고 하더라도 그 Namespace들이 서로 영향을 주지 않으며 각 클러스터는 독립적으로 관리된다.

 

6. 네임스페이스 생성 및 관리

네임스페이스는 kubectl 명령어를 통해 생성, 조회, 관리할 수 있다. 또한 필요에 따라 다른 네임스페이스로 전환해 작업할 수도 있다.

6-1. 네임스페이스 생성

# namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: my-namespace

# 방법1: 정의된 yaml 파일을 이용해 생성
kubectl apply -f namespace.yaml

# 방법2: yaml 파일 없이 간단하게 생성
kubectl create namespace [네임스페이스 이름]

6-2. 네임스페이스 관리

# 현재 클러스터의 모든 네임스페이스 목록 조회
kubectl get namespaces
kubectl get ns

# 특정 네임스페이스의 정보 조회
kubectl get namespace [네임스페이스 이름]

# 네임스페이스 삭제
kubectl delete namespace [네임스페이스 이름]

# 네임스페이스 전환
kubectl config set-context --current --namespace=[네임스페이스 이름]
kubectl config set-context $(kubectl config current-context)  --namespace=[네임스페이스 이름]

# 현재 설정된 네임스페이스 확인
kubectl config view --minify | grep namespace:

# 현재 네임스페이스의 리소스 확인
kubectl get pods

# 특정 네임스페이스의 리소스 확인 (네임스페이스 전환 없이)
kubectl get pods --namespace=[네임스페이스명]
kubectl get pods -n [네임스페이스명]

# 전체 네임스페이스의 리소스 확인
kubectl get pods --all-namespaces
kubectl get pods -A

6-3. 네임스페이스에 리소스 생성

# pod-my-namespace.yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  namespace: my-namespace
spec:
  containers:
    - name: nginx-container
      image: nginx

# 방법1: metadata 섹션에 namespace 추가한 뒤 yaml파일을 이용해 리소스 생성
kubectl apply -f pod-my-namespace.yaml

# 방법2: 명령어로 네임스페이스 지정
kubectl apply -f [리소스.yaml] --namespace=[네임스페이스 이름]

6-4. 네임스페이스에 리소스 제한

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: dev
spec:
  hard:
    pods: "10"
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"

• metadata: 
  • name (required): ResourceQuota의 이름을 정의. 클러스터 내에서 고유해야 한다.
  • namespace: 기본적으로 default namespace로 설정된다. 어떤 namespace의 자원을 할당할지 정의한다.
• spec
  • hard (required): Namespace 전체에서 사용 가능한 자원의 총량을 제한
  • hard.pods: 해당 Namespace에서 생성할 수 있는 파드의 최대 개수를 제한
  • hard.requests.cpu: Namespace 내의 모든 파드가 요청할 수 있는 CPU의 총합을 제한. 모든 파드의 requests.cpu 값의 합계가 해당 값보다 크지 않아야 한다.
  • hard.requests.memory: Namespace 내 모든 파드가 요청할 수 있는 메모리의 총합을 제한. 모든 파드의 requests.memory 값의 합계가 이 값을 넘지 않아야 한다.
  • hard.limits.cpu: Namespace 내 모든 파드가 사용할 수 있는 CPU의 총합을 제한. 파드들이 실제로 사용할 수 있는 CPU의 최대치를 설정하며, 모든 파드의 limits.cpu 값의 합이 이 값보다 커질 수 없다.
  • hard.limits.memory: Namespace 내 모든 파드가 사용할 수 있는 메모리의 총합을 제한. 모든 파드의 limits.memory 값의 합계가 이 값을 넘지 않아야 한다.

Request와 Limit의 개념

• requests
  • 역할: 파드가 최소한으로 보장받아야 하는 자원의 양을 정의. Kubernetes 스케줄러가 파드를 실행할 노드를 선택할 때, 이 requests 값을 기준으로 해당 노드에 충분한 자원이 있는지를 판단한다.
  • 보장된 자원: 파드는 자신이 요청한 자원만큼은 반드시 할당받는다. 예를 들어, requests.cpu: 1으로 설정한 파드는 최소 1코어의 CPU를 보장받는다.
• limits 
  • 역할: 파드가 사용할 수 있는 최대 자원의 양을 정의. 파드가 과도하게 자원을 사용하는 것을 방지하는 역할을 한다.
  • 최대치 제한: 파드는 limits로 정의된 자원 이상을 사용할 수 없다. 예를 들어, limits.cpu: 2로 설정한 경우, 이 파드는 최대 2코어의 CPU만 사용할 수 있다.