네임스페이스와 할당량

소개

Kubernetes 클러스터는 대형 아파트 건물과 같습니다.

모두가 로비에서 생활한다면 매우 혼란스러울 것입니다. 어떤 가구가 누구의 것인지 알 수 없고, 시끄러운 이웃 한 명 때문에 모든 사람이 방해를 받을 수 있습니다.

**네임스페이스 (Namespaces)**는 클러스터를 논리적으로 나누므로 서로 다른 팀, 환경 또는 애플리케이션이 리소스를 분리해 구성할 수 있습니다.

ResourceQuota는 네임스페이스가 사용할 수 있는 특정 리소스의 양을 제한합니다. 이를 통해 한 팀이나 워크로드가 공유 클러스터의 용량을 모두 소진하는 것을 방지할 수 있습니다.

이 실습에서는 다음 작업을 수행합니다.

dev라는 새 "아파트"(네임스페이스) 를 만듭니다.
해당 아파트에 엄격한 "전기 사용량 제한"(ResourceQuota) 을 설정합니다.
가구 (Pod) 를 아파트 안으로 옮겨 보고 제한에 맞는지 확인합니다.

네임스페이스 생성

이 단계에서는 개발 팀의 리소스를 격리할 새 네임스페이스를 만듭니다.

네임스페이스는 하나의 클러스터 안에 있는 논리적 경계이며, 별도의 클러스터가 아닙니다. 팀은 여전히 동일한 컨트롤 플레인과 기본 노드를 공유하지만, 이름과 정책, 여러 리소스 보기 범위를 분리하여 작업을 체계적으로 관리할 수 있습니다.

기본적으로 모든 리소스는 default 네임스페이스 (로비) 에 생성됩니다. 현재 어떤 네임스페이스가 있는지 확인합니다.

kubectl get namespaces

default, kube-system(건물 관리자가 있는 곳) 과 몇 개의 다른 네임스페이스가 표시됩니다.

이제 dev 아파트를 만듭니다.

kubectl create namespace dev

생성되었는지 확인합니다.

kubectl get namespaces

목록에 dev가 표시됩니다. 현재는 벽이나 제한이 없는 빈 아파트이므로 무엇이든 안에 넣을 수 있습니다.

리소스 제한 적용

이제 규칙을 설정해야 합니다. dev 팀이 클러스터 전체의 CPU 와 메모리를 모두 사용하지 않도록 해야 합니다.

ResourceQuota 객체를 생성합니다. 이 객체를 사용하면 다음과 같이 제한을 설정할 수 있습니다. "dev 네임스페이스에서는 CPU 를 최대 2 개, 메모리를 최대 2Gi 까지 사용할 수 있습니다."

공유 클러스터에서는 CPU 와 메모리가 한정되어 있으므로 할당량이 특히 중요합니다. 할당량이 없으면 하나의 과도한 워크로드가 공정한 사용량보다 많은 리소스를 소비하여 다른 사용자의 클러스터 안정성을 해칠 수 있습니다. 이런 의미에서 할당량은 단순히 사용량을 계산하는 기능이 아니라 안정성을 유지하는 도구이기도 합니다.

quota.yaml이라는 파일을 만듭니다.

nano quota.yaml

다음 구성을 붙여 넣습니다.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-quota
  namespace: dev
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi

저장하고 종료합니다 (Ctrl+X, Y, Enter).

이 규칙을 클러스터에 적용합니다.

kubectl apply -f quota.yaml

규칙의 세부 정보를 확인할 수 있습니다. 설정한 "Hard" 제한과 현재 사용량인 "Used" 값 (현재는 0) 이 표시됩니다.

kubectl describe resourcequota dev-quota --namespace=dev

Pod 배포

이제 규칙을 설정했으므로 Pod 를 배치해 봅니다.

중요한 규칙: 아파트에 제한이 설정되어 있으면 안으로 가져오는 모든 가구는 크기를 반드시 선언해야 합니다. Kubernetes 에서는 네임스페이스에 Quota 가 있는 경우 모든 Pod 가 명시적인 resources(requests 및 limits) 를 지정해야 한다는 뜻입니다. 이를 지정하지 않으면 건물 관리자 (Kubernetes) 가 입구에서 배치를 거부합니다.

여기서 서로 관련된 두 가지 개념을 함께 확인합니다. request는 Pod 가 배치될 때 스케줄러가 보장해야 하는 리소스의 양을 나타냅니다. limit는 컨테이너가 사용할 수 있는 최대 리소스 양입니다. Quota 는 네임스페이스 전체의 requests 와 limits 를 합산하여 총량이 정책 범위 안에 있도록 관리합니다.

pod.yaml이라는 파일을 만듭니다.

nano pod.yaml

다음 내용을 붙여 넣습니다. 이 Pod 의 크기를 명시적으로 지정했다는 점에 주목합니다.

apiVersion: v1
kind: Pod
metadata:
  name: dev-pod
  namespace: dev ## <-- Putting it in the 'dev' apartment
spec:
  containers:
    - name: nginx
      image: nginx
      resources:
        requests:
          memory: "128Mi"
          cpu: "250m"
        limits:
          memory: "256Mi"
          cpu: "500m"

저장하고 종료합니다 (Ctrl+X, Y, Enter).

Pod 를 배포합니다.

kubectl apply -f pod.yaml

dev 네임스페이스 안에서 실행 중인지 확인합니다.

kubectl get pods --namespace=dev

상태가 Running으로 표시될 때까지 기다립니다.

이제 Quota 사용량을 다시 확인합니다. "Used" 열의 값이 증가한 것을 볼 수 있습니다.

kubectl describe resourcequota dev-quota --namespace=dev

이제 예산에 따른 리소스 사용량을 성공적으로 추적하고 있습니다.

격리 확인

마지막으로 "아파트"의 벽이 실제로 작동하는지 확인합니다.

네임스페이스 격리는 주로 이름과 정책, 작업 범위를 분리하는 기능입니다. 기본적으로 워크로드가 물리적으로 분리된 하드웨어에서 실행된다는 뜻은 아닙니다. 이후 노드 선택과 더 강력한 격리 메커니즘을 배울 때 이 차이가 중요합니다.

dev-pod를 dev 안에 배치했습니다. 따라서 로비 (default) 에서는 표시되지 않아야 합니다.

default 네임스페이스의 Pod 를 나열합니다.

kubectl get pods

"No resources found in default namespace"가 표시되거나, 최소한 dev-pod가 표시되지 않아야 합니다.

이제 default 네임스페이스에 Quota 가 있는지 확인합니다.

kubectl get resourcequota

아무것도 표시되지 않아야 합니다. 설정한 전기 사용량 제한은 건물 전체가 아니라 dev 아파트에만 적용됩니다.

이를 통해 네임스페이스가 팀 간에 실제 격리를 제공한다는 것을 확인할 수 있습니다.

요약

이 실습에서 Kubernetes 클러스터의 건물 관리자가 되어 보았습니다.

다음 작업을 성공적으로 수행했습니다.

팀 전용 네임스페이스(dev) 를 만들었습니다.
과도한 사용을 방지하기 위해 엄격한 ResourceQuota(전기 사용량 제한) 를 설정했습니다.
이 제한을 준수하는 애플리케이션을 배포했습니다.
네임스페이스 사이의 벽이 리소스를 격리하는지 확인했습니다.

대규모 조직은 이와 같은 방식으로 하나의 Kubernetes 클러스터를 수백 개의 팀이 공유하도록 운영하며, 팀끼리 서로의 작업을 방해하지 않도록 관리합니다.