Change:
<ins> --- title: 네임스페이스를 사용해 클러스터 공유하기 content_type: task --- <!-- overview --> 이 페이지는 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}를 살펴보고, 작업하고, 삭제하는 방법에 대해 다룬다. 또한 쿠버네티스 네임스페이스를 사용해 클러스터를 세분화하는 방법에 대해서도 다룬다. ## {{% heading "prerequisites" %}} * [기존 쿠버네티스 클러스터](/ko/docs/setup/)가 있다. * 쿠버네티스 {{< glossary_tooltip text="파드" term_id="pod" >}}, {{< glossary_tooltip term_id="service" text="서비스" >}}, 그리고 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}에 대해 이해하고 있다. <!-- steps --> ## 네임스페이스 보기 1. 아래 명령어를 사용해 클러스터의 현재 네임스페이스를 나열한다. ```shell kubectl get namespaces ``` ``` NAME          STATUS    AGE default       Active    11d kube-system   Active    11d kube-public   Active    11d ``` 쿠버네티스를 시작하면 세 개의 초기 네임스페이스가 있다. * `default` 다른 네임스페이스가 없는 오브젝트를 위한 기본 네임스페이스 * `kube-system` 쿠버네티스 시스템에서 생성된 오브젝트의 네임스페이스 * `kube-public` 이 네임스페이스는 자동으로 생성되며 모든 사용자(미인증 사용자를 포함)가 읽을 수 있다. 이 네임스페이스는 일부 리소스를 공개적으로 보고 읽을 수 있어야 하는 경우에 대비하여 대부분이 클러스터 사용을 위해 예약돼 있다. 그러나 이 네임스페이스의 공개적인 성격은 관례일 뿐 요구 사항은 아니다. 아래 명령을 실행해 특정 네임스페이스에 대한 요약 정보를 볼 수 있다. ```shell kubectl get namespaces <name> ``` 자세한 정보를 보는 것도 가능하다. ```shell 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)](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md)를 참조하자. 네임스페이스는 다음 두 상태 중 하나에 있을 수 있다. * `Active` 네임스페이스가 사용 중이다. * `Terminating` 네임스페이스가 삭제 중이므로 새 오브젝트에 사용할 수 없다. 자세한 내용은 API 레퍼런스의 [네임스페이스](/docs/reference/kubernetes-api/cluster-resources/namespace-v1/)를 참조한다. ## 새 네임스페이스 생성하기 {{< note >}} `kube-` 접두사는 쿠버네티스 시스템 네임스페이스로 예약돼 있으므로 이를 사용해 네임스페이스를 생성하지 않도록 한다. {{< /note >}} 1. `my-namespace.yaml`이라는 YAML 파일을 생성하고 아래 내용을 작성한다. ```yaml apiVersion: v1 kind: Namespace metadata: name: <insert-namespace-name-here> ``` 다음 명령을 실행한다. ``` kubectl create -f ./my-namespace.yaml ``` 2. 아래 명령으로 네임스페이스를 생성할 수도 있다. ``` kubectl create namespace <insert-namespace-name-here> ``` 네임스페이스의 이름은 유효한 [DNS 레이블](/docs/concepts/overview/working-with-objects/names#dns-label-names)이어야 한다. 옵션 필드인 `finalizer`는 네임스페이스가 삭제 될 때 관찰자가 리소스를 제거할 수 있도록 한다. 존재하지 않는 파이널라이저(finalizer)를 명시한 경우 네임스페이스는 생성되지만 사용자가 삭제하려 하면 `Terminating` 상태가 된다. 파이널라이저에 대한 자세한 내용은 네임스페이스 [디자인 문서](https://git.k8s.io/design-proposals-archive/architecture/namespaces.md#finalizers)에서 확인할 수 있다. ## 네임스페이스 삭제하기 다음 명령을 실행해 네임스페이스를 삭제한다. ```shell kubectl delete namespaces <insert-some-namespace-name> ``` {{< warning >}} 이렇게 하면 네임스페이스의 _모든 것_ 이 삭제된다! {{< /warning >}} 삭제는 비동기적이므로 삭제 후 한동안은 네임스페이스의 상태가 `Terminating`으로 보일 것이다. ## 쿠버네티스 네임스페이스를 사용해 클러스터 세분화하기 1. 기본 네임스페이스 이해하기 기본적으로 쿠버네티스 클러스터는 클러스터에서 사용할 기본 파드, 서비스, 그리고 디플로이먼트(Deployment) 집합을 가지도록 클러스터를 프로비저닝 할 때 기본 네임스페이스를 인스턴스화한다. 새 클러스터가 있다고 가정하고 아래 명령을 수행하면 사용 가능한 네임스페이스를 볼 수 있다. ```shell kubectl get namespaces ``` ``` NAME      STATUS    AGE default   Active    13m ``` 2. 새 네임스페이스 생성하기 이 예제에서는 내용을 저장할 쿠버네티스 네임스페이스를 추가로 두 개 생성할 것이다. 개발과 프로덕션 유스케이스에서 공유 쿠버네티스 클러스터를 사용하는 조직이 있다고 가정하자. 개발 팀은 애플리케이션을 구축하고 실행하는데 사용하는 파드, 서비스, 디플로이먼트의 목록을 볼 수 있는 공간을 클러스터에 유지하려 한다. 이 공간에서는 쿠버네티스 리소스가 자유롭게 추가 및 제거되고, 누가 리소스를 수정할 수 있는지 없는지에 대한 제약이 완화돼 빠른 개발이 가능해진다. 운영 팀은 운영 사이트를 실행하는 파드, 서비스, 디플로이먼트 집합을 조작할 수 있는 사람과 그렇지 않은 사람들에 대해 엄격한 절차를 적용할 수 있는 공간을 클러스터에 유지하려 한다. 이 조직이 따를 수 있는 한 가지 패턴은 쿠버네티스 클러스터를 `development(개발)`와 `production(운영)`이라는 두 개의 네임스페이스로 분할하는 것이다. 우리의 작업을 보존하기 위해 새로운 네임스페이스 두 개를 만들자. kubectl을 사용해 `development` 네임스페이스를 생성한다. ```shell kubectl create -f https://k8s.io/examples/admin/namespace-dev.json ``` 그런 다음 kubectl을 사용해 `production` 네임스페이스를 생성한다. ```shell kubectl create -f https://k8s.io/examples/admin/namespace-prod.json ``` 제대로 생성이 되었는지 확인하기 위해 클러스터 내의 모든 네임스페이스를 나열한다. ```shell kubectl get namespaces --show-labels ``` ``` NAME          STATUS    AGE       LABELS default       Active    32m       <none> development   Active    29s       name=development production    Active    23s       name=production ``` 3. 네임스페이스마다 파드 생성 쿠버네티스 네임스페이스는 클러스터의 파드, 서비스 그리고 디플로이먼트의 범위를 제공한다. 하나의 네임스페이스와 상호 작용하는 사용자는 다른 네임스페이스의 내용을 볼 수 없다. 이를 보여주기 위해 `development` 네임스페이스에서 간단히 디플로이먼트와 파드를 생성하자. ```shell kubectl create deployment snowflake --image=k8s.gcr.io/serve_hostname  -n=development --replicas=2 ``` 호스트 이름을 제공하는 기본 컨테이너로 `snowflake`라는 이름의 파드를 실행하는 레플리카 사이즈 2의 디플로이먼트를 생성했다. ```shell kubectl get deployment -n=development ``` ``` NAME         READY   UP-TO-DATE   AVAILABLE   AGE snowflake    2/2     2            2           2m ``` ```shell 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` 네임스페이스는 비어있어야 하며 아래 명령은 아무 것도 반환하지 않아야 한다. ```shell kubectl get deployment -n=production kubectl get pods -n=production ``` 프로덕션은 마치 가축을 키우는 것과 같다. 그래서 우리도 cattle(가축)이라는 이름의 파드들을 생성하도록 하겠다. ```shell kubectl create deployment cattle --image=k8s.gcr.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 ``` ```shell 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 ``` 지금 쯤이면 사용자가 한 네임스페이스에 생성한 리소스는 다른 네임스페이스에서 숨겨져 있어야 한다는 것을 잘 알고 있을 것이다. 쿠버네티스 정책 지원이 발전함에 따라, 이 시나리오를 확장해 각 네임스페이스에 서로 다른 인증 규칙을 제공하는 방법을 보이도록 하겠다. <!-- discussion --> ## 네임스페이스의 사용 동기 이해하기 단일 클러스터는 여러 사용자 및 사용자 그룹(이하 '사용자 커뮤니티')의 요구를 충족시킬 수 있어야 한다. 쿠버네티스 _네임스페이스_ 는 여러 프로젝트, 팀 또는 고객이 쿠버네티스 클러스터를 공유할 수 있도록 지원한다. 이를 위해 다음을 제공한다. 1. [이름](/ko/docs/concepts/overview/working-with-objects/names/)에 대한 범위 2. 인증과 정책을 클러스터의 하위 섹션에 연결하는 메커니즘 여러 개의 네임스페이스를 사용하는 것은 선택 사항이다. 각 사용자 커뮤니티는 다른 커뮤니티와 격리된 상태로 작업할 수 있기를 원한다. 각 사용자 커뮤니티는 다음을 가진다. 1. 리소스 (파드, 서비스, 레플리케이션 컨트롤러(replication controller) 등 2. 정책 (커뮤니티에서 조치를 수행할 수 있거나 없는 사람) 3. 제약 조건 (해당 커뮤니티에서는 어느 정도의 쿼터가 허용되는지 등) 클러스터 운영자는 각 사용자 커뮤니티 마다 네임스페이스를 생성할 수 있다. 네임스페이스는 다음을 위한 고유한 범위를 제공한다. 1. (기본 명명 충돌을 방지하기 위해) 명명된 리소스 2. 신뢰할 수 있는 사용자에게 관리 권한 위임 3. 커뮤니티 리소스 소비를 제한하는 기능 유스케이스는 다음을 포함한다. 1.  클러스터 운영자로서 단일 클러스터에서 여러 사용자 커뮤니티를 지원하려 한다. 2.  클러스터 운영자로서 클러스터 분할에 대한 권한을 해당 커뮤니티의 신뢰할 수 있는 사용자에게 위임하려 한다. 3.  클러스터 운영자로서 클러스터를 사용하는 다른 커뮤니티에 미치는 영향을 제한하기 위해 각 커뮤니티가 사용할 수 있는 리소스의 양을 제한하고자 한다. 4.  클러스터 사용자로서 다른 사용자 커뮤니티가 클러스터에서 수행하는 작업과는 별도로 사용자 커뮤니티와 관련된 리소스와 상호 작용하고 싶다. ## 네임스페이스와 DNS 이해하기 [서비스](/ko/docs/concepts/services-networking/service/)를 생성하면 상응하는 [DNS 엔트리(entry)](/ko/docs/concepts/services-networking/dns-pod-service/)가 생성된다. 이 엔트리는 `<서비스-이름><네임스페이스=이름>.svc.cluster.local` 형식을 갖는데, 컨테이너가 `<서비스-이름>`만 갖는 경우에는 네임스페이스에 국한된 서비스로 연결된다. 이 기능은 개발, 스테이징 및 프로덕션과 같이 여러 네임스페이스 내에서 동일한 설정을 사용할 때 유용하다. 네임스페이스를 넘어서 접근하려면 전체 주소 도메인 이름(FQDN)을 사용해야 한다. ## {{% heading "whatsnext" %}} * [네임스페이스 선호(preference)](/ko/docs/concepts/overview/working-with-objects/namespaces/#선호하는-네임스페이스-설정하기)에 대해 자세히 알아보기. * [요청(request)에 대한 네임스페이스 설정](/ko/docs/concepts/overview/working-with-objects/namespaces/#요청에-네임스페이스-설정하기)에 대해 자세히 알아보기. * [네임스페이스 설계](https://git.k8s.io/design-proposals-archive/architecture/namespaces.md) 참조하기. </ins>

Discussion:
This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Translate into Korean. link: Why is this needed It has not been translated into Korean yet. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ko /assign
Thanks ! :) /triage accepted
Resolved by (→ ) ( → ) /close
Closing this issue. <detailsIn response to : Resolved by (→ ) ( → ) Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details