해당 문서의 쿠버네티스 버전: v1.29
Kubernetes v1.29 문서는 더 이상 적극적으로 관리되지 않음. 현재 보고있는 문서는 정적 스냅샷임. 최신 문서를 위해서는, 다음을 참고. 최신 버전.
네임스페이스를 사용해 클러스터 공유하기
이 페이지는 네임스페이스를 살펴보고, 작업하고, 삭제하는 방법에 대해 다룬다. 또한 쿠버네티스 네임스페이스를 사용해 클러스터를 세분화하는 방법에 대해서도 다룬다.
시작하기 전에
- 기존 쿠버네티스 클러스터가 있다.
- 쿠버네티스 파드, 서비스, 그리고 디플로이먼트에 대해 이해하고 있다.
네임스페이스 보기
- 아래 명령어를 사용해 클러스터의 현재 네임스페이스를 나열한다.
kubectl get namespaces
NAME STATUS AGE
default Active 11d
kube-system Active 11d
kube-public Active 11d
쿠버네티스를 시작하면 세 개의 초기 네임스페이스가 있다.
default다른 네임스페이스가 없는 오브젝트를 위한 기본 네임스페이스kube-system쿠버네티스 시스템에서 생성된 오브젝트의 네임스페이스kube-public이 네임스페이스는 자동으로 생성되며 모든 사용자(미인증 사용자를 포함)가 읽을 수 있다. 이 네임스페이스는 일부 리소스를 공개적으로 보고 읽을 수 있어야 하는 경우에 대비하여 대부분이 클러스터 사용을 위해 예약돼 있다. 그러나 이 네임스페이스의 공개적인 성격은 관례일 뿐 요구 사항은 아니다.
아래 명령을 실행해 특정 네임스페이스에 대한 요약 정보를 볼 수 있다.
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
이러한 세부 정보에는 리소스 한도(limit) 범위 뿐만 아니라 리소스 쿼터(만약 있다면)까지 모두 표시된다.
리소스 쿼터는 네임스페이스 내 리소스의 집계 사용량을 추적하며, 네임스페이스에서 사용할 수 있는 하드(Hard) 리소스 사용 제한을 클러스터 운영자가 정의할 수 있도록 해준다.
제한 범위는 하나의 엔티티(entity)가 하나의 네임스페이스에서 사용할 수 있는 리소스 양에 대한 최대/최소 제약 조건을 정의한다.
어드미션 컨트롤: 리밋 레인지(Limit Range)를 참조하자.
네임스페이스는 다음 두 상태 중 하나에 있을 수 있다.
Active네임스페이스가 사용 중이다.Terminating네임스페이스가 삭제 중이므로 새 오브젝트에 사용할 수 없다.
자세한 내용은 API 레퍼런스의 네임스페이스를 참조한다.
새 네임스페이스 생성하기
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 레이블이어야 한다.
옵션 필드인 finalizer는 네임스페이스가 삭제 될 때 관찰자가 리소스를 제거할 수 있도록 한다. 존재하지 않는 파이널라이저(finalizer)를 명시한 경우 네임스페이스는 생성되지만 사용자가 삭제하려 하면 Terminating 상태가 된다.
파이널라이저에 대한 자세한 내용은 네임스페이스 디자인 문서에서 확인할 수 있다.
네임스페이스 삭제하기
다음 명령을 실행해 네임스페이스를 삭제한다.
kubectl delete namespaces <insert-some-namespace-name>
삭제는 비동기적이므로 삭제 후 한동안은 네임스페이스의 상태가 Terminating으로 보일 것이다.
쿠버네티스 네임스페이스를 사용해 클러스터 세분화하기
-
기본 네임스페이스 이해하기
기본적으로 쿠버네티스 클러스터는 클러스터에서 사용할 기본 파드, 서비스, 그리고 디플로이먼트(Deployment) 집합을 가지도록 클러스터를 프로비저닝 할 때 기본 네임스페이스를 인스턴스화한다.
새 클러스터가 있다고 가정하고 아래 명령을 수행하면 사용 가능한 네임스페이스를 볼 수 있다.
kubectl get namespacesNAME STATUS AGE default Active 13m -
새 네임스페이스 생성하기
이 예제에서는 내용을 저장할 쿠버네티스 네임스페이스를 추가로 두 개 생성할 것이다.
개발과 프로덕션 유스케이스에서 공유 쿠버네티스 클러스터를 사용하는 조직이 있다고 가정하자.
개발 팀은 애플리케이션을 구축하고 실행하는데 사용하는 파드, 서비스, 디플로이먼트의 목록을 볼 수 있는 공간을 클러스터에 유지하려 한다. 이 공간에서는 쿠버네티스 리소스가 자유롭게 추가 및 제거되고, 누가 리소스를 수정할 수 있는지 없는지에 대한 제약이 완화돼 빠른 개발이 가능해진다.
운영 팀은 운영 사이트를 실행하는 파드, 서비스, 디플로이먼트 집합을 조작할 수 있는 사람과 그렇지 않은 사람들에 대해 엄격한 절차를 적용할 수 있는 공간을 클러스터에 유지하려 한다.
이 조직이 따를 수 있는 한 가지 패턴은 쿠버네티스 클러스터를
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-labelsNAME STATUS AGE LABELS default Active 32m <none> development Active 29s name=development production Active 23s name=production -
네임스페이스마다 파드 생성
쿠버네티스 네임스페이스는 클러스터의 파드, 서비스 그리고 디플로이먼트의 범위를 제공한다.
하나의 네임스페이스와 상호 작용하는 사용자는 다른 네임스페이스의 내용을 볼 수 없다.
이를 보여주기 위해
development네임스페이스에 간단한 디플로이먼트와 파드를 생성하자.kubectl create deployment snowflake --image=registry.k8s.io/serve_hostname -n=development --replicas=2단순히 호스트명을 제공해주는
snowflake라는 파드의 개수를 2개로 유지하는 디플로이먼트를 생성하였다.kubectl get deployment -n=developmentNAME READY UP-TO-DATE AVAILABLE AGE snowflake 2/2 2 2 2mkubectl get pods -l app=snowflake -n=developmentNAME 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네임스페이스에 cattle(가축)이라는 이름의 파드를 생성한다.kubectl create deployment cattle --image=registry.k8s.io/serve_hostname -n=production kubectl scale deployment cattle --replicas=5 -n=production kubectl get deployment -n=productionNAME READY UP-TO-DATE AVAILABLE AGE cattle 5/5 5 5 10skubectl get pods -l app=cattle -n=productionNAME 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
지금 쯤이면 사용자가 한 네임스페이스에 생성한 리소스는 다른 네임스페이스에서 숨겨져 있어야 한다는 것을 잘 알고 있을 것이다.
쿠버네티스 정책 지원이 발전함에 따라, 이 시나리오를 확장해 각 네임스페이스에 서로 다른 인증 규칙을 제공하는 방법을 보이도록 하겠다.
네임스페이스의 사용 동기 이해하기
단일 클러스터는 여러 사용자 및 사용자 그룹(이하 '사용자 커뮤니티')의 요구를 충족시킬 수 있어야 한다.
쿠버네티스 네임스페이스 는 여러 프로젝트, 팀 또는 고객이 쿠버네티스 클러스터를 공유할 수 있도록 지원한다.
이를 위해 다음을 제공한다.
- 이름에 대한 범위
- 인증과 정책을 클러스터의 하위 섹션에 연결하는 메커니즘
여러 개의 네임스페이스를 사용하는 것은 선택 사항이다.
각 사용자 커뮤니티는 다른 커뮤니티와 격리된 상태로 작업할 수 있기를 원한다.
각 사용자 커뮤니티는 다음을 가진다.
- 리소스 (파드, 서비스, 레플리케이션 컨트롤러(replication controller) 등
- 정책 (커뮤니티에서 조치를 수행할 수 있거나 없는 사람)
- 제약 조건 (해당 커뮤니티에서는 어느 정도의 쿼터가 허용되는지 등)
클러스터 운영자는 각 사용자 커뮤니티 마다 네임스페이스를 생성할 수 있다.
네임스페이스는 다음을 위한 고유한 범위를 제공한다.
- (기본 명명 충돌을 방지하기 위해) 명명된 리소스
- 신뢰할 수 있는 사용자에게 관리 권한 위임
- 커뮤니티 리소스 소비를 제한하는 기능
유스케이스는 다음을 포함한다.
- 클러스터 운영자로서 단일 클러스터에서 여러 사용자 커뮤니티를 지원하려 한다.
- 클러스터 운영자로서 클러스터 분할에 대한 권한을 해당 커뮤니티의 신뢰할 수 있는 사용자에게 위임하려 한다.
- 클러스터 운영자로서 클러스터를 사용하는 다른 커뮤니티에 미치는 영향을 제한하기 위해 각 커뮤니티가 사용할 수 있는 리소스의 양을 제한하고자 한다.
- 클러스터 사용자로서 다른 사용자 커뮤니티가 클러스터에서 수행하는 작업과는 별도로 사용자 커뮤니티와 관련된 리소스와 상호 작용하고 싶다.
네임스페이스와 DNS 이해하기
서비스를 생성하면 상응하는 DNS 엔트리(entry)가 생성된다.
이 엔트리는 <서비스-이름><네임스페이스=이름>.svc.cluster.local 형식을 갖는데,
컨테이너가 <서비스-이름>만 갖는 경우에는 네임스페이스에 국한된 서비스로 연결된다.
이 기능은 개발, 스테이징 및 프로덕션과 같이
여러 네임스페이스 내에서 동일한 설정을 사용할 때 유용하다.
네임스페이스를 넘어서 접근하려면 전체 주소 도메인 이름(FQDN)을 사용해야 한다.
다음 내용
- 네임스페이스 선호(preference)에 대해 자세히 알아보기.
- 요청(request)에 대한 네임스페이스 설정에 대해 자세히 알아보기.
- 네임스페이스 설계 참조하기.