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/configuration/assign-pod-node.md

@@ -107,7 +107,8 @@ spec:
 `nodeSelector` 는 파드를 특정 레이블이 있는 노드로 제한하는 매우 간단한 방법을 제공한다.
 어피니티/안티-어피니티 기능은 표현할 수 있는 제약 종류를 크게 확장한다. 주요 개선 사항은 다음과 같다.
 
-1. 언어가 보다 표현적이다("AND 또는 정확한 일치" 만이 아니다).
+1. 어피니티/안티-어피니티 언어가 더 표현적이다. 언어는 논리 연산자인 AND 연산으로 작성된
+   정확한 매칭 항목 이외에 더 많은 매칭 규칙을 제공한다.
 2. 규칙이 엄격한 요구 사항이 아니라 "유연한(soft)"/"선호(preference)" 규칙을 나타낼 수 있기에 스케줄러가 규칙을 만족할 수 없더라도,
    파드가 계속 스케줄 되도록 한다.
 3. 노드 자체에 레이블을 붙이기보다는 노드(또는 다른 토폴로지 도메인)에서 실행 중인 다른 파드의 레이블을 제한할 수 있다.
@@ -155,9 +156,9 @@ spec:
 `nodeSelector` 와 `nodeAffinity` 를 모두 지정한다면 파드가 후보 노드에 스케줄 되기 위해서는
 *둘 다* 반드시 만족해야 한다.
 
-`nodeAffinity` 유형과 연관된 `nodeSelectorTerms` 를 지정하면, 파드를 `nodeSelectorTerms` 가 지정된 것 중 **한 가지**라도 만족하는 노드에 스케줄할 수 있다.
+`nodeAffinity` 유형과 연관된 `nodeSelectorTerms` 를 지정하면, 파드는 `nodeSelectorTerms` 를 **모두** 만족하는 노드에만 스케줄할 수 있다.
 
-`nodeSelectorTerms` 와 연관된 여러 `matchExpressions` 를 지정하면, 파드는 `matchExpressions` 를 **모두** 만족하는 노드에만 스케줄할 수 있다.
+`nodeSelectorTerms` 와 연관된 여러 `matchExpressions` 를 지정하면, 파드는 `matchExpressions` 이 지정된 것 중 **한 가지**라도 만족하는 노드에만 스케줄할 수 있다.
 
 파드가 스케줄 된 노드의 레이블을 지우거나 변경해도 파드는 제거되지 않는다. 다시 말해서 어피니티 선택은 파드를 스케줄링 하는 시점에만 작동한다.
 
@@ -224,7 +225,7 @@ spec:
 1. 어피니티와 `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티는 대해
 `topologyKey` 가 비어있는 것을 허용하지 않는다.
 2. `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티에서 `topologyKey` 를 `kubernetes.io/hostname` 로 제한하기 위해 어드미션 컨트롤러 `LimitPodHardAntiAffinityTopology` 가 도입되었다. 사용자 지정 토폴로지를에 사용할 수 있도록 하려면, 어드미션 컨트롤러를 수정하거나 간단히 이를 비활성화 할 수 있다.
-3. `preferredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티의 경우 빈 `topologyKey` 는 "all topology"("all topology"는 현재 `kubernetes.io/hostname`, `failure-domain.beta.kubernetes.io/zone` 그리고 `failure-domain.beta.kubernetes.io/region` 의 조합으로 제한된다)로 해석한다.
+3. `preferredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티는 `topologyKey` 가 비어있는 것을 허용하지 않는다.
 4. 위의 경우를 제외하고, `topologyKey` 는 적법한 어느 레이블-키도 가능하다.
 
 `labelSelector` 와 `topologyKey` 외에도 `labelSelector` 와 일치해야 하는 네임스페이스 목록 `namespaces` 를
@@ -345,7 +346,7 @@ web-server-1287567482-s330j    1/1       Running   0          7m        10.192.3
 위의 예시에서 `topologyKey:"kubernetes.io/hostname"` 과 함께 `PodAntiAffinity` 규칙을 사용해서
 두 개의 인스터스가 동일한 호스트에 있지 않도록 redis 클러스터를 배포한다.
 같은 기술을 사용해서 고 가용성을 위해 안티-어피니티로 구성된 스테이트풀셋의 예시는
-[ZooKeeper 튜토리얼](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)을 본다.
+[ZooKeeper 튜토리얼](/ko/docs/tutorials/stateful-application/zookeeper/#노드-실패-방지)을 본다.
 
 ## nodeName
 

content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md

@@ -23,7 +23,7 @@ kubeconfig 파일들을 사용하여 클러스터, 사용자, 네임스페이스
 다른 kubeconfig 파일을 사용할 수 있다.
 
 kubeconfig 파일을 생성하고 지정하는 단계별 지시사항은
-[다중 클러스터로 접근 구성하기](/docs/tasks/access-application-cluster/configure-access-multiple-clusters)를 참조한다.
+[다중 클러스터로 접근 구성하기](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)를 참조한다.
 
 {{% /capture %}}
 
@@ -97,7 +97,7 @@ kubectl config view
      두 번째 파일의 `red-user` 하위에 충돌하지 않는 항목이 있어도 버린다.
 
    `KUBECONFIG` 환경 변수 설정의 예로,
-   [KUBECONFIG 환경 변수 설정](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)를 참조한다.
+   [KUBECONFIG 환경 변수 설정](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#kubeconfig-환경-변수-설정)를 참조한다.
 
    그렇지 않다면, 병합하지 않고 기본 kubecofig 파일인 `$HOME/.kube/config`를 사용한다.
 
@@ -148,7 +148,7 @@ kubeconfig 파일에서 파일과 경로 참조는 kubeconfig 파일의 위치
 
 {{% capture whatsnext %}}
 
-* [다중 클러스터 접근 구성하기](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
+* [다중 클러스터 접근 구성하기](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
 * [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
 
 {{% /capture %}}

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

@@ -32,7 +32,7 @@ weight: 10
 
 - 가능하다면 단독 파드(즉, [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다. 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다.
 
-  명백하게 [`restartPolicy: Never`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)를 사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카 셋을 생성하고, 파드를 교체하는 전략([롤링 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-롤링-업데이트)와 같은)을 명시하는 디플로이먼트는 파드를 직접 생성하기 위해 항상 선호되는 방법이다. [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/) 또한 적절할 수 있다.
+  명백하게 [`restartPolicy: Never`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)를 사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카 셋을 생성하고, 파드를 교체하는 전략([롤링 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-롤링-업데이트)와 같은)을 명시하는 디플로이먼트는 파드를 직접 생성하기 위해 항상 선호되는 방법이다. [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/) 또한 적절할 수 있다.
 
 
 ## 서비스