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 <jaehwa@gmail.com>
Co-authored-by: woopyoung <ywp041@gmail.com>
Co-authored-by: coolguyhong <podolsmith@naver.com>
Co-authored-by: PyungHo Yoon <learder@gmail.com>
Co-authored-by: Seokho Son <shsongist@gmail.com>
Co-authored-by: jmyung <jesang.myung@gmail.com>
Co-authored-by: Ian Y. Choi <ianyrchoi@gmail.com>

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

@@ -63,11 +63,11 @@ 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은 다음 옵션과 함께 시작된다.
@@ -75,7 +75,7 @@ kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API
   - `--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,7 +180,7 @@ 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` 상태로 있을 때 접근 불가한 노드 상에서
 동작되고 있는 것을 보게 될 수도 있다. 노드가 영구적으로 클러스터에서 삭제되었는지에
 대한 여부를 쿠버네티스가 기반 인프라로부터 유추할 수 없는 경우, 노드가 클러스터를 영구적으로
 탈퇴하게 되면, 클러스터 관리자는 손수 노드 오브젝트를 삭제해야 할 수도 있다.
@@ -188,7 +188,7 @@ ready 컨디션의 상태가 `pod-eviction-timeout` ({{< glossary_tooltip text="
 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이 리소스 할당 결정을 할 때 토폴로지 힌트를 사용할 수 있다.
 자세한 내용은