Merge pull request #20986 from kubernetes/dev-1.18-ko.3

Third Korean l10n work for release 1.18
2020-05-14 23:56:58 -07:00
parent 23d42bb693 ca62e21766
commit 3dee902b75
67 changed files with 4827 additions and 313 deletions
@@ -0,0 +1,23 @@
+---
+title: 클라우드 컨트롤 매니저
+id: cloud-controller-manager
+date: 2018-04-12
+full_link: /ko/docs/concepts/architecture/cloud-controller/
+short_description: >
+  쿠버네티스를 타사 클라우드 공급자와 통합하는 컨트롤 플레인 컴포넌트.
+aka: 
+tags:
+- core-object
+- architecture
+- operation
+---
+ 클라우드별 컨트롤 로직을 포함하는 쿠버네티스
+{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}} 컴포넌트이다.
+클라우트 컨트롤러 매니저를 통해 클러스터를 클라우드 공급자의 API에 연결하고,
+해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와 상호 작용하는 컴포넌트를 분리할 수 있다.
+
+<!--more-->
+
+쿠버네티스와 기본 클라우드 인프라스터럭처 간의 상호 운용성 로직을
+분리함으로써, cloud-controller-manager 컴포넌트는 클라우드 공급자가
+주요 쿠버네티스 프로젝트와 다른 속도로 기능들을 릴리스할 수 있도록 한다.
@@ -0,0 +1,20 @@
+---
+title: 컨피그맵(ConfigMap)
+id: configmap
+date: 2018-04-12
+full_link: /docs/concepts/configuration/configmap/
+short_description: >
+  키-값 쌍으로 기밀이 아닌 데이터를 저장하는 데 사용하는 API 오브젝트이다. 볼륨에서 환경 변수, 커맨드-라인 인수 또는 구성 파일로 사용될 수 있다.
+
+aka:
+tags:
+- core-object
+---
+ 키-값 쌍으로 기밀이 아닌 데이터를 저장하는 데 사용하는 API 오브젝트이다.
+{{< glossary_tooltip text="파드" term_id="pod" >}}는
+{{< glossary_tooltip text="볼륨" term_id="volume" >}}에서
+환경 변수, 커맨드-라인 인수 또는 구성 파일로 컨피그맵을 사용할 수 있다.
+
+<!--more-->
+
+컨피그맵을 사용하면 {{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}에서 환경별 구성을 분리하여, 애플리케이션을 쉽게 이식할 수 있다.
@@ -11,3 +11,15 @@ tags:
 - fundamental
 ---
  컨테이너의 라이프사이클을 정의, 배포, 관리하기 위한 API와 인터페이스들을 노출하는 컨테이너 오케스트레이션 레이어.
+
+ <!--more-->
+
+이 계층은 다음과 같은 다양한 컴포넌트로 구성된다(그러나 제한되지는 않는다).
+
+ * {{< glossary_tooltip text="etcd" term_id="etcd" >}}
+ * {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}
+ * {{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}
+ * {{< glossary_tooltip text="컨트롤러 매니저" term_id="kube-controller-manager" >}}
+ * {{< glossary_tooltip text="클라우드 컨트롤러 매니저" term_id="cloud-controller-manager" >}}
+
+ 이러한 컴포넌트는 기존 운영체제 서비스(데몬) 또는 컨테이너로 실행할 수 있다. 이러한 컴포넌트를 실행하는 호스트를 {{< glossary_tooltip text="마스터" term_id="master" >}}라 한다.
@@ -4,7 +4,7 @@ id: cronjob
 date: 2018-04-12
 full_link: /ko/docs/concepts/workloads/controllers/cron-jobs/
 short_description: >
-  주기적인 일정에 따라 실행되는 [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)을 관리.
+  정기적인 일정으로 실행되는 반복 작업(잡).

 aka: 
 tags:
@@ -4,7 +4,7 @@ id: deployment
 date: 2018-04-12
 full_link: /ko/docs/concepts/workloads/controllers/deployment/
 short_description: >
-  복제된(replicated) 애플리케이션을 관리하는 API 오브젝트.
+  클러스터에서 복제된 애플리케이션을 관리한다.

 aka:
 tags:
@@ -12,9 +12,10 @@ tags:
 - core-object
 - workload
 ---
- 복제된 애플리케이션을 관리하는 API 오브젝트.
+ 일반적으로 로컬 상태가 없는 파드를 실행하여 복제된 애플리케이션을 관리하는 API 오브젝트.

 <!--more-->

-각 레플리카는 {{< glossary_tooltip text="파드" term_id="pod" >}}로 표현되며, 파드는 클러스터의 {{< glossary_tooltip text="노드" term_id="node" >}}에 분산된다.
-
+각 레플리카는 {{< glossary_tooltip text="파드" term_id="pod" >}}로 표현되며,
+파드는 클러스터의 {{< glossary_tooltip text="노드" term_id="node" >}}에 분산된다.
+로컬 상태가 필요한 워크로드의 경우 {{< glossary_tooltip term_id="StatefulSet" >}}의 사용을 고려한다.
@@ -4,7 +4,7 @@ id: pod
 date: 2018-04-12
 full_link: /ko/docs/concepts/workloads/pods/pod-overview/
 short_description: >
-  가장 작고 단순한 쿠버네티스 오브젝트. 파드는 사용자 클러스터에서 동작하는 컨테이너의 집합을 나타낸다. 
+  파드는 클러스터에서 실행 중인 컨테이너의 집합을 나타낸다.

 aka: 
 tags:
@@ -1,5 +1,5 @@
 ---
-title: 서비스 어카운트(ServiceAccount)
+title: 서비스어카운트(ServiceAccount)
 id: service-account
 date: 2018-04-12
 full_link: /docs/tasks/configure-pod-container/configure-service-account/
@@ -4,7 +4,7 @@ id: statefulset
 date: 2018-04-12
 full_link: /ko/docs/concepts/workloads/controllers/statefulset/
 short_description: >
-  파드 집합의 디플로이먼트와 스케일링을 관리하며, 파드들의 *순서 및 고유성을 보장한다* .
+  내구성이 있는 스토리지와 파드별로 지속성 식별자를 사용해서 파드 집합의 디플로이먼트와 스케일링을 관리한다.

 aka: 
 tags:
@@ -17,4 +17,6 @@ tags:

 <!--more--> 

-{{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}와 유사하게, 스테이트풀 셋은 동일한 컨테이너 스펙을 기반으로 둔 파드들을 관리한다. 디플로이먼트와는 다르게, 스테이트풀 셋은 각 파드의 독자성을 유지한다. 이 파드들은 동일한 스팩으로 생성되었지만, 서로 교체는 불가능하다. 다시 말해, 각각은 재스케줄링 간에도 지속적으로 유지되는 식별자를 가진다.
+{{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}와 유사하게, 스테이트풀셋은 동일한 컨테이너 스펙을 기반으로 둔 파드들을 관리한다. 디플로이먼트와는 다르게, 스테이트풀셋은 각 파드의 독자성을 유지한다. 이 파드들은 동일한 스팩으로 생성되었지만, 서로 교체는 불가능하다. 다시 말해, 각각은 재스케줄링 간에도 지속적으로 유지되는 식별자를 가진다.
+
+스토리지 볼륨을 사용해서 워크로드에 지속성을 제공하려는 경우, 솔루션의 일부로 스테이트풀셋을 사용할 수 있다. 스테이트풀셋의 개별 파드는 장애에 취약하지만, 퍼시스턴트 파드 식별자는 기존 볼륨을 실패한 볼륨을 대체하는 새 파드에 더 쉽게 일치시킬 수 있다.