Seventh Korean l10n work for release 1.18

- Translate reference/command-line-tools-reference/feature-gates.md int… (#22240)
- Fix issue of broken links to translated docs (#22105)
- Fix issue of document link in some ko documents (#22379)
- Translate tasks/administer-cluster/access-cluster-services.md into Ko… (#21776)
- Fix issue with 'Linux' and 'Windows' notation in Korean docs (#22362)
- Fix issue of broken links to translated docs #2 (#22270)
- Fix issue with k8s.io/ko/docs/concepts/overview/kubernetes-api.md (#22261)
- Fix issue with k8s.io/ko/docs/concepts/overview/working-with-objects/ (#22263)
- Fix incorrect notation of 'directory' into Korean (#22155)
- Fix issue with k8s.io/ko/docs/concepts/overview/components.md (#22232)
- Update outdated files in dev-1.18-ko.7 (#22128)
- Modify spacing term ReplicaSet in Korean (#22148)
- Translate tasks/administer-cluster/extended-resource-node.md into Korean (#21849)
- Translate tasks/administer-cluster/access-cluster-api.md into Korean (#21730)

Co-authored-by: Jerry Park <[email protected]>
Co-authored-by: woopyoung <[email protected]>
Co-authored-by: coolguyhong <[email protected]>
Co-authored-by: PyungHo Yoon <[email protected]>
Co-authored-by: Seokho Son <[email protected]>
Co-authored-by: jmyung <[email protected]>
Co-authored-by: Ian Y. Choi <[email protected]>

content/ko/docs/concepts/_index.md

@@ -41,7 +41,7 @@ weight: 40
 * [데몬셋(DaemonSet)](/ko/docs/concepts/workloads/controllers/daemonset/)
 * [스테이트풀셋(StatefulSet)](/ko/docs/concepts/workloads/controllers/statefulset/)
 * [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/)
-* [잡(Job)](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)
+* [잡(Job)](/ko/docs/concepts/workloads/controllers/job/)
 
 ## 쿠버네티스 컨트롤 플레인
 
@@ -66,6 +66,5 @@ weight: 40
 
 
 개념 페이지를 작성하기를 원하면,
-개념 페이지 유형에 대한 정보가 있는
-[페이지 컨텐츠 유형](/docs/contribute/style/page-content-types/#concept)을 참조한다.
-
+개념 페이지 타입에 대한 정보가 있는
+[페이지 컨텐츠 타입](/docs/contribute/style/page-content-types/#concept)을 참고한다.

content/ko/docs/concepts/architecture/nodes.md

@@ -63,19 +63,19 @@ kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록
 {{< /note >}}
 
 노드 오브젝트의 이름은 유효한
-[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
+[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
 
 ### 노드에 대한 자체-등록
 
-kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API 서버에 
+kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API 서버에
 스스로 등록을 시도할 것이다. 이는 대부분의 배포판에 의해 이용되는, 선호하는 패턴이다.
 
 자체-등록에 대해, kubelet은 다음 옵션과 함께 시작된다.
 
   - `--kubeconfig` - apiserver에 스스로 인증하기 위한 자격증명에 대한 경로.
   - `--cloud-provider` - 자신에 대한 메터데이터를 읽기 위해 어떻게 {{< glossary_tooltip text="클라우드 제공자" term_id="cloud-provider" >}}와 소통할지에 대한 방법.
   - `--register-node` - 자동으로 API 서버에 등록.
-  - `--register-with-taints` - 주어진 {{< glossary_tooltip text="테인트(taint)" term_id="taint" >}} 리스트(콤마로 분리된 `<key>=<value>:<effect>`)를 가진 노드 등록. 
+  - `--register-with-taints` - 주어진 {{< glossary_tooltip text="테인트(taint)" term_id="taint" >}} 리스트(콤마로 분리된 `<key>=<value>:<effect>`)를 가진 노드 등록.
 
     `register-node`가 거짓이면 동작 안 함.
   - `--node-ip` - 노드의 IP 주소.
@@ -180,15 +180,15 @@ kubectl describe node <insert-node-name-here>
 ready 컨디션의 상태가 `pod-eviction-timeout` ({{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}에 전달된 인수) 보다 더 길게 `Unknown` 또는 `False`로 유지되는 경우, 노드 상에 모든 파드는 노드 컨트롤러에 의해 삭제되도록 스케줄 된다. 기본 축출 타임아웃 기간은 **5분** 이다. 노드에 접근이 불가할 때와 같은 경우, apiserver는 노드 상의 kubelet과 통신이 불가하다. apiserver와의 통신이 재개될 때까지 파드 삭제에 대한 결정은 kubelet에 전해질 수 없다. 그 사이, 삭제되도록 스케줄 되어진 파드는 분할된 노드 상에서 계속 동작할 수도 있다.
 
 노드 컨트롤러가 클러스터 내 동작 중지된 것을 확신할 때까지는 파드를
-강제로 삭제하지 않는다. 파드가 `Terminating` 또는 `Unknown` 상태로 있을 때 접근 불가한 노드 상에서 
+강제로 삭제하지 않는다. 파드가 `Terminating` 또는 `Unknown` 상태로 있을 때 접근 불가한 노드 상에서
 동작되고 있는 것을 보게 될 수도 있다. 노드가 영구적으로 클러스터에서 삭제되었는지에
 대한 여부를 쿠버네티스가 기반 인프라로부터 유추할 수 없는 경우, 노드가 클러스터를 영구적으로
 탈퇴하게 되면, 클러스터 관리자는 손수 노드 오브젝트를 삭제해야 할 수도 있다.
 쿠버네티스에서 노드 오브젝트를 삭제하면 노드 상에서 동작중인 모든 파드 오브젝트가
 apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳는다.
 
 노드 수명주기 컨트롤러는 자동으로 컨디션을 나타내는
-[테인트(taints)](/docs/concepts/scheduling-eviction/taint-and-toleration/)를 생성한다.
+[테인트(taints)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 생성한다.
 스케줄러는 파드를 노드에 할당 할 때 노드의 테인트를 고려한다.
 또한 파드는 노드의 테인트를 극복(tolerate)할 수 있는 톨러레이션(toleration)을 가질 수 있다.
 
@@ -197,7 +197,7 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳
 
 ### 용량과 할당가능 {#capacity}
 
-노드 상에 사용 가능한 리소스를 나타낸다. 리소스에는 CPU, 메모리 그리고 
+노드 상에 사용 가능한 리소스를 나타낸다. 리소스에는 CPU, 메모리 그리고
 노드 상으로 스케줄 되어질 수 있는 최대 파드 수가 있다.
 
 용량 블록의 필드는 노드에 있는 리소스의 총량을 나타낸다.
@@ -221,18 +221,18 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳
 노드 컨트롤러는 노드가 생성되어 유지되는 동안 다양한 역할을 한다. 첫째는 등록 시점에
 (CIDR 할당이 사용토록 설정된 경우) 노드에 CIDR 블럭을 할당하는 것이다.
 
-두 번째는 노드 컨트롤러의 내부 노드 리스트를 클라우드 제공사업자의 
-사용 가능한 머신 리스트 정보를 근거로 최신상태로 유지하는 것이다. 클라우드 환경에서 
-동작 중일 경우, 노드상태가 불량할 때마다, 노드 컨트롤러는 
-해당 노드용 VM이 여전히 사용 가능한지에 대해 클라우드 제공사업자에게 묻는다. 사용 가능하지 않을 경우, 
+두 번째는 노드 컨트롤러의 내부 노드 리스트를 클라우드 제공사업자의
+사용 가능한 머신 리스트 정보를 근거로 최신상태로 유지하는 것이다. 클라우드 환경에서
+동작 중일 경우, 노드상태가 불량할 때마다, 노드 컨트롤러는
+해당 노드용 VM이 여전히 사용 가능한지에 대해 클라우드 제공사업자에게 묻는다. 사용 가능하지 않을 경우,
 노드 컨트롤러는 노드 리스트로부터 그 노드를 삭제한다.
 
-세 번째는 노드의 동작 상태를 모니터링 하는 것이다. 노드 컨트롤러는 
-노드가 접근 불가할 경우 (즉 노드 컨트롤러가 어떠한 사유로 하트비트 
+세 번째는 노드의 동작 상태를 모니터링 하는 것이다. 노드 컨트롤러는
+노드가 접근 불가할 경우 (즉 노드 컨트롤러가 어떠한 사유로 하트비트
 수신을 중지하는 경우, 예를 들어 노드 다운과 같은 경우이다.)
-NodeStatus의 NodeReady 컨디션을 ConditionUnknown으로 업데이트 하는 책임을 지고, 
-노드가 계속 접근 불가할 경우 나중에 노드로부터 (정상적인 종료를 이용하여) 모든 파드를 축출시킨다. 
-(ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고, 
+NodeStatus의 NodeReady 컨디션을 ConditionUnknown으로 업데이트 하는 책임을 지고,
+노드가 계속 접근 불가할 경우 나중에 노드로부터 (정상적인 종료를 이용하여) 모든 파드를 축출시킨다.
+(ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고,
 파드를 축출하기 시작하는 값은 5분이다.) 노드 컨트롤러는
 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다.
 
@@ -260,30 +260,30 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
 
 #### 안정성
 
- 대부분의 경우, 노드 컨트롤러는 초당 `--node-eviction-rate`(기본값 0.1)로 
-축출 비율을 제한한다. 이 말은 10초당 1개의 노드를 초과하여 
+ 대부분의 경우, 노드 컨트롤러는 초당 `--node-eviction-rate`(기본값 0.1)로
+축출 비율을 제한한다. 이 말은 10초당 1개의 노드를 초과하여
 파드 축출을 하지 않는다는 의미가 된다.
 
 노드 축출 행위는 주어진 가용성 영역 내 하나의 노드가 상태가 불량할
-경우 변화한다. 노드 컨트롤러는 영역 내 동시에 상태가 불량한 노드의 퍼센티지가 얼마나 되는지 
-체크한다(NodeReady 컨디션은 ConditionUnknown 또는 ConditionFalse 다.). 
-상태가 불량한 노드의 일부가 최소 
+경우 변화한다. 노드 컨트롤러는 영역 내 동시에 상태가 불량한 노드의 퍼센티지가 얼마나 되는지
+체크한다(NodeReady 컨디션은 ConditionUnknown 또는 ConditionFalse 다.).
+상태가 불량한 노드의 일부가 최소
 `--unhealthy-zone-threshold` 기본값 0.55) 가
-되면 축출 비율은 감소한다. 클러스터가 작으면 (즉 
-`--large-cluster-size-threshold` 노드 이하면 - 기본값 50) 축출은 중지되고, 
-그렇지 않으면 축출 비율은 초당 
-`--secondary-node-eviction-rate`(기본값 0.01)로 감소된다. 
-이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안 
-하나의 가용성 영역이 마스터로부터 분할되어 질 수도 있기 때문이다. 
-만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않으면, 
+되면 축출 비율은 감소한다. 클러스터가 작으면 (즉
+`--large-cluster-size-threshold` 노드 이하면 - 기본값 50) 축출은 중지되고,
+그렇지 않으면 축출 비율은 초당
+`--secondary-node-eviction-rate`(기본값 0.01)로 감소된다.
+이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안
+하나의 가용성 영역이 마스터로부터 분할되어 질 수도 있기 때문이다.
+만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않으면,
 오직 하나의 가용성 영역만 (전체 클러스터) 존재하게 된다.
 
-노드가 가용성 영역들에 걸쳐 퍼져 있는 주된 이유는 하나의 전체 영역이 
-장애가 발생할 경우 워크로드가 상태 양호한 영역으로 이전되어질 수 있도록 하기 위해서이다. 
-그러므로, 하나의 영역 내 모든 노드들이 상태가 불량하면 노드 컨트롤러는 
-`--node-eviction-rate` 의 정상 비율로 축출한다. 코너 케이스란 모든 영역이 
-완전히 상태불량 (즉 클러스터 내 양호한 노드가 없는 경우) 한 경우이다. 
-이러한 경우, 노드 컨트롤러는 마스터 연결에 문제가 있어 일부 연결이 
+노드가 가용성 영역들에 걸쳐 퍼져 있는 주된 이유는 하나의 전체 영역이
+장애가 발생할 경우 워크로드가 상태 양호한 영역으로 이전되어질 수 있도록 하기 위해서이다.
+그러므로, 하나의 영역 내 모든 노드들이 상태가 불량하면 노드 컨트롤러는
+`--node-eviction-rate` 의 정상 비율로 축출한다. 코너 케이스란 모든 영역이
+완전히 상태불량 (즉 클러스터 내 양호한 노드가 없는 경우) 한 경우이다.
+이러한 경우, 노드 컨트롤러는 마스터 연결에 문제가 있어 일부 연결이
 복원될 때까지 모든 축출을 중지하는 것으로 여긴다.
 
 또한, 노드 컨트롤러는 파드가 테인트를 허용하지 않을 때 `NoExecute` 테인트 상태의
@@ -323,7 +323,7 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
 
 {{< feature-state state="alpha" for_k8s_version="v1.16" >}}
 
-`TopologyManager` 
+`TopologyManager`
 [기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)를
 활성화 시켜두면, kubelet이 리소스 할당 결정을 할 때 토폴로지 힌트를 사용할 수 있다.
 자세한 내용은

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

@@ -33,7 +33,7 @@ content_type: concept
 * [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)은 OVN 기반의 CNI 컨트롤러 플러그인으로 클라우드 네이티브 기반 서비스 기능 체인(Service function chaining(SFC)), 다중 OVN 오버레이 네트워킹, 동적 서브넷 생성, 동적 가상 네트워크 생성, VLAN 공급자 네트워크, 직접 공급자 네트워크와 멀티 클러스터 네트워킹의 엣지 기반 클라우드 등 네이티브 워크로드에 이상적인 멀티 네티워크 플러그인이다.
 * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다.
 * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)는 가시성과 보안 모니터링 기능을 통해 쿠버네티스 파드와 비-쿠버네티스 환경 간에 폴리시 기반 네트워킹을 제공하는 SDN 플랫폼이다.
-* [Romana](http://romana.io)는 [네트워크폴리시 API](/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. Kubeadm 애드온 설치에 대한 세부 정보는 [여기](https://github.com/romana/romana/tree/master/containerize)에 있다.
+* [Romana](http://romana.io)는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. Kubeadm 애드온 설치에 대한 세부 정보는 [여기](https://github.com/romana/romana/tree/master/containerize)에 있다.
 * [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/)은 네트워킹 및 네트워크 폴리시를 제공하고, 네트워크 파티션의 양면에서 작업을 수행하며, 외부 데이터베이스는 필요하지 않다.
 
 ## 서비스 검색
@@ -54,5 +54,3 @@ content_type: concept
 더 이상 사용되지 않는 [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) 디렉터리에 다른 여러 애드온이 문서화되어 있다.
 
 잘 관리된 것들이 여기에 연결되어 있어야 한다. PR을 환영한다!
-
-

content/ko/docs/concepts/cluster-administration/cloud-providers.md

@@ -99,7 +99,7 @@ _어노테이션_ 을 사용하여 AWS의 로드 밸런서 서비스에 다른 
 * `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: 서비스에서 연결 드레이닝 타임아웃 값을 지정하는 데 사용된다.
 * `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: 서비스에서 유휴 연결 타임아웃 값을 지정하는 데 사용된다.
 * `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled`: 서비스에서 교차 영역의 로드 밸런싱을 활성화하거나 비활성화하는 데 사용된다.
-* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: 생성된 ELB에 추가할 보안 그룹을 지정하는 데 사용된다. 이는 이전에 ELB에 할당된 다른 모든 보안 그룹을 대체한다.
+* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: 생성된 ELB에 추가할 보안 그룹을 지정하는 데 사용된다. 이는 이전에 ELB에 할당된 다른 모든 보안 그룹을 대체한다. 여기에 정의된 보안 그룹은 서비스 간에 공유해서는 안된다.
 * `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`: 서비스에서 생성된 ELB에 추가할 추가적인 보안 그룹을 지정하는 데 사용된다.
 * `service.beta.kubernetes.io/aws-load-balancer-internal`: 서비스에서 내부 ELB 사용 희망을 표시하기 위해 사용된다.
 * `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`: 서비스에서 ELB에서 프록시 프로토콜을 활성화하는 데 사용된다. 현재는 모든 ELB 백엔드에서 프록시 프로토콜을 사용하도록 설정하는 `*` 값만 허용한다. 향후에는 특정 백엔드에서만 프록시 프로토콜을 설정할 수 있도록 이를 조정할 수 있게 된다.

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

@@ -19,12 +19,12 @@ weight: 10
  - 단지 자신의 컴퓨터에 쿠버네티스를 테스트를 하는지, 또는 고가용성의 멀티 노드 클러스터를 만들려고 하는지에 따라 니즈에 가장 적절한 배포판을 고르자.
  - [구글 쿠버네티스 엔진](https://cloud.google.com/kubernetes-engine/)과 같은 **호스팅된 쿠버네티스 클러스터** 를 사용할 것인지, **자신의 클러스터에 호스팅할 것인지**?
  - 클러스터가 **온프레미스** 인지, 또는 **클라우드(IaaS)** 인지? 쿠버네티스는 하이브리드 클러스터를 직접적으로 지원하지는 않는다. 대신에, 사용자는 여러 클러스터를 구성할 수 있다.
- - **만약 온프레미스에서 쿠버네티스를 구성한다면**, 어떤 [네트워킹 모델](/docs/concepts/cluster-administration/networking/)이 가장 적합한지 고려한다.
+ - **만약 온프레미스에서 쿠버네티스를 구성한다면**, 어떤 [네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/)이 가장 적합한지 고려한다.
  - 쿠버네티스 실행을 **"베어메탈" 하드웨어** 또는, **가상 머신 (VMs)** 중 어디에서 할 것 인지?
  - **단지 클러스터 동작** 만 할 것인지, 아니면 **쿠버네티스 프로젝트 코드의 적극적인 개발** 을 원하는지? 만약 후자의 경우라면,
    적극적으로 개발된 배포판을 선택한다. 몇몇 배포판은 바이너리 릴리스 밖에 없지만,
    매우 다양한 선택권을 제공한다.
- - 스스로 클러스터 구동에 필요한 [구성요소](/docs/admin/cluster-components/)에 익숙해지자.
+ - 스스로 클러스터 구동에 필요한 [구성요소](/ko/docs/concepts/overview/components/)에 익숙해지자.
 
 참고: 모든 배포판이 적극적으로 유지되는 것은 아니다. 최근 버전의 쿠버네티스로 테스트 된 배포판을 선택하자.
 
@@ -38,7 +38,7 @@ weight: 10
 
 ## 클러스터 보안
 
-* [인증서](/docs/concepts/cluster-administration/certificates/)는 다른 툴 체인을 이용하여 인증서를 생성하는 방법을 설명한다.
+* [인증서](/ko/docs/concepts/cluster-administration/certificates/)는 다른 툴 체인을 이용하여 인증서를 생성하는 방법을 설명한다.
 
 * [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은 쿠버네티스 노드에서 Kubelet에 의해 관리되는 컨테이너 환경에 대해 설명한다.
 
@@ -63,6 +63,4 @@ weight: 10
 
 * [DNS 통합](/ko/docs/concepts/services-networking/dns-pod-service/)은 DNS 이름이 쿠버네티스 서비스에 바로 연결되도록 변환하는 방법을 설명한다.
 
-* [클러스터 활동 로깅과 모니터링](/docs/concepts/cluster-administration/logging/)은 쿠버네티스 로깅이 로깅의 작동 방법과 로깅을 어떻게 구현하는지 설명한다.
-
-
+* [클러스터 활동 로깅과 모니터링](/ko/docs/concepts/cluster-administration/logging/)은 쿠버네티스 로깅이 로깅의 작동 방법과 로깅을 어떻게 구현하는지 설명한다.