Fourth Korean l10n work for release-1.13 (#12242)

* ko-trans: Fix broken page index for concepts/overview (#11533) * ko-trans: Update outdated files in dev-1.13-ko.4 (#11544) * 1. Translate naturally (#11759) 2. Fix markdown error * ko-trans: Translate building-from-source.md (#11893) * ko-trans: Translate building-from-source.md * Address comments * Update etcd.md (#11976) * ko-trans: Translate ko/_index.html into Korean (#11937) * ko-trans: Translate ko/_index.html into Korean. * Reflect a translation comment. Translate ko/_index.html into Korean * ko-trans: Translate online-training/overview.md (#11932) * ko-trans: Translate node-conformance.md (#11907) * ko-trans: Translate node-conformance.md * Replace 명세 with 매니페스트. * Address comments * ko-trans: Translate tutorials/configuration (#11933) * ko-trans: Translate `tutorials/configuration` directory * Address comments * ko-trans: content/ko/docs/reference/glossary/controller.md (#11994) * ko-trans: Controller ko-trans: Controller * the feedback applied. the feedback applied. * minor edit minor edit * minor edit #2 minor edit #2 * ko-trans: reference/glossary/kube-apiserver.md (#12024) ko-trans: reference/glossary/kube-apiserver.md * Translate tutorials/stateless-application/ in Korean (#12008) * Translate tutorials/stateless-application/ in Korean * Apply comments * Fix deployment related typos * Translate content/ko/docs/concepts/architecture/nodes in Korean #11748 (#11850) * Translate content/ko/docs/concepts/architecture/nodes in Korean #11748 * Translate content/ko/docs/concepts/architecture/nodes in Korean #11748 * Translate content/ko/docs/concepts/architecture/nodes in Korean #11748 * Translate concepts/workloads/pods/pod-lifecycle in Korean (#12054) * Translate concepts/workloads/pods/pod-lifecycle in Korean * apply review ko-translate concepts/.../pod-lifecycle * ko-trans: kube-controller-manager.md (#12077) ko-trans: docs/reference/glossary/kube-controller-manager.md * fix Italic syntax markdown error (#12128) * Translate tasks/_index.md in Korean (#12126) * Translate tasks/_index.md in Korean * Apply review for Translate tasks/_index.md in Korean Apply comments for Translate tasks/_index.md in Korean * Translate setup/_index.md in Korean (#12067) * Translate setup/_index.md in Korean * Update setup/_index.md for Korean term consistency * ko-trans: docs/setup/custom-cloud/kops.md (#11904) * ko-trans: concepts/overview/working-with-objects/names (#11758) * ko-trans: /docs/concepts/overview/working-with-objects/namespaces.md (#11773) * Translate setup/cri.md in Korean (#12174) * Translate setup/cri.md in Korean * Apply review, Translate setup/cri.md in Korean * Translate tasks/tools/install-minikube in Korean (#12176) * Translate tasks/tools/install-minikube in Korean * Apply review,Trans tasks/tools/install-minikube in KO
2019-01-16 20:31:18 +09:00
parent 0f6457d5df
commit 848a46a3b7
62 changed files with 2274 additions and 263 deletions
@@ -0,0 +1,5 @@
+---
+title: "개요"
+weight: 20
+---
+
@@ -9,13 +9,13 @@ weight: 10
 {{% /capture %}}

 {{% capture body %}}
-쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 
-확장가능한 오픈소스 플랫폼이다. 쿠버네티스는 선언적 구성과 자동화를 모두 
+쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고,
+확장가능한 오픈소스 플랫폼이다. 쿠버네티스는 선언적 구성과 자동화를 모두
 용이하게 해준다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있다.
 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다.

-구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 [구글의 
-15여년에 걸친 대규모 운영 워크로드 운영 
+구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 [구글의
+15여년에 걸친 대규모 운영 워크로드 운영
 경험](https://research.google.com/pubs/pub43438.html)을 기반으로 만들어졌으며
 커뮤니티의 최고의 아이디어와 적용 사례가 결합되었다.

@@ -28,32 +28,32 @@ weight: 10
 - 이식성 있는 클라우드 플랫폼
 그리고 더 많은 기능.

-쿠버네티스는 **컨테이너 중심의** 관리 환경을 제공한다. 이 환경은 사용자 
-워크로드를 위해서 컴퓨팅, 네트워킹 및 스토리지 인프라스트럭처를 
-오케스트레이션한다. 이는 Platform as a Service(PaaS)의 매우 단순명료함에 
-Infrastructure as a Service (IaaS)의 유연함을 더해 주며, 인프라스트럭처 
+쿠버네티스는 **컨테이너 중심의** 관리 환경을 제공한다. 이 환경은 사용자
+워크로드를 위해서 컴퓨팅, 네트워킹 및 스토리지 인프라스트럭처를
+오케스트레이션한다. 이는 Platform as a Service(PaaS)의 매우 단순명료함에
+Infrastructure as a Service (IaaS)의 유연함을 더해 주며, 인프라스트럭처
 제공자 간 이식이 가능하게 해준다.

 ## 어떻게 쿠버네티스가 플랫폼이 될 수 있는가?

 쿠버네티스가 제공하는 많은 기능이 있지만, 신규 기능을 통해 혜택을 얻을 수 있는
 새로운 시나리오는 항상 있게 마련이다. 개발자의 생산성을 극대화할 수 있도록
-애플리케이션에 특화된 워크플로우를 최적화할 수 있다. 초기에 수용 가능한 애드혹 
-오케스트레이션은 대규모의 견고한 자동화를 필요로 하곤 한다. 이것이 쿠버네티스가 
-애플리케이션을 더 쉽게 배포하고, 스케일링하며, 관리하는 컴포넌트와 툴의 생태계를 
+애플리케이션에 특화된 워크플로우를 최적화할 수 있다. 초기에 수용 가능한 애드혹
+오케스트레이션은 대규모의 견고한 자동화를 필요로 하곤 한다. 이것이 쿠버네티스가
+애플리케이션을 더 쉽게 배포하고, 스케일링하며, 관리하는 컴포넌트와 툴의 생태계를
 만드는 플랫폼의 기능을 하도록 설계된 이유이다.

 [레이블](/docs/concepts/overview/working-with-objects/labels/)은 사용자가 원하는
-방식대로 자원을 정리할 수 있도록 해준다. 
+방식대로 자원을 정리할 수 있도록 해준다.
 [어노테이션](/docs/concepts/overview/working-with-objects/annotations/)은
-자원에 사용자 정의 정보를 추가해서 사용자의 워크플로우에 활용할 수 있도록 하고 
+자원에 사용자 정의 정보를 추가해서 사용자의 워크플로우에 활용할 수 있도록 하고
 관리 툴이 상태를 쉽게 체크할 수 있는 방법을 제공해 준다.

-추가로, [쿠버네티스 컨트롤 플레인](/docs/concepts/overview/components/)은 
-개발자와 사용자가 공통으로 사용할 수 있는 [API](/docs/reference/using-api/api-overview/)를 
-기반으로 하고 있다. 사용자는 범용의 [명령줄 도구]((/docs/user-guide/kubectl-overview/))를 
-대상으로 하는 [자체 API](/docs/concepts/api-extension/custom-resources/)를 가진 
-[스케줄러](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md)와 
+추가로, [쿠버네티스 컨트롤 플레인](/docs/concepts/overview/components/)은
+개발자와 사용자가 공통으로 사용할 수 있는 [API](/docs/reference/using-api/api-overview/)를
+기반으로 하고 있다. 사용자는 범용의 [명령줄 도구]((/docs/user-guide/kubectl-overview/))를
+대상으로 하는 [자체 API](/docs/concepts/api-extension/custom-resources/)를 가진
+[스케줄러](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md)와
 같은 사용자만의 컨트롤러를 작성할 수 있다.

 이 [설계](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md)를 통해
@@ -63,39 +63,39 @@ Infrastructure as a Service (IaaS)의 유연함을 더해 주며, 인프라스

 쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가
 아니다. 쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에,
-PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱, 로깅 및 모니터링과 
+PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱, 로깅 및 모니터링과
 같은 기능에서 공통점이 있기도 하다. 하지만, 쿠버네티스는 모놀리식(monolithic)하지
-않아서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는 
-개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 
+않아서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는
+개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과
 유연성을 지켜준다.

 쿠버네티스는

 * 지원하는 애플리케이션의 유형을 제약하지 않는다. 쿠버네티스는
  상태 유지가 필요 없는(stateless) 워크로드, 상태 유지가 필요한(stateful) 워크로드,
-  데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 
+  데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는
  것을 목표로 한다. 애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서
  매우 잘 동작할 것이다.
 * 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다.
  지속적인 통합, 지속적인 배포(Delivery, Deployment)(CI/CD) 워크플로우는
  기술적인 요구사항은 물론 조직 문화와 취향에 따라 결정된다.
 * 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, mysql),
-  캐시 또는 클러스터 스토리지 시스템(예, Ceph)와 같은 애플리케이션 레벨의 서비스를 
-  제공하지 않는다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 
+  캐시 또는 클러스터 스토리지 시스템(예, Ceph)와 같은 애플리케이션 레벨의 서비스를
+  제공하지 않는다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서
  구동 중인 애플리케이션이 Open Service Broker와 같은 이식 가능한 메커니즘을 통해 접근할
  수도 있다.
 * 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나,
  메트릭을 수집하고 노출하는 메커니즘을 제공한다.
-* 기본 설정 언어/시스템(예, [jsonnet](https://github.com/google/jsonnet))을 제공하거나 
+* 기본 설정 언어/시스템(예, [jsonnet](https://github.com/google/jsonnet))을 제공하거나
  요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다.
 * 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다.

-추가로, 쿠버네티스는 단순한 *오케스트레이션 시스템*이 아니다. 사실,
-쿠버네티스는 오케스트레이션의 필요성을 없애준다. *오케스트레이션*의
-기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 
-수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 
-있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도된 상태로 나아가도록 한다. 
-A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 
+추가로, 쿠버네티스는 단순한 *오케스트레이션 시스템* 이 아니다. 사실,
+쿠버네티스는 오케스트레이션의 필요성을 없애준다. *오케스트레이션* 의
+기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를
+수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어
+있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도된 상태로 나아가도록 한다.
+A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이
 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.

 ## 왜 컨테이너인가?
@@ -104,32 +104,32 @@ A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필

 ![Why Containers?](/images/docs/why_containers.svg)

-애플리케이션을 배포하는 *구식의 방법*은 운영 체제의 패키지 관리자를 
-사용해서 애플리케이션을 호스트에 설치하는 것이었다. 이 방식은 
-애플리케이션의 실행 파일, 설정, 라이브러리 서로 간의 라이프사이클과 
-호스트 OS와 얽히게 된다는 단점이 있다. 예측 가능한 롤아웃과 롤백을 
-위해서 불변의 가상 머신 이미지를 만들 수도 있지만, VM은 너무 크고 
+애플리케이션을 배포하는 *구식의 방법* 은 운영 체제의 패키지 관리자를
+사용해서 애플리케이션을 호스트에 설치하는 것이었다. 이 방식은
+애플리케이션의 실행 파일, 설정, 라이브러리 서로 간의 라이프사이클과
+호스트 OS와 얽히게 된다는 단점이 있다. 예측 가능한 롤아웃과 롤백을
+위해서 불변의 가상 머신 이미지를 만들 수도 있지만, VM은 너무 크고
 이식 가능하지 않다.

-*새로운 방법*은 하드웨어 가상화가 아닌 운영 체제 수준의 가상화에 기반한 
+*새로운 방법* 은 하드웨어 가상화가 아닌 운영 체제 수준의 가상화에 기반한
 컨테이너를 배포하는 것이다. 이 컨테이너는 서로 격리되고 호스트와도
 격리된다. 컨테이너는 컨테이너 자체의 파일시스템을 갖고, 다른 컨테이너의
 프로세스를 알 수 없으며, 연산에 필요한 자원을 제한할 수 있다. VM보다
 빌드하기 쉬우며, 기반이 되는 인프라스트럭처와 호스트 파일시스템에서
 디커플되었기(decoupled) 때문에 클라우드나 OS 배포판 간 이식성이 있다.

-컨테이너는 작고 빠르기 때문에, 애플리케이션 각각을 컨테이너 이미지로 
-패키지할 수 있다. 이렇게 애플리케이션과 이미지를 일대일 관계를 갖도록 
-하면 컨테이너의 혜택을 만끽할 수 있게 된다. 불변의 컨테이너 이미지는 
-배포 시점이 아닌 빌드/릴리스 시점에 만들어질 수 있다. 왜냐하면 각각의 
-애플리케이션은 애플리케이션 스택 외의 나머지 요소와 조합될 필요가 없기 
-때문이고, 운영 인프라스트럭처 환경에 밀접하게 결합시킬 필요도 없기 
-때문이다. 컨테이너 이미지를 빌드/릴리스 시점에 생성하게 되면 개발 
+컨테이너는 작고 빠르기 때문에, 애플리케이션 각각을 컨테이너 이미지로
+패키지할 수 있다. 이렇게 애플리케이션과 이미지를 일대일 관계를 갖도록
+하면 컨테이너의 혜택을 만끽할 수 있게 된다. 불변의 컨테이너 이미지는
+배포 시점이 아닌 빌드/릴리스 시점에 만들어질 수 있다. 왜냐하면 각각의
+애플리케이션은 애플리케이션 스택 외의 나머지 요소와 조합될 필요가 없기
+때문이고, 운영 인프라스트럭처 환경에 밀접하게 결합시킬 필요도 없기
+때문이다. 컨테이너 이미지를 빌드/릴리스 시점에 생성하게 되면 개발
 환경부터 운영 환경까지 일관된 환경을 가져갈 수 있게 된다. 마찬가지로,
 컨테이너는 VM보다 훨씬 더 투명해서 모니터링과 관리가 용이하다.
-컨테이너의 프로세스 라이프사이클이 수퍼바이저 프로세스에 의해 컨테이너 
-내에 감추어지지 않고, 인프라스트럭처에 의해 관리될 때 더욱 이는 
-용이해진다. 컨테이너마다 단일 애플리케이션을 담게되면, 궁극적으로 
+컨테이너의 프로세스 라이프사이클이 수퍼바이저 프로세스에 의해 컨테이너
+내에 감추어지지 않고, 인프라스트럭처에 의해 관리될 때 더욱 이는
+용이해진다. 컨테이너마다 단일 애플리케이션을 담게되면, 궁극적으로
 컨테이너를 관리하는 것이 애플리케이션의 배포를 관리하는 것과 같아진다.

 컨테이너의 혜택 요약:
@@ -140,7 +140,7 @@ A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필
    안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고
    (이미지의 불변성 덕에) 빠르고 쉽게 롤백할 수 있다.
 * **개발과 운영의 관심사 분리**:
-    배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 
+    배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를
    만들기 때문에, 애플리케이션이 인프라스트럭처에서 디커플된다.
 * **가시성**
    OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와
@@ -150,11 +150,11 @@ A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필
 * **클라우드 및 OS 배포판 간 이식성**:
    Ubuntu, RHEL, CoreOS, on-prem, Google Kubernetes Engine 및 다른 어디에서든 구동된다.
 * **애플리케이션 중심 관리**:
-    가상 하드웨어의 OS에서 애플리케이션을 구동하는 수준에서 OS의 
-    논리적인 자원을 사용하여 애플리케이션을 구동하는 수준으로 추상화 
+    가상 하드웨어의 OS에서 애플리케이션을 구동하는 수준에서 OS의
+    논리적인 자원을 사용하여 애플리케이션을 구동하는 수준으로 추상화
    수준이 높아진다.
 * **느슨하게 커플되고, 분산되고, 유연하며, 자유로운 [마이크로서비스](https://martinfowler.com/articles/microservices.html)**:
-    애플리케이션은 단일 목적의 머신에서 비대한 모놀리식 스택으로 
+    애플리케이션은 단일 목적의 머신에서 모놀리식 스택으로
    구동되지 않고 보다 작고 독립적인 단위로 쪼개져서 동적으로 배포되고
    관리될 수 있다.
 * **자원 격리**:
@@ -164,9 +164,9 @@ A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필

 ## 쿠버네티스(Kubernetes)의 뜻은? K8s?

-**쿠버네티스**는 *키잡이*나 *파일럿*을 뜻하는 그리스어에서 유래했으며,
-이는 *governor*(통치자)와 [cybernetic(인공두뇌학)](http://www.etymonline.com/index.php?term=cybernetics)의 
-어원이다. *K8s*는 "ubernete" 8 글자를 "8"로 대체한 약어이다.
+**쿠버네티스**는 *키잡이* 나 *파일럿* 을 뜻하는 그리스어에서 유래했으며,
+이는 *governor*(통치자)와 [cybernetic(인공두뇌학)](http://www.etymonline.com/index.php?term=cybernetics)의
+어원이다. *K8s* 는 "ubernete" 8 글자를 "8"로 대체한 약어이다.

 {{% /capture %}}

@@ -174,5 +174,3 @@ A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필
 *   [시작할](/docs/setup/) 준비가 되었는가?
 *   보다 자세한 내용은 [쿠버네티스 문서](/ko/docs/home/)를 참조한다.
 {{% /capture %}}
-
-
@@ -0,0 +1,30 @@
+---
+title: 이름(Name)
+content_template: templates/concept
+weight: 20
+---
+
+{{% capture overview %}}
+
+쿠버네티스 REST API의 모든 오브젝트는 이름과 UID로 명백히 식별된다.
+
+유일하지 않은 사용자 제공 속성에 대해서, 쿠버네티스는 [레이블](/docs/user-guide/labels)과 [어노테이션](/docs/concepts/overview/working-with-objects/annotations/)을 제공한다.
+
+이름과 UID에 대한 정확한 구문 규칙은 [식별자 설계 문서](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)를 참고한다.
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+## Names
+
+{{< glossary_definition term_id="name" length="all" >}}
+
+관례에 따라, 쿠버네티스 리소스의 이름은 최대 253자까지 허용되고 소문자 알파벳과 숫자(alphanumeric), `-`, 그리고 `.`로 구성되며 특정 리소스는 보다 구체적인 제약을 갖는다.
+
+## UIDs
+
+{{< glossary_definition term_id="uid" length="all" >}}
+
+{{% /capture %}}
@@ -0,0 +1,105 @@
+---
+title: 네임스페이스
+content_template: templates/concept
+weight: 30
+---
+
+{{% capture overview %}}
+
+쿠버네티스는 동일 물리 클러스터를 기반으로 하는 복수의 가상 클러스터를 지원한다.
+이들 가상 클러스터를 네임스페이스라고 한다.
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+## 복수의 네임스페이스를 사용하는 경우
+
+네임스페이스는 복수의 팀이나, 프로젝트에 걸쳐서 많은 사용자가 있는 환경에서 사용하도록
+만들어졌다. 사용자가 거의 없거나, 수 십명 정도가 되는 경우에는, 네임스페이스를 고려할 
+필요가 전혀 없다. 네임스페이스가 제공하는 기능이 필요할 때 사용하도록 하자.
+
+네임스페이스는 이름의 범위를 제공한다. 리소스의 이름은 네임스페이스 내에서 유일해야하지만, 네임스페이스를 통틀어서 유일할 필요는 없다.
+
+네임스페이스는 클러스터 자원을 ([리소스 쿼터](/docs/concepts/policy/resource-quotas/)를 통해) 복수의 사용자 사이에서 나누는 방법이다.
+
+다음 버전의 쿠버네티스에서는, 같은 네임스페이스의 오브젝트는 기본적을 동일한 접근 
+제어 정책을 갖게 된다.
+
+같은 소프트웨어의 다른 버전과 같이 단지 약간의 차이가 있는 리소스를 분리하기 위해서 
+복수의 네임스페이스를 사용할 필요가 있다. 동일한 네임스페이스에 있는 리소스를 
+구분하기 위해서는 [레이블](/docs/user-guide/labels)을 사용한다.
+
+## 네임스페이스 다루기
+
+네임스페이스의 생성과 삭제는 [네임스페이스 관리자 가이드 문서](/docs/admin/namespace)에 
+기술되어 있다.
+
+### 네임스페이스 조회
+
+사용중인 클러스터의 현재 네임스페이스를 나열할 수 있다.
+
+```shell
+$ kubectl get namespaces
+NAME          STATUS    AGE
+default       Active    1d
+kube-system   Active    1d
+kube-public   Active    1d
+```
+
+쿠버네티스는 처음에 세 개의 초기 네임스페이스를 갖는다.
+
+   * `default` 다른 네임스페이스가 없는 오브젝트를 위한 기본 네임스페이스
+   * `kube-system` 쿠버네티스 시스템에서 생성한 오브젝트를 위한 네임스페이스
+   * `kube-public` 이 네임스페이스는 자동으로 생성되며 모든 사용자(인증되지 않은 사용자 포함)가 읽기 권한으로 접근할 수 있다. 이 네임스페이스는 주로 전체 클러스터 중에 공개적으로 드러나서 읽을 수 있는 리소스를 위해 예약되어 있다. 이 네임스페이스의 공개적인 성격은 단지 관례이지 요구 사항은 아니다.
+
+### 요청에 네임스페이스 설정하기
+
+임시로 네임스페이스를 요청에 설정하기 위해서는, `--namespace` 플래그를 사용한다.
+
+예를 들면,
+
+```shell
+$ kubectl --namespace=<insert-namespace-name-here> run nginx --image=nginx
+$ kubectl --namespace=<insert-namespace-name-here> get pods
+```
+
+### 선호하는 네임스페이스 설정하기
+
+이후 모든 kubectl 명령에서 사용될 네임스페이스를 컨텍스트에 영구적으로 저장할 수 있다.
+
+```shell
+$ kubectl config set-context $(kubectl config current-context) --namespace=<insert-namespace-name-here>
+# 확인하기
+$ kubectl config view | grep namespace:
+```
+
+## 네임스페이스와 DNS
+
+[서비스](/docs/user-guide/services)를 생성하면, 대응되는 
+[DNS 엔트리](/docs/concepts/services-networking/dns-pod-service/)가 생성된다.
+이 엔트리는 `<서비스-이름>.<네임스페이스-이름>.svc.cluster.local`의 형식을 갖는데,
+이는 컨테이너가 `<서비스-이름>`만 사용하는 경우, 네임스페이스 내에 국한된 서비스로
+연결된다. 개발, 스테이징, 운영과 같이 여러 네임스페이스 내에서 동일한 설정을 
+사용하는 경우에 유용하다. 네임스페이스를 넘어서 접근하기 위해서는, 전체 주소 도메인 
+이름(FQDN)을 사용해야 한다.
+
+## 모든 오브젝트가 네임스페이스에 속하지는 않음
+
+대부분의 쿠버네티스 리소스(예를 들어, 파드, 서비스, 레플리케이션 컨트롤러 외)는 
+네임스페이스에 속한다. 하지만 네임스페이스 리소스 자체는 네임스페이스에 속하지 않는다.
+그리고 [nodes](/docs/admin/node)나 퍼시스턴트 볼륨과 같은 저수준 리소스는 어느
+네임스페이스에도 속하지 않는다.
+
+네임스페이스에 속하지 않는 쿠버네티스 리소스를 조회하기 위해서는,
+
+```shell
+# 네임스페이스에 속하는 리소스
+$ kubectl api-resources --namespaced=true
+
+# 네임스페이스에 속하지 않는 리소스
+$ kubectl api-resources --namespaced=false
+```
+
+{{% /capture %}}