add ko pages

2020-06-01 09:09:39 -04:00
parent 283572af58
commit 6bfc167c79
168 changed files with 1360 additions and 1190 deletions
@@ -1,13 +1,13 @@
 ---
 title: 쿠버네티스 컴포넌트
-content_template: templates/concept
+content_type: concept
 weight: 20
 card:
  name: concepts
  weight: 20
 ---

-{{% capture overview %}}
+<!-- overview -->
 쿠버네티스를 배포하면 클러스터를 얻는다.
 {{< glossary_definition term_id="cluster" length="all" prepend="쿠버네티스 클러스터는">}}

@@ -18,9 +18,9 @@ card:

 ![쿠버네티스의 컴포넌트](/images/docs/components-of-kubernetes.png)

-{{% /capture %}}

-{{% capture body %}}
+
+<!-- body -->
 ## 컨트롤 플레인 컴포넌트

 컨트롤 플레인 컴포넌트는 클러스터에 관한 전반적인 결정(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(예를 들어, 디플로이먼트의 `replicas` 필드에 대한 요구 조건이 충족되지 않을 경우 새로운 {{< glossary_tooltip text="파드" term_id="pod">}}를 구동시키는 것)를 감지하고 반응한다.
@@ -118,10 +118,11 @@ kube-controller-manager와 마찬가지로 cloud-controller-manager는 논리적
 [클러스터-레벨 로깅](/docs/concepts/cluster-administration/logging/) 메커니즘은
 검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 진다.

-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
 * [노드](/ko/docs/concepts/architecture/nodes/)에 대해 더 배우기
 * [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 더 배우기
 * [kube-scheduler](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 더 배우기
 * etcd의 공식 [문서](https://etcd.io/docs/) 읽기
-{{% /capture %}}
+
@@ -1,13 +1,13 @@
 ---
 title: 쿠버네티스 API
-content_template: templates/concept
+content_type: concept
 weight: 30
 card:
  name: concepts
  weight: 30
 ---

-{{% capture overview %}}
+<!-- overview -->

 전체 API 관례는 [API conventions doc](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)에 기술되어 있다.

@@ -21,10 +21,10 @@ API에 원격 접속하는 방법은 [Controlling API Access doc](/docs/referenc

 쿠버네티스 자체는 여러 컴포넌트로 나뉘어져서 각각의 API를 통해 상호작용한다.

-{{% /capture %}}


-{{% capture body %}}
+
+<!-- body -->

 ## API 변경

@@ -137,4 +137,4 @@ API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명

 {{< note >}}개별 리소스의 활성화/비활성화는 레거시 문제로 `extensions/v1beta1` API 그룹에서만 지원된다. {{< /note >}}

-{{% /capture %}}
+
@@ -2,18 +2,18 @@
 title: 쿠버네티스란 무엇인가?
 description: >
  쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식할 수 있고, 확장 가능한 오픈소스 플랫폼으로, 선언적 구성과 자동화를 모두 지원한다. 쿠버네티스는 크고 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 지원 그리고 도구들은 광범위하게 제공된다.
-content_template: templates/concept
+content_type: concept
 weight: 10
 card:
  name: concepts
  weight: 10
 ---

-{{% capture overview %}}
+<!-- overview -->
 이 페이지에서는 쿠버네티스 개요를 설명한다.
-{{% /capture %}}

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

 쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 프로덕션 워크로드를 대규모로 운영하는 [15년 이상의 구글 경험](/blog/2015/04/borg-predecessor-to-kubernetes/)과 커뮤니티의 최고의 아이디어와 적용 사례가 결합되어 있다.
@@ -83,9 +83,10 @@ card:
 * 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다.
 * 추가로, 쿠버네티스는 단순한 오케스트레이션 시스템이 아니다. 사실, 쿠버네티스는 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도한 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.

-{{% /capture %}}

-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
 *   [쿠버네티스 구성요소](/ko/docs/concepts/overview/components/) 살펴보기
 *   [시작하기](/ko/docs/setup/) 준비가 되었는가?
-{{% /capture %}}
+
@@ -1,15 +1,15 @@
 ---
 title: 어노테이션
-content_template: templates/concept
+content_type: concept
 weight: 50
 ---

-{{% capture overview %}}
+<!-- overview -->
 쿠버네티스 어노테이션을 사용하여 임의의 비-식별 메타데이터를
 오브젝트에 첨부할 수 있다. 도구 및 라이브러리와 같은 클라이언트는 이 메타데이터를 검색할 수 있다.
-{{% /capture %}}

-{{% capture body %}}
+
+<!-- body -->
 ## 오브젝트에 메타데이터 첨부

 레이블이나 어노테이션을 사용하여 쿠버네티스
@@ -88,10 +88,11 @@ spec:

 ```

-{{% /capture %}}

-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
 [레이블과 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)에 대해 알아본다.
-{{% /capture %}}
+


@@ -1,17 +1,17 @@
 ---
 title: 권장 레이블
-content_template: templates/concept
+content_type: concept
 ---

-{{% capture overview %}}
+<!-- overview -->
 kubectl과 대시보드와 같은 많은 도구들로 쿠버네티스 오브젝트를 시각화 하고 관리할 수 있다.
 공통 레이블 셋은 모든 도구들이 이해할 수 있는 공통의 방식으로 오브젝트를 식별하고
 도구들이 상호 운용적으로 작동할 수 있도록 한다.

 권장 레이블은 지원 도구 외에도 쿼리하는 방식으로 애플리케이션을 식별하게 한다.
-{{% /capture %}}

-{{% capture body %}}
+
+<!-- body -->
 메타데이터는 _애플리케이션_ 의 개념을 중심으로 정리된다.
 쿠버네티스는 플랫폼 서비스(PaaS)가 아니며 애플리케이션에 대해 공식적인 개념이 없거나 강요하지 않는다.
 대신 애플리케이션은 비공식적이며 메타데이터로 설명된다.
@@ -166,4 +166,4 @@ metadata:

 MySQL `StatefulSet` 과 `Service` 로 MySQL과 WordPress가 더 큰 범위의 애플리케이션에 포함되어 있는 것을 알게 된다.

-{{% /capture %}}
+
@@ -1,17 +1,17 @@
 ---
 title: 쿠버네티스 오브젝트 이해하기
-content_template: templates/concept
+content_type: concept
 weight: 10
 card:
  name: concepts
  weight: 40
 ---

-{{% capture overview %}}
+<!-- overview -->
 이 페이지에서는 쿠버네티스 오브젝트가 쿠버네티스 API에서 어떻게 표현되고, 그 오브젝트를 어떻게 `.yaml` 형식으로 표현할 수 있는지에 대해 설명한다.
-{{% /capture %}}

-{{% capture body %}}
+
+<!-- body -->
 ## 쿠버네티스 오브젝트 이해하기 {#kubernetes-objects}

 *쿠버네티스 오브젝트* 는 쿠버네티스 시스템에서 영속성을 가지는 개체이다. 쿠버네티스는 클러스터의 상태를 나타내기 위해 이 개체를 이용한다. 구체적으로 말하자면, 다음을 기술할 수 있다.
@@ -86,10 +86,11 @@ deployment.apps/nginx-deployment created
 에서 확인할 수 있고, 디플로이먼트에 대한 `spec` 포맷은 
 [DeploymentSpec v1 apps](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)에서 확인할 수 있다.

-{{% /capture %}}

-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
 * API 개념의 더 많은 설명은 [Kubernetes API 개요](/ko/docs/reference/using-api/api-overview/)를 본다.
 * [파드(Pod)](/ko/docs/concepts/workloads/pods/pod-overview/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다.
 * 쿠버네티스의 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 배운다.
-{{% /capture %}}
+
@@ -1,10 +1,10 @@
 ---
 title: 레이블과 셀렉터
-content_template: templates/concept
+content_type: concept
 weight: 40
 ---

-{{% capture overview %}}
+<!-- overview -->

 _레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이다.
 레이블은 오브젝트의 특성을 식별하는 데 사용되어 사용자에게 중요하지만, 코어 시스템에 직접적인 의미는 없다.
@@ -22,10 +22,10 @@ _레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이

 레이블은 UI와 CLI에서 효율적인 쿼리를 사용하고 검색에 사용하기에 적합하다. 식별되지 않는 정보는 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)으로 기록해야 한다.

-{{% /capture %}}


-{{% capture body %}}
+
+<!-- body -->

 ## 사용 동기

@@ -225,4 +225,4 @@ selector:
 레이블을 통해 선택하는 사용 사례 중 하나는 파드를 스케줄 할 수 있는 노드 셋을 제한하는 것이다.
 자세한 내용은 [노드 선택](/ko/docs/concepts/scheduling-eviction/assign-pod-node/) 문서를 참조한다.

-{{% /capture %}}
+
@@ -1,10 +1,10 @@
 ---
 title: 오브젝트 이름과 ID
-content_template: templates/concept
+content_type: concept
 weight: 20
 ---

-{{% capture overview %}}
+<!-- overview -->

 클러스터의 각 오브젝트는 해당 유형의 리소스에 대하여 고유한 [_이름_](#names) 을 가지고 있다.
 또한, 모든 쿠버네티스 오브젝트는 전체 클러스터에 걸쳐 고유한 [_UID_](#uids) 를 가지고 있다.
@@ -13,10 +13,10 @@ weight: 20

 유일하지 않은 사용자 제공 속성의 경우 쿠버네티스는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)과 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)을 제공한다.

-{{% /capture %}}


-{{% capture body %}}
+
+<!-- body -->

 ## 이름 {#names}

@@ -79,8 +79,9 @@ spec:
 쿠버네티스 UID는 보편적으로 고유한 식별자이다(또는 UUID라고 한다).
 UUID는 ISO/IEC 9834-8 과 ITU-T X.667 로 표준화 되어 있다.

-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
 * 쿠버네티스의 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)에 대해 읽기.
 * [쿠버네티스의 식별자와 이름](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) 디자인 문서 읽기.
-{{% /capture %}}
+
@@ -1,18 +1,18 @@
 ---
 title: 네임스페이스
-content_template: templates/concept
+content_type: concept
 weight: 30
 ---

-{{% capture overview %}}
+<!-- overview -->

 쿠버네티스는 동일한 물리 클러스터를 기반으로 하는 여러 가상 클러스터를 지원한다.
 이런 가상 클러스터를 네임스페이스라고 한다.

-{{% /capture %}}


-{{% capture body %}}
+
+<!-- body -->

 ## 여러 개의 네임스페이스를 사용하는 경우

@@ -108,11 +108,12 @@ kubectl api-resources --namespaced=true
 kubectl api-resources --namespaced=false
 ```

-{{% /capture %}}

-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
 * [신규 네임스페이스 생성](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)에 대해 더 배우기.
 * [네임스페이스 삭제](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)에 대해 더 배우기.

-{{% /capture %}}
+

@@ -1,17 +1,17 @@
 ---
 title: 쿠버네티스 오브젝트 관리
-content_template: templates/concept
+content_type: concept
 weight: 15
 ---

-{{% capture overview %}}
+<!-- overview -->
 `kubectl` 커맨드라인 툴은 쿠버네티스 오브젝트를 생성하고 관리하기 위한
 몇 가지 상이한 방법을 지원한다. 이 문서는 여러가지 접근법에 대한 개요을
 제공한다. Kubectl로 오브젝트 관리하기에 대한 자세한 설명은 
 [Kubectl 서적](https://kubectl.docs.kubernetes.io)에서 확인한다.
-{{% /capture %}}

-{{% capture body %}}
+
+<!-- body -->

 ## 관리 기법

@@ -174,9 +174,10 @@ kubectl apply -R -f configs/
 - 선언형 오브젝트 구성은 예상치 못한 결과를 디버깅하고 이해하기가 더 어렵다.
 - diff를 사용한 부분 업데이트는 복잡한 병합 및 패치 작업을 일으킨다.

-{{% /capture %}}

-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
 - [명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/)
 - [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기(명령형)](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/)
 - [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
@@ -187,4 +188,4 @@ kubectl apply -R -f configs/

 {{< comment >}}
 {{< /comment >}}
-{{% /capture %}}
+