네임스페이스

네임스페이스 (Namespaces)

쿠버네티스에서 네임스페이스(namespace)는 단일 클러스터 안에서 리소스 그룹을 격리하는 메커니즘을 제공해요. 리소스 이름은 네임스페이스 안에서만 유일하면 되고, 네임스페이스 간에는 유일하지 않아도 돼요. 네임스페이스 기반의 범위 지정은 네임스페이스가 있는 객체(예: Deployment, Service 등)에만 적용되며, 클러스터 전역 객체(예: StorageClass, Node, PersistentVolume 등)에는 적용되지 않아요.

출처: 문서

본문

여러 네임스페이스를 써야 하는 경우

네임스페이스는 여러 팀이나 프로젝트에 걸쳐 많은 사용자가 있는 환경을 위해 고안됐어요. 사용자가 몇 명에서 수십 명인 클러스터라면 네임스페이스를 만들거나 생각할 필요조차 없어요. 네임스페이스가 제공하는 기능이 필요해질 때부터 사용하면 돼요.

네임스페이스는 이름의 범위(scope)를 제공해요. 리소스 이름은 네임스페이스 안에서만 유일하면 되고, 네임스페이스 간에는 유일하지 않아도 돼요. 네임스페이스는 서로 중첩될 수 없고, 각 쿠버네티스 리소스는 오직 하나의 네임스페이스에만 있을 수 있어요.

네임스페이스는 (리소스 할당량을 통해) 클러스터 리소스를 여러 사용자에게 나누어 주는 한 방법이에요.

같은 소프트웨어의 다른 버전처럼 아주 조금씩 다른 리소스를 분리하기 위해 여러 네임스페이스를 쓸 필요는 없어요. 같은 네임스페이스 안에서 리소스를 구분하려면 라벨(labels)을 사용해요.

참고:

초기 네임스페이스 (Initial namespaces)

쿠버네티스는 네 개의 초기 네임스페이스로 시작해요.

default

쿠버네티스는 이 네임스페이스를 포함해서, 네임스페이스를 먼저 만들지 않아도 새 클러스터를 바로 사용할 수 있게 해줘요.

kube-node-lease

이 네임스페이스는 각 노드와 연결된 Lease 객체를 보관해요. 노드 임대(lease)는 kubelet이 하트비트를 보내 제어 플레인이 노드 장애를 감지할 수 있게 해줘요.

kube-public

이 네임스페이스는 모든 클라이언트(인증되지 않은 클라이언트 포함)가 읽을 수 있어요. 이 네임스페이스는 주로 클러스터 사용을 위해 예약되어 있으며, 일부 리소스가 클러스터 전체에서 공개적으로 보이고 읽히기를 원할 때 사용돼요. 이 네임스페이스의 공개적인 성격은 관례(convention)일 뿐, 필수 조건은 아니에요.

kube-system

쿠버네티스 시스템이 만든 객체를 위한 네임스페이스예요.

네임스페이스 사용하기 (Working with Namespaces)

네임스페이스의 생성과 삭제는 관리자 가이드의 네임스페이스 문서에 설명되어 있어요.

참고:

네임스페이스 보기

클러스터의 현재 네임스페이스를 나열하려면 다음을 실행하세요.

kubectl get namespace

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

요청에 대한 네임스페이스 설정

현재 요청에 대한 네임스페이스를 설정하려면 --namespace 플래그를 사용해요.

예를 들어:

kubectl run nginx --image=nginx --namespace=<insert-namespace-name-here>

kubectl get pods --namespace=<insert-namespace-name-here>

네임스페이스 기본 설정

해당 컨텍스트에서 이후의 모든 kubectl 명령에 대해 네임스페이스를 영구적으로 저장할 수 있어요.

kubectl config set-context --current --namespace=<insert-namespace-name-here>

# 확인해 보기
kubectl config view --minify | grep namespace:

네임스페이스와 DNS

Service를 만들면 그에 해당하는 DNS 항목이 생겨요. 이 항목은 <service-name>.<namespace-name>.svc.cluster.local 형태라서, 컨테이너가 <service-name>만 사용한다면 그 네임스페이스에 로컬인 Service로 해석돼요. 이는 Development, Staging, Production 같은 여러 네임스페이스에서 같은 구성을 사용할 때 유용해요. 네임스페이스를 넘어 접근하려면 완전히 정규화된 도메인 이름(FQDN)을 사용해야 해요.

결과적으로 모든 네임스페이스 이름은 유효한 RFC 1123 DNS 라벨이어야 해요.

경고:

공개 최상위 도메인(public top-level domains)과 같은 이름으로 네임스페이스를 만들면, 그 네임스페이스의 Service는 공개 DNS 레코드와 겹치는 짧은 DNS 이름을 가질 수 있어요. 어떤 네임스페이스의 워크로드든 마침표(trailing dot) 없이 DNS 조회를 수행하면 공개 DNS보다 우선해서 그 Service로 리다이렉트될 수 있어요.

이를 완화하려면 네임스페이스 생성 권한을 신뢰할 수 있는 사용자에게만 제한해요. 필요하다면 admission webhook 같은 서드파티 보안 제어를 추가로 구성해서 공개 TLD 이름의 네임스페이스가 생성되는 것을 막을 수도 있어요.

모든 객체가 네임스페이스에 있는 것은 아님

대부분의 쿠버네티스 리소스(예: Pod, Service, Deployment 등)는 어떤 네임스페이스에 들어 있어요. 하지만 네임스페이스 리소스 자체는 네임스페이스에 있지 않아요. 그리고 Node나 PersistentVolume 같은 하위 수준의 리소스는 어떤 네임스페이스에도 속하지 않아요.

어떤 쿠버네티스 리소스가 네임스페이스에 있고 없는지 보려면 다음을 실행하세요.

# 네임스페이스에 있는 것
kubectl api-resources --namespaced=true

# 네임스페이스에 없는 것
kubectl api-resources --namespaced=false

자동 라벨링 (Automatic labelling)

쿠버네티스 제어 플레인은 모든 네임스페이스에 kubernetes.io/metadata.name 이라는 불변(immutable) 라벨을 설정해요. 이 라벨의 값은 네임스페이스 이름이에요.

더 알아보기 (Learn more)