Sixth Korean l10n work for release-1.15 (#16550)

* Remove duplicated sentence (+1 squashed commit) (#16265)
* Fix links to locate Korean docs (#16289)
* Fix typo (#16304)
* Modify #16364 and links in korean docs. (#16516)
* Updated outdated content in `dev-1.15-ko.6` (#16500)
* Modify #16415, #16417 korean docs. (#16501)

Co-Authored-By: 한지승 <jinh574@naver.com>
Co-Authored-By: June Yi <gochist@gmail.com>

content/ko/docs/concepts/architecture/cloud-controller.md

@@ -223,13 +223,14 @@ rules:
 
 다음은 클라우드 제공사업자들이 구현한 CCM들이다.
 
-* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
-* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
-* [Azure](https://github.com/kubernetes/cloud-provider-azure)
-* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
 * [AWS](https://github.com/kubernetes/cloud-provider-aws)
+* [Azure](https://github.com/kubernetes/cloud-provider-azure)
 * [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
+* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
+* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
 * [Linode](https://github.com/linode/linode-cloud-controller-manager)
+* [OpenStack](https://github.com/kubernetes/cloud-provider-openstack)
+* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
 
 ## 클러스터 관리
 

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

@@ -148,7 +148,7 @@ _집합성 기준_ 요건은 _일치성 기준_ 요건과 조합해서 사용할
 
 ### LIST와 WATCH 필터링
 
-LIST와 WATCH 작업은 쿼리 파라미터를 사용해서 반환되는 오브젝트 집합을 필터링하기 위해 레이블 셀럭터를 지정할 수 있다. 다음의 2가지 요건 모두 허용된다(URL 쿼리 문자열을 그대로 표기함).
+LIST와 WATCH 작업은 쿼리 파라미터를 사용해서 반환되는 오브젝트 집합을 필터링하기 위해 레이블 셀렉터를 지정할 수 있다. 다음의 2가지 요건 모두 허용된다(URL 쿼리 문자열을 그대로 표기함).
 
   * _불일치 기준_ 요건: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
   * _집합성 기준_ 요건: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`
@@ -181,11 +181,11 @@ kubectl get pods -l 'environment,environment notin (frontend)'
 
 [`서비스`](/docs/user-guide/services) 와 [`레플리케이션 컨트롤러`](/docs/user-guide/replication-controller)와 같은 일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서 [`파드`](/docs/user-guide/pods)와 같은 다른 리소스 집합을 선택한다.
 
-#### 서비스와 리플리케이션 컨트롤러
+#### 서비스와 레플리케이션 컨트롤러
 
-`서비스`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `리플레케이션 컨트롤러`가 관리하는 파드의 개체군도 레이블 셀렉터로 정의한다.
+`서비스`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `레플리케이션 컨트롤러`가 관리하는 파드의 개체군도 레이블 셀렉터로 정의한다.
 
-서비스와 리플리케이션 컨트롤러의 레이블 셀렉터는 `json` 또는 `yaml` 파일에 매핑된 _균등-기반_ 요구사항의 셀렉터만 지원한다.
+서비스와 레플리케이션 컨트롤러의 레이블 셀렉터는 `json` 또는 `yaml` 파일에 매핑된 _균등-기반_ 요구사항의 셀렉터만 지원한다.
 
 ```json
 "selector": {

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

@@ -27,16 +27,16 @@ weight: 30
 
 네임스페이스는 클러스터 자원을 ([리소스 쿼터](/docs/concepts/policy/resource-quotas/)를 통해) 복수의 사용자 사이에서 나누는 방법이다.
 
-다음 버전의 쿠버네티스에서는, 같은 네임스페이스의 오브젝트는 기본적을 동일한 접근  제어 정책을 갖게 된다.
+다음 버전의 쿠버네티스에서는, 같은 네임스페이스의 오브젝트는 기본적으로 동일한 접근  제어 정책을 갖게 된다.
 네임스페이스는 서로 중첩될 수 없으며, 각 쿠버네티스 리소스는 하나의 네임스페이스에만 있을 수 있다.
 
 같은 소프트웨어의 다른 버전과 같이 단지 약간의 차이가 있는 리소스를 분리하기 위해서
 복수의 네임스페이스를 사용할 필요가 있다. 동일한 네임스페이스에 있는 리소스를
-구분하기 위해서는 [레이블](/docs/user-guide/labels)을 사용한다.
+구분하기 위해서는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 사용한다.
 
 ## 네임스페이스 다루기
 
-네임스페이스의 생성과 삭제는 [네임스페이스 관리자 가이드 문서](/docs/admin/namespace)에
+네임스페이스의 생성과 삭제는 [네임스페이스 관리자 가이드 문서](/docs/tasks/administer-cluster/namespaces/)에
 기술되어 있다.
 
 ### 네임스페이스 조회
@@ -94,7 +94,7 @@ kubectl config view | grep namespace:
 
 대부분의 쿠버네티스 리소스(예를 들어, 파드, 서비스, 레플리케이션 컨트롤러 외)는
 네임스페이스에 속한다. 하지만 네임스페이스 리소스 자체는 네임스페이스에 속하지 않는다.
-그리고 [nodes](/docs/admin/node)나 퍼시스턴트 볼륨과 같은 저수준 리소스는 어느
+그리고 [nodes](/ko/docs/concepts/architecture/nodes/)나 퍼시스턴트 볼륨과 같은 저수준 리소스는 어느
 네임스페이스에도 속하지 않는다.
 
 네임스페이스에 속하지 않는 쿠버네티스 리소스를 조회하기 위해서는,

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

@@ -20,7 +20,7 @@ _파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지
 컨테이너 이전의 세상에서 같은 물리적 또는 가상의 머신에서 실행되는 것은
 같은 논리적 호스트에서 실행되고 있는 것을 의미한다.
 
-쿠버네티스는는 도커 이외에도 많은 컨테이너 런타임을 지원하지만,
+쿠버네티스는 도커 이외에도 많은 컨테이너 런타임을 지원하지만,
 도커는 가장 일반적으로 알려진 런타임이므로 도커 용어로 파드를 설명하는 것이 도움이 된다.
 
 파드의 공유 컨텍스트는 Linux 네임 스페이스, 컨트롤 그룹(cgroup) 및
@@ -189,7 +189,7 @@ API에서 파드를 즉시 제거하므로 동일한 이름으로 새 파드를
 Kubernetes v1.1부터, 파드의 모든 컨테이너는 컨테이너 스펙의 `SecurityContext`의 `privileged` 플래그를 사용하여 특권 모드를 사용할 수 있다. 이것은 네트워크 스택을 조작하고 장치에 액세스하는 것과 같은 Linux 기능을 사용하려는 컨테이너에 유용하다. 컨테이너 내의 프로세스는 컨테이너 외부의 프로세스에서 사용할 수 있는 거의 동일한 권한을 갖는다. 특권 모드를 사용하면 네트워크 및 볼륨 플러그인을 kubelet에 컴파일 할 필요가 없는 별도의 파드로 쉽게 만들 수 있다.
 
 마스터가 Kubernetes v1.1 이상에서 실행 중이고, 노드가 v1.1 보다 낮은 버전을 실행중인 경우 새 권한이 부여 된 파드는 api-server에 의해 승인되지만 시작되지는 않는다. 이것들은 pending 상태가 될 것이다.
-사용자가 `kubectl describe pod FooPodName` 을 호출하면 사용자는 파드가 사용자가 `kubectl describe pod FooPodName` 을 호출하면 사용자는 파드가 pending 상태에 있는 이유를 볼 수 있다. describe 명령 출력의 이벤트 테이블은 다음과 같다.
+사용자가 `kubectl describe pod FooPodName` 을 호출하면 사용자는 파드가 pending 상태에 있는 이유를 볼 수 있다. describe 명령 출력의 이벤트 테이블은 다음과 같다.
 `Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'`
 
 마스터가 v1.1보다 낮은 버전에서 실행중인 경우 특권을 갖는 파드를 만들 수 없다. 유저가 특권을 갖는 컨테이너가 있는 파드를 만들려고 하면 다음과 같은 오류가 발생한다.

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

@@ -5,7 +5,6 @@ date: 2019-05-12
 full_link:
 short_description: >
   컨테이너화된 다양한 애플리케이션들이 실행되는 레이어.
-
 aka:
 tags:
 - fundamental

content/ko/docs/reference/glossary/static-pod.md

@@ -2,13 +2,17 @@
 title: 스태틱 파드(Static Pod)
 id: static-pod
 date: 2019-02-12
-full_link: /docs/tasks/administer-cluster/static-pod/
+full_link: /docs/tasks/configure-pod-container/static-pod/
 short_description: >
   특정 노드의 Kubelet 데몬이 직접 관리하는 파드
 
-aka:
+aka: 
 tags:
 - fundamental
 ---
- API 서버가 관찰하지 않고, 특정 노드의 Kubelet 데몬이
- 직접 관리하는 {{< glossary_tooltip text="파드" term_id="pod" >}}.
+
+특정 노드의 Kubelet 데몬이
+ 직접 관리하는 {{< glossary_tooltip text="파드" term_id="pod" >}}로,
+ <!--more-->
+ 
+API 서버가 관찰하지 않는다.

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

@@ -9,20 +9,15 @@ short_description: >
 aka: 
 tags:
 - fundamental
-- core-object
-- workload
 ---
-  워크로드는 클러스터의 컨테이너를 동작시키고 관리하기 위해 사용하는 오브젝트이다.
+  워크로드는 쿠버네티스에서 구동되는 애플리케이션이다.
 
 <!--more--> 
 
-쿠버네티스는 
-애플리케이션의 현재 상태에 따라 워크로드의 디플로이먼트와 업데이트를 수행한다.
-워크로드는 데몬셋, 디플로이먼트, 잡, 파드, 레플리카셋, 레플리케이션컨트롤러, 스테이트풀셋과 같은 오브젝트를 포함한다.
+데몬셋, 디플로이먼트, 잡, 레플리카셋, 그리고 스테이트풀셋 오브젝트를 포함해서
+서로 다른 워크로드의 유형이나 부분을 대표하는 다양한 핵심 오브젝트.
 
-예를 들어, 웹 요소와 데이터베이스 요소가 있는 워크로드는 
-데이터베이스를 {{< glossary_tooltip text="파드" term_id="pod" >}}의 한 
-{{< glossary_tooltip text="스테이트풀셋" term_id="StatefulSet" >}} 안에서 실행할 것이며, 
-웹서버를 많은 웹 앱 {{< glossary_tooltip text="파드" term_id="pod" >}}로 구성된 
-{{< glossary_tooltip text="디플로이먼트" term_id="Deployment" >}}를 통해 실행할 것이다.
+예를 들어, 웹 서버와 데이터베이스가 있는 워크로드는
+데이터베이스를 한 {{< glossary_tooltip text="스테이트풀셋" term_id="StatefulSet" >}} 안에서 실행할 것이며, 
+웹서버를 {{< glossary_tooltip text="디플로이먼트" term_id="Deployment" >}}를 통해 실행할 것이다.
 

content/ko/docs/setup/_index.md

@@ -105,5 +105,6 @@ card:
 | [Tencent Cloud](https://intl.cloud.tencent.com/)  | [Tencent Kubernetes Engine](https://intl.cloud.tencent.com/product/tke) |   ✔   |   ✔ |    |      |   ✔  |
 | [VEXXHOST](https://vexxhost.com/)         | ✔             | ✔      |             |      |          |
 | [VMware](https://cloud.vmware.com/) | [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks)              |[VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks)        |   [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks)          | [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks)      |          |[VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks)
+| [Z.A.R.V.I.S.](https://zarvis.ai/) | ✔ | | | | | |
 
 {{% /capture %}}