Ko: Second Korean l10n work for release-1.20

- Update outdated files in the dev-1.20-ko.2(p1) (#25915)
- Update outdated files in the dev-1.20-ko.2(p2) (#25916)
- Fix issue with links to already translated ko documents (#25991)
- Translate reference/glossary/dynamic-volume-provisioning.md in Korean (#26047)

Co-authored-by: seokho-son <[email protected]>
Co-authored-by: Jerry Park <[email protected]>
Co-authored-by: santachopa <[email protected]>

Author: 3 people

content/ko/community/static/cncf-code-of-conduct.md

@@ -2,44 +2,44 @@
      https://github.com/cncf/foundation/blob/master/code-of-conduct.md -->
 ## CNCF 커뮤니티 행동 강령 v1.0
 
-### 참여자 행동 강령
+### 기여자 행동 강령
 
-본 프로젝트의 기여자 및 유지 관리자로서, 환영하는 분위기의 공개 커뮤니티를
-육성하기 위하여, 저희는 이슈를 보고하고, 기술 요청을 작성하며, 문서를 업데이트하며,
-pull 요청 또는 패치를 제출하고, 다른 활동에 참여하는
-모든 분들을 존중하겠다고 약속드립니다.
+본 프로젝트의 기여자 및 메인테이너(maintainer)로서 개방적이고 친근한 분위기의
+커뮤니티 조성을 위하여, 이슈 보고, 기능 요청, 문서 업데이트,
+풀 리퀘스트(pull request) 또는 패치 제출, 그리고 기타 다른 활동으로 기여하는
+모든 분들을 존중할 것을 약속합니다.
 
-저희는 경험 수준, 성별, 성 정체성과 표현, 성적 지향,
-장애, 외양, 신체 크기, 인종, 민족, 나이, 종교, 또는
-국적에 상관 없이 모두가 괴롭힘 없는 환경에서
-본 프로젝트에 참여하도록 최선을 다하고 있습니다.
+우리는 경험의 수준, 성별, 성 정체성 및 표현(gender identity and expression),
+성적 지향, 장애, 외양, 신체 크기, 인종, 민족, 나이, 종교,
+또는 국적에 상관 없이 모두가 차별 없는 환경에서 본 프로젝트에
+참여할 수 있도록 최선을 다하고 있습니다.
 
-참여자에게 금지하는 행동의 예는 다음과 같습니다.:
+참여자에게 금지하는 행위의 예시는 다음과 같습니다.
 
-*	성적 언어 또는 이미지 사용
-*	개인적인 공격
-*	시비 걸기 또는 모욕/경멸적인 코멘트
-*	공적 및 사적 괴롭힘
-*	분명한 허락을 받지 않은 타인의 사적 정보 출판,
-  예를 들어 물리적 또는 전자 주소
-*	다른 비윤리적 또는 비전문적인 행동
+-	성적인 언어 또는 이미지 사용
+-	인신 공격
+-	도발적이거나 모욕/경멸적인 코멘트
+-	공개적이거나 사적인 괴롭힘
+-	타인의 주소 및 전자주소와 같은 개인 정보의
+ 동의 없는 공개
+-	기타 비윤리적이거나 비전문적인 행동
 
-프로젝트 유지 관리자는 본 행동 강령을 위반하는 코멘트, 협약, 강령,
-위키 수정, 이슈와 다른 참여자를 제거, 수정, 삭제할 권한과
-책임을 가집니다. 본 행동 강령을 적용하여, 프로젝트 유지 관리자는 본
-프로젝트를 유지하는 모든 상황에 공정하고 일관적으로 이러한 원칙들을
-적용하기 위해 헌신해야 합니다. 프로젝트 유지 관리자는
-행동 강령이 프로젝트 팀에서 영구적으로 사라지도록 하거나 강요해서는 안됩니다.
+프로젝트 메인테이너에게는 본 행동 강령을 위반하는 코멘트, 커밋(commit),
+코드, 위키(wiki) 수정, 이슈, 그리고 그 밖의 기여에 대해서 삭제, 수정,
+거부할 수 있는 권한과 책임이 있습니다. 프로젝트 메인테이너는 프로젝트 관리의
+모든 관점에서 이러한 행동 강령 원칙을 공정하고 일관되게 적용할 것을 약속해야 합니다.
+행동 강령을 준수하지 않거나 시행하지 않는 프로젝트 메인테이너는 프로젝트 팀에서
+영구적으로 제적될 수 있습니다.
 
-본 행동 강령은 프로젝트 공간과 개인이 프로젝트 또는
-그 커뮤니티를 대표하는 공적 공간에 모두 적용됩니다.
+본 행동 강령은 프로젝트 활동 영역 내에서 뿐만 아니라 개인이 프로젝트
+또는 커뮤니티를 대변하는 공공의 활동 영역에서도 적용됩니다.
 
-Kubernetes에서의 폭력, 학대 또는 기타 허용되지 않는 행동 사례는 이메일 주소 <[email protected]>를 통해 [Kubernetes 행동 강령 위원회](https://git.k8s.io/community/committee-code-of-conduct)로 신고하실 수 있습니다. 다른 프로젝트는 CNCF 프로젝트 관리자 또는 저희 중재자인 Mishi Choudhary에게 이메일 <[email protected]>으로 연락하십시오.
+쿠버네티스(Kubernetes)에서의 폭력, 학대 또는 기타 허용되지 않는 행위는 [쿠버네티스 행동 강령 위원회](https://git.k8s.io/community/committee-code-of-conduct)에 이메일 <[email protected]>를 통해 신고할 수 있습니다. 다른 프로젝트의 경우는 CNCF 프로젝트 메인테이너 또는 중재자인 Mishi Choudhary의 이메일 <[email protected]>으로 문의해 주시기 바랍니다.
 
-본 행동강령은 참여자 Contributor Covenant (http://contributor-covenant.org)의
-버전 1.2.0을 적용하였으며,
-해당 내용은 여기 http://contributor-covenant.org/version/1/2/0/에서 확인할 수 있습니다.
+본 행동 강령은 기여자 서약 (https://contributor-covenant.org) 에서
+제공하는 버전 1.2.0을 적용하였으며, 해당 내용은
+https://contributor-covenant.org/version/1/2/0/ 에서 확인할 수 있습니다.
 
-### CNCF 커뮤니티 행동 강령
+### CNCF 이벤트 행동 강령
 
-CNCF 이벤트는 리눅스 재단의 [행동 강령](https://events.linuxfoundation.org/code-of-conduct/) 을 따르며, 해당 내용은 이벤트 페이지에서 확인할 수 있습니다. 본 강령은 위 정책과 호환할 수 있도록 설계되었으며, 또한 사건에 따라 더 많은 세부 내용을 포함합니다.
+CNCF 이벤트는 리눅스 재단의 이벤트 페이지에서 볼 수 있는 [행동 강령](https://events.linuxfoundation.org/code-of-conduct/)을 준수합니다. 이 행동 강령은 위의 정책과 호환되도록 설계되었으며, 사고 대응에 대한 세부 내용도 포함하고 있습니다.

content/ko/docs/concepts/architecture/control-plane-node-communication.md

@@ -46,7 +46,7 @@ API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다.
 이것이 가능하지 않은 경우, 신뢰할 수 없는 네트워크 또는 공용 네트워크를 통한 연결을 피하기 위해 필요한 경우 API 서버와 kubelet 사이에 [SSH 터널링](#ssh-터널)을
 사용한다.
 
-마지막으로, kubelet API를 보호하려면 [Kubelet 인증 및/또는 권한 부여](/docs/admin/kubelet-authentication-authorization/)를 활성화해야 한다.
+마지막으로, kubelet API를 보호하려면 [Kubelet 인증 및/또는 권한 부여](/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)를 활성화해야 한다.
 
 ### API 서버에서 노드, 파드 및 서비스로의 통신
 

content/ko/docs/concepts/cluster-administration/_index.md

@@ -60,7 +60,7 @@ no_list: true
 ### kubelet 보안
   * [컨트롤 플레인-노드 통신](/ko/docs/concepts/architecture/control-plane-node-communication/)
   * [TLS 부트스트래핑(bootstrapping)](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
-  * [Kubelet 인증/인가](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)
+  * [Kubelet 인증/인가](/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)
 
 ## 선택적 클러스터 서비스
 

content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md

@@ -1,12 +1,13 @@
 ---
+
 title: kubelet 가비지(Garbage) 수집 설정하기
 content_type: concept
 weight: 70
 ---
 
 <!-- overview -->
 
-가비지 수집은 사용되지 않는 이미지들과 컨테이너들을 정리하는 kubelet의 유용한 기능이다. Kubelet은 1분마다 컨테이너들에 대하여 가비지 수집을 수행하며, 5분마다 이미지들에 대하여 가비지 수집을 수행한다.
+가비지 수집은 사용되지 않는 [이미지](/ko/docs/concepts/containers/#컨테이너-이미지)들과 [컨테이너](/ko/docs/concepts/containers/)들을 정리하는 kubelet의 유용한 기능이다. Kubelet은 1분마다 컨테이너들에 대하여 가비지 수집을 수행하며, 5분마다 이미지들에 대하여 가비지 수집을 수행한다.
 
 별도의 가비지 수집 도구들을 사용하는 것은, 이러한 도구들이 존재할 수도 있는 컨테이너들을 제거함으로써 kubelet 을 중단시킬 수도 있으므로 권장하지 않는다.
 
@@ -20,7 +21,7 @@ weight: 70
 쿠버네티스는 cadvisor와 imageManager를 통하여 모든 이미지들의
 라이프사이클을 관리한다.
 
-이미지들에 대한 가비지 수집 정책에는 다음 2가지 요소가 고려된다:
+이미지들에 대한 가비지 수집 정책은 다음의 2가지 요소를 고려한다.
 `HighThresholdPercent` 와 `LowThresholdPercent`. 임계값을 초과하는
 디스크 사용량은 가비지 수집을 트리거 한다. 가비지 수집은 낮은 입계값에 도달 할 때까지 최근에 가장 적게 사용한
 이미지들을 삭제한다.

content/ko/docs/concepts/cluster-administration/system-metrics.md

@@ -1,18 +1,19 @@
 ---
 title: 쿠버네티스 컨트롤 플레인에 대한 메트릭
+
+
+
+
 content_type: concept
 weight: 60
-aliases:
-- controller-metrics.md
 ---
 
 <!-- overview -->
 
 시스템 컴포넌트 메트릭으로 내부에서 발생하는 상황을 더 잘 파악할 수 있다. 메트릭은 대시보드와 경고를 만드는 데 특히 유용하다.
 
-쿠버네티스 컨트롤 플레인의 메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)으로 출력되며 사람이 읽기 쉽다.
-
-
+쿠버네티스 컨트롤 플레인의 메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)으로 출력된다.
+이 형식은 구조화된 평문으로 디자인되어 있으므로 사람과 기계 모두가 쉽게 읽을 수 있다.
 
 <!-- body -->
 
@@ -49,36 +50,38 @@ rules:
 
 ## 메트릭 라이프사이클
 
-알파 메트릭 → 안정적인 메트릭 → 사용 중단된 메트릭 → 히든(hidden) 메트릭 → 삭제
+알파(Alpha) 메트릭 → 안정적인(Stable) 메트릭 → 사용 중단된(Deprecated) 메트릭 → 히든(Hidden) 메트릭 → 삭제된(Deleted) 메트릭
 
 알파 메트릭은 안정성을 보장하지 않는다. 따라서 언제든지 수정되거나 삭제될 수 있다.
 
-안정적인 메트릭은 변경되지 않는다는 보장을 할 수 있다. 특히 안정성은 다음을 의미한다.
+안정적인 메트릭은 변경되지 않는다는 것을 보장한다. 이것은 다음을 의미한다.
+* 사용 중단 표기가 없는 안정적인 메트릭은, 이름이 변경되거나 삭제되지 않는다.
+* 안정적인 메트릭의 유형(type)은 수정되지 않는다.
 
-* 메트릭 자체는 삭제되거나 이름이 변경되지 않는다
-* 메트릭 유형은 수정되지 않는다
+사용 중단된 메트릭은 해당 메트릭이 결국 삭제된다는 것을 나타내지만, 아직은 사용 가능하다는 뜻이다.
+이 메트릭은 어느 버전에서부터 사용 중단된 것인지를 표시하는 어노테이션을 포함한다.
 
-사용 중단된 메트릭은 메트릭이 결국 삭제된다는 것을 나타낸다. 어떤 버전을 찾으려면, 해당 메트릭이 어떤 쿠버네티스 버전에서부터 사용 중단될 것인지를 고려하는 내용을 포함하는 어노테이션을 확인해야 한다.
+예를 들면,
 
-사용 중단되기 전에는 아래와 같다.
+* 사용 중단 이전에는 다음과 같다.
 
 ```
 # HELP some_counter this counts things
 # TYPE some_counter counter
 some_counter 0
 ```
 
-사용 중단된 이후에는 아래와 같다.
+* 사용 중단 이후에는 다음과 같다.
 
 ```
 # HELP some_counter (Deprecated since 1.15.0) this counts things
 # TYPE some_counter counter
 some_counter 0
 ```
 
-메트릭이 일단 숨겨지면 기본적으로 메트릭은 수집용으로 게시되지 않는다. 히든 메트릭을 사용하려면, 관련 클러스터 컴포넌트의 구성을 오버라이드(override)해야 한다.
+히든 메트릭은 깔끔함(scraping)을 위해 더 이상 게시되지는 않지만, 여전히 사용은 가능하다. 히든 메트릭을 사용하려면, [히든 메트릭 표시](#히든-메트릭-표시) 섹션을 참고한다.
 
-메트릭이 삭제되면, 메트릭이 게시되지 않는다. 오버라이드해서 이를 변경할 수 없다.
+삭제된 메트릭은 더 이상 게시되거나 사용할 수 없다.
 
 
 ## 히든 메트릭 표시
@@ -128,6 +131,7 @@ cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
 cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
 ```
 
+
 ### kube-scheduler 메트릭
 
 {{< feature-state for_k8s_version="v1.20" state="alpha" >}}

content/ko/docs/concepts/configuration/configmap.md

@@ -225,7 +225,6 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최
 그러나, kubelet은 로컬 캐시를 사용해서 컨피그맵의 현재 값을 가져온다.
 캐시 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의
 `ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용해서 구성할 수 있다.
-
 컨피그맵은 watch(기본값), ttl 기반 또는 API 서버로 직접
 모든 요청을 리디렉션할 수 있다.
 따라서 컨피그맵이 업데이트되는 순간부터 새 키가 파드에 업데이트되는 순간까지의
@@ -262,12 +261,10 @@ data:
 immutable: true
 ```
 
-{{< note >}}
 컨피그맵을 immutable로 표시하면, 이 변경 사항을 되돌리거나
 `data` 또는 `binaryData` 필드 내용을 변경할 수 _없다_. 컨피그맵만
 삭제하고 다시 작성할 수 있다. 기존 파드는 삭제된 컨피그맵에 대한 마운트 지점을
 유지하므로, 이러한 파드를 다시 작성하는 것을 권장한다.
-{{< /note >}}
 
 ## {{% heading "whatsnext" %}}
 

content/ko/docs/concepts/configuration/secret.md

@@ -349,7 +349,7 @@ data:
 
 부트스트랩 타입 시크릿은 `data` 아래 명시된 다음의 키들을 가진다.
 
-- `token_id`: 토큰 식별자로 임의의 6개 문자의 문자열. 필수 사항.
+- `token-id`: 토큰 식별자로 임의의 6개 문자의 문자열. 필수 사항.
 - `token-secret`: 실제 토큰 시크릿으로 임의의 16개 문자의 문자열. 필수 사항.
 - `description`: 토큰의 사용처를 설명하는 사람이 읽을 수 있는
   문자열. 선택 사항.

content/ko/docs/concepts/overview/kubernetes-api.md

@@ -17,8 +17,8 @@ card:
 최종 사용자, 클러스터의 다른 부분 그리고 외부 컴포넌트가 서로 통신할
 수 있도록 HTTP API를 제공한다.
 
-쿠버네티스 API를 사용하면 쿠버네티스 API 오브젝트(예:
-파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의하고 조작할 수 있다.
+쿠버네티스 API를 사용하면 쿠버네티스의 API 오브젝트(예:
+파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의(query)하고 조작할 수 있다.
 
 대부분의 작업은 [kubectl](/docs/reference/kubectl/overview/)
 커맨드 라인 인터페이스 또는 API를 사용하는

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

@@ -58,14 +58,14 @@ metadata:
 
 ## 애플리케이션과 애플리케이션 인스턴스
 
-애플리케이션은 동일한 쿠버네티스 클러스터에, 
+애플리케이션은 동일한 쿠버네티스 클러스터에,
 심지어는 동일한 네임스페이스에도 한번 또는 그 이상 설치될 수 있다. 예를 들어, 하나의 쿠버네티스 클러스터에
-워드프레스가 여러 번 설치되어 각각 서로 다른 웹사이트를 서비스할 수 있다.
+WordPress가 여러 번 설치되어 각각 서로 다른 웹사이트를 서비스할 수 있다.
 
-애플리케이션의 이름과 애플리케이션 인스턴스 이름은 별도로 기록된다. 
-예를 들어 워드프레스는 애플리케이션 이름으로 `app.kubernetes.io/name` 이라는 레이블에 `wordpress` 라는 값을 가지며, 
-애플리케이션 인스턴스 이름으로는 `app.kubernetes.io/instance` 라는 레이블에 
-`wordpress-abcxzy` 라는 값을 가진다. 이를 통해 애플리케이션과 애플리케이션 인스턴스를 
+애플리케이션의 이름과 애플리케이션 인스턴스 이름은 별도로 기록된다.
+예를 들어 WordPress는 애플리케이션 이름으로 `app.kubernetes.io/name` 이라는 레이블에 `wordpress` 라는 값을 가지며,
+애플리케이션 인스턴스 이름으로는 `app.kubernetes.io/instance` 라는 레이블에
+`wordpress-abcxzy` 라는 값을 가진다. 이를 통해 애플리케이션과 애플리케이션 인스턴스를
 식별할 수 있다. 모든 애플리케이션 인스턴스는 고유한 이름을 가져야 한다.
 
 ## 예시
@@ -169,4 +169,3 @@ metadata:
 ```
 
 MySQL `StatefulSet` 과 `Service` 로 MySQL과 WordPress가 더 큰 범위의 애플리케이션에 포함되어 있는 것을 알게 된다.
-

content/ko/docs/concepts/policy/pod-security-policy.md

@@ -1,4 +1,7 @@
 ---
+
+
+
 title: 파드 시큐리티 폴리시
 content_type: concept
 weight: 30
@@ -213,12 +216,17 @@ kubectl-user create -f- <<EOF
 apiVersion: v1
 kind: Pod
 metadata:
-  name:      pause
+  name: pause
 spec:
   containers:
-    - name:  pause
+    - name: pause
       image: k8s.gcr.io/pause
 EOF
+```
+
+이것의 출력은 다음과 같을 것이다.
+
+```
 Error from server (Forbidden): error when creating "STDIN": pods "pause" is forbidden: unable to validate against any pod security policy: []
 ```
 
@@ -261,12 +269,17 @@ kubectl-user create -f- <<EOF
 apiVersion: v1
 kind: Pod
 metadata:
-  name:      pause
+  name: pause
 spec:
   containers:
-    - name:  pause
+    - name: pause
       image: k8s.gcr.io/pause
 EOF
+```
+
+이것의 출력은 다음과 같을 것이다.
+
+```
 pod "pause" created
 ```
 
@@ -278,14 +291,19 @@ kubectl-user create -f- <<EOF
 apiVersion: v1
 kind: Pod
 metadata:
-  name:      privileged
+  name: privileged
 spec:
   containers:
-    - name:  pause
+    - name: pause
       image: k8s.gcr.io/pause
       securityContext:
         privileged: true
 EOF
+```
+
+이것의 출력은 다음과 같을 것이다.
+
+```
 Error from server (Forbidden): error when creating "STDIN": pods "privileged" is forbidden: unable to validate against any pod security policy: [spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed]
 ```