First Korean l10n work for release-1.19

- Translate tasks/job/parallel-processing-expansion.md into Korean (#23544)
- Fix issue with ko/docs/concepts/workloads/controllers/job.md (#23720)
- Translate reference/scheduling/policies.md in Korean (#23690)
- Update outdated files in the dev-1.19-ko.1 branch (#23702)
- Modify translation access by Korean glossary (#23627)

Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: junghyeonsu <54893898+junghyeonsu@users.noreply.github.com>
Co-authored-by: coolguyhong <podolsmith@naver.com>

content/ko/docs/tasks/access-application-cluster/_index.md

@@ -1,5 +1,5 @@
 ---
-title: "클러스터 내 어플리케이션 액세스"
+title: "클러스터 내 어플리케이션 접근"
 description: 클러스터의 애플리케이션에 접근하기 위해 로드 밸런싱, 포트 포워딩, 방화벽 설정 또는 DNS 구성을 설정한다.
 weight: 60
 ---

content/ko/docs/tasks/access-application-cluster/access-cluster.md

@@ -1,5 +1,5 @@
 ---
-title: 클러스터 액세스
+title: 클러스터 접근
 weight: 20
 content_type: concept
 ---
@@ -8,17 +8,14 @@ content_type: concept
 
 여기에서는 클러스터와 통신을 하는 다양한 방식에 대해서 다룰 것이다.
 
-
-
-
 <!-- body -->
 
-## 처음이라면 kubectl을 사용하여 액세스
+## 처음이라면 kubectl을 사용하여 접근
 
-최초로 쿠버네티스 API에 액세스할 때 우리는
+최초로 쿠버네티스 API에 접근할 때 우리는
 쿠버네티스 CLI인 `kubectl`을 사용하는 것을 추천한다.
 
-클러스터에 액세스하려면 클러스터의 위치정보를 알아야 하고 클러스터에 접속하기 위한
+클러스터에 접근하려면 클러스터의 위치정보를 알아야 하고 클러스터에 접속하기 위한
 인증정보를 가져야 한다. 일반적으로 이는 당신이
 [Getting started guide](/ko/docs/setup/)를 다 진행했을 때 자동으로 구성되거나,
 다른 사람이 클러스터를 구성하고 당신에게 인증정보와 위치정보를 제공할 수도 있다.
@@ -29,14 +26,15 @@ kubectl이 인지하는 위치정보와 인증정보는 다음 커맨드로 확
 kubectl config view
 ```
 
-많은 [예제들](/ko/docs/reference/kubectl/cheatsheet/)에서 kubectl을 사용하는 것을 소개하고 있으며
-완전한 문서는 [kubectl manual](/docs/user-guide/kubectl-overview)에서 찾아볼 수 있다.
+많은 [예제들](/ko/docs/reference/kubectl/cheatsheet/)에서
+kubectl을 사용하는 것을 소개하고 있으며 완전한 문서는
+[kubectl 매뉴얼](/ko/docs/reference/kubectl/overview/)에서 찾아볼 수 있다.
 
-## REST API에 직접 액세스
+## REST API에 직접 접근
 
 kubectl은 apiserver의 위치 파악과 인증을 처리한다.
 만약 당신이 curl, wget 또는 웹브라우저와 같은 http 클라이언트로
-REST API에 직접 액세스하려고 한다면 위치 파악과 인증을 하는 몇 가지 방법이 존재한다.
+REST API에 직접 접근하려고 한다면 위치 파악과 인증을 하는 몇 가지 방법이 존재한다.
 
   - kubectl을 proxy 모드로 실행.
     - 권장하는 접근 방식.
@@ -155,7 +153,7 @@ localhost에서 제공되거나 방화벽으로 보호되는 몇몇 클러스터
 는 클러스터 관리자가 이를 어떻게 구성할 수 있는지를 설명한다.
 이 방식들은 미래의 고가용성 지원과 충돌될 수 있다.
 
-## API에 프로그래밍 방식으로 액세스
+## API에 프로그래밍 방식으로 접근
 
 쿠버네티스는 공식적으로 [Go](#go-클라이언트)와 [Python](#python-클라이언트)
 클라이언트 라이브러리를 지원한다.
@@ -165,16 +163,16 @@ localhost에서 제공되거나 방화벽으로 보호되는 몇몇 클러스터
 * 라이브러리를 취득하려면 `go get k8s.io/client-go@kubernetes-<kubernetes-version-number>` 커맨드를 실행한다. [INSTALL.md](https://github.com/kubernetes/client-go/blob/master/INSTALL.md#for-the-casual-user)에서 상세한 설치 방법을 알 수 있다. [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go#compatibility-matrix)에서 어떤 버젼이 지원되는지 확인할 수 있다.
 * client-go 클라이언트 위에 애플리케이션을 작성하자. client-go는 자체적으로 API 오브젝트를 정의하므로 필요하다면 main 레포지터리보다는 client-go에서 API 정의들을 import하기를 바란다. 정확하게 `import "k8s.io/client-go/kubernetes"`로 import하는 것을 예로 들 수 있다.
 
-Go 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)을 사용할 수 있다.
+Go 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을 사용할 수 있다.
 [예제](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)를 참고한다.
 
-만약 애플리케이션이 클러스터 내에 파드로 배포되었다면 [다음 장](#파드에서-api-액세스)을 참조하기를 바란다.
+만약 애플리케이션이 클러스터 내에 파드로 배포되었다면 [다음 장](#파드에서-api-접근)을 참조하기를 바란다.
 
 ### Python 클라이언트
 
 Python 클라이언트를 사용하려면 `pip install kubernetes` 커맨드를 실행한다. 설치 옵션에 대한 상세 사항은 [Python Client Library page](https://github.com/kubernetes-client/python)를 참조한다.
 
-Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)을 사용할 수 있다.
+Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을 사용할 수 있다.
 [예제](https://github.com/kubernetes-client/python/tree/master/examples)를 참조한다.
 
 ### 다른 언어
@@ -182,7 +180,7 @@ Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와
 다른 언어에서 API를 접속하기 위한 [클라이언트 라이브러리들](/ko/docs/reference/using-api/client-libraries/)도 존재한다.
 이들이 어떻게 인증하는지는 다른 라이브러리들의 문서를 참조한다.
 
-## 파드에서 API 액세스
+## 파드에서 API 접근
 
 파드에서 API를 접속한다면 apiserver의
 위치지정과 인증은 다소 다르다.
@@ -215,11 +213,13 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다.
 
 각각의 사례에서 apiserver와의 보안 통신에 파드의 인증정보가 사용된다.
 
-## 클러스터에서 실행되는 서비스로 액세스
+## 클러스터에서 실행되는 서비스로 접근
 
 이전 장은 쿠버네티스 API server 접속에 대한 내용을 다루었다. 이번 장은
 쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다. 쿠버네티스에서
-[노드들](/ko/docs/concepts/architecture/nodes/), [파드들](/ko/docs/concepts/workloads/pods/pod/), [서비스들](/docs/user-guide/services)은
+[노드들](/ko/docs/concepts/architecture/nodes/),
+[파드들](/ko/docs/concepts/workloads/pods/pod/),
+[서비스들](/ko/docs/concepts/services-networking/service/)은
 모두 자신의 IP들을 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는
 클러스터 상의 노드 IP들, 파드 IP들, 서비스 IP들로 라우팅되지 않아서 접근을
 할 수 없을 것이다.
@@ -228,9 +228,9 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다.
 
 클러스터 외부에서 노드들, 파드들, 서비스들에 접속하는 데는 몇 가지 선택지들이 있다.
 
-  - 공인 IP를 통해 서비스에 액세스.
+  - 공인 IP를 통해 서비스에 접근.
     - 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의
-      서비스를 사용한다. [서비스](/docs/user-guide/services)와
+      서비스를 사용한다. [서비스](/ko/docs/concepts/services-networking/service/)와
       [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참조한다.
     - 당신의 클러스터 환경에 따라 회사 네트워크에만 서비스를 노출하거나
       인터넷으로 노출할 수 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다.
@@ -238,19 +238,19 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다.
     - 파드들은 서비스 뒤에 위치시킨다. 레플리카들의 집합에서 특정 파드 하나에 debugging 같은 목적으로 접근하려면
       해당 파드에 고유의 레이블을 붙이고 셀렉터에 해당 레이블을 선택한 신규 서비스를 생성한다.
     - 대부분의 경우에는 애플리케이션 개발자가 노드 IP를 통해 직접 노드에
-      액세스할 필요는 없다.
-  - Proxy Verb를 사용하여 서비스, 노드, 파드에 액세스.
-    - 원격 서비스에 액세스하기에 앞서 apiserver의 인증과 인가를 받아야 한다.
+      접근할 필요는 없다.
+  - Proxy Verb를 사용하여 서비스, 노드, 파드에 접근.
+    - 원격 서비스에 접근하기에 앞서 apiserver의 인증과 인가를 받아야 한다.
       서비스가 인터넷에 노출하기에 보안이 충분하지 않거나 노드 IP 상의 port에
-      액세스를 취득하려고 하거나 debugging을 하려면 이를 사용한다.
+      접근을 하려고 하거나 debugging을 하려면 이를 사용한다.
     - 어떤 web 애플리케이션에서는 proxy가 문제를 일으킬 수 있다.
     - HTTP/HTTPS에서만 동작한다.
     - [여기](#수작업으로-apiserver-proxy-url들을-구축)에서 설명하고 있다.
-  - 클러스터 내 노드 또는 파드에서 액세스.
+  - 클러스터 내 노드 또는 파드에서 접근.
     - 파드를 Running시킨 다음 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 해당 파드의 셸로 접속한다.
       해당 셸에서 다른 노드들, 파드들, 서비스들에 연결한다.
     - 어떤 클러스터는 클러스터 내의 노드에 ssh 접속을 허용하기도 한다. 이런 클러스터에서는
-      클러스터 서비스에 액세스도 가능하다. 이는 비표준 방식으로 특정 클러스터에서는 동작하지만
+      클러스터 서비스에 접근도 가능하다. 이는 비표준 방식으로 특정 클러스터에서는 동작하지만
       다른 클러스터에서는 동작하지 않을 수 있다. 브라우저와 다른 도구들이 설치되지 않았거나 설치되었을 수 있다. 클러스터 DNS가 동작하지 않을 수도 있다.
 
 ### 빌트인 서비스들의 발견
@@ -273,10 +273,10 @@ grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/servic
 heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
 ```
 
-이는 각 서비스에 액세스하기 위한 proxy-verb URL을 보여준다.
+이는 각 서비스에 접근하기 위한 proxy-verb URL을 보여준다.
 예를 들어 위 클러스터는 클러스터 수준의 logging(Elasticsearch 사용)이 활성화되었으므로 적절한 인증을 통과하여
-`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`로 액세스할 수 있다. 예를 들어 kubectl proxy로
-`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`를 통해 logging에 액세스할 수도 있다.
+`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`로 접근할 수 있다. 예를 들어 kubectl proxy로
+`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`를 통해 logging에 접근할 수도 있다.
 (인증을 통과하는 방법이나 kubectl proxy를 사용하는 것은 [쿠버네티스 API를 사용해서 클러스터에 접근하기](/ko/docs/tasks/administer-cluster/access-cluster-api/)을 참조한다.)
 
 #### 수작업으로 apiserver proxy URL을 구축
@@ -298,8 +298,8 @@ URL의 네임 부분에 지원되는 양식은 다음과 같다.
 
 ##### 예제들
 
- * Elasticsearch 서비스 endpoint `_search?q=user:kimchy`에 액세스하려면 `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`를 사용할 수 있다.
- * Elasticsearch 클러스터 상태 정보 `_cluster/health?pretty=true`에 액세스하려면 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`를 사용할 수 있다.
+ * Elasticsearch 서비스 endpoint `_search?q=user:kimchy`에 접근하려면 `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`를 사용할 수 있다.
+ * Elasticsearch 클러스터 상태 정보 `_cluster/health?pretty=true`에 접근하려면 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`를 사용할 수 있다.
 
 ```json
 {
@@ -316,7 +316,7 @@ URL의 네임 부분에 지원되는 양식은 다음과 같다.
 }
 ```
 
-### 클러스터 상에서 실행되는 서비스에 웹브라우저를 사용하여 액세스
+### 클러스터 상에서 실행되는 서비스에 웹브라우저를 사용하여 접근
 
 브라우저의 주소창에 apiserver proxy url을 넣을 수도 있다. 하지만
 
@@ -333,7 +333,7 @@ redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) proxy
 
 쿠버네티스를 사용하면서 당신이 접할 수 있는 몇 가지 다른 proxy들이 존재한다.
 
-1.  [kubectl proxy](#rest-api에-직접-액세스):
+1.  [kubectl proxy](#rest-api에-직접-접근):
 
     - 사용자의 데스크탑이나 파드 내에서 실행한다
     - localhost 주소에서 쿠버네티스 apiserver로 proxy한다
@@ -375,3 +375,4 @@ redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) proxy
 
 일반적으로 쿠버네티스 사용자들은 처음 두 타입이 아닌 다른 방식은 고려할 필요가 없지만 클러스터 관리자는
 나머지 타입을 적절하게 구성해줘야 한다.
+

content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md

@@ -6,20 +6,15 @@ weight: 110
 
 <!-- overview -->
 
-이 페이지에서는 동일한 파드에서 실행 중인 두 개의 컨테이너 간에 통신할 때에, 어떻게 볼륨을 이용하는지
-살펴본다. 컨테이너 간에 [프로세스 네임스페이스 공유하기](/docs/tasks/configure-pod-container/share-process-namespace/)를 통해 통신할 수 있는 방법을 참고하자.
-
-
-
+이 페이지에서는 동일한 파드에서 실행 중인 두 개의 컨테이너 간에 통신할 때에,
+어떻게 볼륨을 이용하는지 살펴본다. 컨테이너 간에
+[프로세스 네임스페이스 공유하기](/docs/tasks/configure-pod-container/share-process-namespace/)를
+통해 통신할 수 있는 방법을 참고하자.
 
 ## {{% heading "prerequisites" %}}
 
-
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
-
-
-
 <!-- steps -->
 
 ## 두 개의 컨테이너를 실행하는 파드 생성
@@ -103,14 +98,15 @@ nginx 컨테이너의 쉘(shell)을 실행한다.
 Debian 컨테이너에서 nginx 웹 서버가 호스팅하는 문서의 루트 디렉터리에 `index.html` 파일을 생성했었음을 상기하자.
 `curl`을 이용하여 nginx 웹 서버에 HTTP GET 요청을 보낸다.
 
-    root@two-containers:/# curl localhost
+```
+root@two-containers:/# curl localhost
+```
 
 출력을 보면, nginx 웹 서버에서 debian 컨테이너에서 쓰여진 웹 페이지를 제공하는 것을 알 수 있다.
 
-    debian 컨테이너에서 안녕하세요
-
-
-
+```
+debian 컨테이너에서 안녕하세요
+```
 
 <!-- discussion -->
 
@@ -127,20 +123,14 @@ Debian 컨테이너에서 nginx 웹 서버가 호스팅하는 문서의 루트
 이 예제에서 볼륨은 파드의 생명 주기 동안 컨테이너를 위한 통신 방법으로 이용했다.
 파드가 삭제되고 재생성되면, 공유 볼륨에 저장된 데이터는 잃어버린다.
 
-
-
-
 ## {{% heading "whatsnext" %}}
 
 
-* [합성 컨테이너(composite container) 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)에 관하여
-더 공부한다.
+* [합성 컨테이너(composite container) 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)에 관하여 더 공부한다.
 
-* [모듈 구조를 위한 합성 컨테이너 구조](http://www.slideshare.net/Docker/slideshare-burns)에 관하여
-더 공부한다.
+* [모듈 구조를 위한 합성 컨테이너 구조](https://www.slideshare.net/Docker/slideshare-burns)에 관하여 더 공부한다.
 
-* [파드에서 저장소로 볼룸을 사용하도록 구성하기](/ko/docs/tasks/configure-pod-container/configure-volume-storage/)에 관하여
-확인한다.
+* [파드에서 저장소로 볼룸을 사용하도록 구성하기](/ko/docs/tasks/configure-pod-container/configure-volume-storage/)에 관하여 확인한다.
 
 * [파드에서 컨테이너 간에 프로세스 네임스페이스를 공유하는 파드 구성하는 방법](/docs/tasks/configure-pod-container/share-process-namespace/)을 참고한다.
 

content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md

@@ -10,15 +10,19 @@ card:
 
 <!-- overview -->
 
-대시보드는 웹 기반 쿠버네티스 유저 인터페이스이다. 대시보드를 통해 컨테이너화 된 애플리케이션을 쿠버네티스 클러스터에 배포할 수 있고, 컨테이너화 된 애플리케이션을 트러블슈팅 할 수 있으며, 클러스터 리소스들을 관리할 수 있다. 대시보드를 통해 클러스터에서 동작중인 애플리케이션의 정보를 볼 수 있고, 개별적인 쿠버네티스 리소스들을(예를 들면 디플로이먼트, 잡, 데몬셋 등) 생성하거나 수정할 수 있다. 예를 들면, 디플로이먼트를 스케일하거나, 롤링 업데이트를 초기화하거나, 파드를 재시작하거나 또는 배포 마법사를 이용해 새로운 애플리케이션을 배포할 수 있다.
+대시보드는 웹 기반 쿠버네티스 유저 인터페이스이다.
+대시보드를 통해 컨테이너화 된 애플리케이션을 쿠버네티스 클러스터에 배포할 수 있고,
+컨테이너화 된 애플리케이션을 트러블슈팅할 수 있으며, 클러스터 리소스들을 관리할 수 있다.
+대시보드를 통해 클러스터에서 동작 중인 애플리케이션의 정보를 볼 수 있고,
+개별적인 쿠버네티스 리소스들을(예를 들면 디플로이먼트, 잡, 데몬셋 등)
+생성하거나 수정할 수 있다.
+예를 들면, 디플로이먼트를 스케일하거나, 롤링 업데이트를 초기화하거나, 파드를 재시작하거나
+또는 배포 마법사를 이용해 새로운 애플리케이션을 배포할 수 있다.
 
 또한 대시보드는 클러스터 내 쿠버네티스 리소스들의 상태와 발생하는 모든 에러 정보를 제공한다.
 
 ![Kubernetes Dashboard UI](/images/docs/ui-dashboard.png)
 
-
-
-
 <!-- body -->
 
 ## 대시보드 UI 배포
@@ -32,7 +36,10 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/a
 ## 대시보드 UI 접근
 
 
-클러스터 데이터를 보호하기 위해, 대시보드는 기본적으로 최소한의 RBAC 설정을 제공한다. 현재, 대시보드는 Bearer 토큰으로 로그인 하는 방법을 제공한다. 본 시연을 위한 토큰을 생성하기 위해서는, [샘플 사용자 만들기](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md) 가이드를 따른다.
+클러스터 데이터를 보호하기 위해, 대시보드는 기본적으로 최소한의 RBAC 설정을 제공한다.
+현재, 대시보드는 Bearer 토큰으로 로그인 하는 방법을 제공한다.
+본 시연을 위한 토큰을 생성하기 위해서는,
+[샘플 사용자 만들기](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md) 가이드를 따른다.
 
 {{< warning >}}
 시연 중에 생성한 샘플 사용자는 어드민 권한이 부여되며, 이는 교육 목적으로만 사용한다.
@@ -55,13 +62,17 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
 
 ## 웰컴 뷰
 
-초기 클러스터 대시보드에 접근하면, 환영 페이지를 볼 수 있다. 이 페이지는 첫 애플리케이션을 배포하는 버튼이 있을 뿐만 아니라, 이 문서의 링크를 포함하고 있다. 게다가, 대시보드가 있는 클러스터에서 기본적으로 `kube-system` [네임스페이스](/docs/tasks/administer-cluster/namespaces/)이 동작중인 시스템 애플리케이션을 볼 수 있다.
+초기 클러스터 대시보드에 접근하면, 환영 페이지를 볼 수 있다.
+이 페이지는 첫 애플리케이션을 배포하는 버튼이 있을 뿐만 아니라, 이 문서의 링크를 포함하고 있다.
+게다가, 대시보드가 있는 클러스터에서 기본적으로 `kube-system`
+[네임스페이스](/docs/tasks/administer-cluster/namespaces/)이 동작중인 시스템 애플리케이션을 볼 수 있다.
 
 ![Kubernetes Dashboard welcome page](/images/docs/ui-dashboard-zerostate.png)
 
 ## 컨테이너화 된 애플리케이션 배포
 
-대시보드를 이용하여 컨테이너화 된 애플리케이션을 디플로이먼트와 간단한 마법사를 통한 선택적인 서비스로 생성하고 배포할 수 있다. 애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML, JSON 파일을 업로드 할 수 있다.
+대시보드를 이용하여 컨테이너화 된 애플리케이션을 디플로이먼트와 간단한 마법사를 통한 선택적인 서비스로 생성하고 배포할 수 있다.
+애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML, JSON 파일을 업로드할 수 있다.
 
 시작하는 페이지의 상위 오른쪽 코너에 있는 **CREATE** 버튼을 클릭한다.
 
@@ -69,17 +80,29 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
 
 배포 마법사는 다음 정보를 제공한다.
 
-- **앱 이름** (필수): 애플리케이션 이름. [레이블](/ko/docs/concepts/overview/working-with-objects/labels/) 이름은 배포할 모든 디플로이먼트와 서비스에 추가되어야 한다.
+- **앱 이름** (필수): 애플리케이션 이름.
+  [레이블](/ko/docs/concepts/overview/working-with-objects/labels/) 이름은
+  배포할 모든 디플로이먼트와 서비스에 추가되어야 한다.
 
-  애플리케이션 이름은 선택된 쿠버네티스 [네임스페이스](/docs/tasks/administer-cluster/namespaces/) 안에서 유일해야 한다. 소문자로 시작해야하며, 소문자 또는 숫자로 끝나고, 소문자, 숫자 및 대쉬(-)만을 포함해야한다. 24 문자만을 제한한다. 처음과 끝의 스페이스는 무시된다.
+  애플리케이션 이름은 선택된 쿠버네티스 [네임스페이스](/docs/tasks/administer-cluster/namespaces/) 안에서 유일해야 한다.
+  소문자로 시작해야 하며, 소문자 또는 숫자로 끝나고,
+  소문자, 숫자 및 대쉬(-)만을 포함해야 한다. 24 문자만을 제한한다.
+  처음과 끝의 스페이스는 무시된다.
 
-- **컨테이너 이미지** (필수): 레지스트리에 올라간 퍼블릭 도커 [컨테이너 이미지](/ko/docs/concepts/containers/images/) 또는 프라이빗 이미지(대체로 Google Container Registry 또는 도커 허브에 올라간)의 URL. 컨테이너 이미지 사양은 콜론으로 끝난다.
+- **컨테이너 이미지** (필수):
+  레지스트리에 올라간 퍼블릭 도커 [컨테이너 이미지](/ko/docs/concepts/containers/images/)
+  또는 프라이빗 이미지(대체로 Google Container Registry 또는 도커 허브에 올라간)의 URL.
+  컨테이너 이미지 사양은 콜론으로 끝난다.
 
-- **파드의 수** (필수): 배포하고 싶은 애플리케이션의 원하는 목표 파드 개수. 값은 양의 정수만 허용됩니다.
+- **파드의 수** (필수): 배포하고 싶은 애플리케이션의 원하는 목표 파드 개수.
+  값은 양의 정수만 허용됩니다.
 
-  클러스터에 의도한 파드의 수를 유지하기 위해서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)가 생성될 것이다.
+  클러스터에 의도한 파드의 수를 유지하기 위해서
+  [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)가 생성될 것이다.
 
-- **서비스** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스](/ko/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다.
+- **서비스** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의
+  퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스](/ko/docs/concepts/services-networking/service/)를
+  노출시키고 싶을 수 있다.
 
   {{< note >}}
   외부 서비스들을 위해, 한 개 또는 여러 개의 포트를 열어 둘 필요가 있다.
@@ -87,13 +110,22 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
 
   클러스터 내부에서만 보고 싶은 어떤 서비스들이 있을 것이다. 이를 내부 서비스라고 한다.
 
-  서비스 타입과는 무관하게, 서비스 생성을 선택해서 컨테이너의 (들어오는 패킷의) 포트를 리슨한다면, 두 개의 포트를 정의해야 한다. 서비스는 컨테이너가 바라보는 타겟 포트와 (들어오는 패킷의) 맵핑하는 포트가 만들어져야 할 것이다. 서비스는 배포된 파드에 라우팅 될 것이다. 지원하는 프로토콜은 TCP와 UDP이다. 서비스가 이용하는 내부 DNS 이름은 애플리케이션 이름으로 지정한 값이 될 것이다.
+  서비스 타입과는 무관하게, 서비스 생성을 선택해서 컨테이너의 (들어오는 패킷의) 포트를 리슨한다면,
+  두 개의 포트를 정의해야 한다.
+  서비스는 컨테이너가 바라보는 타겟 포트와 (들어오는 패킷의) 맵핑하는 포트가 만들어져야 할 것이다.
+  서비스는 배포된 파드에 라우팅 될 것이다. 지원하는 프로토콜은 TCP와 UDP이다.
+  서비스가 이용하는 내부 DNS 이름은 애플리케이션 이름으로 지정한 값이 될 것이다.
 
 만약 필요하다면, 더 많은 세팅을 지정할 수 있는 **자세한 옵션 보기** 섹션에서 확장할 수 있다.
 
-- **설명**: 입력하는 텍스트값은 디플로이먼트에 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/) 으로 추가될 것이고, 애플리케이션의 세부사항에 표시될 것이다.
+- **설명**: 입력하는 텍스트값은 디플로이먼트에
+  [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)으로
+  추가될 것이고, 애플리케이션의 세부사항에 표시될 것이다.
 
-- **레이블**: 애플리케이션에 사용되는 기본적인 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)은 애플리케이션 이름과 버전이다. 릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스, 그리고 파드를 생성할 때 추가적으로 정의할 수 있다.
+- **레이블**: 애플리케이션에 사용되는 기본적인 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)은
+  애플리케이션 이름과 버전이다.
+  릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스, 그리고 파드를
+  생성할 때 추가적으로 정의할 수 있다.
 
   예를 들면:
 
@@ -104,66 +136,111 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
   track=stable
   ```
 
-- **네임스페이스**: 쿠버네티스는 동일한 물리 클러스터를 바탕으로 여러 가상의 클러스터를 제공한다. 이러한 가상 클러스터들을 [네임스페이스](/docs/tasks/administer-cluster/namespaces/)라고 부른다. 논리적으로 명명된 그룹으로 리소스들을 분할 할 수 있다.
+- **네임스페이스**: 쿠버네티스는 동일한 물리 클러스터를 바탕으로 여러 가상의 클러스터를 제공한다.
+  이러한 가상 클러스터들을 [네임스페이스](/docs/tasks/administer-cluster/namespaces/)라고 부른다.
+  논리적으로 명명된 그룹으로 리소스들을 분할할 수 있다.
 
-  대시보드는 드롭다운 리스트로 가능한 모든 네임스페이스를 제공하고, 새로운 네임스페이스를 생성할 수 있도록 한다. 네임스페이스 이름은 최대 63개의 영숫자 단어와 대시(-)를 포함하고 있지만 대문자를 가지지 못한다.
-  네임스페이스 이름은 숫자로만 구성할 수 없다. 만약 이름을 10이라는 숫자로 세팅한다면, 파드는 기본 네임스페이스로 배정하게 될 것이다.
+  대시보드는 드롭다운 리스트로 가능한 모든 네임스페이스를 제공하고, 새로운 네임스페이스를 생성할 수 있도록 한다.
+  네임스페이스 이름은 최대 63개의 영숫자 단어와 대시(-)를 포함하고 있지만 대문자를 가지지 못한다.
+  네임스페이스 이름은 숫자로만 구성할 수 없다.
+  만약 이름을 10이라는 숫자로 세팅한다면, 파드는 기본 네임스페이스로 배정하게 될 것이다.
 
-  네임스페이스 생성이 성공하는 경우, 생성된 네임스페이스가 기본으로 선택된다. 만약 생성에 실패하면, 첫번째 네임스페이스가 선택된다.
+  네임스페이스 생성이 성공하는 경우, 생성된 네임스페이스가 기본으로 선택된다.
+  만약 생성에 실패하면, 첫번째 네임스페이스가 선택된다.
 
-- **이미지 풀(Pull) 시크릿**: 특정 도커 컨테이너 이미지가 프라이빗한 경우, [풀(Pull) 시크릿](/docs/concepts/configuration/secret/) 증명을 요구한다.
+- **이미지 풀(Pull) 시크릿**:
+  특정 도커 컨테이너 이미지가 프라이빗한 경우,
+  [풀(Pull) 시크릿](/docs/concepts/configuration/secret/) 자격 증명을 요구한다.
 
-  대시보드는 가능한 모든 시크릿을 드롭다운 리스트로 제공하며, 새로운 시크릿을 생성 할 수 있도록 한다. 시크릿 이름은 예를 들어 `new.image-pull.secret` 과 같이 DNS 도메인 이름 구문으로 따르기로 한다. 시크릿 내용은 base64 인코딩 방식이며, [`.dockercfg`](/ko/docs/concepts/containers/images/#파드에-imagepullsecrets-명시) 파일로 정의된다. 시크릿 이름은 최대 253 문자를 포함할 수 있다.
+  대시보드는 가능한 모든 시크릿을 드롭다운 리스트로 제공하며, 새로운 시크릿을 생성할 수 있도록 한다.
+  시크릿 이름은 예를 들어 `new.image-pull.secret` 과 같이 DNS 도메인 이름 구문으로 따르기로 한다.
+  시크릿 내용은 base64 인코딩 방식이며,
+  [`.dockercfg`](/ko/docs/concepts/containers/images/#파드에-imagepullsecrets-명시) 파일로 정의된다.
+  시크릿 이름은 최대 253 문자를 포함할 수 있다.
 
   이미지 풀(Pull) 시크릿의 생성이 성공한 경우, 기본으로 선택된다. 만약 생성에 실패하면, 시크릿은 허용되지 않는다.
 
-- **CPU 요구 사항 (cores)** 와 **메모리 요구 사항 (MiB)**: 컨테이너를 위한 최소 [리소스 상한](/docs/tasks/configure-pod-container/limit-range/)을 정의할 수 있다. 기본적으로, 파드는 CPU와 메모리 상한을 두지 않고 동작한다.
+- **CPU 요구 사항 (cores)** 와 **메모리 요구 사항 (MiB)**:
+  컨테이너를 위한 최소 [리소스 상한](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)을
+  정의할 수 있다. 기본적으로, 파드는 CPU와 메모리 상한을 두지 않고 동작한다.
 
-- **커맨드 실행** 와 **커맨드 인수 실행**: 기본적으로, 컨테이너는 선택된 도커 이미지의 [기본 엔트리포인트 커맨드](/ko/docs/tasks/inject-data-application/define-command-argument-container/)를 실행한다. 커맨드 옵션과 인자를 기본 옵션에 우선 적용하여 사용할 수 있다.
+- **커맨드 실행** 와 **커맨드 인수 실행**:
+  기본적으로, 컨테이너는 선택된 도커 이미지의
+  [기본 엔트리포인트 커맨드](/ko/docs/tasks/inject-data-application/define-command-argument-container/)를 실행한다.
+  커맨드 옵션과 인자를 기본 옵션에 우선 적용하여 사용할 수 있다.
 
-- **특권을 가진(privileged) 상태로 실행**: 다음 세팅은 호스트에서 루트 권한을 가진 프로세스들이 [특권을 가진 컨테이너](/ko/docs/concepts/workloads/pods/pod/#파드-컨테이너의-특권-privileged-모드)의 프로세스들과 동등한 지 아닌지 정의한다. 특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다.
+- **특권을 가진(privileged) 상태로 실행**: 다음 세팅은 호스트에서 루트 권한을 가진 프로세스들이
+  [특권을 가진 컨테이너](/ko/docs/concepts/workloads/pods/pod/#파드-컨테이너의-특권-privileged-모드)의
+  프로세스들과 동등한지 아닌지 정의한다.
+  특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다.
 
-- **환경 변수**: 쿠버네티스 서비스를 [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다. 환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다. 애플리케이션들이 서비스를 찾는데 사용된다. 값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다.
+- **환경 변수**: 쿠버네티스 서비스를
+  [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다.
+  환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다.
+  애플리케이션들이 서비스를 찾는데 사용된다.
+  값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다.
 
 ### YAML 또는 JSON 파일 업로드
 
-쿠버네티스는 선언적인 설정을 제공한다. 이 방식으로 모든 설정은 쿠버네티스 [API](/ko/docs/concepts/overview/kubernetes-api/) 리소스 스키마를 이용하여 YAML 또는 JSON 설정 파일에 저장한다.
+쿠버네티스는 선언적인 설정을 제공한다.
+이 방식으로 모든 설정은 쿠버네티스 [API](/ko/docs/concepts/overview/kubernetes-api/) 리소스 스키마를
+이용하여 YAML 또는 JSON 설정 파일에 저장한다.
 
-배포 마법사를 통해 애플리케이션 세부사항들을 지정하는 대신, 애플리케이션을 YAML 또는 JSON 파일로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다.
+배포 마법사를 통해 애플리케이션 세부사항들을 지정하는 대신,
+애플리케이션을 YAML 또는 JSON 파일로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다.
 
 ## 대시보드 사용
 다음 섹션들은 어떻게 제공하고 어떻게 사용할 수 있는지에 대한 쿠버네티스 대시보드 UI의 모습을 보여준다.
 
 ### 탐색
 
-클러스터에 정의된 쿠버네티스 오프젝트가 있으면, 대시보드는 초기화된 뷰를 제공한다. 기본적으로 _기본_ 네임스페이스의 오프젝트만이 보이는데, 이는 탐색 창에 위치한 네임스페이스 셀렉터를 이용해 변경할 수 있다.
+클러스터에 정의된 쿠버네티스 오프젝트가 있으면, 대시보드는 초기화된 뷰를 제공한다.
+기본적으로 _기본_ 네임스페이스의 오프젝트만이 보이는데,
+이는 탐색 창에 위치한 네임스페이스 셀렉터를 이용해 변경할 수 있다.
 
 대시보드는 몇가지 메뉴 카테고리 중에서 대부분의 쿠버네티스 오브젝트 종류와 그룹을 보여준다.
 
 #### 어드민 개요
-클러스터와 네임스페이스 관리자에게 대시보드는 노드, 네임스페이스 그리고 퍼시스턴트 볼륨과 세부사항들이 보여진다. 노드는 모든 노드를 통틀어 CPU와 메모리 사용량을 보여준다. 세부사항은 각 노드들에 대한 사용량, 사양, 상태, 할당된 리소스, 이벤트 그리고 노드에서 돌아가는 파드를 보여준다.
+클러스터와 네임스페이스 관리자에게 대시보드는 노드, 네임스페이스 그리고 퍼시스턴트 볼륨과 세부사항들이 보여진다.
+노드는 모든 노드를 통틀어 CPU와 메모리 사용량을 보여준다.
+세부사항은 각 노드들에 대한 사용량, 사양, 상태,
+할당된 리소스, 이벤트 그리고 노드에서 돌아가는 파드를 보여준다.
 
 #### 워크로드
-선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. 애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet) 등)를 보여주고 각각의 워크로드 종류는 따로 보여진다. 리스트는 예를 들어 레플리카셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 워크로드에 대한 실용적인 정보를 요약한다.
 
-워크로드에 대한 세부적인 것들은 상태와 사양 정보, 오프젝트들 간의 관계를 보여준다. 예를 들어, 레플리카셋으로 관리하는 파드들 또는 새로운 레플리카셋과 디플로이먼트를 위한 Horizontal Pod Autoscalers 이다.
+선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다.
+애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet) 등)를 보여주고
+각각의 워크로드 종류는 따로 보여진다.
+리스트는 예를 들어 레플리카셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은
+워크로드에 대한 실용적인 정보를 요약한다.
+
+워크로드에 대한 세부적인 것들은 상태와 사양 정보,
+오프젝트들 간의 관계를 보여준다.
+예를 들어, 레플리카셋으로 관리하는 파드들 또는 새로운 레플리카셋과 디플로이먼트를 위한 Horizontal Pod Autoscalers 이다.
 
 #### 서비스
-외부로 노출되는 서비스들과 클러스터 내에 발견되는 서비스들을 허용하는 쿠버네티스 리소스들을 보여준다. 이러한 이유로 서비스와 인그레스는 클러스터간의 연결을 위한 내부 엔드포인트들과 외부 사용자를 위한 외부 엔드포인트들에 의해 타게팅된 파드들을 보여준다.
+
+외부로 노출되는 서비스들과 클러스터 내에 발견되는 서비스들을 허용하는
+쿠버네티스 리소스들을 보여준다.
+이러한 이유로 서비스와 인그레스는 클러스터간의 연결을 위한 내부 엔드포인트들과
+외부 사용자를 위한 외부 엔드포인트들에 의해 타게팅된 파드들을 보여준다.
 
 #### 스토리지
+
 스토리지는 애플리케이션이 데이터를 저장하기 위해 사용하는 퍼시턴트 볼륨 클레임 리소스들을 보여준다.
 
 #### 컨피그 맵과 시크릿
-클러스터에서 동작 중인 애플리케이션의 라이브 설정을 사용하는 모든 쿠버네티스 리소스들을 보여준다. 컨피그 오브젝트들을 수정하고 관리할 수 있도록 허용하며, 기본적으로는 숨겨져 있는 시크릿들을 보여준다.
+
+클러스터에서 동작 중인 애플리케이션의 라이브 설정을 사용하는 모든 쿠버네티스 리소스들을 보여준다.
+컨피그 오브젝트들을 수정하고 관리할 수 있도록 허용하며, 기본적으로는 숨겨져 있는 시크릿들을 보여준다.
 
 #### 로그 뷰어
-파드 목록과 세부사항 페이지들은 대시보드에 구현된 로그 뷰어에 링크된다. 뷰어는 단일 파드에 있는 컨테이너들의 로그들을 내려가면 볼 수 있도록 한다.
+
+파드 목록과 세부사항 페이지들은 대시보드에 구현된 로그 뷰어에 링크된다.
+뷰어는 단일 파드에 있는 컨테이너들의 로그들을 내려가면 볼 수 있도록 한다.
 
 ![Logs viewer](/images/docs/ui-dashboard-logs-view.png)
 
-
-
 ## {{% heading "whatsnext" %}}