네임스페이스

네임스페이스 (Namespaces)

네임스페이스는 단일 클러스터 내에서 리소스 그룹을 격리하는 메커니즘이에요. 네임스페이스의 개념부터 사용 시기, 초기 네임스페이스, 그리고 DNS와의 관계까지 옆에서 차근차근 설명드릴게요.

출처: Kubernetes 공식 문서 — Namespaces

네임스페이스란 무엇인가요?

Kubernetes에서 네임스페이스는 단일 클러스터 내에서 리소스 그룹을 격리하는 메커니즘을 제공해요. 리소스 이름은 네임스페이스 안에서만 고유하면 되고, 네임스페이스 간에는 고유할 필요가 없어요. 네임스페이스 기반 범위는 네임스페이스가 있는 객체 (예: Deployment, Service 등)에만 적용되며, 클러스터 전체 객체 (예: StorageClass, Node, PersistentVolume 등)에는 적용되지 않습니다.

여러 네임스페이스를 언제 사용할까요?

네임스페이스는 여러 팀이나 프로젝트에 걸친 많은 사용자가 있는 환경에서 사용하도록 설계됐어요. 몇 명에서 수십 명의 사용자가 있는 클러스터에서는 네임스페이스를 만들거나 고민할 필요가 없습니다. 네임스페이스가 제공하는 기능이 필요할 때 사용하세요.

네임스페이스는 이름에 대한 범위를 제공합니다. 리소스 이름은 네임스페이스 안에서만 고유하면 됩니다. 네임스페이스는 서로 중첩될 수 없으며, 각 Kubernetes 리소스는 하나의 네임스페이스에만 있을 수 있어요.

네임스페이스는 리소스 쿼터를 통해 여러 사용자 간에 클러스터 리소스를 나누는 방법입니다.

같은 소프트웨어의 다른 버전처럼 약간 다른 리소스를 분리하기 위해 여러 네임스페이스를 사용할 필요는 없어요. 같은 네임스페이스 내에서 리소스를 구분하려면 라벨을 사용하세요.

참고: 프로덕션 클러스터에서는 default 네임스페이스를 사용하지 않는 것을 고려하세요. 대신 다른 네임스페이스를 만들어 사용하세요.

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

Kubernetes는 네 가지 초기 네임스페이스로 시작합니다.

default: 새 클러스터를 먼저 네임스페이스를 만들지 않고 사용할 수 있게 Kubernetes에 포함된 네임스페이스예요.
kube-node-lease: 각 노드와 연결된 Lease 객체를 보관합니다. 노드 임대를 통해 kubelet이 하트비트를 보내 컨트롤 플레인이 노드 장애를 감지할 수 있게 해줍니다.
kube-public: 인증되지 않은 클라이언트를 포함한 모든 클라이언트가 읽을 수 있는 네임스페이스예요. 주로 클러스터 사용을 위해 예약되어 있으며, 일부 리소스가 전체 클러스터에 공개적으로 보이고 읽히기를 원할 때 사용합니다.
kube-system: Kubernetes 시스템이 만든 객체를 위한 네임스페이스예요.

네임스페이스 작업하기 (Working with Namespaces)

네임스페이스의 생성과 삭제는 네임스페이스에 대한 Admin Guide 문서에 설명되어 있어요.

참고: kube- 접두사로 시작하는 네임스페이스는 Kubernetes 시스템 네임스페이스를 위해 예약되어 있으므로 만들지 마세요.

네임스페이스 보기 (Viewing namespaces)

클러스터의 현재 네임스페이스를 나열하려면:

kubectl get namespace

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

요청에 대한 네임스페이스 설정 (Setting the namespace for a request)

현재 요청의 네임스페이스를 설정하려면 --namespace 플래그를 사용하세요.

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

네임스페이스 기본값 설정 (Setting the namespace preference)

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

kubectl config set-context --current --namespace=<insert-namespace-name-here>
# 검증하기
kubectl config view --minify | grep namespace:

네임스페이스와 DNS (Namespaces and DNS)

Service를 만들면 해당 DNS 항목도 생깁니다. 이 항목은 <service-name>.<namespace-name>.svc.cluster.local 형태예요. 즉 컨테이너가 <service-name>만 사용하면 네임스페이스 로컬의 서비스로 해석됩니다. 이는 Development, Staging, Production처럼 여러 네임스페이스에서 같은 구성을 사용할 때 유용해요. 네임스페이스 간에 도달하려면 정규화된 도메인 이름(FQDN)을 사용해야 합니다.

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

경고: 공개 최상위 도메인과 같은 이름으로 네임스페이스를 만들면, 이 네임스페이스의 서비스는 공개 DNS 레코드와 겹치는 짧은 DNS 이름을 가질 수 있어요. 후행 점 없이 DNS 조회를 수행하는 모든 네임스페이스의 워크로드는 공개 DNS보다 우선하여 해당 서비스로 리다이렉트됩니다.

이를 완화하려면 네임스페이스 생성 권한을 신뢰할 수 있는 사용자로 제한하고, 필요하다면 admission webhook 같은 타사 보안 제어를 구성해 공개 TLD 이름의 네임스페이스 생성을 차단하세요.

모든 객체가 네임스페이스에 있는 것은 아님 (Not all objects are in a namespace)

대부분의 Kubernetes 리소스(Pod, Service, Deployment 등)는 어떤 네임스페이스에 있습니다. 그러나 네임스페이스 리소스 자체는 네임스페이스에 속하지 않아요. 그리고 Node와 PersistentVolume 같은 저수준 리소스도 어떤 네임스페이스에도 없습니다.

어떤 리소스가 네임스페이스에 있고 없는지 보려면:

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

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

자동 라벨링 (Automatic labelling)

기능 상태: Kubernetes 1.22 [stable]

Kubernetes 컨트롤 플레인은 모든 네임스페이스에 변경 불가능한 라벨 kubernetes.io/metadata.name을 설정합니다. 라벨의 값은 네임스페이스 이름이에요.