Fourth Korean localization work for release-1.14

This commit is the fourth Korean l10n work for release-1.14. Change List * Translate concepts/overview/object-management-kubectl/declarative-config in Korean (#14285) * translate cron-jobs.md to korean + add _index.md (#14024) * ko: update outdated files in dev-1.14-ko.4 #14207 (#14347) * Translate standardized glossary Tag Workload in Korean (#14208) * translate to content/ko/docs/concepts/cluster-administration/controll… (#14234) * ko: update concepts, contribute, tasks in dev-1.14-ko.4 #14207 (#14502) * ko: update cheatsheet in dev-1.14-ko.4 (#14515) Co-Authored-By: Seokho <[email protected]> Co-Authored-By: Yoon <[email protected]> Co-Authored-By: Woojin Na(Eddie) <[email protected]> Co-Authored-By: Kim Young Dae <[email protected]> Co-Authored-by: June Yi <[email protected]> Co-Authored-by: Claudia J. Kang <[email protected]>
kubernetes · May 28, 2019 · e326e58 · e326e58
1 parent 1054269
commit e326e58
Show file tree

Hide file tree

Showing 25 changed files with 1,723 additions and 383 deletions.
diff --git a/content/ko/docs/concepts/_index.md b/content/ko/docs/concepts/_index.md
@@ -15,11 +15,11 @@ weight: 40
 
 ## 개요
 
-쿠버네티스를 사용하려면, *쿠버네티스 API 오브젝트로* 클러스터에 대해 사용자가 *바라는 상태를* 기술해야 한다. 어떤 애플리케이션이나 워크로드를 구동시키려고 하는지, 어떤 컨테이너 이미지를 쓰는지, 복제의 수는 몇 개인지, 어떤 네트워크와 디스크 자원을 쓸 수 있도록 할 것인지 등을 의미한다. 바라는 상태를 설정하는 방법은 쿠버네티스 API를 사용해서 오브젝트를 만드는 것인데, 대개 `kubectl`이라는 커맨드라인 인터페이스를 사용한다. 클러스터와 상호 작용하고 바라는 상태를 설정하거나 수정하기 위해서 쿠버네티스 API를 직접 사용할 수도 있다.
+쿠버네티스를 사용하려면, *쿠버네티스 API 오브젝트* 로 클러스터에 대해 사용자가 *바라는 상태* 를 기술해야 한다. 어떤 애플리케이션이나 워크로드를 구동시키려고 하는지, 어떤 컨테이너 이미지를 쓰는지, 복제의 수는 몇 개인지, 어떤 네트워크와 디스크 자원을 쓸 수 있도록 할 것인지 등을 의미한다. 바라는 상태를 설정하는 방법은 쿠버네티스 API를 사용해서 오브젝트를 만드는 것인데, 대개 `kubectl`이라는 커맨드라인 인터페이스를 사용한다. 클러스터와 상호 작용하고 바라는 상태를 설정하거나 수정하기 위해서 쿠버네티스 API를 직접 사용할 수도 있다.
 
-일단 바라는 상태를 설정하고 나면, *쿠버네티스 컨트롤 플레인*이 Pod Lifecycle Event Generator (PLEG) 를 사용하여 클러스터의 현재 상태를 바라는 상태와 일치시키기 위한 일을 하게 된다. 그렇게 함으로써, 쿠버네티스가 컨테이너를 시작 또는 재시작 시키거나, 주어진 애플리케이션의 복제 수를 스케일링하는 등의 다양한 작업을 자동으로 수행할 수 있게 된다. 쿠버네티스 컨트롤 플레인은 클러스터에서 돌아가는 프로세스의 집합으로 구성된다.
+바라는 상태를 설정하면, *쿠버네티스 컨트롤 플레인* 은 Pod Lifecycle Event Generator (PLEG) 를 통해 클러스터의 현재 상태를 바라는 상태와 일치시킨다. 그렇게 함으로써, 쿠버네티스가 컨테이너를 시작 또는 재시작하거나, 주어진 애플리케이션의 복제 수를 스케일링하는 등의 다양한 작업을 자동으로 수행한다. 쿠버네티스 컨트롤 플레인은 클러스터에서 실행 중인 프로세스의 묶음(collection)으로 구성된다.
 
-* **쿠버네티스 마스터**는 클러스터 내 마스터 노드로 지정된 노드 내에서 구동되는 세 개의 프로세스 집합이다. 해당 프로세스는 [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) 및 [kube-scheduler](/docs/admin/kube-scheduler/)이다.
+* **쿠버네티스 마스터**는 클러스터 내 마스터 노드로 지정된 노드 내에서 구동되는 세 개의 프로세스 묶음이다. 해당 프로세스는 [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) 및 [kube-scheduler](/docs/admin/kube-scheduler/)이다.
 * 클러스터 내 마스터 노드가 아닌 각각의 노드는 다음 두 개의 프로세스를 구동시킨다.
   * 쿠버네티스 마스터와 통신하는 **[kubelet](/docs/admin/kubelet/)**.
   * 각 노드의 쿠버네티스 네트워킹 서비스를 반영하는 네트워크 프록시인 **[kube-proxy](/docs/admin/kube-proxy/)**.
@@ -53,7 +53,7 @@ weight: 40
 
 클러스터에 대해 바라는 상태를 유지할 책임은 쿠버네티스 마스터에 있다. `kubectl` 커맨드라인 인터페이스와 같은 것을 사용해서 쿠버네티스로 상호 작용할 때에는 쿠버네티스 마스터와 통신하고 있는 셈이다.
 
-> "마스터"는 클러스터 상태를 관리하는 프로세스의 집합이다. 주로 이 프로세스는 클러스터 내 단일 노드에서 구동되며, 이 노드가 바로 마스터이다. 마스터는 가용성과 중복을 위해 복제될 수도 있다.
+> "마스터"는 클러스터 상태를 관리하는 프로세스의 묶음이다. 주로 이 프로세스는 클러스터 내 단일 노드에서 구동되며, 이 노드가 바로 마스터이다. 마스터는 가용성과 중복을 위해 복제될 수도 있다.
 
 ### 쿠버네티스 노드
 
@@ -68,7 +68,8 @@ weight: 40
 
 {{% capture whatsnext %}}
 
-개념 페이지를 작성하기를 원하면, 개념 페이지 유형과 개념 템플릿에 대한 정보가 있는
+개념 페이지를 작성하기를 원하면,
+개념 페이지 유형과 개념 템플릿에 대한 정보가 있는
 [페이지 템플릿 사용하기](/docs/home/contribute/page-templates/)를 참조한다.
 
 {{% /capture %}}
diff --git a/content/ko/docs/concepts/cluster-administration/controller-metrics.md b/content/ko/docs/concepts/cluster-administration/controller-metrics.md
@@ -0,0 +1,48 @@
+---
+title: 컨트롤러 관리자 메트릭
+content_template: templates/concept
+weight: 100
+---
+
+{{% capture overview %}}
+컨트롤러 관리자 메트릭은 컨트롤러 관리자의 성능과 상태에 대한
+중요한 통찰을 제공한다.
+
+{{% /capture %}}
+
+{{% capture body %}}
+## 컨트롤러 관리자 메트릭은 무엇인가
+
+컨트롤러 관리자 메트릭은 컨트롤러 관리자의 성능과 상태에 대한 중요한 통찰을 제공한다.
+메트릭은 go_routine count와 같은 일반적인 Go 언어 런타임 메트릭과 
+etcd 요청 대기 시간 또는 클라우드 제공자(AWS, GCE, OpenStack) API 대기 시간과 같이 클러스터 상태를
+측정할 수 있는 컨트롤러 특징적 메트릭을 포함한다.
+
+쿠버네티스 1.7 부터, GCE, AWS, Vsphere 그리고 OpenStack의 저장소 작업에 대한 자세한 클라우드 제공자 메트릭을 사용할 수 있다.
+이 메트릭은 영구 볼륨 작업의 상태 감시에 사용될 수 있다.
+
+예를 들어, GCE의 경우 다음과 같은 메트릭이 호출된다:
+
+```
+cloudprovider_gce_api_request_duration_seconds { request = "instance_list"}
+cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"}
+cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"}
+cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"}
+cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
+cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
+```
+
+
+
+## 구성
+
+
+클러스터에서 컨트롤러-관리자 메트릭은 컨트롤러-관리자가 실행되고 있는 호스트의 `http://localhost:10252/metrics`를 통해서
+이용 가능하다.
+
+메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)에서 나오고, 사람이 읽을 수 있다.
+
+운영 환경에서는 주기적으로 메트릭을 모으고, 일종의 시계열 데이터베이스로 만들기 위해,
+프로메테우스 설정이나 다른 메트릭 수집기를 구성할 것이다.
+
+{{% /capture %}}
diff --git a/content/ko/docs/concepts/overview/components.md b/content/ko/docs/concepts/overview/components.md
@@ -16,7 +16,7 @@ card:
 ## 마스터 컴포넌트
 
 마스터 컴포넌트는 클러스터의 컨트롤 플레인을 제공한다. 마스터 컴포넌트는 클러스터에 관한 전반적인 결정
