[Kubernetes] 네임스페이스

Kubernetes는 컨테이너 오케스트레이션 시스템의 대표적인 예시입니다. 하지만, 대규모 애플리케이션을 운영하다보면, 수 많은 컨테이너와 그들의 리소스들을 한 곳에 두면, 서로 간의 충돌이나 오작동과 같이 다양한 문제가 발생할 수 있습니다. 이러한 문제를 해결하기 위해 Kubernetes는 네임스페이스 기능을 제공합니다.

네임스페이스는 리소스를 논리적으로 분리하고 격리시키는 개념입니다. Kubernetes에서 네임스페이스를 사용하면, 클러스터 내에서 리소스를 분리하고 다른 네임스페이스와 격리시킬 수 있습니다. 이를 통해, 서로 다른 팀이나 프로젝트 간에 리소스를 분리하여 충돌을 방지하고, 보안을 강화할 수 있습니다.

네임스페이스의 가장 큰 특징은 네임스페이스 내에서만 유효하다는 것입니다. 예를 들어, Pod, ReplicationController, Deployment, Service, ConfigMap, Secret 등이 네임스페이스에 속하면, 해당 네임스페이스 내에서만 유효하며, 다른 네임스페이스에서는 접근할 수 없습니다. 이는 리소스 간의 충돌을 방지하고, 유지보수 및 관리를 용이하게 만들어줍니다.

또한, Kubernetes는 기본적으로 'default'라는 네임스페이스를 제공합니다. 이는 별도의 네임스페이스를 지정하지 않은 경우에는 자동으로 default 네임스페이스에 리소스가 생성됩니다. 그리고, kubectl 명령어를 사용할 때에도, 별도의 네임스페이스를 지정하지 않은 경우에는 default 네임스페이스가 사용됩니다. 이처럼, 기본적으로 제공되는 default 네임스페이스를 사용하면, 별도의 설정 없이도 리소스를 생성하고 관리할 수 있습니다.

하지만, 다수의 애플리케이션을 운영하다보면, default 네임스페이스만으로는 모든 리소스를 관리할 수 없습니다. 따라서, Kubernetes에서는 여러 개의 네임스페이스를 생성할 수 있으며, 각각의 네임스페이스는 독립적인 가상 클러스터처럼 동작합니다. 예를 들어, 애플리케이션A의 모든 리소스를 namespaceA에, 애플리케이션B의 리소스를 namespaceB에 배치할 수 있습니다. 이를 통해, 각각의 애플리케이션의 리소스를 쉽게 구분하여 관리할 수 있습니다.

마지막으로, 네임스페이스는 스코핑과 같은 개념을 제공합니다. 네임스페이스 기반 스코핑은 네임스페이스 기반 오브젝트에만 적용 가능하며 클러스터 범위의 오브젝트에는 적용 불가능합니다. 이는 각각의 네임스페이스가 독립적인 가상 클러스터처럼 동작하기 때문입니다. 따라서, 네임스페이스를 적절하게 사용함으로써, 안정적이고 보안성 높은 애플리케이션 운영이 가능해집니다.

네임스페이스 다루기

💡 `kube-` 접두사로 시작하는 네임스페이스는 쿠버네티스 시스템 전용이므로, 사용자는 이를 생성하지 않습니다.

네임스페이스 조회

사용 중인 클러스터의 현재 네임스페이스를 나열할 수 있습니다.

kubectl get namespace

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

쿠버네티스는 초기에 네 개의 네임스페이스를 가지고 있습니다.

• default: 오브젝트를 위한 기본 네임스페이스
• kube-system: 쿠버네티스 시스템에서 생성한 오브젝트를 위한 네임스페이스
• kube-public: 모든 사용자가 읽기 권한으로 접근할 수 있는 네임스페이스. 이 네임스페이스는 전체 클러스터에서 공개적으로 드러나고 읽을 수 있는 리소스를 위해 예약되어 있습니다.
• kube-node-lease: 각 노드와 연관된 리스 오브젝트를 가지고 있습니다. 노드 리스는 kubelet이 하트비트를 보내서 컨트롤 플레인이 노드의 장애를 탐지할 수 있게 합니다.

요청에 네임스페이스 설정하기

현재 요청에 대한 네임스페이스를 설정하기 위해서 --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

서비스 생성 시 해당 DNS 엔트리가 생성됩니다. 이는 <서비스-이름>.<네임스페이스-이름>.svc.cluster.local 형식의 엔트리이며, 컨테이너가 <서비스-이름>만 사용하는 경우 네임스페이스 내에 국한된 서비스로 연결됩니다. 개발, 스테이징, 운영과 같이 여러 네임스페이스 내에서 동일한 설정을 사용하는 경우 유용하며, 네임스페이스를 넘어서 접근하기 위해서는 전체 주소 도메인 이름(FQDN)을 사용해야 합니다. 따라서, 모든 네임스페이스 이름은 유효한 RFC 1123 DNS 레이블이어야 합니다.

💡 네임스페이스 이름을 공개 최상위 도메인 중 하나와 같게 만들면, 해당 네임스페이스 내의 서비스의 짧은 DNS 이름이 공개 DNS 레코드와 겹칠 수 있습니다. 어떤 네임스페이스 내의 워크로드가 DNS 룩업을 접미점 없이 수행하면, 해당 서비스로 리다이렉트될 가능성이 높습니다.

위 문제를 방지하기 위해, 네임스페이스를 만들기 위해서는 권한이 있어야 합니다. 필요한 경우, 추가적인 보안 컨트롤을 구성할 수 있습니다. 예를 들어, 어드미션 웹훅을 이용하여 공개 TLD와 같은 이름의 네임스페이스 생성을 금지시킬 수 있습니다.

모든 오브젝트가 네임스페이스에 속하지는 않음

쿠버네티스 리소스 대부분(예: 파드, 서비스, 레플리케이션 컨트롤러)는 네임스페이스에 속하지만, 네임스페이스 리소스 자체는 네임스페이스에 속하지 않으며, 노드나 퍼시스턴트 볼륨과 같은 저수준 리소스는 어느 네임스페이스에도 속하지 않습니다.

# 네임스페이스에 속하는 리소스
kubectl api-resources --namespaced=true

# 네임스페이스에 속하지 않는 리소스
kubectl api-resources --namespaced=false

자동 레이블링

쿠버네티스 컨트롤 플레인은 NamespaceDefaultLabelName 기능 게이트가 활성화되면 모든 네임스페이스에 kubernetes.io/metadata.name 레이블을 설정합니다. 이 레이블 값은 네임스페이스 이름입니다.

레퍼런스

https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/namespaces/