Update outdated files in dev-1.14-ko.2 partly-concepts-contribute-ref (…

…#13890)

content/ko/docs/concepts/configuration/scheduler-perf-tuning.md

@@ -6,7 +6,7 @@ weight: 70
 
 {{% capture overview %}}
 
-{{< feature-state for_k8s_version="1.12" >}}
+{{< feature-state for_k8s_version="1.14" state="beta" >}}
 
 Kube-scheduler는 쿠버네티스의 기본 스케줄러이다. 그것은 클러스터의 
 노드에 파드를 배치하는 역할을 한다. 파드의 스케줄링 요건을 충족하는 
@@ -24,16 +24,24 @@ API 서버에 해당 결정을 통지한다.
 
 쿠버네티스 1.12 이전 버전에서, Kube-scheduler는 클러스터의 모든 노드에 
 대한 적합성(feasibility)을 확인한 후에 적합한 노드들에 대해서 점수를 측정했다. 
-쿠버네티스 1.12는 새로운 특징을 가지고 있으며, 이 특징은 스케줄러가 특정 
+쿠버네티스 1.12는 새로운 특징을 추가했으며, 이 특징은 스케줄러가 특정 
 숫자의 적합한 노드를 찾은 이후에 추가적인 적합 노드를 찾는 것을 중단하게 한다. 
 이것은 대규모 클러스터에서 스케줄러 성능을 향상시킨다. 해당 숫자는 클러스터 
-크기에 대한 비율로 지정되며 `percentageOfNodesToScore` 구성 옵션으로 
-제어된다. 값의 범위는 1과 100 사이여야 한다. 그 이외의 값은 100%로 간주한다. 
-이 옵션의 기본 값은 50%이다. 클러스터 관리자는 이 값은 스케줄러 구성에 다른 
-값을 지정함으로써 기본 값을 변경할 수 있다. 그러나, 이 값을 변경할 필요는 없을 것이다.
+크기에 대한 비율로 지정된다. 그 비율은 `percentageOfNodesToScore` 구성 
+옵션으로 제어될 수 있다. 값의 범위는 1과 100 사이여야 한다. 더 높은 값은 
+100%로 간주된다. 0은 구성 옵션을 제공하지 않는 것과 동일하다. 
+점수를 측정할 노드의 비율이 구성 옵션에 명시되지 않은 경우를 대비하여, 쿠버네티스 1.14는 
+클러스터의 크기에 기반하여 해당 비율 값을 찾는 로직을 가지고 있다. 이 로직은 
+100-노드 클러스터에 대해 50%를 값으로 출력하는 선형 공식을 사용한다. 해당 공식은 5000-노드 
+클러스터에 대해서는 10%를 값으로 출력한다. 자동으로 지정되는 값의 하한값은 5%이다. 다시 
+말해, 사용자가 구성 옵션에 5 보다 낮은 값은 지정하지 않은 한, 스케줄러는 
+클러스터의 크기와 무관하게 적어도 5%의 클러스터에 대해서는 항상 점수를 
+측정한다. 
+
+아래는 `percentageOfNodesToScore`를 50%로 설정하는 구성 예제이다.
 
 ```yaml
-apiVersion: componentconfig/v1alpha1
+apiVersion: kubescheduler.config.k8s.io/v1alpha1
 kind: KubeSchedulerConfiguration
 algorithmSource:
   provider: DefaultProvider
@@ -43,40 +51,36 @@ algorithmSource:
 percentageOfNodesToScore: 50
 ```
 
-{{< note >}}
-클러스터에서 적합한 노드가 0 또는 50 미만인 경우, 
-스케줄러는 여전히 모든 노드를 확인한다. 이는 스케줄러가 탐색을 조기 
-중단하기에는 적합한 노드의 수가 충분하지 않기 때문이다.
-{{< /note >}}
+{{< note >}} 클러스터에서 적합한 노드가 50 미만인 경우, 스케줄러는 여전히 
+모든 노드를 확인한다. 그 이유는 스케줄러가 탐색을 조기 중단하기에는 적합한 
+노드의 수가 충분하지 않기 때문이다. {{< /note >}}
 
 **이 특징을 비활성화하려면**, `percentageOfNodesToScore`를 100으로 지정한다.
 
 ### percentageOfNodesToScore 튜닝
 
 `percentageOfNodesToScore`는 1과 100 사이의 값이어야하며 
-기본 값은 50이다. 또한 50%의 노드로 하드 코딩된 최소 값이 내부적으로 
-적용된다. 스케줄러는 `percentageOfNodesToScore` 값과 상관없이 
-적어도 50%의 노드 탐색을 수행한다. 이는 수백 개 정도의 노드가 있는 
+기본 값은 클러스터 크기에 따라 계산된다. 또한 50 노드로 하드 코딩된 
+최소 값도 있다. 이는 수백 개 정도의 노드가 있는 
 클러스터에서는 해당 옵션을 더 낮은 값으로 변경하더라도 스케줄러가 
-찾으려는 적합한 노드의 개수에는 크게 영향을 주지 않는다는 
-뜻이다. 이것은 규모가 작은 클러스터에서는 이 옵션의 조정이 성능을 
-눈에 띄게 향상시키지 않는 것을 감안하여 의도적으로 설계되었다. 1000 노드 
-이상의 큰 규모의 클러스터에서는 이 값을 낮은 수로 설정하면 눈에 띄는 성능 
-향상을 보일 수도 있다.
+찾으려는 적합한 노드의 개수에는 크게 영향을 주지 않는다는 뜻이다. 
+이것은 규모가 작은 클러스터에서는 이 옵션의 조정이 성능을 눈에 띄게 향상시키지 않는 
+것을 감안하여 의도적으로 설계되었다. 1000 노드 이상의 큰 규모의 클러스터에서는 이 값을 
+낮은 수로 설정하면 눈에 띄는 성능 향상을 보일 수도 있다.
 
 이 값을 세팅할 때 중요하게 고려해야 할 사항은, 클러스터에서 
 적은 수의 노드에 대해서만 적합성을 확인하면, 주어진 파드에 대해서
 일부 노드의 점수는 측정이되지 않는다는 것이다. 결과적으로, 주어진 파드를 실행하는데 
 가장 높은 점수를 가질 가능성이 있는 노드가 점수 측정 단계로 조차 넘어가지 
 않을 수 있다. 이것은 파드의 이상적인 배치보다 낮은 결과를 초래할 것이다.
-그 이유로, 이 값은 너무 낮은 비율로 설정되면 안 된다. 대략의 경험적 법칙은 30 이하의 
+그 이유로, 이 값은 너무 낮은 비율로 설정되면 안 된다. 대략의 경험적 법칙은 10 이하의 
 값으로는 설정하지 않는 것이다. 더 낮은 값은 사용자의 애플리케이션에서 스케줄러의 
 처리량이 치명적이고 노드의 점수가 중요하지 않을 경우에만 사용해야 한다. 다시 말해서, 파드의 
 실행에 적합하기만 하다면 어느 노드가 선택되어도 사용자에게 상관없는 경우를 말한다.
 
-만약 사용자의 클러스터가 단지 백여 개의 노드를 가지고 있는 경우 기본 값보다 낮은 값으로의 
-변경을 추천하지 않는다. 그것은 스케줄러의 성능을 
-크게 향상시키지 않을 것이다.
+만약 사용자의 클러스터가 단지 백여 개 또는 더 적은 노드를 가지고 있는 경우, 이 구성 옵션의 
+기본 값보다 낮은 값으로의 변경을 추천하지 않는다. 그것이 스케줄러의 성능을 크게 
+향상시키지는 않을 것이다.
 
 ### 스케줄러가 노드 탐색을 반복(iterate)하는 방법
 

content/ko/docs/concepts/overview/kubernetes-api.md

@@ -9,7 +9,7 @@ card:
 
 {{% capture overview %}}
 
-전체 API 관례는 [API conventions doc](https://git.k8s.io/community/contributors/devel/api-conventions.md)에 기술되어 있다.
+전체 API 관례는 [API conventions doc](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)에 기술되어 있다.
 
 API 엔드포인트, 리소스 타입과 샘플은 [API Reference](/docs/reference)에 기술되어 있다.
 
@@ -32,7 +32,7 @@ API에 원격 접속하는 방법은 [Controlling API Access doc](/docs/referenc
 
 경험에 따르면, 성공적인 시스템은 새로운 유스케이스의 등장과 기존의 유스케이스의 변경에 맞춰 성장하고 변경될 필요가 있다. 그래서, 쿠버네티스 API가 지속적으로 변경되고 성장하기를 바란다. 그러나, 일정 기간 동안은 현존하는 클라이언트와의 호환성을 깨지 않으려고 한다. 일반적으로, 새로운 API 리소스와 새로운 리소스 필드가 주기적으로 추가될 것이다. 리소스나 필드를 없애는 일은 다음의 [API deprecation policy](/docs/reference/using-api/deprecation-policy/)를 따른다.
 
-호환되는 변경에 어떤 내용이 포함되는지, 어떻게 API를 변경하는지에 대한 자세한 내용은 [API change document](https://git.k8s.io/community/contributors/devel/api_changes.md)에 있다.
+호환되는 변경에 어떤 내용이 포함되는지, 어떻게 API를 변경하는지에 대한 자세한 내용은 [API change document](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md)에 있다.
 
 ## OpenAPI 및 Swagger 정의
 
@@ -67,12 +67,12 @@ GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github
 필드를 없애거나 리소스 표현을 재구성하기 쉽도록, 쿠버네티스는 `/api/v1`이나 
 `/apis/extensions/v1beta1`과 같이 각각 다른 API 경로에서 복수의 API 버전을 지원한다.
 
-리소스나 필드 수준보다는 API 수준에서 버전을 선택했는데, API가 명료하고, 시스템 리소스와 행위 관점에서 일관성있으며, 더 이상 사용하지 않는 API나 실험적인 API에 접근을 제어할 수 있도록 하기 위함이다. 스키마 변경에 대해서 JSON과 Protobuf 직렬화 스키마 모두 동일한 가이드라인을 따른다. 다음에 이어지는 설명 모두는 이 두 가지 형식에 모두 해당한다.
+리소스나 필드 수준보다는 API 수준에서 버전을 선택했는데, API가 명료하고, 시스템 리소스와 행위 관점에서 일관성있으며, 더 이상 사용되지 않는 API나 실험적인 API에 접근을 제어할 수 있도록 하기 위함이다. 스키마 변경에 대해서 JSON과 Protobuf 직렬화 스키마 모두 동일한 가이드라인을 따른다. 다음에 이어지는 설명 모두는 이 두 가지 형식에 모두 해당한다.
 
 API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관되어 있음을 알아두자. [API and release versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는 API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다.
 
 
-API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르다는 것을 암시한다. 각각의 수준에 대한 조건은 [API Changes documentation](https://git.k8s.io/community/contributors/devel/api_changes.md#alpha-beta-and-stable-versions)에서 상세히 다룬다. 요약하자면 다음과 같다.
+API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르다는 것을 암시한다. 각각의 수준에 대한 조건은 [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서 상세히 다룬다. 요약하자면 다음과 같다.
 
 - 알파(Alpha) 수준:
   - 버전 이름에 `alpha`가 포함된다. (예: `v1alpha1`)

content/ko/docs/concepts/overview/object-management-kubectl/overview.md

@@ -7,7 +7,8 @@ weight: 10
 {{% capture overview %}}
 `kubectl` 커맨드라인 툴은 쿠버네티스 오브젝트를 생성하고 관리하기 위한
 몇 가지 상이한 방법을 지원한다. 이 문서는 여러가지 접근법에 대한 개요을
-제공한다.
+제공한다. Kubectl으로 오브젝트 관리하기에 대한 자세한 설명은 
+[Kubectl 서적](https://kubectl.docs.kubernetes.io)에서 확인한다.
 {{% /capture %}}
 
 {{% capture body %}}
@@ -179,6 +180,7 @@ kubectl apply -R -f configs/
 - [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기 (명령형)](/docs/concepts/overview/object-management-kubectl/imperative-config/)
 - [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기 (선언형)](/docs/concepts/overview/object-management-kubectl/declarative-config/)
 - [Kubectl 명령어 참조](/docs/reference/generated/kubectl/kubectl-commands/)
+- [Kubectl 서적](https://kubectl.docs.kubernetes.io)
 - [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
 
 {{< comment >}}

content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md

@@ -41,7 +41,7 @@ card:
 
 {{< codenew file="application/deployment.yaml" >}}
 
-위 예시와 같이 .yaml 파일을 이용하여 디플로이먼트를 생성하기 위한 하나의 방식으로는 `kubectl` 커맨드-라인 인터페이스에 인자값으로 `.yaml` 파일를 건네 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 명령을 이용하는 것이다. 다음 예시와 같다.
+위 예시와 같이 .yaml 파일을 이용하여 디플로이먼트를 생성하기 위한 하나의 방식으로는 `kubectl` 커맨드-라인 인터페이스에 인자값으로 `.yaml` 파일를 건네 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 커맨드를 이용하는 것이다. 다음 예시와 같다.
 
 
 ```shell

content/ko/docs/concepts/workloads/pods/pod-lifecycle.md

@@ -183,7 +183,7 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 두 가지
 
 ## 파드의 준비성 게이트(readiness gate)
 
-{{< feature-state for_k8s_version="v1.12" state="beta" >}}
+{{< feature-state for_k8s_version="v1.14" state="stable" >}}
 
 파드의 준비성에 대한 확장성을 추가하기 위해서 
 추가적인 피드백이나 신호를 `PodStatus`에 주입하는 방법인, 

content/ko/docs/concepts/workloads/pods/pod-overview.md

@@ -106,5 +106,5 @@ spec:
 {{% capture whatsnext %}}
 * 파드의 다른 동작들을 더 배워보자.
   * [파드 종료](/docs/concepts/workloads/pods/pod/#termination-of-pods)
-  * [파드 라이프사이클](../pod-lifecycle)
+  * [파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)
 {{% /capture %}}

content/ko/docs/contribute/_index.md

@@ -47,7 +47,7 @@ weight: 80
 시작하는 데에 도움이 될 것이다.
 
 - [누구나](/docs/contribute/start/)
-  - 조치 가능한 버그 리포트 제출
+  - 조치 가능한 이슈 열기
 - [멤버](/docs/contribute/start/)
   - 기존 문서 개선
   - [Slack](http://slack.k8s.io/) 또는 [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에서 개선을 위한 아이디어 제시

content/ko/docs/reference/_index.md

@@ -16,29 +16,29 @@ content_template: templates/concept
 
 ## API 레퍼런스
 
-* [Kubernetes API Overview](/docs/reference/using-api/api-overview/) - 쿠버네티스 API에 대한 개요
+* [쿠버네티스 API 개요](/docs/reference/using-api/api-overview/) - 쿠버네티스 API에 대한 개요
 * 쿠버네티스 API 버전
+  * [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](https://v1-10.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/)
-  * [1.9](https://v1-9.docs.kubernetes.io/docs/api-reference/v1.9/)
+  * [1.10](/docs/reference/generated/kubernetes-api/v1.10/)
 
 ## API 클라이언트 라이브러리
 
 프로그래밍 언어에서 쿠버네티스 API를 호출하기 위해서, 
-[client libraries](/docs/reference/using-api/client-libraries/)를 사용할 수 있다. 
+[클라이언트 라이브러리](/docs/reference/using-api/client-libraries/)를 사용할 수 있다. 
 공식적으로 지원되는 클라이언트 라이브러리는 다음과 같다.
 
-- [Kubernetes Go client library](https://github.com/kubernetes/client-go/)
-- [Kubernetes Python client library](https://github.com/kubernetes-client/python)
-- [Kubernetes Java client library](https://github.com/kubernetes-client/java)
-- [Kubernetes JavaScript client library](https://github.com/kubernetes-client/javascript)
+- [쿠버네티스 Go 클라이언트 라이브러리](https://github.com/kubernetes/client-go/)
+- [쿠버네티스 Python 클라이언트 라이브러리](https://github.com/kubernetes-client/python)
+- [쿠버네티스 Java 클라이언트 라이브러리](https://github.com/kubernetes-client/java)
+- [쿠버네티스 JavaScript 클라이언트 라이브러리](https://github.com/kubernetes-client/javascript)
 
 ## CLI 레퍼런스
 
 * [kubectl](/docs/user-guide/kubectl-overview) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구.
-    * [JSONPath](/docs/user-guide/jsonpath/) - kubectl에서 [JSONPath expressions](http://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드.
+    * [JSONPath](/docs/user-guide/jsonpath/) - kubectl에서 [JSONPath 표현](http://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드.
 * [kubeadm](/docs/admin/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구.
 * [kubefed](/docs/admin/kubefed/) - 연합된(federated) 클러스터 관리를 도와주는 CLI 도구.
 
@@ -54,6 +54,6 @@ content_template: templates/concept
 
 ## 설계 문서
 
-쿠버네티스 기능에 대한 설계 문서의 아카이브. [Kubernetes Architecture](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md)와 [Kubernetes Design Overview](https://git.k8s.io/community/contributors/design-proposals)가 좋은 출발점이다.
+쿠버네티스 기능에 대한 설계 문서의 아카이브. [쿠버네티스 아키텍처](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md)와 [쿠버네티스 디자인 개요](https://git.k8s.io/community/contributors/design-proposals)가 좋은 출발점이다.
 
 {{% /capture %}}

content/ko/docs/reference/glossary/taint.md

@@ -4,14 +4,14 @@ id: taint
 date: 2019-01-11
 full_link: /docs/concepts/configuration/taint-and-toleration/
 short_description: >
-  파드가 노드나 노드 그룹에 스케줄링되는 것을 방지하는 키-값 쌍 및 효과이다.
+  세 가지 필수 속성: 키(key), 값(value), 효과(effect)로 구성된 코어 오브젝트. 테인트는 파드가 노드나 노드 그룹에 스케줄링되는 것을 방지한다.
 
 aka:
 tags:
 - core-object
 - fundamental
 ---
- 파드가 노드나 노드 그룹에 스케줄링되는 것을 방지하는 키-값 쌍 및 효과이다.
+ 세 가지 필수 속성: 키(key), 값(value), 효과(effect)로 구성된 코어 오브젝트. 테인트는 파드가 노드나 노드 그룹에 스케줄링되는 것을 방지한다.
 
 <!--more-->
 

content/ko/docs/reference/glossary/toleration.md

@@ -4,15 +4,15 @@ id: toleration
 date: 2019-01-11
 full_link: /docs/concepts/configuration/taint-and-toleration/
 short_description: >
-  매칭되는 테인트(taint)를 가진 노드나 노드 그룹에 파드가 스케줄링되는 것을 활성화하는 키-값 쌍 및 효과이다.
+  세 가지 필수 속성: 키(key), 값(value), 효과(effect)로 구성된 코어 오브젝트. 톨러레이션은 매칭되는 테인트(taint)를 가진 노드나 노드 그룹에 파드가 스케줄링되는 것을 활성화한다.
 
 aka:
 tags:
 - core-object
 - fundamental
 ---
- 매칭되는 {{< glossary_tooltip text="테인트(taint)" term_id="taint" >}}를 가진 노드나 노드 그룹에 파드가 스케줄링되는 것을 활성화하는 키-값 쌍 및 효과이다.
+ 세 가지 필수 속성: 키(key), 값(value), 효과(effect)로 구성된 코어 오브젝트. 톨러레이션은 매칭되는 {{< glossary_tooltip text="테인트(taints)" term_id="taint" >}}를 가진 노드나 노드 그룹에 파드가 스케줄링되는 것을 활성화한다.
 
 <!--more-->
 
-톨러레이션 및 {{< glossary_tooltip text="테인트" term_id="taint" >}}는 함께 작동하며, 파드가 적절하지 못한 노드에 스케줄되는 것을 방지한다. 하나 이상의 톨러레이션이 {{< glossary_tooltip text="파드" term_id="pod" >}}에 적용될 수 있으며, 이것은 매칭되는 {{< glossary_tooltip text="테인트" term_id="taint" >}}를 가진 노드나 노드 그룹에 파드가 스케줄링되는 것을 허용(그러나 필수는 아님)하도록 표시한다.
+톨러레이션 및 {{< glossary_tooltip text="테인트" term_id="taint" >}}는 함께 작동하며, 파드가 적절하지 못한 노드에 스케줄되는 것을 방지한다. 하나 이상의 톨러레이션이 {{< glossary_tooltip text="파드" term_id="pod" >}}에 적용될 수 있다. 톨러레이션은 매칭되는 {{< glossary_tooltip text="테인트" term_id="taint" >}}를 가진 노드나 노드 그룹에 {{< glossary_tooltip text="파드" term_id="pod" >}}가 스케줄링되는 것을 허용(그러나 필수는 아님)하도록 표시한다.