-(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(레플리케이션 컨트롤러의 '레플리카' 필드가 요구조건을 충족되지 않을 경우 새로운 파드를 구동 시키는 것)를 감지하고 반응한다.
+(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(레플리케이션 컨트롤러의 `replicas` 필드가 요구조건을 충족되지 않을 경우 새로운 파드를 구동 시키는 것)를 감지하고 반응한다.
 
 마스터 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작 될 수 있다. 그러나,
 간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 마스터 컴포넌트를 구동시키고,
@@ -72,19 +72,21 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드
 
 ### kube-proxy
 
-[kube-proxy](/docs/admin/kube-proxy/)는 호스트 상에서 네트워크 규칙을 유지하고 연결에 대한 포워딩을 수행함으로서 쿠버네티스 서비스 추상화가 가능하도록 해준다.
+[kube-proxy](/docs/admin/kube-proxy/)는 호스트 상에서 네트워크 규칙을 유지하고 연결에 대한 포워딩을 수행함으로서
+ 쿠버네티스 서비스 추상화가 가능하도록 해준다.
 
 ### 컨테이너 런타임
 
-컨테이너 런타임은 컨테이너의 동작을 책임지는 소프트웨어다. 
+컨테이너 런타임은 컨테이너의 동작을 책임지는 소프트웨어다.
 쿠버네티스는 몇몇의 런타임을 지원하는데 [Docker](http://www.docker.com), [containerd](https://containerd.io), [cri-o](https://cri-o.io/), [rktlet](https://github.com/kubernetes-incubator/rktlet) 그리고 [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)를 구현한 모든 런타임이다.
 
 ## 애드온
 
-애드온은 클러스터 기능을 이행하는 파드와 서비스다. 이 파드는 디플로이먼트, 레플리케이션 컨트롤러, 기타 등등에 의해 관리될 수도 있다. 네임스페이스를 갖는 애드온 오브젝트는 `kube-system` 네임스페이스 내에서 생성되어 진다.
+애드온은 클러스터 기능을 이행하는 파드와 서비스다.
+이 파드는 디플로이먼트, 레플리케이션 컨트롤러, 기타 등등에 의해 관리될 수도 있다.
+네임스페이스를 갖는 애드온 오브젝트는 `kube-system` 네임스페이스 내에서 생성되어 진다.
 
-선택된 일부 애드온이 아래에 설명되었으며, 사용가능한 전체 확장 애드온 리스트는
-[애드온](/docs/concepts/cluster-administration/addons/)을 참조한다.
+선택된 일부 애드온이 아래에 설명되었으며, 사용가능한 전체 확장 애드온 리스트는 [애드온](/docs/concepts/cluster-administration/addons/)을 참조한다.
 
 ### DNS
 
@@ -100,11 +102,13 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드
 
 ### 컨테이너 리소스 모니터링
 
-[컨테이너 리소스 모니터링](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)은 중앙 데이터베이스 내에 컨테이너들에 대한 포괄적인 시계열 메트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공해 준다.
+[컨테이너 리소스 모니터링](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)은
+중앙 데이터베이스 내에 컨테이너들에 대한 포괄적인 시계열 메트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공해 준다.
 
 ### 클러스터-레벨 로깅
 
-[클러스터-레벨 로깅](/docs/concepts/cluster-administration/logging/) 메커니즘은 검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 가진다.
+[클러스터-레벨 로깅](/docs/concepts/cluster-administration/logging/) 메커니즘은
+검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 가진다.
 
 {{% /capture %}}