네임스페이스로 클러스터 공유하기

이 페이지는 네임스페이스를 보고, 작업하고, 삭제하는 방법을 보여드려요. 또한 쿠버네티스 네임스페이스를 사용해 클러스터를 세분화하는 방법도 보여드려요.

출처: 문서

본문

시작하기 전에 (Before you begin)

기존 쿠버네티스 클러스터가 있어야 해요.
쿠버네티스 Pod, Service, Deployment에 대한 기본 이해가 있어야 해요.

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

클러스터의 현재 네임스페이스를 나열해요.

kubectl get namespaces

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

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

default — 다른 네임스페이스가 없는 객체의 기본 네임스페이스
kube-node-lease — 각 노드와 연관된 Lease 객체를 담는 네임스페이스. 노드 리스는 kubelet이 하트비트를 보내 컨트롤 플레인이 노드 실패를 감지할 수 있게 해 줘요.
kube-public — 자동으로 생성되고 모든 사용자(인증되지 않은 사용자 포함)가 읽을 수 있는 네임스페이스. 이 네임스페이스는 주로 클러스터 사용을 위해 예약되며, 일부 리소스가 클러스터 전체에서 공개적으로 보이고 읽혀야 하는 경우를 위한 것이에요. 이 네임스페이스의 공개적 측면은 단지 관례일 뿐 요구 사항은 아니에요.
kube-system — 쿠버네티스 시스템이 만든 객체를 위한 네임스페이스

다음을 사용해 특정 네임스페이스의 요약을 얻을 수도 있어요.

kubectl get namespaces <name>

또는 다음으로 자세한 정보를 얻을 수 있어요.

kubectl describe namespaces <name>

Name:           default
Labels:         <none>
Annotations:    <none>
Status:         Active

No resource quota.

Resource Limits
 Type       Resource    Min Max Default
 ----               --------    --- --- ---
 Container          cpu         -   -   100m

이 세부 사항은 리소스 쿼터(있는 경우)와 리소스 제한 범위를 모두 보여준다는 점에 주의하세요. 리소스 쿼터는 네임스페이스의 리소스 총 사용량을 추적하고, 클러스터 운영자가 네임스페이스가 소비할 수 있는 Hard 리소스 사용량 제한을 정의할 수 있게 해 줘요. 리미트 범위는 네임스페이스에서 단일 엔티티가 소비할 수 있는 리소스 양에 대한 최소/최대 제약을 정의해요. 승인 제어: Limit Range를 참고하세요.

네임스페이스는 두 가지 단계 중 하나일 수 있어요.

Active — 네임스페이스가 사용 중
Terminating — 네임스페이스가 삭제 중이며 새 객체에 사용할 수 없음

자세한 내용은 API 참조의 Namespace를 참고하세요.

새 네임스페이스 만들기 (Creating a new namespace)

참고: kube- 접두사가 있는 네임스페이스는 쿠버네티스 시스템 네임스페이스로 예약돼 있으므로 만들지 마세요.

my-namespace.yaml이라는 새 YAML 파일을 다음 내용으로 만들어요.

apiVersion: v1
kind: Namespace
metadata:
  name: <insert-namespace-name-here>

그런 다음 실행해요.

kubectl create -f ./my-namespace.yaml

또는 아래 명령으로 네임스페이스를 만들 수 있어요.

kubectl create namespace <insert-namespace-name-here>

네임스페이스의 이름은 유효한 DNS 라벨이어야 해요. 선택적 필드 finalizers가 있으며, 이를 통해 관찰 가능한 항목이 네임스페이스가 삭제될 때마다 리소스를 정리할 수 있어요. 존재하지 않는 finalizer를 지정하면 네임스페이스는 생성되지만, 사용자가 삭제하려 하면 Terminating 상태에 갇히게 된다는 점을 명심하세요.

finalizers에 대한 더 많은 정보는 네임스페이스 설계 문서에서 찾을 수 있어요.

네임스페이스 삭제하기 (Deleting a namespace)

네임스페이스를 삭제해요.

kubectl delete namespaces <insert-some-namespace-name>

