diff --git a/content/ko/docs/tasks/administer-cluster/namespaces.md b/content/ko/docs/tasks/administer-cluster/namespaces.md new file mode 100644 index 0000000000000..ebcc640447561 --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/namespaces.md @@ -0,0 +1,319 @@ +--- + + + +title: 네임스페이스를 사용해 클러스터 공유하기 +content_type: task +--- + + +이 페이지는 {{< 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" >}}에 대해 이해하고 있다. + + + + +## 네임스페이스 보기 + +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 +``` + +자세한 정보를 보는 것도 가능하다. + +```shell +kubectl describe namespaces +``` +``` +Name: default +Labels: +Annotations: +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: + ``` + 다음 명령을 실행한다. + + ``` + kubectl create -f ./my-namespace.yaml + ``` + +2. 아래 명령으로 네임스페이스를 생성할 수도 있다. + + ``` + kubectl create namespace + ``` + +네임스페이스의 이름은 +유효한 [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 +``` + +{{< 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 + 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 + ``` + +지금 쯤이면 사용자가 한 네임스페이스에 생성한 리소스는 다른 네임스페이스에서 숨겨져 있어야 한다는 것을 잘 알고 있을 것이다. + +쿠버네티스 정책 지원이 발전함에 따라, 이 시나리오를 확장해 각 네임스페이스에 +서로 다른 인증 규칙을 제공하는 방법을 보이도록 하겠다. + + + + + +## 네임스페이스의 사용 동기 이해하기 + +단일 클러스터는 여러 사용자 및 사용자 그룹(이하 '사용자 커뮤니티')의 요구를 충족시킬 수 있어야 한다. + +쿠버네티스 _네임스페이스_ 는 여러 프로젝트, 팀 또는 고객이 쿠버네티스 클러스터를 공유할 수 있도록 지원한다. + +이를 위해 다음을 제공한다. + +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) 참조하기. + +