Seventh Korean l10n Work For Release 1.17 (#19858)

- Translation error correction with k8s.io/ko/docs/concepts/overview/components.md (#19720)
- Error correction with overview/working-with-objects/kubernetes-objects.md (#19735)
- Fix issues with working-with-objects/namespaces.md (#19753)
- Issue with working-with-objects/object-management.md (#19740)
- Fix issue with working-with-objects/labels.md (#19763)
- Translate training/_index.html in Korean. (#19718)
- Update links to docs that reference new docs added in the dev-1.17-ko.6 branch. (#19724)
- Fix Issues with working-with-objects/names.md (#19749)
- Update to Outdated files in the dev-1.17-ko.7 branch (#19712)
- Error correction with /concepts/overview/kubernetes-api.md (#19733)
- Translation error correction in /concepts/overview/what-is-kubernetes.md (#19710)
- Typo in /contribute/participating.md (#19683)
- Correct the Korean word typo 맴버 to 멤버 (#19674)

Co-Authored-by: Jerry Park <jaehwa@gmail.com>
Co-Authored-by: Yuk, Yongsu <ysyukr@gmail.com>
Co-Authored-by: June Yi <june.yi@samsung.com>

Co-authored-by: June Yi <june.yi@samsung.com>
Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com>

content/ko/docs/concepts/workloads/controllers/cron-jobs.md

@@ -8,7 +8,7 @@ weight: 80
 
 {{< feature-state for_k8s_version="v1.8" state="beta" >}}
 
-_크론 잡은_ 시간 기반의 일정에 따라 [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/)을 만든다.
+_크론 잡은_ 시간 기반의 일정에 따라 [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)을 만든다.
 
 하나의 크론잡 객체는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다. 크론잡은 잡을 [크론](https://en.wikipedia.org/wiki/Cron)형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다.
 
@@ -23,7 +23,8 @@ _크론 잡은_ 시간 기반의 일정에 따라 [잡](/docs/concepts/workloads
 {{< /caution >}}
 
 크론잡 리소스에 대한 매니페스트를 생성할때에는 제공하는 이름이
-52자 이하인지 확인해야 한다. 이는 크론잡 컨트롤러는 제공된 잡 이름에
+유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
+이름은 52자 이하여야 한다. 이는 크론잡 컨트롤러는 제공된 잡 이름에
 11자를 자동으로 추가하고, 작업 이름의 최대 길이는
 63자라는 제약 조건이 있기 때문이다.
 

content/ko/docs/concepts/workloads/controllers/daemonset.md

@@ -33,7 +33,8 @@ YAML 파일로 데몬셋을 설명 할 수 있다. 예를 들어 아래 `daemons
 
 {{< codenew file="controllers/daemonset.yaml" >}}
 
-* YAML 파일을 기반으로 데몬셋을 생성한다.
+YAML 파일을 기반으로 데몬셋을 생성한다.
+
 ```
 kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
 ```
@@ -44,6 +45,8 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
 일반적인 설정파일 작업에 대한 정보는 [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/), 
 [컨테이너 구성하기](/ko/docs/tasks/) 그리고 [kubectl을 사용한 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다.
 
+데몬셋 오브젝트의 이름은 유효한
+[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
 데몬셋에는 [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 섹션도 필요하다.
 
 ### 파드 템플릿
@@ -61,7 +64,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
 ### 파드 셀렉터
 
 `.spec.selector` 필드는 파드 셀렉터이다. 이것은 
-[잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/)의 `.spec.selector` 와 같은 동작을 한다.
+[잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)의 `.spec.selector` 와 같은 동작을 한다.
 
 쿠버네티스 1.8 부터는 레이블이 `.spec.template` 와 일치하는 파드 셀렉터를 명시해야 한다.
 파드 셀렉터는 비워두면 더 이상 기본 값이 설정이 되지 않는다.

content/ko/docs/concepts/workloads/controllers/deployment.md

@@ -1018,6 +1018,8 @@ $ echo $?
 다른 모든 쿠버네티스 설정과 마찬가지로 디플로이먼트에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다.
 설정 파일 작업에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tutorials/stateless-application/run-stateless-application-deployment/), 
 컨테이너 구성하기 그리고 [kubectl을 사용해서 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참조한다.
+디플로이먼트 오브젝트의 이름은 유효한
+[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
 
 디플로이먼트에는 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다.
 

content/ko/docs/concepts/workloads/controllers/jobs-run-to-completion.md

@@ -36,7 +36,7 @@ weight: 70
 이 명령으로 예시를 실행할 수 있다.
 
 ```shell
-kubectl apply -f https://k8s.io/examples/controllers/job.yaml
+kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml
 ```
 ```
 job.batch/pi created
@@ -111,6 +111,7 @@ kubectl logs $pods
 ## 잡 사양 작성하기
 
 다른 쿠버네티스의 설정과 마찬가지로 잡에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다.
+잡의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
 
 잡에는 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다.
 

content/ko/docs/concepts/workloads/controllers/replicaset.md

@@ -54,22 +54,26 @@ kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml
 ```
 
 현재 배포된 레플리카셋을 확인할 수 있다.
+
 ```shell
 kubectl get rs
 ```
 
 그리고 생성된 프런트엔드를 볼 수 있다.
+
 ```shell
 NAME       DESIRED   CURRENT   READY   AGE
 frontend   3         3         3       6s
 ```
 
 또한 레플리카셋의 상태를 확인할 수 있다.
+
 ```shell
 kubectl describe rs/frontend
 ```
 
 출력은 다음과 유사할 것이다.
+
 ```shell
 Name:         frontend
 Namespace:    default
@@ -99,11 +103,13 @@ Events:
 ```
 
 마지막으로 파드가 올라왔는지 확인할 수 있다.
+
 ```shell
 kubectl get pods
 ```
 
 다음과 유사한 파드 정보를 볼 수 있다.
+
 ```shell
 NAME             READY   STATUS    RESTARTS   AGE
 frontend-b2zdv   1/1     Running   0          6m36s
@@ -113,11 +119,13 @@ frontend-wtsmm   1/1     Running   0          6m36s
 
 또한 파드들의 소유자 참조 정보가 해당 프런트엔드 레플리카셋으로 설정되어 있는지 확인할 수 있다.
 확인을 위해서는 실행 중인 파드 중 하나의 yaml을 확인한다.
+
 ```shell
 kubectl get pods frontend-b2zdv -o yaml
 ```
 
 메타데이터의 ownerReferences 필드에 설정되어있는 프런트엔드 레플리카셋의 정보가 다음과 유사하게 나오는 것을 볼 수 있다.
+
 ```shell
 apiVersion: v1
 kind: Pod
@@ -162,11 +170,13 @@ kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml
 즉시 종료된다.
 
 파드를 가져온다.
+
 ```shell
 kubectl get pods
 ```
 
 결과에는 새로운 파드가 이미 종료되었거나 종료가 진행 중인 것을 보여준다.
+
 ```shell
 NAME             READY   STATUS        RESTARTS   AGE
 frontend-b2zdv   1/1     Running       0          10m
@@ -177,17 +187,20 @@ pod2             0/1     Terminating   0          1s
 ```
 
 파드를 먼저 생성한다.
+
 ```shell
 kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml
 ```
 
 그 다음 레플리카셋을 생성한다.
+
 ```shell
 kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml
 ```
 
 레플리카셋이 해당 파드를 소유한 것을 볼 수 있으며 새 파드 및 기존 파드의 수가 
 레플리카셋이 필요로 하는 수와 일치할 때까지 사양에 따라 신규 파드만 생성한다. 파드를 가져온다.
+
 ```shell
 kubectl get pods
 ```
@@ -209,6 +222,9 @@ pod2             1/1     Running   0          36s
 쿠버네티스 1.9에서의 레플리카셋의 kind에 있는 API 버전 `apps/v1`은 현재 버전이며, 기본으로 활성화 되어있다. API 버전 `apps/v1beta2`은 사용 중단(deprecated)되었다.
 API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한다.
 
+레플리카셋 오브젝트의 이름은 유효한
+[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
+
 레플리카셋도 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)이 필요하다.
 
 ### 파드 템플릿

content/ko/docs/concepts/workloads/controllers/replicationcontroller.md

@@ -113,6 +113,8 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
 ## 레플리케이션 컨트롤러의 Spec 작성
 
 다른 모든 쿠버네티스 컨피그와 마찬가지로 레플리케이션 컨트롤러는 `apiVersion`, `kind`, `metadata` 와 같은 필드가 필요하다.
+레플리케이션 컨트롤러 오브젝트의 이름은 유효한
+[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
 컨피그 파일의 동작에 관련된 일반적인 정보는 다음을 참조하라 [쿠버네티스 오브젝트 관리 ](/ko/docs/concepts/overview/working-with-objects/object-management/).
 
 레플리케이션 컨트롤러는 또한 [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 도 필요하다.
@@ -254,7 +256,7 @@ API 오브젝트에 대한 더 자세한 것은
 
 ### 레플리카셋
 
-[`레플리카셋`](/docs/concepts/workloads/controllers/replicaset/)은 새로운 [집합성 기준 레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#집합성-기준-요건) 이다.
+[`레플리카셋`](/ko/docs/concepts/workloads/controllers/replicaset/)은 새로운 [집합성 기준 레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#집합성-기준-요건) 이다.
 이것은 주로 [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/) 에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다.
 사용자 지정 업데이트 조정이 필요하거나 업데이트가 필요하지 않은 경우가 아니면 레플리카 셋을 직접 사용하는 대신 디플로이먼트를 사용하는 것이 좋다.
 

content/ko/docs/concepts/workloads/controllers/statefulset.md

@@ -100,11 +100,16 @@ spec:
 * 이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다.
 * 이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다.
 * volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)을 사용해서 안정적인 스토리지를 제공한다.
+스테이트풀셋 오브젝트의 이름은 유효한
+[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
+
 
 ## 파드 셀렉터
+
 스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정 해야 한다. 쿠버네티스 1.8 이전에서는 생략시에 `.spec.selector` 필드가 기본 설정 되었다. 1.8 과 이후 버전에서는 파드 셀렉터를 명시하지 않으면 스테이트풀셋 생성시 유효성 검증 오류가 발생하는 결과가 나오게 된다.
 
 ## 파드 신원
+
 스테이트풀셋 파드는 순서, 안정적인 네트워크 신원 그리고
 안정적인 스토리지로 구성되는 고유한 신원을 가진다. 신원은 
 파드가 어떤 노드에 있고, (재)스케줄과도 상관없이 파드에 붙어있다.

content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md

@@ -10,7 +10,7 @@ weight: 65
 
 TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을
 제한하는 TTL (time to live) 메커니즘을 제공한다. TTL 컨트롤러는 현재
-[잡(Job)](/docs/concepts/workloads/controllers/jobs-run-to-completion/)만
+[잡(Job)](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)만
 처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를
 처리하도록 확장될 수 있다.
 
@@ -28,7 +28,7 @@ TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을
 ## TTL 컨트롤러
 
 현재의 TTL 컨트롤러는 잡만 지원한다. 클러스터 운영자는
-[예시](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
+[예시](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/#완료된-잡을-자동으로-정리)
 와 같이 `.spec.ttlSecondsAfterFinished` 필드를 명시하여
 완료된 잡(`완료` 또는 `실패`)을 자동으로 정리하기 위해 이 기능을 사용할 수 있다.
 리소스의 작업이 완료된 TTL 초(sec) 후 (다른 말로는, TTL이 만료되었을 때),
@@ -79,7 +79,7 @@ TTL 컨트롤러는 쿠버네티스 리소스에
 
 {{% capture whatsnext %}}
 
-[자동으로 잡 정리](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
+[자동으로 잡 정리](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/#완료된-잡을-자동으로-정리)
 
 [디자인 문서](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)