경고: 이것은 네임스페이스 아래의 모든 것을 삭제해요!

이 삭제는 비동기적이므로, 잠시 동안 네임스페이스가 Terminating 상태로 보일 거예요.

쿠버네티스 네임스페이스로 클러스터 세분화하기 (Subdividing your cluster using Kubernetes namespaces)

기본적으로 쿠버네티스 클러스터는 클러스터가 사용하는 기본 Pod, Service, Deployment 집합을 담기 위해 프로비저닝할 때 default 네임스페이스를 만든다. 새 클러스터가 있다고 가정하면 다음으로 사용 가능한 네임스페이스를 검사할 수 있어요.

kubectl get namespaces

NAME      STATUS    AGE
default   Active    13m

새 네임스페이스 만들기 (Create new namespaces)

이 실습에서는 콘텐츠를 담을 두 개의 추가 쿠버네티스 네임스페이스를 만들어요. 조직에서 개발과 프로덕션 사용 사례에 공유 쿠버네티스 클러스터를 사용하는 시나리오에서:

개발 팀은 애플리케이션을 빌드하고 실행하는 데 사용하는 Pod, Service, Deployment 목록에 대한 보기를 얻을 수 있는 클러스터 공간을 유지하고 싶어해요. 이 공간에서는 쿠버네티스 리소스가 생겼다 사라지고, 리소스를 수정할 수 있는지에 대한 제한은 민첩한 개발을 위해 완화돼 있어요.
운영 팀은 프로덕션 사이트를 실행하는 Pod, Service, Deployment 집합을 조작할 수 있는 사람을 엄격한 절차로 강제할 수 있는 클러스터 공간을 유지하고 싶어해요.

이 조직이 따를 수 있는 한 패턴은 쿠버네티스 클러스터를 development와 production 두 네임스페이스로 분할하는 것이에요. 작업을 담을 두 개의 새 네임스페이스를 만들어요.

kubectl로 development 네임스페이스를 만들어요.

kubectl create -f https://k8s.io/examples/admin/namespace-dev.json

kubectl로 production 네임스페이스를 만들어요.

kubectl create -f https://k8s.io/examples/admin/namespace-prod.json

확실히 하기 위해 클러스터의 모든 네임스페이스를 나열해요.

kubectl get namespaces --show-labels

NAME          STATUS    AGE       LABELS
default       Active    32m       <none>
development   Active    29s       name=development
production    Active    23s       name=production

각 네임스페이스에 파드 만들기 (Create pods in each namespace)

쿠버네티스 네임스페이스는 클러스터의 Pod, Service, Deployment의 범위를 제공해요. 한 네임스페이스와 상호작용하는 사용자는 다른 네임스페이스의 콘텐츠를 보지 못해요. 이것을 보여주기 위해 development 네임스페이스에 Deployment와 Pod를 만들어요.

kubectl create deployment snowflake \
  --image=registry.k8s.io/serve_hostname \
  -n=development --replicas=2

호스트네임을 서빙하는 기본 컨테이너가 있는 snowflake라는 파드를 실행하는, 복제본 크기 2의 디플로이먼트를 만들었어요.

kubectl get deployment -n=development

NAME         READY   UP-TO-DATE   AVAILABLE   AGE
snowflake    2/2     2            2           2m

kubectl get pods -l app=snowflake -n=development

NAME                         READY     STATUS    RESTARTS   AGE
snowflake-3968820950-9dgr8   1/1       Running   0          2m
snowflake-3968820950-vgc4n   1/1       Running   0          2m

이것은 개발자들이 원하는 것을 할 수 있고 production 네임스페이스의 콘텐츠에 영향을 줄 걱정을 하지 않아도 된다는 것을 보여줘요.

production 네임스페이스로 전환해 한 네임스페이스의 리소스가 다른 네임스페이스로부터 어떻게 숨겨지는지 보여드릴게요. production 네임스페이스는 비어 있어야 하고, 다음 명령은 아무것도 반환하지 않아야 해요.

kubectl get deployment -n=production
kubectl get pods -n=production

