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/overview/components.md

@@ -1,8 +1,11 @@
 ---
 title: 쿠버네티스 컴포넌트
 content_type: concept
+description: >
+  쿠버네티스 클러스터는 컴퓨터 집합인 노드 컴포넌트와 컨트롤 플레인
+  컴포넌트로 구성된다.
 weight: 20
-card:
+card: 
   name: concepts
   weight: 20
 ---
@@ -96,7 +99,7 @@ kube-controller-manager와 마찬가지로 cloud-controller-manager는 논리적
 애드온에 대한 네임스페이스 리소스는 `kube-system` 네임스페이스에 속한다.
 
 선택된 일부 애드온은 아래에 설명하였고, 사용 가능한 전체 확장 애드온 리스트는
-[애드온](/docs/concepts/cluster-administration/addons/)을 참조한다.
+[애드온](/ko/docs/concepts/cluster-administration/addons/)을 참조한다.
 
 ### DNS
 
@@ -117,7 +120,7 @@ kube-controller-manager와 마찬가지로 cloud-controller-manager는 논리적
 
 ### 클러스터-레벨 로깅
 
-[클러스터-레벨 로깅](/docs/concepts/cluster-administration/logging/) 메커니즘은
+[클러스터-레벨 로깅](/ko/docs/concepts/cluster-administration/logging/) 메커니즘은
 검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 진다.
 
 
