Sixth Korean l10n work for release 1.18

- Update outdated files in dev-1.18-ko.6 partly (#21714)
- Translate StorageClass to Korean word (#21805)
- Translate StatefulSet to Korean word in pods.md (#21794)
- Translate tasks/run-application/delete-stateful-set/ in Korean (#21686)
- Translate tasks/administer-cluster/change-default-storage-class in Korean (#21801)
- update outdated docs (#21940)
- Modify spacing term StatefulSet in Korean (#21871)
- Translate /tasks/administer-cluster/coredns in Korean (#21876)
- Fix typo in k8s.io/ko/docs/contribute/new-content/new-content/ (#21975)
- Translation error correction in /concepts/containers/runtime-class.md (#21868)
- Translate tasks/tls/certificate-rotation/ in Korean (#21838)
- Translate /tasks/configure-pod-container/static-pod in Korean (#21798)
- Update to Outdated files in the dev-1.18-ko.6 branch - (1/4) (#21911)
- Fix English bugs in Korean documentation (#21994)
- Update outdated dev-1.18-ko.6 partly (#22067)

Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: PyungHo Yoon <learder@gmail.com>
Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com>
Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: Seokho Son <shsongist@gmail.com>
Co-authored-by: Jordy Ruiter <jordy.ruiter@gmail.com>
Co-authored-by: bluefriday <bluefriday86@gmail.com>
Co-authored-by: Dajin Gwon <d.gweon@samsung.com>
Co-authored-by: Hyungseok Lee <hs0426.lee@samsung.com>
Co-authored-by: Jihoon Seo <jihoon.seo@etri.re.kr>
Co-authored-by: coolguyhong <podolsmith@naver.com>
Co-authored-by: jmyung <jesang.myung@gmail.com>
Co-authored-by: June Yi <june.yi@samsung.com>

content/ko/docs/concepts/architecture/cloud-controller.md

@@ -19,7 +19,6 @@ weight: 40
 
 
 
-
 <!-- body -->
 
 ## 디자인
@@ -31,6 +30,7 @@ weight: 40
 프로세스에 여러 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}를
 구현한다.
 
+
 {{< note >}}
 또한 사용자는 클라우드 컨트롤러 매니저를 컨트롤 플레인의 일부가 아닌 쿠버네티스
 {{< glossary_tooltip text="애드온" term_id="addons" >}}으로

content/ko/docs/concepts/architecture/control-plane-node-communication.md

@@ -15,7 +15,7 @@ aliases:
 <!-- body -->
 
 ## 노드에서 컨트롤 플레인으로의 통신
-노드에서 컨트롤 플레인까지의 모든 통신 경로는 API 서버에서 종료된다(다른 마스터 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다). 일반적인 배포에서 API 서버는 하나 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형식이 활성화된 보안 HTTPS 포트(443)에서 원격 연결을 수신하도록 구성된다.
+쿠버네티스에는 "허브 앤 스포크(hub-and-spoke)" API 패턴을 가지고 있다. 노드(또는 노드에서 실행되는 파드들)의 모든 API 사용은 API 서버에서 종료된다(다른 컨트롤 플레인 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다). API 서버는 하나 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형식이 활성화된 보안 HTTPS 포트(일반적으로 443)에서 원격 연결을 수신하도록 구성된다.
 특히 [익명의 요청](/docs/reference/access-authn-authz/authentication/#anonymous-requests) 또는 [서비스 어카운트 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)이 허용되는 경우, 하나 이상의 [권한 부여](/docs/reference/access-authn-authz/authorization/) 형식을 사용해야 한다.
 
 노드는 유효한 클라이언트 자격 증명과 함께 API 서버에 안전하게 연결할 수 있도록 클러스터에 대한 공개 루트 인증서로 프로비전해야 한다. 예를 들어, 기본 GKE 배포에서, kubelet에 제공되는 클라이언트 자격 증명은 클라이언트 인증서 형식이다. kubelet 클라이언트 인증서의 자동 프로비저닝은 [kubelet TLS 부트스트랩](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 참고한다.
@@ -28,9 +28,11 @@ API 서버에 연결하려는 파드는 쿠버네티스가 공개 루트 인증
 결과적으로, 노드 및 노드에서 실행되는 파드에서 컨트롤 플레인으로 연결하기 위한 기본 작동 모드는 기본적으로 보호되며 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행될 수 있다.
 
 ## 컨트롤 플레인에서 노드로의 통신
+
 컨트롤 플레인(API 서버)에서 노드로는 두 가지 기본 통신 경로가 있다. 첫 번째는 API 서버에서 클러스터의 각 노드에서 실행되는 kubelet 프로세스이다. 두 번째는 API 서버의 프록시 기능을 통해 API 서버에서 모든 노드, 파드 또는 서비스에 이르는 것이다.
 
 ### API 서버에서 kubelet으로의 통신
+
 API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다.
 
 * 파드에 대한 로그를 가져온다.
@@ -58,9 +60,10 @@ API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로
 SSH 터널은 현재 더 이상 사용되지 않으므로 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안된다. Konnectivity 서비스는 이 통신 채널을 대체한다.
 
 ### Konnectivity 서비스
+
 {{< feature-state for_k8s_version="v1.18" state="beta" >}}
 
-SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity는 컨트롤 플레인 네트워크와 노드 네트워크에서 각각 실행되는 Konnectivity 서버와 Konnectivity 에이전트의 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 연결을 유지한다.
-그런 다음 컨트롤 플레인에서 노드로의 모든 트래픽은 이 연결을 통과한다.
+SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity 서비스는 컨트롤 플레인 네트워크와 노드 네트워크에서 각각 실행되는 Konnectivity 서버와 Konnectivity 에이전트의 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 네트워크 연결을 유지한다.
+Konnectivity 서비스를 활성화한 후, 모든 컨트롤 플레인에서 노드로의 트래픽은 이 연결을 통과한다.
 
-클러스터에서 설정하는 방법에 대해서는 [Konnectivity 서비스 설정](/docs/tasks/setup-konnectivity/)을 참조한다.
+[Konnectivity 서비스 태스크](/docs/tasks/extend-kubernetes/setup-konnectivity/)에 따라 클러스터에서 Konnectivity 서비스를 설정한다.

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

@@ -48,7 +48,7 @@ weight: 30
 내장 컨트롤러의 예시이다. 내장 컨트롤러는 클러스터 API 서버와 
 상호 작용하며 상태를 관리한다.
 
-잡은 단일 {{< glossary_tooltip term_id="pod" >}} 또는 여러 파드를 실행하고, 
+잡은 단일 {{< glossary_tooltip text="파드" term_id="pod" >}} 또는 여러 파드를 실행하고, 
 작업을 수행한 다음 중지하는 
 쿠버네티스 리소스 이다.
 

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

@@ -31,7 +31,8 @@ weight: 10
 1. 노드의 kubelet으로 컨트롤 플레인에 자체 등록
 2. 사용자 또는 다른 사용자가 노드 오브젝트를 수동으로 추가
 
-노드 오브젝트 또는 노드의 kubelet으로 자체 등록한 후 컨트롤 플레인은 새 노드 오브젝트가 유효한지 확인한다.
+노드 오브젝트 또는 노드의 kubelet으로 자체 등록한 후
+컨트롤 플레인은 새 노드 오브젝트가 유효한지 확인한다.
 예를 들어 다음 JSON 매니페스트에서 노드를 만들려는 경우이다.
 
 ```json
@@ -61,7 +62,8 @@ 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-서브도메인-이름들)이어야 한다.
 
 ### 노드에 대한 자체-등록
 
@@ -73,7 +75,9 @@ kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API
   - `--kubeconfig` - apiserver에 스스로 인증하기 위한 자격증명에 대한 경로.
   - `--cloud-provider` - 자신에 대한 메터데이터를 읽기 위해 어떻게 {{< glossary_tooltip text="클라우드 제공자" term_id="cloud-provider" >}}와 소통할지에 대한 방법.
   - `--register-node` - 자동으로 API 서버에 등록.
-  - `--register-with-taints` - 주어진 taint 리스트 (콤마로 분리된 `<key>=<value>:<effect>`)를 가진 노드 등록. `register-node`가 거짓이면 동작 안함.
+  - `--register-with-taints` - 주어진 {{< glossary_tooltip text="테인트(taint)" term_id="taint" >}} 리스트(콤마로 분리된 `<key>=<value>:<effect>`)를 가진 노드 등록. 
+
+    `register-node`가 거짓이면 동작 안 함.
   - `--node-ip` - 노드의 IP 주소.
   - `--node-labels` - 클러스터에 노드를 등록할 때 추가 할 {{< glossary_tooltip text="레이블" term_id="label" >}}([NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)에 의해 적용되는 레이블 제한 사항 참고).
   - `--node-status-update-frequency` - 얼마나 자주 kubelet이 마스터에 노드 상태를 게시할 지 정의.
@@ -188,6 +192,9 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳
 스케줄러는 파드를 노드에 할당 할 때 노드의 테인트를 고려한다.
 또한 파드는 노드의 테인트를 극복(tolerate)할 수 있는 톨러레이션(toleration)을 가질 수 있다.
 
+자세한 내용은
+[컨디션별 노드 테인트하기](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/#컨디션별-노드-테인트하기)를 참조한다.
+
 ### 용량과 할당가능 {#capacity}
 
 노드 상에 사용 가능한 리소스를 나타낸다. 리소스에는 CPU, 메모리 그리고 
@@ -201,7 +208,7 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳
 [컴퓨팅 리소스 예약](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)하는 방법을
 배우는 동안 용량 및 할당가능 리소스에 대해 자세히 읽어보자.
 
-### 정보 {#info}
+### 정보
 
 커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), (사용하는 경우) Docker 버전, OS 이름과 같은노드에 대한 일반적인 정보를 보여준다.
 이 정보는 Kubelet에 의해 노드로부터 수집된다.
@@ -285,6 +292,7 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
 {{< glossary_tooltip text="테인트" term_id="taint" >}}를 추가한다.
 이는 스케줄러가 비정상적인 노드에 파드를 배치하지 않게 된다.
 
+
 {{< caution >}}
 `kubectl cordon` 은 노드를 'unschedulable'로 표기하는데, 이는
 서비스 컨트롤러가 이전에 자격 있는 로드밸런서 노드 대상 목록에서 해당 노드를 제거하기에
@@ -318,7 +326,6 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
 `TopologyManager` 
 [기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)를
 활성화 시켜두면, kubelet이 리소스 할당 결정을 할 때 토폴로지 힌트를 사용할 수 있다.
-
 자세한 내용은
 [노드의 컨트롤 토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)을 본다.
 
@@ -331,4 +338,3 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
   섹션을 읽어본다.
 * [테인트와 톨러레이션](/ko/docs/concepts/configuration/taint-and-toleration/)을 읽어본다.
 * [클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)을 읽어본다.
-