Third Korean l10n work for release-1.15 (#15744)

* Add Link /docs/reference/ in Korean (#15610) * Translate tasks/debug-application-cluster/resource-usage-monitoring in Korean (#15593) * Translate tasks/inject-data-application/define-environment-variable-container in Korean (#15606) * ko: Update outdated files in dev-1.15-ko.3 (#15605) * Translate home/supported-doc-version in Korean (#15621) * ko: Update some files in reference/glossary (#15631) * Translate reference/glossary/cloud-provider.md in Korean (#15685) * Translate docs/reference/using-api/api-overview in Korean (#15644) * Translate tasks/debug-application-cluster/resource-metrics-pipeline in Korean (#15665) Co-Authored-By: June Yi <june.yi@samsung.com> Co-Authored-By: Seokho <shsongist@gmail.com> Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Yoon <learder@gmail.com> Co-authored-by: JiMyung Lee <lee.ji.myung@gmail.com> Co-authored-by: lapee79 <lapee79@gmail.com> Co-authored-by: Sunghoon Kang <hoon@linecorp.com> Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com> Co-authored-by: Lawrence Kay <me@lkaybob.pe.kr>
2019-08-08 23:33:19 +09:00
parent 05690331ce
commit 4518c983d2
28 changed files with 819 additions and 330 deletions
@@ -16,13 +16,13 @@ content_template: templates/concept

 ## API 레퍼런스

-* [쿠버네티스 API 개요](/docs/reference/using-api/api-overview/) - 쿠버네티스 API에 대한 개요
+* [쿠버네티스 API 개요](/ko/docs/reference/using-api/api-overview/) - 쿠버네티스 API에 대한 개요
 * 쿠버네티스 API 버전
+  * [1.15](/docs/reference/generated/kubernetes-api/v1.15/)
  * [1.14](/docs/reference/generated/kubernetes-api/v1.14/)
  * [1.13](/docs/reference/generated/kubernetes-api/v1.13/)
  * [1.12](/docs/reference/generated/kubernetes-api/v1.12/)
  * [1.11](/docs/reference/generated/kubernetes-api/v1.11/)
-  * [1.10](/docs/reference/generated/kubernetes-api/v1.10/)

 ## API 클라이언트 라이브러리

@@ -0,0 +1,17 @@
+---
+title: 클라우드 공급자
+id: cloud-provider
+date: 2018-04-12
+full_link: /docs/concepts/cluster-administration/cloud-providers
+short_description: >
+  클라우드 공급자는 쿠버네티스 클러스터를 실행할 수 있는 클라우드 컴퓨팅 플랫폼을 제공하는 회사.
+
+aka: 
+tags:
+- community
+---
+ 클라우드 공급자는 쿠버네티스 클러스터를 실행할 수 있는 클라우드 컴퓨팅 플랫폼을 제공하는 회사.
+
+<!--more--> 
+
+클라우드 컴퓨팅 플랫폼을 제공하는 클라우드 공급자 또는 클라우드 서비스 공급자(CSP)라고 한다. 이들은 인프라 서비스(IaaS) 또는 플랫폼 서비스(PaaS)를 제공할 수 있다. 클라우드 공급자는 쿠버네티스 클러스터를 호스트 하며 클러스터와 상호작용하는 로드밸런서, 스토리지 클래스 등의 서비스도 제공한다.
@@ -1,19 +1,17 @@
 ---
 title: 클러스터(Cluster)
 id: cluster
-date: 2018-04-12
+date: 2019-06-15
 full_link: 
 short_description: >
-  쿠버네티스를 통해 관리되는 컨테이너화 된 애플리케이션을 실행하는, 노드라고 불리는 기계의 집합.
+   쿠버네티스에서 관리하는 컨테이너화된 애플리케이션을 실행하는 노드라고 하는 기계의 집합. 클러스터는 최소 1개의 워커 노드와 최소 1개의 마스터 노드를 가진다.

-aka: 
+aka:
 tags:
 - fundamental
 - operation
 ---
- 쿠버네티스를 통해 관리되는 컨테이너화 된 애플리케이션을 실행하는, 노드라고 불리는 기계의 집합.
+쿠버네티스에서 관리하는 컨테이너화된 애플리케이션을 실행하는 노드라고 하는 기계의 집합. 클러스터는 최소 1개의 워커 노드와 최소 1개의 마스터 노드를 가진다.

 <!--more--> 
-
-클러스터는 여러 개의 워커 노드와 적어도 하나의 마스터를 가진다.
-
+워커 노드는 애플리케이션의 구성요소인 파드를 호스트한다. 마스터 노드는 워커 노드와 클러스터 내 파드를 관리한다. 다수의 마스터 노드는 장애극복(failover)과 고가용성의 클러스터에서 사용한다.
@@ -15,7 +15,7 @@ tags:

 <!--more-->

-쿠버네티스느 여러 컨테이너 런타임을 지원한다. [Docker](http://www.docker.com),
+쿠버네티스는 여러 컨테이너 런타임을 지원한다. [Docker](http://www.docker.com),
 [containerd](https://containerd.io), [cri-o](https://cri-o.io/),
 [rktlet](https://github.com/kubernetes-incubator/rktlet)과
 [Kubernetes CRI (컨테이너 런타임 인터페이스)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)를 구현한 모든 소프트웨어.
@@ -1,20 +1,20 @@
 ---
-title: 데몬 셋(DaemonSet)
+title: 데몬셋(DaemonSet)
 id: daemonset
 date: 2018-04-12
 full_link: /docs/concepts/workloads/controllers/daemonset
 short_description: >
-  파드의 복제품이 클러스터의 노드 집합에 걸쳐 동작하는 것을 확실히 한다.
+  파드의 복제본을 클러스터 노드 집합에서 동작하게 한다.

-aka: 
+aka:
 tags:
 - fundamental
 - core-object
 - workload
 ---
- {{< glossary_tooltip text="파드" term_id="pod" >}}의 복제품이 {{< glossary_tooltip text="클러스터" term_id="cluster" >}}의 노드 집합에 걸쳐 동작하는 것을 확실히 한다.
+ {{< glossary_tooltip text="파드" term_id="pod" >}} 복제본을 {{< glossary_tooltip text="클러스터" term_id="cluster" >}} 노드 집합에서 동작하게 한다.

-<!--more--> 
+<!--more-->

-일반적으로 모든 {{< glossary_tooltip text="노드" term_id="node" >}}에서 실행돼야 하는 로그 수집기 및 모니터링 에이전트 등의 시스템 데몬을 디플로이하기 위해서 사용된다.
+일반적으로 모든 {{< glossary_tooltip text="노드" term_id="node" >}}에서 실행돼야 하는 로그 수집기 및 모니터링 에이전트 등의 시스템 데몬을 배포하기 위해서 사용된다.

@@ -4,17 +4,17 @@ id: deployment
 date: 2018-04-12
 full_link: /docs/concepts/workloads/controllers/deployment/
 short_description: >
-  레플리케이션 된 애플리케이션을 관리하는 API 오브젝트.
+  복제된(replicated) 애플리케이션을 관리하는 API 오브젝트.

-aka: 
+aka:
 tags:
 - fundamental
 - core-object
 - workload
 ---
- 레플리케이션 된 애플리케이션을 관리하는 API 오브젝트.
+ 복제된 애플리케이션을 관리하는 API 오브젝트.

-<!--more--> 
+<!--more-->

-각 레플리카는 {{< glossary_tooltip text="파드" term_id="pod" >}}로 표현되며, 각 파드는 클러스터의 노드에 분산된다.
+각 레플리카는 {{< glossary_tooltip text="파드" term_id="pod" >}}로 표현되며, 파드는 클러스터의 노드에 분산된다.

@@ -2,17 +2,17 @@
 title: 초기화 컨테이너(Init Container)
 id: init-container
 date: 2018-04-12
-full_link: 
+full_link:
 short_description: >
-  앱 컨테이너가 동작하기 전에 완료되기 위해 실행되는 하나 이상의 초기화 컨테이너. 
+  앱 컨테이너가 동작하기 전에 완료되기 위해 실행되는 하나 이상의 초기화 컨테이너.

-aka: 
+aka:
 tags:
 - fundamental
 ---
- 앱 컨테이너가 동작하기 전에 완료되기 위해 실행되는 하나 이상의 초기화 컨테이너. 
+ 앱 컨테이너가 동작하기 전에 완료되기 위해 실행되는 하나 이상의 초기화 컨테이너.

-<!--more--> 
+<!--more-->

 한 가지 차이점을 제외하면, 초기화 컨테이너는 일반적인 앱 컨테이너와 동일하다. 초기화 컨테이너는 앱 컨테이너가 시작되기 전에 완료되는 것을 목표로 실행되어야 한다. 초기화 컨테이너는 연달아 실행된다. 다시말해, 각 초기화 컨테이너의 실행은 다음 초기화 컨테이너가 시작되기 전에 완료되어야 한다.

@@ -4,7 +4,7 @@ id: limitrange
 date: 2019-04-15
 full_link:  /docs/concepts/policy/limit-range/
 short_description: >
-  네임스페이스 안의 컨테이너나 파드의 리소스 사용량을 제한하는 제약을 제공한다.
+  네임스페이스 내에 컨테이너나 파드당 리소스 소비를 한정하는 제약 조건을 제공한다.

 aka:
 tags:
@@ -16,8 +16,8 @@ related:
 - container

 ---
-  네임스페이스 안의 {{< glossary_tooltip text="컨테이너" term_id="container" >}}나 {{< glossary_tooltip text="파드" term_id="pod" >}}의 리소스 사용량을 제한하는 제약을 제공한다.
+  네임스페이스 내에 {{< glossary_tooltip text="컨테이너" term_id="container" >}}나 {{< glossary_tooltip text="파드" term_id="pod" >}}당 리소스 소비를 한정하는 제약 조건을 제공한다.

 <!--more-->
-범위 제한은 타입별로 만들 수 있는 객체의 수와
-네임스페이스 안의 개별 {{< glossary_tooltip text="컨테이너" term_id="container" >}}나 {{< glossary_tooltip text="파드" term_id="pod" >}}가 요청하거나 소비한 컴퓨팅 리소스의 양을 제한한다.
+범위 제한은 타입별로 만들 수 있는 오브젝트의 개수와
+네임스페이스 안에 개별 {{< glossary_tooltip text="컨테이너" term_id="container" >}}나 {{< glossary_tooltip text="파드" term_id="pod" >}}가 요청하거나 소비할 컴퓨팅 리소스의 양을 제한한다.
@@ -4,11 +4,11 @@ id: static-pod
 date: 2091-02-12
 full_link: /docs/tasks/administer-cluster/static-pod/
 short_description: >
-  특정 노드의 kubelet 데몬이 직접 관리하는 파드
+  특정 노드의 Kubelet 데몬이 직접 관리하는 파드

 aka:
 tags:
 - fundamental
 ---
- API 서버가 관찰하지 않고, 특정 노드의 kubelet 데몬이
+ API 서버가 관찰하지 않고, 특정 노드의 Kubelet 데몬이
 직접 관리하는 {{< glossary_tooltip text="파드" term_id="pod" >}}.
@@ -344,7 +344,7 @@ Kubectl 로그 상세 레벨(verbosity)은 `-v` 또는`--v` 플래그와 로그

 로그 레벨 | 세부 사항
 --------------| -----------
-`--v=0` | 일반적으로 운영자에게 유용함.
+`--v=0` | 일반적으로 클러스터 운영자(operator)에게 *항상* 보여지게 하기에는 유용함.
 `--v=1` | 자세한 정보를 원하지 않는 경우, 적절한 기본 로그 수준.
 `--v=2` | 서비스와 시스템의 중요한 변화와 관련이있는 중요한 로그 메시지에 대한 유용한 정상 상태 정보. 이는 대부분의 시스템에서 권장되는 기본 로그 수준이다.
 `--v=3` | 변경 사항에 대한 확장 정보.
@@ -0,0 +1,5 @@
+---
+title: 쿠버네티스 API 사용하기
+weight: 10
+toc-hide: true
+---
@@ -0,0 +1,111 @@
+---
+title: 쿠버네티스 API 개요
+content_template: templates/concept
+weight: 10
+card:
+  name: 레퍼런스
+  weight: 50
+  title: API 개요
+---
+
+{{% capture overview %}}
+이 페이지는 쿠버네티스 API에 대한 개요를 제공한다.
+{{% /capture %}}
+
+{{% capture body %}}
+REST API는 쿠버네티스의 근본적인 구조이다. 모든 조작, 컴포넌트 간의 통신과 외부 사용자의 명령은 API 서버에서 처리할 수 있는 REST API 호출이다. 따라서, 쿠버네티스 플랫폼 안의 모든 것은
+API 오브젝트로 취급되고,
+[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)에 상응하는 항목이 있다.
+
+대부분의 작업은 API에 의존하고 있는
+[kubectl](/docs/reference/kubectl/overview/) 커맨드라인 인터페이스 또는
+[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)과 같은 다른 커맨드라인 툴을 통해 수행할 수 있다.
+그러나, REST 호출 사용을 통해서 API에 직접 접근할 수도 있다.
+
+쿠버네티스 API를 사용하는 애플리케이션을 작성하는 경우
+[클라이언트 라이브러리](/docs/reference/using-api/client-libraries/)중 하나의 사용을 고려한다.
+
+## API 버전 규칙
+
+필드를 없애거나 리소스 표현을 재구성하기 쉽도록,
+쿠버네티스는 `/api/v1`이나 `/apis/extensions/v1beta1`과 같이
+각각 다른 API 경로에서 복수의 API 버전을 지원한다.
+
+아래를 위해 버전은 리소스나 필드 수준보다는 API 수준에서 설정된다.
+
+- API가 시스템 리소스와 동작에 대해 명확하고 일관성 있게 표현하는 것을 보장
+- 수명 종료(end-of-life) 또는 실험적인 API 접근 제어 활성화
+
+JSON과 Protobuf 직렬화 스키마 모두 스키마 변경에 대해서 동일한 가이드라인을 따른다. 이후 설명에서는 이 형식 모두를 다룬다.
+
+{{< note >}}
+API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관된다.
+[API와 릴리스 버전 부여에 관한 제안](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는 API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다.
+{{< /note >}}
+
+API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. [API 변경 문서](https://git.k8s.io/community/contributors/devel/api_changes.md#alpha-beta-and-stable-versions)에서 각 수준의 기준에 대한 더 많은 정보를 찾을 수 있다.
+
+아래는 각 수준의 기준에 대한 요약이다.
+
+- 알파(Alpha) 수준:
+  - 버전 이름에 `alpha`가 포함된다. (예: `v1alpha1`)
+  - 버그가 있을 수도 있다. 이 기능을 활성화하면 버그가 노출될 수 있다. 기본적으로 비활성화되어 있다.
+  - 기능에 대한 기술 지원이 언제든 공지 없이 중단될 수 있다.
+  - 다음 소프트웨어를 릴리스할 때 공지 없이 API의 호환성이 깨지는 방식으로 변경될 수 있다.
+  - 버그의 위험이 높고 장기간 지원되지 않으므로 단기간 테스트 용도의 클러스터에서만 사용하기를 권장한다.
+
+- 베타(Beta) 수준:
+  - 버전 이름에 `beta`가 포함된다. (예: `v2beta3`).
+  - 코드가 잘 테스트되었다. 이 기능을 활성화 시켜도 안전하다. 기본적으로 활성화되어 있다.
+  - 구체적인 내용이 바뀔 수는 있지만, 전반적인 기능에 대한 기술 지원이 중단되지 않는다.
+  - 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서 호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우, 다음 버전으로 이관할 수 있는 가이드가 제공된다. 이때 API 오브젝트의 삭제, 편집 또는 재생성이
+    필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다. 이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다.
+  - 이후 여러 버전에서 잠재적으로 호환되지 않을 수도 있으므로 사업적으로 중요하지 않은 용도로만 사용하기를 권장한다. 복수의 클러스터를 가지고 있어서 독립적으로 업그레이드할 수 있다면, 이런 제약에서 안심이 될 수도 있겠다.
+
+ {{< note >}}
+베타 기능을 사용해보고 피드백을 제공하자. 일단 베타가 끝나면, 실질적으로 더 많은 변경이 어렵다.
+ {{< /note >}}
+
+- 안정화(stable) 수준:
+  - 버전 이름이 `vX`이고 `X` 는 정수다.
+  - 안정화 버전의 기능은 이후 여러 버전에 걸쳐서 소프트웨어 릴리스에 포함된다.
+
+## API 그룹
+
+[*API 그룹*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)은 쿠버네티스 API를 더 쉽게 확장하게 해준다. API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명시된다.
+
+현재 다음과 같은 다양한 API 그룹이 사용되고 있다:
+
+*  *핵심* (또는 *레거시*라고 불리는) 그룹은 `apiVersion: v1`와 같이 `apiVersion` 필드에 명시되지 않고 REST 경로 `/api/v1`에 있다.
+*  이름이 있는 그룹은 REST 경로 `/apis/$GROUP_NAME/$VERSION`에 있으며 `apiVersion: $GROUP_NAME/$VERSION`을 사용한다
+   (예를 들어 `apiVersion: batch/v1`).  지원되는 API 그룹 전체의 목록은 [쿠버네티스 API 참조 문서](/docs/reference/)에서 확인할 수 있다.
+
+[사용자 정의 리소스](/docs/concepts/api-extension/custom-resources/)로 API를 확장하는 경우에는 다음 두 종류의 경로가 지원된다.
+
+ - 기본적인 CRUD 요구에는
+   [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)
+ - 쿠버네티스 API의 의미론적 전체 집합으로 사용자만의 Apiserver를 구현하려는 경우에는 [aggregator](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)
+
+
+## API 그룹 활성화 시키기
+
+특정 리소스와 API 그룹은 기본적으로 활성화되어 있다. 이들은 apiserver에서 `--runtime-config`를 설정해서 활성화하거나
+비활성화 시킬 수 있다. `--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어:
+ - batch/v1을 비활성화하려면 `--runtime-config=batch/v1=false`로 설정
+ - batch/v2alpha1을 활성화하려면 `--runtime-config=batch/v2alpha1`로 설정
+이 플래그는 apiserver의 런타임 구성을 설명하는 쉼표로 분리된 키=값 쌍의 집합을 허용한다.
+
+{{< note >}}
+그룹이나 리소스를 활성화 또는 비활성화하려면, apiserver와 controller-manager를 재시작하여
+`--runtime-config` 변경을 반영해야 한다.
+{{< /note >}}
+
+## 그룹 내 리소스 활성화 시키기
+
+데몬셋, 디플로이먼트, HorizontalPodAutoscaler, 인그레스, 잡 및 레플리카셋이 기본적으로 활성화되어 있다.
+다른 확장 리소스는 apiserver의 `--runtime-config`를 설정해서
+활성화할 수 있다. `--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어 디플로이먼트와 잡을 비활성화하려면,
+`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingresses=false`와 같이 설정한다.
+{{% /capture %}}
+
+