@@ -127,4 +130,3 @@ kube-controller-manager와 마찬가지로 cloud-controller-manager는 논리적
 * [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 더 배우기
 * [kube-scheduler](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 더 배우기
 * etcd의 공식 [문서](https://etcd.io/docs/) 읽기
-

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

@@ -2,6 +2,9 @@
 title: 쿠버네티스 API
 content_type: concept
 weight: 30
+description: >
+  쿠버네티스 API를 사용하면 쿠버네티스 오브젝트들의 상태를 쿼리하고 조작할 수 있다. 
+  쿠버네티스 컨트롤 플레인의 핵심은 API 서버와 그것이 노출하는 HTTP API이다. 사용자와 클러스터의 다른 부분 및 모든 외부 컴포넌트는 API 서버를 통해 서로 통신한다.
 card:
   name: concepts
   weight: 30

content/ko/docs/concepts/overview/what-is-kubernetes.md

@@ -71,7 +71,7 @@ card:
 
 ## 쿠버네티스가 아닌 것
 
-쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가 아니다. 쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱, 로깅 및 모니터링과 같은 기능에서 공통점이 있기도 하다. 하지만, 쿠버네티스는 모놀리식(monolithic)이 아니어서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는 개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다.
+쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가 아니다. 쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱과 같은 기능을 제공하며, 사용자가 로깅, 모니터링 및 알림 솔루션을 통합할 수 있다. 하지만, 쿠버네티스는 모놀리식(monolithic)이 아니어서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는 개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다.
 
 쿠버네티스는:
 
@@ -89,4 +89,3 @@ card:
 
 *   [쿠버네티스 구성요소](/ko/docs/concepts/overview/components/) 살펴보기
 *   [시작하기](/ko/docs/setup/) 준비가 되었는가?
-

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

@@ -1,4 +1,7 @@
 ---
 title: "쿠버네티스 오브젝트로 작업하기"
 weight: 40
+description: >
+  쿠버네티스 오브젝트는 쿠버네티스 시스템의 영구 엔티티이다. 쿠버네티스는 이러한 엔티티들을 사용하여 클러스터의 상태를 나타낸다. 
+  쿠버네티스 오브젝트 모델과 쿠버네티스 오브젝트를 사용하는 방법에 대해 학습한다.
 ---

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

@@ -51,13 +51,13 @@ weight: 50
 * 경량 롤아웃 도구 메타데이터. 예: 구성 또는 체크포인트
 
 * 책임자의 전화번호 또는 호출기 번호, 또는 팀 웹 사이트 같은
-  해당 정보를 찾을 수 있는 디렉토리 진입점.
+  해당 정보를 찾을 수 있는 디렉터리 진입점.
 
 * 행동을 수정하거나 비표준 기능을 수행하기 위한
   최종 사용자의 지시 사항.
 
 어노테이션을 사용하는 대신, 이 유형의 정보를
-외부 데이터베이스 또는 디렉토리에 저장할 수 있지만, 이는 배포, 관리, 인트로스펙션(introspection) 등을 위한
+외부 데이터베이스 또는 디렉터리에 저장할 수 있지만, 이는 배포, 관리, 인트로스펙션(introspection) 등을 위한
 공유 클라이언트 라이브러리와 도구 생성을
 훨씬 더 어렵게 만들 수 있다.
 

content/ko/docs/concepts/overview/working-with-objects/field-selectors.md

@@ -9,7 +9,7 @@ _필드 셀렉터_ 는 한 개 이상의 리소스 필드 값에 따라 [쿠버
 * `metadata.namespace!=default`
 * `status.phase=Pending`
 
-다음의 `kubectl` 커맨드는 [`status.phase`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) 필드의 값이 `Running` 인 모든 파드를 선택한다.
+다음의 `kubectl` 커맨드는 [`status.phase`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계-phase) 필드의 값이 `Running` 인 모든 파드를 선택한다.
 
 ```shell
 kubectl get pods --field-selector status.phase=Running

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

@@ -87,7 +87,7 @@ API는 현재 _일치성 기준_ 과 _집합성 기준_ 이라는 두 종류의
 문서화해야 한다.
 
 {{< note >}}
-레플리카 셋과 같은 일부 API 유형에서 두 인스턴스의 레이블 셀렉터는 네임스페이스 내에서 겹치지 않아야 한다. 그렇지 않으면 컨트롤러는 상충하는 명령으로 보고, 얼마나 많은 복제본이 필요한지 알 수 없다.
+레플리카셋(ReplicaSet)과 같은 일부 API 유형에서 두 인스턴스의 레이블 셀렉터는 네임스페이스 내에서 겹치지 않아야 한다. 그렇지 않으면 컨트롤러는 상충하는 명령으로 보고, 얼마나 많은 복제본이 필요한지 알 수 없다.
 {{< /note >}}
 
 {{< caution >}}

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

@@ -27,7 +27,7 @@ weight: 30
 
 네임스페이스는 클러스터 자원을 ([리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 통해) 여러 사용자 사이에서 나누는 방법이다.
 
-이후 버전의 쿠버네티스에서는 같은 네임스페이스의 오브젝트는 기본적으로 
+이후 버전의 쿠버네티스에서는 같은 네임스페이스의 오브젝트는 기본적으로
 동일한 접근 제어 정책을 갖게 된다.
 
 동일한 소프트웨어의 다른 버전과 같이 약간 다른 리소스를 분리하기 위해
@@ -39,6 +39,10 @@ weight: 30
 네임스페이스의 생성과 삭제는 [네임스페이스 관리자 가이드 문서](/docs/tasks/administer-cluster/namespaces/)에
 기술되어 있다.
 
+{{< note >}}
+    쿠버네티스 시스템 네임스페이스용으로 예약되어 있으므로, `kube-` 접두사로 네임스페이스를 생성하지 않는다.
+{{< /note >}}
+
 ### 네임스페이스 조회
 
 사용 중인 클러스터의 현재 네임스페이스를 나열할 수 있다.
@@ -54,11 +58,12 @@ kube-public       Active   1d
 kube-system       Active   1d
 ```
 
-쿠버네티스는 처음에 세 개의 초기 네임스페이스를 갖는다.
+쿠버네티스는 처음에 네 개의 초기 네임스페이스를 갖는다.
 
    * `default` 다른 네임스페이스가 없는 오브젝트를 위한 기본 네임스페이스
    * `kube-system` 쿠버네티스 시스템에서 생성한 오브젝트를 위한 네임스페이스
    * `kube-public` 이 네임스페이스는 자동으로 생성되며 모든 사용자(인증되지 않은 사용자 포함)가 읽기 권한으로 접근할 수 있다. 이 네임스페이스는 주로 전체 클러스터 중에 공개적으로 드러나서 읽을 수 있는 리소스를 위해 예약되어 있다. 이 네임스페이스의 공개적인 성격은 단지 관례이지 요구 사항은 아니다.
+   * `kube-node-lease` 클러스터가 스케일링될 때 노드 하트비트의 성능을 향상시키는 각 노드와 관련된 리스(lease) 오브젝트에 대한 네임스페이스
 
 ### 요청에 네임스페이스 설정하기
 
@@ -114,6 +119,3 @@ kubectl api-resources --namespaced=false
 
 * [신규 네임스페이스 생성](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)에 대해 더 배우기.
 * [네임스페이스 삭제](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)에 대해 더 배우기.
-
-
-

content/ko/docs/concepts/overview/working-with-objects/object-management.md

@@ -7,7 +7,7 @@ weight: 15
 <!-- overview -->
 `kubectl` 커맨드라인 툴은 쿠버네티스 오브젝트를 생성하고 관리하기 위한
 몇 가지 상이한 방법을 지원한다. 이 문서는 여러가지 접근법에 대한 개요을
-제공한다. Kubectl로 오브젝트 관리하기에 대한 자세한 설명은 
+제공한다. Kubectl로 오브젝트 관리하기에 대한 자세한 설명은
 [Kubectl 서적](https://kubectl.docs.kubernetes.io)에서 확인한다.
 
 
@@ -40,12 +40,6 @@ weight: 15
 
 디플로이먼트 오브젝트를 생성하기 위해 nginx 컨테이너의 인스턴스를 구동시킨다.
 
-```sh
-kubectl run nginx --image nginx
-```
-
-다른 문법을 이용하여 동일한 작업을 수행한다.
-
 ```sh
 kubectl create deployment nginx --image nginx
 ```
@@ -75,11 +69,11 @@ kubectl create deployment nginx --image nginx
 참고한다.
 
 {{< warning >}}
-명령형 `replace` 커맨드는 기존 spec을 새로 제공된 spec으로 바꾸고 
-구성 파일에서 누락된 오브젝트의 모든 변경 사항을 삭제한다. 
-이 방법은 spec이 구성 파일과는 별개로 업데이트되는 리소스 유형에는 
-사용하지 말아야한다. 
-예를 들어 `LoadBalancer` 유형의 서비스는 클러스터의 구성과 별도로 
+명령형 `replace` 커맨드는 기존 spec을 새로 제공된 spec으로 바꾸고
+구성 파일에서 누락된 오브젝트의 모든 변경 사항을 삭제한다.
+이 방법은 spec이 구성 파일과는 별개로 업데이트되는 리소스 유형에는
+사용하지 말아야한다.
+예를 들어 `LoadBalancer` 유형의 서비스는 클러스터의 구성과 별도로
 `externalIPs` 필드가 업데이트된다.
 {{< /warning >}}
 
@@ -124,7 +118,7 @@ kubectl replace -f nginx.yaml
 
 선언형 오브젝트 구성에 비해 단점은 다음과 같다.
 
-- 명령형 오브젝트 구성은 디렉토리가 아닌, 파일에 대해 가장 효과가 있다.
+- 명령형 오브젝트 구성은 디렉터리가 아닌, 파일에 대해 가장 효과가 있다.
 - 활성 오브젝트에 대한 업데이트는 구성 파일에 반영되어야 한다. 그렇지 않으면 다음 교체 중에 손실된다.
 
 ## 선언형 오브젝트 구성
@@ -133,19 +127,19 @@ kubectl replace -f nginx.yaml
 구성 파일을 대상으로 작동시키지만, 사용자는 파일에서 수행 할
 작업을 정의하지 않는다. 생성, 업데이트, 그리고 삭제 작업은
 `kubectl`에 의해 오브젝트 마다 자동으로 감지된다. 이를 통해 다른 오브젝트에 대해 
-다른 조작이 필요할 수 있는 디렉토리에서 작업할 수 있다.
+다른 조작이 필요할 수 있는 디렉터리에서 작업할 수 있다.
 
 {{< note >}}
-선언형 오브젝트 구성은 변경 사항이 오브젝트 구성 파일에 
-다시 병합되지 않더라도 다른 작성자가 작성한 변경 사항을 유지한다. 
+선언형 오브젝트 구성은 변경 사항이 오브젝트 구성 파일에
+다시 병합되지 않더라도 다른 작성자가 작성한 변경 사항을 유지한다.
 이것은 전체 오브젝트 구성 변경을 위한 `replace` API를
-사용하는 대신, `patch` API를 사용하여 인지되는 차이만 
+사용하는 대신, `patch` API를 사용하여 인지되는 차이만
 작성하기 때문에 가능하다.
 {{< /note >}}
 
 ### 예시
 
-`configs` 디렉토리 내 모든 오브젝트 구성 파일을 처리하고 활성 오브젝트를
+`configs` 디렉터리 내 모든 오브젝트 구성 파일을 처리하고 활성 오브젝트를
 생성 또는 패치한다. 먼저 어떠한 변경이 이루어지게 될지 알아보기 위해 `diff`
 하고 나서 적용할 수 있다.
 
@@ -154,7 +148,7 @@ kubectl diff -f configs/
 kubectl apply -f configs/
 ```
 
-재귀적으로 디렉토리를 처리한다.
+재귀적으로 디렉터리를 처리한다.
 
 ```sh
 kubectl diff -R -f configs/
@@ -166,7 +160,7 @@ kubectl apply -R -f configs/
 명령형 오브젝트 구성에 비해 장점은 다음과 같다.
 
 - 활성 오브젝트에 직접 작성된 변경 사항은 구성 파일로 다시 병합되지 않더라도 유지된다.
-- 선언형 오브젝트 구성은 디렉토리에서의 작업 및 오브젝트 별 작업 유형(생성, 패치, 삭제)의 자동 감지에 더 나은 지원을 제공한다.
+- 선언형 오브젝트 구성은 디렉터리에서의 작업 및 오브젝트 별 작업 유형(생성, 패치, 삭제)의 자동 감지에 더 나은 지원을 제공한다.
 
 명령형 오브젝트 구성에 비해 단점은 다음과 같다.
 
@@ -185,5 +179,3 @@ kubectl apply -R -f configs/
 - [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl-commands/)
 - [Kubectl 서적](https://kubectl.docs.kubernetes.io)
 - [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
-
-