Eighth Korean l10n work for release 1.18

- Translate tasks/administer-cluster/declare-network-policy in Korean (#22526) - Translate tasks/debug-application-cluster/debug-init-containers in Korean (#22608) - Fix a missing markdown syntax to enable external link (#22661) - Translate tasks/administer-cluster/change-pv-reclaim-policy in Korean (#22551) - Update docs/contribute/participate/ for Korean (#22605) - Update outdated files in dev-1.18-ko.8 (#22466) - Translate tasks/administer-cluster/dns-custom-nameservers in Korean (#22524) Co-authored-by: Daehyun Paik <[email protected]> Co-authored-by: Jerry Park <[email protected]> Co-authored-by: bluefriday <[email protected]> Co-authored-by: June Yi <[email protected]> Co-authored-by: Jesang Myung <[email protected]> Co-authored-by: Seokho Son <[email protected]>
kubernetes · Jul 24, 2020 · fe296af · fe296af
1 parent 6bf2feb
commit fe296af
Show file tree

Hide file tree

Showing 46 changed files with 1,454 additions and 654 deletions.
diff --git a/content/ko/docs/concepts/_index.md b/content/ko/docs/concepts/_index.md
@@ -12,59 +12,3 @@ weight: 40
 
 
 <!-- body -->
-
-## 개요
-
-쿠버네티스를 사용하려면, *쿠버네티스 API 오브젝트* 로 클러스터에 대해 사용자가 *바라는 상태* 를 기술해야 한다. 어떤 애플리케이션이나 워크로드를 구동시키려고 하는지, 어떤 컨테이너 이미지를 쓰는지, 복제의 수는 몇 개인지, 어떤 네트워크와 디스크 자원을 쓸 수 있도록 할 것인지 등을 의미한다. 바라는 상태를 설정하는 방법은 쿠버네티스 API를 사용해서 오브젝트를 만드는 것인데, 대개 `kubectl`이라는 커맨드라인 인터페이스를 사용한다. 클러스터와 상호 작용하고 바라는 상태를 설정하거나 수정하기 위해서 쿠버네티스 API를 직접 사용할 수도 있다.
-
-바라는 상태를 설정하면, *쿠버네티스 컨트롤 플레인* 은 Pod Lifecycle Event Generator ([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md))를 통해 클러스터의 현재 상태를 바라는 상태와 일치시킨다. 그렇게 함으로써, 쿠버네티스가 컨테이너를 시작 또는 재시작하거나, 주어진 애플리케이션의 복제 수를 스케일링하는 등의 다양한 작업을 자동으로 수행한다. 쿠버네티스 컨트롤 플레인은 클러스터에서 실행 중인 프로세스의 묶음(collection)으로 구성된다.
-
-* **쿠버네티스 마스터**는 클러스터 내 마스터 노드로 지정된 노드 내에서 구동되는 세 개의 프로세스 묶음이다. 해당 프로세스는 [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/)**.
-
-## 쿠버네티스 오브젝트
-
-쿠버네티스는 시스템의 상태를 나타내는 추상 개념을 다수 포함하고 있다. 컨테이너화되어 배포된 애플리케이션과 워크로드, 이에 연관된 네트워크와 디스크 자원, 그 밖에 클러스터가 무엇을 하고 있는지에 대한 정보가 이에 해당한다. 이런 추상 개념은 쿠버네티스 API 내 오브젝트로 표현된다. 보다 자세한 내용은 [쿠버네티스 오브젝트 이해하기](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) 문서를 참조한다.
-
-기초적인 쿠버네티스 오브젝트에는 다음과 같은 것들이 있다.
-
-* [파드](/ko/docs/concepts/workloads/pods/pod-overview/)
-* [서비스](/ko/docs/concepts/services-networking/service/)
-* [볼륨](/ko/docs/concepts/storage/volumes/)
-* [네임스페이스(Namespace)](/ko/docs/concepts/overview/working-with-objects/namespaces/)
-
-또한, 쿠버네티스에는 기초 오브젝트를 기반으로, 부가 기능 및 편의 기능을 제공하는 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 의존하는 보다 높은 수준의 추상 개념도 포함되어 있다. 다음이 포함된다.
-
-* [디플로이먼트(Deployment)](/ko/docs/concepts/workloads/controllers/deployment/)
-* [데몬셋(DaemonSet)](/ko/docs/concepts/workloads/controllers/daemonset/)
-* [스테이트풀셋(StatefulSet)](/ko/docs/concepts/workloads/controllers/statefulset/)
-* [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/)
-* [잡(Job)](/ko/docs/concepts/workloads/controllers/job/)
-
-## 쿠버네티스 컨트롤 플레인
-
-쿠버네티스 마스터와 kubelet 프로세스와 같은 쿠버네티스 컨트롤 플레인의 다양한 구성 요소는 쿠버네티스가 클러스터와 통신하는 방식을 관장한다. 컨트롤 플레인은 시스템 내 모든 쿠버네티스 오브젝트의 레코드를 유지하면서, 오브젝트의 상태를 관리하는 제어 루프를 지속적으로 구동시킨다. 컨트롤 플레인의 제어 루프는 클러스터 내 변경이 발생하면 언제라도 응답하고 시스템 내 모든 오브젝트의 실제 상태가 사용자가 바라는 상태와 일치시키기 위한 일을 한다.
-
-예를 들어, 쿠버네티스 API를 사용해서 디플로이먼트를 만들 때에는, 바라는 상태를 시스템에 신규로 입력해야한다. 쿠버네티스 컨트롤 플레인이 오브젝트 생성을 기록하고, 사용자 지시대로 필요한 애플리케이션을 시작시키고 클러스터 노드에 스케줄링한다. 그래서 결국 클러스터의 실제 상태가 바라는 상태와 일치하게 된다.
-
-### 쿠버네티스 마스터
-
-클러스터에 대해 바라는 상태를 유지할 책임은 쿠버네티스 마스터에 있다. `kubectl` 커맨드라인 인터페이스와 같은 것을 사용해서 쿠버네티스로 상호 작용할 때에는 쿠버네티스 마스터와 통신하고 있는 셈이다.
-
-> "마스터"는 클러스터 상태를 관리하는 프로세스의 묶음이다. 주로 모든 프로세스는 클러스터 내 단일 노드에서 구동되며, 이 노드가 바로 마스터이다. 마스터는 가용성과 중복을 위해 복제될 수도 있다.
-
-### 쿠버네티스 노드
-
-클러스터 내 노드는 애플리케이션과 클라우드 워크플로우를 구동시키는 머신(VM, 물리 서버 등)이다. 쿠버네티스 마스터는 각 노드를 관리한다. 직접 노드와 직접 상호 작용할 일은 거의 없을 것이다.
-
-
-
-
-## {{% heading "whatsnext" %}}
-
-
-개념 페이지를 작성하기를 원하면,
-개념 페이지 타입에 대한 정보가 있는
-[페이지 컨텐츠 타입](/docs/contribute/style/page-content-types/#concept)을 참고한다.
diff --git a/content/ko/docs/concepts/architecture/_index.md b/content/ko/docs/concepts/architecture/_index.md
@@ -1,4 +1,6 @@
 ---
 title: "클러스터 아키텍처"
 weight: 30
+description: >
+  쿠버네티스 뒤편의 구조와 설계 개념들
 ---
diff --git a/content/ko/docs/concepts/cluster-administration/_index.md b/content/ko/docs/concepts/cluster-administration/_index.md
@@ -1,5 +1,71 @@
 ---
-title: "클러스터 관리"
+title: 클러스터 관리
 weight: 100
+content_type: concept
+description: >
+  쿠버네티스 클러스터 생성 또는 관리에 관련된 로우-레벨(lower-level)의 세부 정보를 설명한다.
+no_list: true
 ---
 
+<!-- overview -->
+클러스터 관리 개요는 쿠버네티스 클러스터를 생성하거나 관리하는 모든 사람들을 위한 것이다.
+핵심 쿠버네티스 [개념](/ko/docs/concepts/)에 어느 정도 익숙하다고 가정한다.
+
+<!-- body -->
+## 클러스터 계획
+
+쿠버네티스 클러스터를 계획, 설정 및 구성하는 방법에 대한 예는 [시작하기](/ko/docs/setup/)에 있는 가이드를 참고한다. 이 문서에 나열된 솔루션을 *배포판* 이라고 한다.
+
+   {{< note  >}}
+   모든 배포판이 활발하게 유지되는 것은 아니다. 최신 버전의 쿠버네티스에서 테스트된 배포판을 선택한다.
+   {{< /note >}}
+
+가이드를 선택하기 전에 고려해야 할 사항은 다음과 같다.
+
+ - 컴퓨터에서 쿠버네티스를 그냥 한번 사용해보고 싶은가? 아니면, 고가용 멀티 노드 클러스터를 만들고 싶은가? 사용자의 필요에 따라 가장 적합한 배포판을 선택한다.
+ - [구글 쿠버네티스 엔진(Google Kubernetes Engine)](https://cloud.google.com/kubernetes-engine/)과 같은 클라우드 제공자의 **쿠버네티스 클러스터 호스팅** 을 사용할 것인가? 아니면, **자체 클러스터를 호스팅** 할 것인가?
+ - 클러스터가 **온-프레미스 환경** 에 있나? 아니면, **클라우드(IaaS)** 에 있나? 쿠버네티스는 하이브리드 클러스터를 직접 지원하지는 않는다. 대신 여러 클러스터를 설정할 수 있다.
+ - **온-프레미스 환경에 쿠버네티스** 를 구성하는 경우, 어떤 [네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/)이 가장 적합한 지 고려한다.
+ - 쿠버네티스를 **"베어 메탈" 하드웨어** 에서 실행할 것인가? 아니면, **가상 머신(VM)** 에서 실행할 것인가?
+ - **단지 클러스터만 실행할 것인가?** 아니면, **쿠버네티스 프로젝트 코드를 적극적으로 개발** 하는 것을 기대하는가? 만약
+   후자라면, 활발하게 개발이 진행되고 있는 배포판을 선택한다. 일부 배포판은 바이너리 릴리스만 사용하지만,
+   더 다양한 선택을 제공한다.
+ - 클러스터를 실행하는 데 필요한 [컴포넌트](/ko/docs/concepts/overview/components/)에 익숙해지자.
+
+
+## 클러스터 관리
+
+* [클러스터 관리](/ko/docs/tasks/administer-cluster/cluster-management/)는 클러스터 라이프사이클과 관련된 몇 가지 주제를 설명한다. 새로운 클러스터 생성, 클러스터의 마스터 및 워커 노드 업그레이드, 노드 유지 관리 수행(예: 커널 업그레이드) 및 실행 중인 클러스터의 쿠버네티스 API 버전 업그레이드
+
+* [노드 관리](/ko/docs/concepts/architecture/nodes/) 방법을 배운다.
+
+* 공유 클러스터에 대한 [리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 설정하고 관리하는 방법을 배운다.
+
+## 클러스터 보안
+
+* [인증서](/ko/docs/concepts/cluster-administration/certificates/)는 다른 툴 체인을 사용하여 인증서를 생성하는 단계를 설명한다.
+
+* [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은 쿠버네티스 노드에서 Kubelet으로 관리하는 컨테이너에 대한 환경을 설명한다.
+
+* [쿠버네티스 API에 대한 접근 제어](/docs/reference/access-authn-authz/controlling-access/)는 사용자와 서비스 어카운트에 대한 권한을 설정하는 방법을 설명한다.
+
+* [인증](/docs/reference/access-authn-authz/authentication/)은 다양한 인증 옵션을 포함한 쿠버네티스에서의 인증에 대해 설명한다.
+
+* [인가](/docs/reference/access-authn-authz/authorization/)는 인증과는 별개로, HTTP 호출 처리 방법을 제어한다.
+
+* [어드미션 컨트롤러 사용하기](/docs/reference/access-authn-authz/admission-controllers/)는 인증과 권한 부여 후 쿠버네티스 API 서버에 대한 요청을 가로채는 플러그인에 대해 설명한다.
+
+* [쿠버네티스 클러스터에서 Sysctls 사용하기](/docs/concepts/cluster-administration/sysctl-cluster/)는 관리자가 `sysctl` 커맨드라인 도구를 사용하여 커널 파라미터를 설정하는 방법에 대해 설명한다.
+
+* [감사(audit)](/docs/tasks/debug-application-cluster/audit/)는 쿠버네티스의 감사 로그를 다루는 방법에 대해 설명한다.
+
+### kubelet 보안
+  * [마스터-노드 통신](/ko/docs/concepts/architecture/control-plane-node-communication/)
+  * [TLS 부트스트래핑(bootstrapping)](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
+  * [Kubelet 인증/인가](/docs/admin/kubelet-authentication-authorization/)
+
+## 선택적 클러스터 서비스
+
+* [DNS 통합](/ko/docs/concepts/services-networking/dns-pod-service/)은 DNS 이름을 쿠버네티스 서비스로 직접 확인하는 방법을 설명한다.
+
+* [클러스터 액티비티 로깅과 모니터링](/ko/docs/concepts/cluster-administration/logging/)은 쿠버네티스에서의 로깅이 어떻게 작동하는지와 구현 방법에 대해 설명한다.
diff --git a/content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md
diff --git a/content/ko/docs/concepts/configuration/_index.md b/content/ko/docs/concepts/configuration/_index.md
@@ -1,5 +1,6 @@
 ---
 title: "구성"
 weight: 80
+description: >
+  쿠버네티스가 파드 구성을 위해 제공하는 리소스
 ---
-
diff --git a/content/ko/docs/concepts/configuration/configmap.md b/content/ko/docs/concepts/configuration/configmap.md
@@ -126,25 +126,32 @@ spec:
       configMap:
         # 마운트하려는 컨피그맵의 이름을 제공한다.
         name: game-demo
+        # 컨피그맵에서 파일로 생성할 키 배열
+        items:
+        - key: "game.properties"
+          path: "game.properties"
+        - key: "user-interface.properties"
+          path: "user-interface.properties"
 ```
 
 
 컨피그맵은 단일 라인 속성(single line property) 값과 멀티 라인의 파일과 비슷한(multi-line file-like) 값을
 구분하지 않는다.
 더 중요한 것은 파드와 다른 오브젝트가 이러한 값을 소비하는 방식이다.
+
 이 예제에서, 볼륨을 정의하고 `demo` 컨테이너에
-`/config` 로 마운트하면 4개의 파일이 생성된다.
+`/config` 로 마운트하면 컨피그맵에 4개의 키가 있더라도
+`/config/game.properties` 와 `/config/user-interface.properties`
+2개의 파일이 생성된다. 이것은 파드 정의가
+`volume` 섹션에서 `items` 배열을 지정하기 때문이다.
+`items` 배열을 완전히 생략하면, 컨피그맵의 모든 키가
+키와 이름이 같은 파일이 되고, 4개의 파일을 얻게 된다.
 
-- `/config/player_initial_lives`
-- `/config/ui_properties_file_name`
-- `/config/game.properties`
-- `/config/user-interface.properties`
+## 컨피그맵 사용하기
 
-`/config` 에 `.properties` 확장자를 가진 파일만
-포함시키려면, 두 개의 다른 컨피그맵을 사용하고, 파드에
-대해서는 `spec` 의 두 컨피그맵을 참조한다. 첫 번째 컨피그맵은
-`player_initial_lives` 와 `ui_properties_file_name` 을 정의한다. 두 번째
-컨피그맵은 kubelet이 `/config` 에 넣는 파일을 정의한다.
+컨피그맵은 데이터 볼륨으로 마운트할 수 있다. 컨피그맵은 파드에 직접적으로
+노출되지 않고, 시스템의 다른 부분에서도 사용할 수 있다. 예를 들어,
+컨피그맵은 시스템의 다른 부분이 구성을 위해 사용해야 하는 데이터를 보유할 수 있다.
 
 {{< note >}}
 컨피그맵을 사용하는 가장 일반적인 방법은 동일한 네임스페이스의
@@ -157,12 +164,6 @@ spec:
 사용할 수도 있다.
 {{< /note >}}
 
-## 컨피그맵 사용하기
-
-컨피그맵은 데이터 볼륨으로 마운트할 수 있다. 컨피그맵은 파드에 직접적으로
-노출되지 않고, 시스템의 다른 부분에서도 사용할 수 있다. 예를 들어,
-컨피그맵은 시스템의 다른 부분이 구성을 위해 사용해야 하는 데이터를 보유할 수 있다.
-
 ### 파드에서 컨피그맵을 파일로 사용하기
 
 파드의 볼륨에서 컨피그맵을 사용하려면 다음을 수행한다.