production 네임스페이스에 파드를 조금 만들어요.

kubectl create deployment cattle --image=registry.k8s.io/serve_hostname -n=production
kubectl scale deployment cattle --replicas=5 -n=production

kubectl get deployment -n=production

NAME         READY   UP-TO-DATE   AVAILABLE   AGE
cattle       5/5     5            5           10s

kubectl get pods -l app=cattle -n=production

NAME                      READY     STATUS    RESTARTS   AGE
cattle-2263376956-41xy6   1/1       Running   0          34s
cattle-2263376956-kw466   1/1       Running   0          34s
cattle-2263376956-n4v97   1/1       Running   0          34s
cattle-2263376956-p5p3i   1/1       Running   0          34s
cattle-2263376956-sxpth   1/1       Running   0          34s

이 시점에서 사용자가 한 네임스페이스에서 만든 리소스는 다른 네임스페이스로부터 숨겨진다는 것이 분명해요. 쿠버네티스의 정책 지원이 발전함에 따라, 이 시나리오는 각 네임스페이스에 서로 다른 인가 규칙을 제공하는 방법을 보여주도록 확장돼요.

네임스페이스 사용의 동기 이해하기 (Understanding the motivation for using namespaces)

단일 클러스터는 여러 사용자 또는 사용자 그룹(이하 이 문서에서 사용자 커뮤니티)의 요구를 충족할 수 있어야 해요. 쿠버네티스 네임스페이스는 서로 다른 프로젝트, 팀, 고객이 쿠버네티스 클러스터를 공유하도록 도와줘요. 다음을 제공함으로써 이 역할을 해요.

이름(Name)의 범위
클러스터의 일부에 인가와 정책을 부착하는 메커니즘

여러 네임스페이스의 사용은 선택적이에요. 각 사용자 커뮤니티는 다른 커뮤니티와 격리되어 작업할 수 있기를 원해요. 각 사용자 커뮤니티는 고유한:

리소스(파드, 서비스, 복제 컨트롤러 등)
정책(커뮤니티에서 누가 어떤 작업을 수행할 수 있는지)
제약(이 커뮤니티는 이만큼의 쿼터가 허용되는 등)

클러스터 운영자는 각 고유한 사용자 커뮤니티에 대해 Namespace를 만들 수 있어요. Namespace는 다음에 대한 고유한 범위를 제공해요.

이름이 있는 리소스(기본 명명 충돌을 피하기 위해)
신뢰하는 사용자에게 위임된 관리 권한
커뮤니티 리소스 소비를 제한하는 능력

사용 사례는 다음과 같아요.

클러스터 운영자로서 단일 클러스터에서 여러 사용자 커뮤니티를 지원하고 싶음.
클러스터 운영자로서 클러스터의 파티션에 대한 권한을 그 커뮤니티의 신뢰하는 사용자에게 위임하고 싶음.
클러스터 운영자로서 각 커뮤니티가 소비할 수 있는 리소스의 양을 제한해, 클러스터를 사용하는 다른 커뮤니티에 미치는 영향을 제한하고 싶음.
클러스터 사용자로서 다른 사용자 커뮤니티가 클러스터에서 하는 일과 격리된 채, 내 사용자 커뮤니티와 관련된 리소스와 상호작용하고 싶음.

네임스페이스와 DNS 이해하기 (Understanding namespaces and DNS)

Service를 만들면 해당 DNS 항목이 생성돼요. 이 항목은 <service-name>.<namespace-name>.svc.cluster.local 형식이며, 이는 컨테이너가 <service-name>을 사용하면 네임스페이스에 로컬인 서비스로 해석된다는 뜻이에요. 이는 Development, Staging, Production 같은 여러 네임스페이스에서 동일한 구성을 사용하는 데 유용해요. 네임스페이스를 넘어 도달하려면 FQDN(정규화된 도메인 이름)을 사용해야 해요.

다음 단계 (What's next)

네임스페이스 선호 설정에 대해 더 배우기
요청에 대한 네임스페이스 설정에 대해 더 배우기
네임스페이스 설계 보기

네임스페이스로 클러스터 공유하기