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/_index.md

@@ -33,15 +33,15 @@ weight: 40
 * [파드](/ko/docs/concepts/workloads/pods/pod-overview/)
 * [서비스](/ko/docs/concepts/services-networking/service/)
 * [볼륨](/ko/docs/concepts/storage/volumes/)
-* [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces/)
+* [네임스페이스(Namespace)](/ko/docs/concepts/overview/working-with-objects/namespaces/)
 
 또한, 쿠버네티스에는 기초 오브젝트를 기반으로, 부가 기능 및 편의 기능을 제공하는 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 의존하는 보다 높은 수준의 추상 개념도 포함되어 있다. 다음이 포함된다.
 
-* [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)
+* [디플로이먼트(Deployment)](/ko/docs/concepts/workloads/controllers/deployment/)
-* [데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/)
+* [데몬셋(DaemonSet)](/ko/docs/concepts/workloads/controllers/daemonset/)
-* [스테이트풀 셋](/ko/docs/concepts/workloads/controllers/statefulset/)
+* [스테이트풀셋(StatefulSet)](/ko/docs/concepts/workloads/controllers/statefulset/)
-* [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)
+* [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/)
-* [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)
+* [잡(Job)](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)
 
 ## 쿠버네티스 컨트롤 플레인
 
@@ -66,7 +66,6 @@ weight: 40
 
 
 개념 페이지를 작성하기를 원하면,
-개념 페이지 유형과 개념 템플릿에 대한 정보가 있는
+개념 페이지 유형에 대한 정보가 있는
-[페이지 템플릿 사용하기](/docs/home/contribute/page-templates/)를 참조한다.
+[페이지 컨텐츠 유형](/docs/contribute/style/page-content-types/#concept)을 참조한다.
-
 

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/#클러스터-오토스케일링)을 읽어본다.
-

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

@@ -134,13 +134,13 @@ CloudStack 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이
 GCE 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름을 사용한다.
 참고로 쿠버네티스 노드 이름의 첫 번째 세그먼트는 GCE 인스턴스 이름과 일치해야 한다(예: `kubernetes-node-2.c.my-proj.internal` 이름이 지정된 노드는 `kubernetes-node-2` 이름이 지정된 인스턴스에 해당해야 함).
 
-## HUAWEI 클라우드
+## HUAWEI CLOUD
 
 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [kubernetes-sigs/cloud-provider-huaweicloud](https://github.com/kubernetes-sigs/cloud-provider-huaweicloud)이다.
 
 ### 노드 이름
 
-HUAWEI 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 프라이빗 IP 주소가 필요하다.
+HUAWEI CLOUD 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 프라이빗 IP 주소가 필요하다.
 노드에서 kubelet을 시작할 때 반드시 `--hostname-override=<node private IP>` 를 사용한다.
 
 ## OpenStack
@@ -415,6 +415,7 @@ Baidu 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으
 참고로 쿠버네티스 노드 이름은 Baidu VM 프라이빗 IP와 일치해야 한다.
 
 ## Tencent 쿠버네티스 엔진
+
 이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [TencentCloud/tencentcloud-cloud-controller-manager](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager)이다.
 
 ### 노드 이름

content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md

@@ -78,7 +78,6 @@ kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대
 
 
 
-
 ## {{% heading "whatsnext" %}}
 
 

content/ko/docs/concepts/cluster-administration/manage-deployment.md

@@ -400,7 +400,7 @@ rm /tmp/nginx.yaml
 
 `kubectl patch` 를 사용하여 API 오브젝트를 인플레이스 업데이트할 수 있다. 이 명령은 JSON 패치,
 JSON 병합 패치 그리고 전략적 병합 패치를 지원한다.
-[kubectl patch를 사용한 인플레이스 API 오브젝트 업데이트](/docs/tasks/run-application/update-api-object-kubectl-patch/)와
+[kubectl patch를 사용한 인플레이스 API 오브젝트 업데이트](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)와
 [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch)를
 참조한다.
 

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

@@ -43,7 +43,7 @@ API [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-ob
 컨피그맵의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
 
-## 컨피그맵과 파드(Pod)
+## 컨피그맵과 파드
 
 컨피그맵을 참조하는 파드 `spec` 을 작성하고 컨피그맵의 데이터를
 기반으로 해당 파드의 컨테이너를 구성할 수 있다. 파드와 컨피그맵은
@@ -157,7 +157,91 @@ spec:
 사용할 수도 있다.
 {{< /note >}}
 
+## 컨피그맵 사용하기
 
+컨피그맵은 데이터 볼륨으로 마운트할 수 있다. 컨피그맵은 파드에 직접적으로
+노출되지 않고, 시스템의 다른 부분에서도 사용할 수 있다. 예를 들어,
+컨피그맵은 시스템의 다른 부분이 구성을 위해 사용해야 하는 데이터를 보유할 수 있다.
+
+### 파드에서 컨피그맵을 파일로 사용하기
+
+파드의 볼륨에서 컨피그맵을 사용하려면 다음을 수행한다.
+
+1. 컨피그맵을 생성하거나 기존 컨피그맵을 사용한다. 여러 파드가 동일한 컨피그맵을 참조할 수 있다.
+1. 파드 정의를 수정해서 `.spec.volumes[]` 아래에 볼륨을 추가한다. 볼륨 이름은 원하는 대로 정하고, 컨피그맵 오브젝트를 참조하도록 `.spec.volumes[].configmap.localObjectReference` 필드를 설정한다.
+1. 컨피그맵이 필요한 각 컨테이너에 `.spec.containers[].volumeMounts[]` 를 추가한다. `.spec.containers[].volumeMounts[].readOnly = true` 를 설정하고 컨피그맵이 연결되기를 원하는 곳에 사용하지 않은 디렉터리 이름으로 `.spec.containers[].volumeMounts[].mountPath` 를 지정한다.
+1. 프로그램이 해당 디렉터리에서 파일을 찾도록 이미지 또는 커맨드 라인을 수정한다. 컨피그맵의 `data` 맵 각 키는 `mountPath` 아래의 파일 이름이 된다.
+
+다음은 볼륨에 컨피그맵을 마운트하는 파드의 예시이다.
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: mypod
+spec:
+  containers:
+  - name: mypod
+    image: redis
+    volumeMounts:
+    - name: foo
+      mountPath: "/etc/foo"
+      readOnly: true
+  volumes:
+  - name: foo
+    configmap:
+      name: myconfigmap
+```
+
+사용하려는 각 컨피그맵은 `.spec.volumes` 에서 참조해야 한다.
+
+파드에 여러 컨테이너가 있는 경우 각 컨테이너에는 자체 `volumeMounts` 블록이 필요하지만,
+컨피그맵은 각 컨피그맵 당 하나의 `.spec.volumes` 만 필요하다.
+
+#### 마운트된 컨피그맵이 자동으로 업데이트
+
+현재 볼륨에서 사용된 컨피그맵이 업데이트되면, 프로젝션된 키도 마찬가지로 업데이트된다.
+kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최신 상태인지 확인한다.
+그러나, kubelet은 로컬 캐시를 사용해서 컨피그맵의 현재 값을 가져온다.
+캐시 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의
+`ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용해서 구성할 수 있다.
+
+컨피그맵은 watch(기본값), ttl 기반 또는 API 서버로 직접
+모든 요청을 리디렉션할 수 있다.
+따라서 컨피그맵이 업데이트되는 순간부터 새 키가 파드에 업데이트되는 순간까지의
+총 지연시간은 kubelet 동기화 기간 + 캐시 전파 지연만큼 길 수 있다. 여기서 캐시
+전파 지연은 선택한 캐시 유형에 따라 달라질 수 있다(전파
+지연을 지켜보거나, 캐시의 ttl 또는 0에 상응함).
+
+{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
+
+쿠버네티스 알파 기능인 _변경할 수 없는(immutable) 시크릿과 컨피그맵_ 은 개별 시크릿과
+컨피그맵을 변경할 수 없는 것으로 설정하는 옵션을 제공한다. 컨피그맵을 광범위하게
+사용하는 클러스터(최소 수만 개의 고유한 컨피그맵이 파드에 마운트)의 경우
+데이터 변경을 방지하면 다음과 같은 이점이 있다.
+
+- 애플리케이션 중단을 일으킬 수 있는 우발적(또는 원하지 않는) 업데이트로부터 보호
+- immutable로 표시된 컨피그맵에 대한 감시를 중단하여, kube-apiserver의 부하를 크게 줄임으로써 클러스터의 성능을 향상시킴
+
+이 기능을 사용하려면 `ImmutableEmphemeralVolumes`
+[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하고
+시크릿 또는 컨피그맵의 `immutable` 필드를 `true` 로 한다. 다음은 예시이다.
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  ...
+data:
+  ...
+immutable: true
+```
+
+{{< note >}}
+컨피그맵 또는 시크릿을 immutable로 표시하면, 이 변경 사항을 되돌리거나
+`data` 필드 내용을 변경할 수 _없다_. 컨피그맵만 삭제하고 다시 작성할 수 있다.
+기존 파드는 삭제된 컨피그맵에 대한 마운트 지점을 유지하며, 이러한 파드를 다시 작성하는
+것을 권장한다.
+{{< /note >}}
 
 ## {{% heading "whatsnext" %}}
 
@@ -167,4 +251,3 @@ spec:
 * 코드를 구성에서 분리하려는 동기를 이해하려면
   [Twelve-Factor 앱](https://12factor.net/ko/)을 읽어본다.
 
-

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

@@ -99,7 +99,7 @@ kubectl config view
    `KUBECONFIG` 환경 변수 설정의 예로,
    [KUBECONFIG 환경 변수 설정](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#kubeconfig-환경-변수-설정)를 참조한다.
 
-   그렇지 않다면, 병합하지 않고 기본 kubecofig 파일인 `$HOME/.kube/config`를 사용한다.
+   그렇지 않다면, 병합하지 않고 기본 kubeconfig 파일인 `$HOME/.kube/config`를 사용한다.
 
 1. 이 체인에서 첫 번째를 기반으로 사용할 컨텍스트를 결정한다.
 

content/ko/docs/concepts/configuration/pod-overhead.md

@@ -8,6 +8,7 @@ weight: 20
 
 {{< feature-state for_k8s_version="v1.18" state="beta" >}}
 
+
 노드 위에서 파드를 구동할 때, 파드는 그 자체적으로 많은 시스템 리소스를 사용한다.
 이러한 리소스는 파드 내의 컨테이너들을 구동하기 위한 리소스 이외에 추가적으로 필요한 것이다.
 _파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파드의 인프라에 의해 

content/ko/docs/concepts/containers/container-environment.md

@@ -56,6 +56,7 @@ FOO_SERVICE_PORT=<서비스가 동작 중인 포트>
 
 
 * [컨테이너 라이프사이클 훅(hooks)](/ko/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배워 보기.
-* [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) 실제 경험 얻기.
+* [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)
+  실제 경험 얻기.
 
 

content/ko/docs/concepts/containers/images.md

@@ -63,6 +63,7 @@ Docker *18.06 또는 그 이상* 을 사용하길 바란다. 더 낮은 버전
   - Oracle 클라우드 인프라스트럭처 레지스트리(OCIR) 사용
     - IAM 역할과 정책을 사용하여 OCIR 저장소에 접근을 제어함
   - Azure 컨테이너 레지스트리(ACR) 사용
+    - IAM 역할과 정책을 사용하여 ACR 저장소에 접근을 제어함
   - IBM 클라우드 컨테이너 레지스트리 사용
     - IAM 역할 및 정책을 사용하여 IBM 클라우드 컨테이너 레지스트리에 대한 접근 권한 부여
   - 프라이빗 레지스트리에 대한 인증을 위한 노드 구성
@@ -127,13 +128,19 @@ kubelet은 ECR 자격 증명을 가져오고 주기적으로 갱신할 것이다
   - `aws_credentials.go:116] Got ECR credentials from ECR API for <AWS account ID for ECR>.dkr.ecr.<AWS region>.amazonaws.com`
 
 ### Azure 컨테이너 레지스트리(ACR) 사용
-[Azure 컨테이너 레지스트리](https://azure.microsoft.com/en-us/services/container-registry/)를 사용하는 경우
+쿠버네티스는 Azure 쿠버네티스 서비스(AKS)를 사용할 때
-관리자 역할의 사용자나 서비스 주체(principal) 중 하나를 사용하여 인증할 수 있다.
+[Azure 컨테이너 레지스트리(ACR)](https://azure.microsoft.com/ko-kr/services/container-registry/)를
+기본적으로 지원한다.
+
+AKS 클러스터 서비스 주체(principal)는 ACR 인스턴스에서 `ArcPull` 권한이 있어야 한다.  구성에 대한
+지침은 [Azure 쿠버네티스 서비스에서 Azure 컨테이너 레지스트리로 인증](https://docs.microsoft.com/ko-kr/azure/aks/cluster-container-registry-integration)을 참조한다.  그런 다음, 전체 ACR 이미지 이름(예: `my_registry.azurecr.io/image:tag`)을 사용한다.
+
+ACR 관리자 또는 서비스 주체를 사용해서 인증할 수도 있다.
 어느 경우라도, 인증은 표준 Docker 인증을 통해서 수행된다. 이러한 지침은
 [azure-cli](https://github.com/azure/azure-cli) 명령줄 도구 사용을 가정한다.
 
 우선 레지스트리를 생성하고 자격 증명을 만들어야한다. 이에 대한 전체 문서는
-[Azure 컨테이너 레지스트리 문서](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-get-started-azure-cli)에서 찾을 수 있다.
+[Azure 컨테이너 레지스트리 문서](https://docs.microsoft.com/ko-kr/azure/container-registry/container-registry-get-started-azure-cli)에서 찾을 수 있다.
 
 컨테이너 레지스트리를 생성하고 나면, 다음의 자격 증명을 사용하여 로그인한다.
 
@@ -367,4 +374,3 @@ imagePullSecrets을 셋팅하여 자동화할 수 있다.
 다중 레지스트리에 접근해야 하는 경우, 각 레지스트리에 대해 하나의 시크릿을 생성할 수 있다.
 Kubelet은 모든`imagePullSecrets` 파일을 하나의 가상`.docker / config.json` 파일로 병합한다.
 
-

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

@@ -31,7 +31,6 @@ weight: 10
 애플리케이션을 변경하려는 경우, 변경사항을 포함하여 만든
 새로운 이미지를 통해 컨테이너를 다시 생성해야 한다.
 
-
 ## 컨테이너 런타임
 
 {{< glossary_definition term_id="container-runtime" length="all" >}}

content/ko/docs/concepts/containers/runtime-class.md

@@ -1,5 +1,5 @@
 ---
-title: 런타임 클래스
+title: 런타임클래스(RuntimeClass)
 content_type: concept
 weight: 20
 ---
@@ -8,7 +8,7 @@ weight: 20
 
 {{< feature-state for_k8s_version="v1.12" state="alpha" >}}
 
-이 페이지는 런타임 클래스(RuntimeClass) 리소스와 런타임 선택 메커니즘에 대해서 설명한다.
+이 페이지는 런타임클래스 리소스와 런타임 선택 메커니즘에 대해서 설명한다.
 
 런타임클래스는 컨테이너 런타임을 구성을 선택하는 기능이다. 컨테이너 런타임
 구성은 파드의 컨테이너를 실행하는데 사용된다.
@@ -32,9 +32,9 @@ weight: 20
 
 ## 셋업
 
-RuntimeClass 특징 게이트가 활성화(기본값)를 확인한다.
+런타임클래스 기능 게이트가 활성화(기본값)된 것을 확인한다.
-특징 게이트 활성화에 대한 설명은 [특징 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를
+기능 게이트 활성화에 대한 설명은 [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를
-참고한다. `RuntimeClass` 특징 게이트는 apiservers _및_ kubelets에서 활성화되어야 한다.
+참고한다. `RuntimeClass` 기능 게이트는 apiservers _및_ kubelets에서 활성화되어야 한다.
 
 1. CRI 구현(implementation)을 노드에 설정(런타임에 따라서)
 2. 상응하는 런타임클래스 리소스 생성
@@ -102,7 +102,7 @@ spec:
 확인한다.
 
 만약 명시된 `runtimeClassName`가 없다면, 기본 런타임 핸들러가 사용되며,
-런타임 클래스 특징이 비활성화되었을 때와 동일하게 동작한다.
+런타임클래스 기능이 비활성화되었을 때와 동일하게 동작한다.
 
 ### CRI 구성 {#cri-configuration}
 
@@ -143,14 +143,16 @@ https://github.com/containerd/cri/blob/master/docs/config.md
 
 {{< feature-state for_k8s_version="v1.16" state="beta" >}}
 
-쿠버네티스 v1.16 부터, 런타임 클래스는 `scheduling` 필드를 통해 이종의 클러스터 지원을 포함한다.
+쿠버네티스 v1.16 부터, 런타임 클래스는 `scheduling` 필드를 통해 이종의 클러스터
-이 필드를 사용하면, 이 런타임 클래스를 갖는 파드가 이를 지원하는 노드로 스케줄된다는 것을 보장할 수 있다.
+지원을 포함한다. 이 필드를 사용하면, 이 런타임 클래스를 갖는 파드가 이를 지원하는
-이 스케줄링 기능을 사용하려면, [런타임 클래스 어드미션(admission) 컨트롤러][]를 활성화(1.16 부터 기본 값)해야 한다.
+노드로 스케줄된다는 것을 보장할 수 있다. 이 스케줄링 기능을 사용하려면,
+[런타임 클래스 어드미션(admission) 컨트롤러][]를 활성화(1.16 부터 기본값)해야 한다.
 
 파드가 지정된 런타임클래스를 지원하는 노드에 안착한다는 것을 보장하려면,
 해당 노드들은 `runtimeClass.scheduling.nodeSelector` 필드에서 선택되는 공통 레이블을 가져야한다.
 런타임 클래스의 nodeSelector는 파드의 nodeSelector와 어드미션 시 병합되어서, 실질적으로
-각각에 의해 선택된 노드의 교집합을 취한다. 충돌이 있는 경우, 파드는 거부된다.
+각각에 의해 선택된 노드의 교집합을 취한다. 충돌이 있는 경우,
+파드는 거부된다.
 
 지원되는 노드가 테인트(taint)되어서 다른 런타임클래스 파드가 노드에서 구동되는 것을 막고 있다면,
 `tolerations`를 런타임클래스에 추가할 수 있다. `nodeSelector`를 사용하면, 어드미션 시 
@@ -171,7 +173,6 @@ https://github.com/containerd/cri/blob/master/docs/config.md
 PodOverhead를 사용하려면, PodOverhead [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)
 를 활성화 시켜야 한다. (기본으로 활성화 되어 있다.)
 
-
 파드 오버헤드는 런타임 클래스에서 `overhead` 필드를 통해 정의된다. 이 필드를 사용하면,
 해당 런타임 클래스를 사용해서 구동 중인 파드의 오버헤드를 특정할 수 있고 이 오버헤드가
 쿠버네티스 내에서 처리된다는 것을 보장할 수 있다.

content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md

@@ -35,9 +35,8 @@ extention API server가 레이턴시 요구 사항을 달성할 수 없는 경
 ## {{% heading "whatsnext" %}}
 
 
-* 사용자의 환경에서 Aggregator를 동작시키려면, [애그리게이션 레이어를 설정한다](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/).
+* 사용자의 환경에서 Aggregator를 동작시키려면, [애그리게이션 레이어를 설정한다](/docs/tasks/extend-kubernetes/configure-aggregation-layer/).
-* 다음에, [extension api-server를 구성해서](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) 애그리게이션 레이어와 연계한다.
+* 다음에, [확장 API 서버를 구성해서](/docs/tasks/extend-kubernetes/setup-extension-api-server/) 애그리게이션 레이어와 연계한다.
-* 또한, 어떻게 [쿠버네티스 API를 커스텀 리소스 데피니션으로 확장하는지](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)를 배워본다.
+* 또한, 어떻게 [쿠버네티스 API를 커스텀 리소스 데피니션으로 확장하는지](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)를 배워본다.
 * [API 서비스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)의 사양을 읽어본다.
 
-

content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md

@@ -175,15 +175,15 @@ CRD는 애그리게이트 API보다 생성하기가 쉽다.
 
 | 기능     | 설명         | CRD  | 애그리게이트 API        |
 | ------- | ----------- | ---- | -------------- |
-| 유효성 검사 | 사용자가 오류를 방지하고 클라이언트와 독립적으로 API를 발전시킬 수 있도록 도와준다. 이러한 기능은 동시에 많은 클라이언트를 모두 업데이트할 수 없는 경우에 아주 유용하다. | 예. [OpenAPI v3.0 유효성 검사](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation)를 사용하여 CRD에서 대부분의 유효성 검사를 지정할 수 있다. [웹훅 유효성 검사](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)를 추가해서 다른 모든 유효성 검사를 지원한다. | 예, 임의의 유효성 검사를 지원한다. |
+| 유효성 검사 | 사용자가 오류를 방지하고 클라이언트와 독립적으로 API를 발전시킬 수 있도록 도와준다. 이러한 기능은 동시에 많은 클라이언트를 모두 업데이트할 수 없는 경우에 아주 유용하다. | 예. [OpenAPI v3.0 유효성 검사](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation)를 사용하여 CRD에서 대부분의 유효성 검사를 지정할 수 있다. [웹훅 유효성 검사](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)를 추가해서 다른 모든 유효성 검사를 지원한다. | 예, 임의의 유효성 검사를 지원한다. |
-| 기본 설정 | 위를 참고하자. | 예, [OpenAPI v3.0 유효성 검사](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting)의 `default` 키워드(1.17에서 GA) 또는 [웹훅 변형(mutating)](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)(이전 오브젝트의 etcd에서 읽을 때는 실행되지 않음)을 통해 지원한다. | 예 |
+| 기본 설정 | 위를 참고하자. | 예, [OpenAPI v3.0 유효성 검사](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting)의 `default` 키워드(1.17에서 GA) 또는 [웹훅 변형(mutating)](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)(이전 오브젝트의 etcd에서 읽을 때는 실행되지 않음)을 통해 지원한다. | 예 |
-| 다중 버전 관리 | 두 가지 API 버전을 통해 동일한 오브젝트를 제공할 수 있다. 필드 이름 바꾸기와 같은 API 변경을 쉽게 할 수 있다. 클라이언트 버전을 제어하는 ​​경우는 덜 중요하다. | [예](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning) | 예 |
+| 다중 버전 관리 | 두 가지 API 버전을 통해 동일한 오브젝트를 제공할 수 있다. 필드 이름 바꾸기와 같은 API 변경을 쉽게 할 수 있다. 클라이언트 버전을 제어하는 ​​경우는 덜 중요하다. | [예](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning) | 예 |
 | 사용자 정의 스토리지 | 다른 성능 모드(예를 들어, 키-값 저장소 대신 시계열 데이터베이스)나 보안에 대한 격리(예를 들어, 암호화된 시크릿이나 다른 암호화) 기능을 가진 스토리지가 필요한 경우 | 아니오 | 예 |
 | 사용자 정의 비즈니스 로직 | 오브젝트를 생성, 읽기, 업데이트 또는 삭제를 할 때 임의의 점검 또는 조치를 수행한다. | 예, [웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)을 사용한다. | 예 |
-| 서브리소스 크기 조정 | HorizontalPodAutoscaler 및 PodDisruptionBudget과 같은 시스템이 새로운 리소스와 상호 작용할 수 있다. | [예](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#scale-subresource)  | 예 |
+| 서브리소스 크기 조정 | HorizontalPodAutoscaler 및 PodDisruptionBudget과 같은 시스템이 새로운 리소스와 상호 작용할 수 있다. | [예](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource)  | 예 |
-| 서브리소스 상태 | 사용자가 스펙 섹션을 작성하고 컨트롤러가 상태 섹션을 작성하는 세분화된 접근 제어를 허용한다. 커스텀 리소스 데이터 변형 시 오브젝트 생성을 증가시킨다(리소스에서 별도의 스펙과 상태 섹션 필요). | [예](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | 예 |
+| 서브리소스 상태 | 사용자가 스펙 섹션을 작성하고 컨트롤러가 상태 섹션을 작성하는 세분화된 접근 제어를 허용한다. 커스텀 리소스 데이터 변형 시 오브젝트 생성을 증가시킨다(리소스에서 별도의 스펙과 상태 섹션 필요). | [예](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#status-subresource) | 예 |
 | 기타 서브리소스 | "logs" 또는 "exec"과 같은 CRUD 이외의 작업을 추가한다. | 아니오 | 예 |
-| strategic-merge-patch | 새로운 엔드포인트는 `Content-Type: application/strategic-merge-patch+json` 형식의 PATCH를 지원한다. 로컬 및 서버 양쪽에서 수정할 수도 있는 오브젝트를 업데이트하는 데 유용하다. 자세한 내용은 ["kubectl 패치를 사용한 API 오브젝트 업데이트"](/docs/tasks/run-application/update-api-object-kubectl-patch/)를 참고한다. | 아니오 | 예 |
+| strategic-merge-patch | 새로운 엔드포인트는 `Content-Type: application/strategic-merge-patch+json` 형식의 PATCH를 지원한다. 로컬 및 서버 양쪽에서 수정할 수도 있는 오브젝트를 업데이트하는 데 유용하다. 자세한 내용은 ["kubectl 패치를 사용한 API 오브젝트 업데이트"](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)를 참고한다. | 아니오 | 예 |
 | 프로토콜 버퍼 | 새로운 리소스는 프로토콜 버퍼를 사용하려는 클라이언트를 지원한다. | 아니오 | 예 |
 | OpenAPI 스키마 | 서버에서 동적으로 가져올 수 있는 타입에 대한 OpenAPI(스웨거(swagger)) 스키마가 있는가? 허용된 필드만 설정하여 맞춤법이 틀린 필드 이름으로부터 사용자를 보호하는가? 타입이 적용되는가(즉, `string` 필드에 `int`를 넣지 않는가?) | 예, [OpenAPI v3.0 유효성 검사](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation)를 기반으로 하는 스키마(1.16에서 GA) | 예 |
 
@@ -250,6 +250,5 @@ CRD는 항상 API 서버의 빌트인 리소스와 동일한 인증, 권한 부
 
 * [애그리게이션 레이어(aggregation layer)로 쿠버네티스 API 확장](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)하는 방법에 대해 배우기.
 
-* [커스텀리소스데피니션으로 쿠버네티스 API 확장](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)하는 방법에 대해 배우기.
+* [커스텀리소스데피니션으로 쿠버네티스 API 확장](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)하는 방법에 대해 배우기.
-
 

content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md

@@ -158,7 +158,7 @@ kubelet 인스턴스에 자신을 다시 등록할 것으로 기대된다. 현
 장치 플러그인에서 제공하는 리소스를 모니터링하려면, 모니터링 에이전트가
 노드에서 사용 중인 장치 셋을 검색하고 메트릭과 연관될 컨테이너를 설명하는
 메타데이터를 얻을 수 있어야 한다. 장치 모니터링 에이전트에 의해 노출된
-[프로메테우스(Prometheus)](https://prometheus.io/) 지표는
+[프로메테우스](https://prometheus.io/) 지표는
 [쿠버네티스 Instrumentation 가이드라인](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/instrumentation.md)을 따라
 `pod`, `namespace` 및 `container` 프로메테우스 레이블을 사용하여 컨테이너를 식별해야 한다.
 

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

@@ -56,6 +56,8 @@ card:
 
 ### cloud-controller-manager
 
+{{< glossary_definition term_id="cloud-controller-manager" length="short" >}}
+
 cloud-controller-manager는 클라우드 제공자 전용 컨트롤러만 실행한다.
 자신의 사내 또는 PC 내부의 학습 환경에서 쿠버네티스를 실행 중인 경우
 클러스터에는 클라우드 컨트롤러 매니저가 없다.

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

@@ -9,17 +9,15 @@ card:
 
 <!-- overview -->
 
-전체 API 관례는 [API conventions doc](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)에 기술되어 있다.
+쿠버네티스 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}의 핵심은
+{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}이다. API 서버는
+최종 사용자, 클러스터의 다른 부분 그리고 외부 컴포넌트가 서로 통신할
+수 있도록 HTTP API를 제공한다.
 
-API 엔드포인트, 리소스 타입과 샘플은 [API Reference](/docs/reference)에 기술되어 있다.
+쿠버네티스 API를 사용하면 쿠버네티스 API 오브젝트(예:
+파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의하고 조작할 수 있다.
 
-API에 원격 접속하는 방법은 [Controlling API Access doc](/docs/reference/access-authn-authz/controlling-access/)에서 논의되었다.
+API 엔드포인트, 리소스 타입과 샘플은 [API Reference](/ko/docs/reference)에 기술되어 있다.
-
-쿠버네티스 API는 시스템을 위한 선언적 설정 스키마를 위한 기초가 되기도 한다. [kubectl](/ko/docs/reference/kubectl/overview/) 커맨드라인 툴을 사용해서 API 오브젝트를 생성, 업데이트, 삭제 및 조회할 수 있다.
-
-쿠버네티스는 또한 API 리소스에 대해 직렬화된 상태를 (현재는 [etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)에) 저장한다.
-
-쿠버네티스 자체는 여러 컴포넌트로 나뉘어져서 각각의 API를 통해 상호작용한다.
 
 
 
@@ -28,54 +26,77 @@ API에 원격 접속하는 방법은 [Controlling API Access doc](/docs/referenc
 
 ## API 변경
 
-경험에 따르면, 성공적인 시스템은 새로운 유스케이스의 등장과 기존 유스케이스의 변경에 맞춰 성장하고 변경될 필요가 있다. 그래서, 쿠버네티스 API가 지속적으로 변경되고 성장하기를 바란다. 그러나, 일정 기간 동안은 현재의 클라이언트와의 호환성을 깨지 않으려고 한다. 일반적으로, 새로운 API 리소스와 새로운 리소스 필드가 주기적으로 추가될 것이다. 리소스나 필드를 없애는 일은 다음의 [API deprecation policy](/docs/reference/using-api/deprecation-policy/)를 따른다.
+새로운 유스케이스가 등장하거나 기존 시스템이 변경됨에 따라 성공적인 시스템은 성장하고 변경될 필요가 있다.
+따라서, 쿠버네티스는 쿠버네티스 API를 지속적으로 변경하고 성장시킬 수 있는 디자인 기능을 가지고 있다.
+쿠버네티스 프로젝트는 기존 클라이언트와의 호환성을 중단하지 _않고_,
+다른 프로젝트가 적응할 수 있도록 오랫동안 호환성을 유지하는 것을 목표로 한다.
 
-호환되는 변경에 어떤 내용이 포함되는지, 어떻게 API를 변경하는지에 대한 자세한 내용은 [API change document](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md)에 있다.
+일반적으로, 새로운 API 리소스와 새로운 리소스 필드가 주기적으로 추가될 것이다.
+리소스나 필드를 없애는 일은 다음의
+[API 사용 중단 정책](/docs/reference/using-api/deprecation-policy/)을 따른다.
 
-## OpenAPI 및 Swagger 정의
+호환되는 변경에 어떤 내용이 포함되는지, 어떻게 API를 변경하는지에 대한 자세한 내용은
+[API 변경](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)을 참고한다.
+
+## OpenAPI 명세 {#api-specification}
 
 완전한 API 상세 내용은 [OpenAPI](https://www.openapis.org/)를 활용해서 문서화했다.
 
-쿠버네티스 1.10부터, OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다.
+OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다.
-요청 형식은 HTTP 헤더에 명시해서 설정할 수 있다.
+다음과 같은 요청 헤더를 사용해서 응답 형식을 요청할 수 있다.
 
-헤더   | 가능한 값
+<table>
------- | ---------
+  <thead>
-Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (기본 content-type은 `*/*`에 대해 `application/json`이거나 이 헤더를 전달하지 않음)
+     <tr>
-Accept-Encoding | `gzip` (이 헤더를 전달하지 않아도 됨)
+        <th>Header</th>
-
+        <th style="min-width: 50%;">Possible values</th>
-1.14 이전 버전에서 형식이 구분된 엔드포인트(`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`)는 OpenAPI 스펙을 다른 포맷으로 제공한다.
+        <th>Notes</th>
-이러한 엔드포인트는 사용이 중단되었으며, 쿠버네티스 1.14에서 제거되었다.
+     </tr>
-
+  </thead>
-**OpenAPI 규격을 조회하는 예제**
+  <tbody>
-
+     <tr>
-1.10 이전 | 쿠버네티스 1.10 이상
+        <td><code>Accept-Encoding</code></td>
------------ | -----------------------------
+        <td><code>gzip</code></td>
-GET /swagger.json | GET /openapi/v2 **Accept**: application/json
+        <td><em>not supplying this header is also acceptable</em></td>
-GET /swagger-2.0.0.pb-v1 | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf
+     </tr>
-GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf **Accept-Encoding**: gzip
+     <tr>
+        <td rowspan="3"><code>Accept</code></td>
+        <td><code>application/com.github.proto-openapi.spec.v2@v1.0+protobuf</code></td>
+        <td><em>mainly for intra-cluster use</em></td>
+     </tr>
+     <tr>
+        <td><code>application/json</code></td>
+        <td><em>default</em></td>
+     </tr>
+     <tr>
+        <td><code>*</code></td>
+        <td><em>serves </em><code>application/json</code></td>
+     </tr>
+  </tbody>
+  <caption>Valid request header values for OpenAPI v2 queries</caption>
+</table>
 
 쿠버네티스는 주로 클러스터 내부 통신용 API를 위해 대안적인 Protobuf에 기반한 직렬화 형식을 구현한다. 해당 API는 [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) 문서와 IDL 파일에 문서화되어 있고 각각의 스키마를 담고 있는 IDL 파일은 API 오브젝트를 정의하는 Go 패키지에 들어있다.
 
-1.14 이전 버전에서 쿠버네티스 apiserver는 `/swaggerapi`에서 [Swagger v1.2](http://swagger.io/)
-쿠버네티스 API 스펙을 검색하는데 사용할 수 있는 API도 제공한다.
-이러한 엔드포인트는 사용이 중단되었으며, 쿠버네티스 1.14에서 제거되었다.
-
 ## API 버전 규칙
 
 필드를 없애거나 리소스 표현을 재구성하기 쉽도록,
 쿠버네티스는 `/api/v1`이나 `/apis/extensions/v1beta1`과 같이
 각각 다른 API 경로에서 복수의 API 버전을 지원한다.
 
-리소스나 필드 수준보다는 API 수준에서 버전을 선택했는데, API가 명료하고, 시스템 리소스와 행위 관점에서 일관성있으며, 더 이상 사용되지 않는 API나 실험적인 API에 접근을 제어할 수 있도록 하기 위함이다. 스키마 변경에 대해서 JSON과 Protobuf 직렬화 스키마 모두 동일한 가이드라인을 따른다. 다음에 이어지는 설명 모두는 이 두 가지 형식에 모두 해당한다.
+버전 관리는 API가 시스템 리소스와 동작에 대해 명확하고 일관된 보기를
+제공하고 수명 종료(end-of-life)와 실험적인 API에 대한 접근을 제어할 수 있도록
+리소스 또는 필드 수준이 아닌 API 수준에서 수행된다.
 
-API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관되어 있음을 알아두자.
+JSON과 Protobuf 직렬화 스키마는 스키마 변경에 대한 동일한 지침을 따르며 아래의 모든 설명은 두 형식을 모두 포함한다.
-[API and release versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는
-API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다.
 
+참고로 API 버전 관리와 소프트웨어 버전 관리는 간접적으로만 연관이 있다.
+[쿠버네티스 릴리스 버전 관리](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)
+제안은 API 버전 관리와 소프트웨어 버전 관리 사이의 관계를 설명한다.
 
-API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르다는 것을 암시한다.
+API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르다는 것을 암시한다. 각각의 수준에 대한 조건은
-각각의 수준에 대한 조건은 [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서 상세히 다룬다. 요약하자면 다음과 같다.
+[API 변경](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서
+상세히 다룬다. 요약하자면 다음과 같다.
 
 - 알파(Alpha) 수준:
   - 버전 이름에 `alpha`가 포함된다. (예: `v1alpha1`)
@@ -102,32 +123,35 @@ API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르
 쿠버네티스 API를 보다 쉽게 확장하기 위해서, [*API 그룹*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)을 구현했다.
 API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명시된다.
 
-현재 다양한 API 그룹이 사용되고 있다.
+클러스터에 다양한 API 그룹이 있다.
 
-1. *핵심* 그룹 또는 *레거시 그룹* 이라고 하는 그룹은 REST 경로 `/api/v1`에서 `apiVersion: v1`을 사용한다.
+1. *레거시* 그룹이라고도 하는 *핵심* 그룹은 REST 경로인 `/api/v1/` 에 있고, `apiVersion: v1`을 사용한다.
 
 1. 이름이 있는 그룹은 REST 경로 `/apis/$GROUP_NAME/$VERSION`에 있으며 `apiVersion: $GROUP_NAME/$VERSION`을 사용한다
-   (예: `apiVersion: batch/v1`).  지원되는 API 그룹 전체의 목록은 [Kubernetes API reference](/docs/reference/)에서 확인할 수 있다.
+  (예: `apiVersion: batch/v1`). 사용 가능한 API 그룹의 전체의 목록은
+  [쿠버네티스 API 참조](/ko/docs/reference/)에 있다.
 
 
-[Custom resources](/docs/concepts/api-extension/custom-resources/)로 API를 확장하는 경우에는 두 종류의 경로가 지원된다.
+[사용자 지정 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)로 API를 확장하는 두 가지 방법이 있다.
 
-1. [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)은 아주 기본적인
+1. [커스텀리소스데피니션(CustomResourceDefinition)](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)은
-   CRUD 요구를 갖는 사용자에게 적합하다.
+   API 서버가 선택한 리소스 API를 제공하는 방법을 선언적으로 정의할 수 있다.
-1. 쿠버네티스 API 의미론의 전체 셋을 가지고, 사용자만의 apiserver를 만들고자하는 사용자는
+1. 또한, [자신의 확장 API 서버 구현](/docs/tasks/extend-kubernetes/setup-extension-api-server/)과
-   [aggregator](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)를 사용해서 클라이언트 입장에서 매끄럽게 동작하도록
+   [aggregator](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)를
-   만들 수 있다.
+   사용해서 클라이언트를 원활하게 만들 수 있다.
 
 
 ## API 그룹 활성화 또는 비활성화하기
 
-특정 리소스와 API 그룹은 기본적으로 활성화되어 있다. 이들은 apiserver에서 `--runtime-config`를 설정해서 활성화하거나
+특정 리소스와 API 그룹은 기본적으로 활성화되어 있다. kube-apiserver에서 커맨드 라인 옵션으로 `--runtime-config` 를
-비활성화 시킬 수 있다. `--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어서 batch/v1을 비활성화 시키려면
+설정해서 활성화하거나 비활성화할 수 있다.
-`--runtime-config=batch/v1=false`와 같이 설정하고, batch/v2alpha1을 활성화 시키려면 `--runtime-config=batch/v2alpha1`을
-설정한다. 이 플래그는 apiserver의 런타임 설정에 쉼표로 분리된 키=값 쌍의 집합을 허용한다.
 
-{{< note >}}그룹이나 리소스를 활성화 또는 비활성화 시키기 위해서는 apiserver와 controller-manager를 재시작해서
+`--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어서 batch/v1을 비활성화시키려면,
-`--runtime-config` 변경을 반영시켜야 한다. {{< /note >}}
+`--runtime-config=batch/v1=false`와 같이 설정하고, batch/v2alpha1을 활성화시키려면, `--runtime-config=batch/v2alpha1`을
+설정한다. 이 플래그는 API 서버의 런타임 설정에 쉼표로 분리된 키=값 쌍의 집합을 허용한다.
+
+{{< note >}}그룹이나 리소스를 활성화 또는 비활성화하려면 kube-apiserver와
+controller-manager를 재시작해서 `--runtime-config` 변경 사항을 반영해야 한다. {{< /note >}}
 
 ## extensions/v1beta1 그룹 내 특정 리소스 활성화하기
 
@@ -137,4 +161,19 @@ API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명
 
 {{< note >}}개별 리소스의 활성화/비활성화는 레거시 문제로 `extensions/v1beta1` API 그룹에서만 지원된다. {{< /note >}}
 
+## 지속성
 
+쿠버네티스는 API 리소스에 대한 직렬화된 상태를 {{< glossary_tooltip term_id="etcd" >}}에
+기록하고 저장한다.
+
+
+## {{% heading "whatsnext" %}}
+
+[API 접근 제어하기](/docs/reference/access-authn-authz/controlling-access/)는 클러스터가
+API 접근에 대한 인증과 권한을 관리하는 방법을 설명한다.
+
+전체 API 규약은
+[API 규약](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions)
+문서에 설명되어 있다.
+
+API 엔드포인트, 리소스 타입과 샘플은 [API 참조](/docs/reference/kubernetes-api/)에 설명되어 있다.

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

@@ -8,7 +8,8 @@ kubectl과 대시보드와 같은 많은 도구들로 쿠버네티스 오브젝
 공통 레이블 셋은 모든 도구들이 이해할 수 있는 공통의 방식으로 오브젝트를 식별하고
 도구들이 상호 운용적으로 작동할 수 있도록 한다.
 
-권장 레이블은 지원 도구 외에도 쿼리하는 방식으로 애플리케이션을 식별하게 한다.
+권장 레이블은 지원 도구 외에도 쿼리하는 방식으로
+애플리케이션을 식별하게 한다.
 
 
 <!-- body -->
@@ -18,17 +19,18 @@ kubectl과 대시보드와 같은 많은 도구들로 쿠버네티스 오브젝
 애플리케이션에 포함된 정의는 유연하다.
 
 {{< note >}}
-메타데이터들은 권장하는 레이블이다. 애플리케이션을 보다 쉽게 관리할 수 있지만 코어 도구에는 필요하지 않다.
+메타데이터들은 권장하는 레이블이다. 애플리케이션을 보다 쉽게 관리할 수 있지만
+코어 도구에는 필요하지 않다.
 {{< /note >}}
 
 공유 레이블과 주석에는 공통 접두사인 `app.kubernetes.io` 가 있다.
 접두사가 없는 레이블은 사용자가 개인적으로 사용할 수 있다.
 공유 접두사는 공유 레이블이 사용자 정의 레이블을 방해하지 않도록 한다.
 
-
 ## 레이블
 
-레이블을 최대한 활용하려면 모든 리소스 오브젝트에 적용해야 한다.
+레이블을 최대한 활용하려면 모든 리소스 오브젝트에
+적용해야 한다.
 
 | Key                                 | Description           | Example  | Type |
 | ----------------------------------- | --------------------- | -------- | ---- |
@@ -56,8 +58,9 @@ metadata:
 
 ## 애플리케이션과 애플리케이션 인스턴스
 
-애플리케이션은 때에 따라 쿠버네티스 클러스터의 동일한 네임스페이스에 한번 또는 그 이상 설치할 수 있다.
+애플리케이션은 때에 따라 쿠버네티스 클러스터의 동일한 네임스페이스에
-예를 들어 워드프레스는 다른 워드프레스가 설치되어있는 웹사이트에 한번 한번 또는 그 이상 설치할 수 있다.
+한번 또는 그 이상 설치할 수 있다. 예를 들어 워드프레스는 다른 워드프레스가
+설치되어있는 웹사이트에 한번 한번 또는 그 이상 설치할 수 있다.
 
 애플리케이션의 이름과 인스턴스 이름은 별도로 기록된다.
 예를 들어 워드프레스는 `app.kubernetes.io/name` 에 `wordpress` 를 가지며 인스턴스 이름으로는 
@@ -97,7 +100,8 @@ metadata:
 
 ### 데이터베이스가 있는 웹 애플리케이션
 
-Helm을 이용해서 데이터베이스(MySQL)을 이용하는 웹 애플리케이션(WordPress)을 설치한 것과 같이 좀 더 복잡한 애플리케이션을 고려할 수 있다.
+Helm을 이용해서 데이터베이스(MySQL)을 이용하는 웹 애플리케이션(WordPress)을
+설치한 것과 같이 좀 더 복잡한 애플리케이션을 고려할 수 있다.
 다음 식별자는 이 애플리케이션을 배포하는데 사용하는 오브젝트의 시작을 보여준다.
 
 WordPress를 배포하는데 다음과 같이 `Deployment` 로 시작한다.

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

@@ -16,12 +16,7 @@ kubectl get pods --field-selector status.phase=Running
 ```
 
 {{< note >}}
-필드 셀렉터는 본질적으로 리소스 *필터* 이다. 기본적으로 적용되는 셀렉터나 필드는 없으며, 이는 명시된 종류의 모든 리소스가 선택된다는 것을 의미한다. 따라서 다음의 `kubectl` 쿼리들은 동일하다.
+필드 셀렉터는 본질적으로 리소스 *필터* 이다. 기본적으로 적용되는 셀렉터나 필드는 없으며, 이는 명시된 종류의 모든 리소스가 선택된다는 것을 의미한다. 여기에 따라오는 `kubectl` 쿼리인 `kubectl get pods` 와 `kubectl get pods --field-selector ""` 는 동일하다.
-
-```shell
-kubectl get pods
-kubectl get pods --field-selector ""
-```
 {{< /note >}}
 
 ## 사용 가능한 필드
@@ -53,7 +48,7 @@ kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Alway
 
 ## 여러 개의 리소스 종류
 
-필드 셀렉터를 여러 개의 리소스 종류에 걸쳐 사용할 수 있다. 다음의 `kubectl` 커맨드는 `default` 네임스페이스에 속해있지 않은 모든 스테이트풀 셋과 서비스를 선택한다.
+필드 셀렉터를 여러 개의 리소스 종류에 걸쳐 사용할 수 있다. 다음의 `kubectl` 커맨드는 `default` 네임스페이스에 속해있지 않은 모든 스테이트풀셋(StatefulSet)과 서비스를 선택한다.
 
 ```shell
 kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default

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

@@ -44,7 +44,8 @@ spec에 3개의 애플리케이션 레플리카가 동작되도록
 설정할 수 있다. 쿠버네티스 시스템은 그 디플로이먼트 spec을 읽어
 spec에 일치되도록 상태를 업데이트하여 3개의 의도한
 애플리케이션 인스턴스를 구동시킨다. 만약, 그 인스턴스들 중 어느 하나가
-어떤 문제로 인해 멈춘다면(상태 변화 발생), 쿠버네티스 시스템은 보정(이 경우에는 대체 인스턴스를 시작하여)을 통해
+어떤 문제로 인해 멈춘다면(상태 변화 발생), 쿠버네티스 시스템은 보정(이
+경우에는 대체 인스턴스를 시작하여)을 통해
 spec과 status간의 차이에 대응한다.
 
 오브젝트 명세, 상태, 그리고 메타데이터에 대한 추가 정보는, [Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md) 를 참조한다.
@@ -91,6 +92,5 @@ deployment.apps/nginx-deployment created
 ## {{% heading "whatsnext" %}}
 
 * API 개념의 더 많은 설명은 [Kubernetes API 개요](/ko/docs/reference/using-api/api-overview/)를 본다.
-* [파드(Pod)](/ko/docs/concepts/workloads/pods/pod-overview/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다.
+* [파드](/ko/docs/concepts/workloads/pods/pod-overview/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다.
 * 쿠버네티스의 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 배운다.
-

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

@@ -83,7 +83,8 @@ API는 현재 _일치성 기준_ 과 _집합성 기준_ 이라는 두 종류의
 레이블 셀렉터는 쉼표로 구분된 다양한 _요구사항_ 에 따라 만들 수 있다. 다양한 요구사항이 있는 경우 쉼표 기호가 AND(`&&`) 연산자로 구분되는 역할을 하도록 해야 한다.
 
 비어있거나 지정되지 않은 셀렉터는 상황에 따라 달라진다.
-셀렉터를 사용하는 API 유형은 유효성과 의미를 문서화해야 한다.
+셀렉터를 사용하는 API 유형은 유효성과 의미를
+문서화해야 한다.
 
 {{< note >}}
 레플리카 셋과 같은 일부 API 유형에서 두 인스턴스의 레이블 셀렉터는 네임스페이스 내에서 겹치지 않아야 한다. 그렇지 않으면 컨트롤러는 상충하는 명령으로 보고, 얼마나 많은 복제본이 필요한지 알 수 없다.

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

@@ -15,7 +15,6 @@ weight: 20
 
 
 
-
 <!-- body -->
 
 ## 이름 {#names}

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

@@ -127,7 +127,6 @@ kubectl replace -f nginx.yaml
 - 명령형 오브젝트 구성은 디렉토리가 아닌, 파일에 대해 가장 효과가 있다.
 - 활성 오브젝트에 대한 업데이트는 구성 파일에 반영되어야 한다. 그렇지 않으면 다음 교체 중에 손실된다.
 
-
 ## 선언형 오브젝트 구성
 
 선언형 오브젝트 구성을 사용할 경우, 사용자는 로컬에 보관된 오브젝트
@@ -178,6 +177,7 @@ kubectl apply -R -f configs/
 
 ## {{% heading "whatsnext" %}}
 
+
 - [명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/)
 - [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기(명령형)](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/)
 - [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
@@ -186,6 +186,4 @@ kubectl apply -R -f configs/
 - [Kubectl 서적](https://kubectl.docs.kubernetes.io)
 - [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
 
-{{< comment >}}
-{{< /comment >}}
 

content/ko/docs/concepts/policy/limit-range.md

@@ -24,11 +24,13 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다.
 
 ## 리밋레인지 활성화
 
-많은 쿠버네티스 배포판에 리밋레인지 지원이 기본적으로 활성화되어 있다. apiserver `--enable-admission-plugins=` 플래그의 인수 중 하나로 `LimitRanger` 어드미션 컨트롤러가 있는 경우 활성화된다.
+쿠버네티스 1.10 버전부터 리밋레인지 지원이 기본적으로 활성화되었다.
 
-해당 네임스페이스에 리밋레인지 오브젝트가 있는 경우 특정 네임스페이스에 리밋레인지가 지정된다.
+해당 네임스페이스에 리밋레인지 오브젝트가 있는 경우
+특정 네임스페이스에 리밋레인지가 지정된다.
 
-리밋레인지 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야한다.
+리밋레인지 오브젝트의 이름은 유효한
+[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
 
 ### 리밋 레인지 개요
 
@@ -36,7 +38,8 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다.
 - 사용자는 네임스페이스에서 파드, 컨테이너 및 퍼시스턴트볼륨클레임과 같은 리소스를 생성한다.
 - `LimitRanger` 어드미션 컨트롤러는 컴퓨팅 리소스 요청 사항을 설정하지 않은 모든 파드와 컨테이너에 대한 기본값과 제한을 지정하고 네임스페이스의 리밋레인지에 정의된 리소스의 최소, 최대 및 비율을 초과하지 않도록 사용량을 추적한다.
 - 리밋레인지 제약 조건을 위반하는 리소스(파드, 컨테이너, 퍼시스턴트볼륨클레임)를 생성하거나 업데이트하는 경우 HTTP 상태 코드 `403 FORBIDDEN` 및 위반된 제약 조건을 설명하는 메시지와 함께 API 서버에 대한 요청이 실패한다.
-- `cpu`, `memory`와 같은 컴퓨팅 리소스의 네임스페이스에서 리밋레인지가 활성화된 경우 사용자는 해당 값에 대한 요청 또는 제한을 지정해야 한다. 그렇지 않으면 시스템에서 파드 생성이 거부될 수 있다.
+- `cpu`, `memory`와 같은 컴퓨팅 리소스의 네임스페이스에서 리밋레인지가 활성화된 경우 사용자는 해당 값에
+  대한 요청 또는 제한을 지정해야 한다. 그렇지 않으면 시스템에서 파드 생성이 거부될 수 있다.
 - 리밋레인지 유효성 검사는 파드 실행 단계가 아닌 파드 어드미션 단계에서만 발생한다.
 
 리밋 레인지를 사용하여 생성할 수 있는 정책의 예는 다음과 같다.
@@ -66,4 +69,3 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다.
 - [네임스페이스당 할당량을 설정하는 자세한 예시](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/).
 
 
-

content/ko/docs/concepts/policy/pod-security-policy.md

@@ -31,7 +31,7 @@ _Pod Security Policy_ 는 파드 명세의 보안 관련 측면을 제어하는
 | 호스트 네트워킹과 포트의 사용                               | [`hostNetwork`, `hostPorts`](#호스트-네임스페이스) |
 | 볼륨 유형의 사용                                        | [`volumes`](#볼륨-및-파일시스템)      |
 | 호스트 파일시스템의 사용                                  | [`allowedHostPaths`](#볼륨-및-파일시스템) |
-| FlexVolume 드라이버의 화이트리스트                         | [`allowedFlexVolumes`](#flexvolume-드라이버) |
+| 특정 FlexVolume 드라이버의 허용                         | [`allowedFlexVolumes`](#flexvolume-드라이버) |
 | 파드 볼륨을 소유한 FSGroup 할당                           | [`fsGroup`](#볼륨-및-파일시스템)      |
 | 읽기 전용 루트 파일시스템 사용 필요                          | [`readOnlyRootFilesystem`](#볼륨-및-파일시스템) |
 | 컨테이너의 사용자 및 그룹 ID                               | [`runAsUser`, `runAsGroup`, `supplementalGroups`](#사용자-및-그룹) |
@@ -398,13 +398,13 @@ podsecuritypolicy "example" deleted
 동일한 노드에 있는 다른 파드의 네트워크 활동을 스누핑(snoop)하는 데
 사용할 수 있다.
 
-**HostPorts** - 호스트 네트워크 네임스페이스에 허용되는 포트 범위의 화이트리스트(whitelist)를
+**HostPorts** - 호스트 네트워크 네임스페이스에 허용되는 포트 범위의 목록을
 제공한다. `min`과 `max`를 포함하여 `HostPortRange`의 목록으로 정의된다.
 기본값은 허용하는 호스트 포트 없음(no allowed host ports)이다.
 
 ### 볼륨 및 파일시스템
 
-**Volumes** - 허용되는 볼륨 유형의 화이트리스트를 제공한다. 허용 가능한 값은
+**Volumes** - 허용되는 볼륨 유형의 목록을 제공한다. 허용 가능한 값은
 볼륨을 생성할 때 정의된 볼륨 소스에 따른다. 볼륨 유형의 전체 목록은
 [볼륨 유형들](/ko/docs/concepts/storage/volumes/#볼륨-유형들)에서 참고한다.
 또한 `*`를 사용하여 모든 볼륨 유형을
@@ -435,7 +435,7 @@ podsecuritypolicy "example" deleted
 유효성을 검사한다.
 - *RunAsAny* - 기본값은 제공되지 않는다. 어떠한 `fsGroup` ID의 지정도 허용한다.
 
-**AllowedHostPaths** - hostPath 볼륨에서 사용할 수 있는 호스트 경로의 화이트리스트를
+**AllowedHostPaths** - hostPath 볼륨에서 사용할 수 있는 호스트 경로의 목록을
 지정한다. 빈 목록은 사용되는 호스트 경로에 제한이 없음을 의미한다.
 이는 단일 `pathPrefix` 필드가 있는 오브젝트 목록으로 정의되며, hostPath 볼륨은
 허용된 접두사로 시작하는 경로를 마운트할 수 있으며 `readOnly` 필드는
@@ -466,7 +466,7 @@ allowedHostPaths:
 
 ### FlexVolume 드라이버
 
-flexvolume에서 사용할 수 있는 FlexVolume 드라이버의 화이트리스트를 지정한다.
+flexvolume에서 사용할 수 있는 FlexVolume 드라이버의 목록을 지정한다.
 빈 목록 또는 nil은 드라이버에 제한이 없음을 의미한다.
 [`volumes`](#볼륨-및-파일시스템) 필드에 `flexVolume` 볼륨 유형이 포함되어
 있는지 확인한다. 그렇지 않으면 FlexVolume 드라이버가 허용되지 않는다.
@@ -552,7 +552,7 @@ spec:
 다음 필드는 대문자로 표기된 기능 이름 목록을
 `CAP_` 접두사 없이 가져온다.
 
-**AllowedCapabilities** - 컨테이너에 추가될 수 있는 기능의 화이트리스트를
+**AllowedCapabilities** - 컨테이너에 추가될 수 있는 기능의 목록을
 제공한다. 기본적인 기능 셋은 암시적으로 허용된다. 비어있는 셋은
 기본 셋을 넘어서는 추가 기능이 추가되지 않는 것을
 의미한다. `*`는 모든 기능을 허용하는 데 사용할 수 있다.
@@ -576,7 +576,7 @@ spec:
 
 ### AllowedProcMountTypes
 
-`allowedProcMountTypes`는 허용된 ProcMountTypes의 화이트리스트이다.
+`allowedProcMountTypes`는 허용된 ProcMountTypes의 목록이다.
 비어 있거나 nil은 `DefaultProcMountType`만 사용할 수 있음을 나타낸다.
 
 `DefaultProcMount`는 /proc의 읽기 전용 및 마스킹(masking)된 경로에 컨테이너 런타임
@@ -637,4 +637,3 @@ spec:
 
 API 세부 정보는 [파드 시큐리티 폴리시 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 참조한다.
 
-

content/ko/docs/concepts/policy/resource-quotas.md

@@ -56,7 +56,8 @@ weight: 10
 API 서버 `--enable-admission-plugins=` 플래그의 인수 중 하나로
 `ResourceQuota`가 있는 경우 활성화된다.
 
-해당 네임스페이스에 `ResourceQuota`가 있는 경우 특정 네임스페이스에 리소스 쿼터가 적용된다.
+해당 네임스페이스에 `ResourceQuota`가 있는 경우 특정 네임스페이스에
+리소스 쿼터가 적용된다.
 
 ## 컴퓨트 리소스 쿼터
 
@@ -160,9 +161,10 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다.
 | `services.nodeports` | 네임스페이스에 존재할 수 있는 노드 포트 유형의 총 서비스 수 |
 | `secrets` | 네임스페이스에 존재할 수 있는 총 시크릿 수 |
 
-예를 들어, `pods` 쿼터는 터미널이 아닌 단일 네임스페이스에서 생성된 `pods` 수를 계산하고 최대값을 적용한다.
+예를 들어, `pods` 쿼터는 터미널이 아닌 단일 네임스페이스에서 생성된 `pods` 수를
-사용자가 작은 파드를 많이 생성하여 클러스터의 파드 IP 공급이 고갈되는 경우를 피하기 위해
+계산하고 최댓값을 적용한다. 사용자가 작은 파드를 많이 생성하여 클러스터의 파드 IP
-네임스페이스에 `pods` 쿼터를 설정할 수 있다.
+공급이 고갈되는 경우를 피하기 위해 네임스페이스에
+`pods` 쿼터를 설정할 수 있다.
 
 ## 쿼터 범위
 
@@ -599,4 +601,3 @@ plugins:
 
 자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)를 참고하길 바란다.
 
-

content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md

@@ -151,7 +151,7 @@ spec:
 
 예시에서 연산자 `In` 이 사용되고 있는 것을 볼 수 있다. 새로운 노드 어피니티 구문은 다음의 연산자들을 지원한다. `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`.
 `NotIn` 과 `DoesNotExist` 를 사용해서 안티-어피니티를 수행하거나,
-특정 노드에서 파드를 쫓아내는 [노드 테인트(taint)](/docs/concepts/configuration/taint-and-toleration/)를 설정할 수 있다.
+특정 노드에서 파드를 쫓아내는 [노드 테인트(taint)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 설정할 수 있다.
 
 `nodeSelector` 와 `nodeAffinity` 를 모두 지정한다면 파드가 후보 노드에 스케줄 되기 위해서는
 *둘 다* 반드시 만족해야 한다.
@@ -206,13 +206,11 @@ spec:
 `preferredDuringSchedulingIgnoredDuringExecution` 이다. 파드 어피니티 규칙에 의하면 키 "security" 와 값
 "S1"인 레이블이 있는 하나 이상의 이미 실행 중인 파드와 동일한 영역에 있는 경우에만 파드를 노드에 스케줄할 수 있다.
 (보다 정확하게는, 클러스터에 키 "security"와 값 "S1"인 레이블을 가지고 있는 실행 중인 파드가 있는 키
-`failure-domain.beta.kubernetes.io/zone` 와 값 V인 노드가 최소 하나 이상 있고, 노드 N이 키
+`failure-domain.beta.kubernetes.io/zone` 와 값 V인 노드가 최소 하나 이상 있고,
-`failure-domain.beta.kubernetes.io/zone` 와 일부 값이 V인 레이블을 가진다면 파드는 노드 N에서 실행할 수 있다.)
+노드 N이 키 `failure-domain.beta.kubernetes.io/zone` 와
-파드 안티-어피니티 규칙에 의하면 노드가 이미 키 "security"와 값 "S2"인 레이블을 가진 파드를
+일부 값이 V인 레이블을 가진다면 파드는 노드 N에서 실행할 수 있다.)
-실행하고 있는 파드는 노드에 스케줄되는 것을 선호하지 않는다.
+파드 안티-어피니티 규칙에 의하면 파드는 키 "security"와 값 "S2"인 레이블을 가진 파드와
-(만약 `topologyKey` 가 `failure-domain.beta.kubernetes.io/zone` 라면 노드가 키
+동일한 영역의 노드에 스케줄되지 않는다.
-"security"와 값 "S2"를 레이블로 가진 파드와
-동일한 영역에 있는 경우, 노드에 파드를 예약할 수 없음을 의미한다.)
 [디자인 문서](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)를 통해
 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 의
 파드 어피니티와 안티-어피니티에 대한 많은 예시를 맛볼 수 있다.
@@ -222,10 +220,11 @@ spec:
 원칙적으로, `topologyKey` 는 적법한 어느 레이블-키도 될 수 있다.
 하지만, 성능과 보안상의 이유로 topologyKey에는 몇 가지 제약조건이 있다.
 
-1. 어피니티와 `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티는 대해
+1. 파드 어피니티에서 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 는
-`topologyKey` 가 비어있는 것을 허용하지 않는다.
+`topologyKey` 의 빈 값을 허용하지 않는다.
-2. `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티에서 `topologyKey` 를 `kubernetes.io/hostname` 로 제한하기 위해 어드미션 컨트롤러 `LimitPodHardAntiAffinityTopology` 가 도입되었다. 사용자 지정 토폴로지를에 사용할 수 있도록 하려면, 어드미션 컨트롤러를 수정하거나 간단히 이를 비활성화 할 수 있다.
+2. 파드 안티-어피니티에서도 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 는
-3. `preferredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티는 `topologyKey` 가 비어있는 것을 허용하지 않는다.
+`topologyKey` 의 빈 값을 허용하지 않는다.
+3. `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티에서 `topologyKey` 를 `kubernetes.io/hostname` 로 제한하기 위해 어드미션 컨트롤러 `LimitPodHardAntiAffinityTopology` 가 도입되었다. 사용자 지정 토폴로지를 사용할 수 있도록 하려면, 어드미션 컨트롤러를 수정하거나 아니면 간단히 이를 비활성화해야 한다.
 4. 위의 경우를 제외하고, `topologyKey` 는 적법한 어느 레이블-키도 가능하다.
 
 `labelSelector` 와 `topologyKey` 외에도 `labelSelector` 와 일치해야 하는 네임스페이스 목록 `namespaces` 를
@@ -388,7 +387,7 @@ spec:
 ## {{% heading "whatsnext" %}}
 
 
-[테인트](/docs/concepts/configuration/taint-and-toleration/)는 노드가 특정 파드들을 *쫓아내게* 할 수 있다.
+[테인트](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)는 노드가 특정 파드들을 *쫓아낼* 수 있다.
 
 [노드 어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)와
 [파드간 어피니티/안티-어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)에 대한 디자인 문서에는
@@ -397,5 +396,3 @@ spec:
 파드가 노드에 할당되면 kubelet은 파드를 실행하고 노드의 로컬 리소스를 할당한다.
 [토폴로지 매니저](/docs/tasks/administer-cluster/topology-manager/)는
 노드 수준의 리소스 할당 결정에 참여할 수 있다.
-
-

content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md

@@ -89,10 +89,10 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
 
 ## {{% heading "whatsnext" %}}
 
-* [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling/scheduler-perf-tuning/)에 대해 읽기
+* [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기
 * [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽기
 * kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기
 * [멀티 스케줄러 구성하기](/docs/tasks/administer-cluster/configure-multiple-schedulers/)에 대해 배우기
 * [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기
-* [파드 오버헤드](/docs/concepts/configuration/pod-overhead/)에 대해 배우기
+* [파드 오버헤드](/ko/docs/concepts/configuration/pod-overhead/)에 대해 배우기
 

content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md

@@ -8,8 +8,8 @@ weight: 70
 
 {{< feature-state for_k8s_version="1.14" state="beta" >}}
 
-[kube-scheduler](/ko/docs/concepts/scheduling/kube-scheduler/#kube-scheduler)
+[kube-scheduler](/ko/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler)는
-는 쿠버네티스의 기본 스케줄러이다. 그것은 클러스터의
+쿠버네티스의 기본 스케줄러이다. 그것은 클러스터의
 노드에 파드를 배치하는 역할을 한다.
 
 파드의 스케줄링 요건을 충족하는
@@ -68,7 +68,7 @@ scheduler            Healthy   ok
 정수 값(숫자)로 변환 한다. 스케줄링 중에 kube-scheduler가 구성된
 비율을 초과 할만큼 충분히 실행 가능한 노드를 식별한 경우, kube-scheduler는
 더 실행 가능한 노드를 찾는 검색을 중지하고
-[스코어링 단계](/ko/docs/concepts/scheduling/kube-scheduler/#kube-scheduler-implementation)를 진행한다.
+[스코어링 단계](/ko/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)를 진행한다.
 
 [스케줄러가 노드 탐색을 반복(iterate)하는 방법](#스케줄러가-노드-탐색을-반복-iterate-하는-방법)
 은 이 프로세스를 자세히 설명한다.
@@ -101,11 +101,12 @@ algorithmSource:
 percentageOfNodesToScore: 50
 ```
 
+
 ### percentageOfNodesToScore 튜닝
 
 `percentageOfNodesToScore`는 1과 100 사이의 값이어야 하며
 기본값은 클러스터 크기에 따라 계산된다. 또한 50 노드로 하드 코딩된
-최소 값도 있다. 
+최솟값도 있다.
 
 {{< note >}} 클러스터에서 적합한 노드가 50 미만인 경우, 스케줄러는 여전히
 모든 노드를 확인한다. 그 이유는 스케줄러가 탐색을 조기 중단하기에는 적합한
@@ -160,5 +161,3 @@ percentageOfNodesToScore: 50
 ```
 
 모든 노드를 검토한 후, 노드 1로 돌아간다.
-
-

content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md

@@ -6,16 +6,17 @@ weight: 40
 
 
 <!-- overview -->
-[여기](/ko/docs/concepts/configuration/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)에 설명된 노드 어피니티는
+[_노드 어피니티_](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)는
-노드 셋을 *끌어들이는* (기본 설정 또는 어려운 요구 사항)
+{{< glossary_tooltip text="노드" term_id="node" >}} 셋을
-*파드* 속성이다. 테인트는 그 반대로, *노드* 가 파드 셋을
+(기본 설정 또는 어려운 요구 사항으로) *끌어들이는* {{< glossary_tooltip text="파드" term_id="pod" >}}의 속성이다.
-*제외* 할 수 있다.
+_테인트_ 는 그 반대로, 노드가 파드 셋을 제외할 수 있다.
+
+_톨러레이션_ 은 파드에 적용되며, 파드를 일치하는 테인트가 있는 노드에
+스케줄되게 하지만 필수는 아니다.
 
 테인트와 톨러레이션은 함께 작동하여 파드가 부적절한 노드에 스케줄되지
 않게 한다. 하나 이상의 테인트가 노드에 적용된다. 이것은
 노드가 테인트를 용인하지 않는 파드를 수용해서는 안 되는 것을 나타낸다.
-톨러레이션은 파드에 적용되며, 파드를 일치하는 테인트가 있는 노드에 스케줄되게
-하지만 필수는 아니다.
 
 
 
@@ -61,13 +62,13 @@ tolerations:
 
 {{< codenew file="pods/pod-with-toleration.yaml" >}}
 
+지정하지 않으면 `operator` 의 기본값은 `Equal` 이다.
+
 톨러레이션은 키가 동일하고 이펙트가 동일한 경우, 테인트와 "일치"한다. 그리고 다음의 경우에도 마찬가지다.
 
 * `operator` 가 `Exists` 인 경우(이 경우 `value` 를 지정하지 않아야 함), 또는
 * `operator` 는 `Equal` 이고 `value` 는 `value` 로 같다.
 
-지정하지 않으면 `operator` 의 기본값은 `Equal` 이다.
-
 {{< note >}}
 
 두 가지 특별한 경우가 있다.
@@ -198,8 +199,7 @@ tolerations:
  * `tolerationSeconds` 가 지정된 테인트를 용인하는 파드는 지정된
   시간 동안 바인딩된 상태로 유지된다.
 
-덧붙여, 쿠버네티스 1.6 버전에서는 노드 문제를 나타내는 알파 지원이
+노드 컨트롤러는 특정 조건이 참일 때 자동으로
-도입되었다. 다시 말해, 특정 조건이 참일 때 노드 컨트롤러는 자동으로
 노드를 테인트시킨다. 다음은 빌트인 테인트이다.
 
  * `node.kubernetes.io/not-ready`: 노드가 준비되지 않았다. 이는 NodeCondition
@@ -221,10 +221,9 @@ tolerations:
 관련 테인트를 제거할 수 있다.
 
 {{< note >}}
-노드 문제로 인해 파드 축출의 기존 [비율 제한](/ko/docs/concepts/architecture/nodes/)
+콘트롤 플레인은 노드에 새 테인트를 추가하는 비율을 제한한다.
-동작을 유지하기 위해, 시스템은 실제로 테인트를 비율-제한 방식으로
+이 비율-제한은 많은 노드가 동시에 도달할 수 없을 때(예를 들어, 네트워크 중단으로)
-추가한다. 이는 마스터가 노드에서 분할되는 등의 시나리오에서
+트리거될 축출 개수를 관리한다.
-대규모 파드 축출을 방지한다.
 {{< /note >}}
 
 이 기능을 `tolerationSeconds` 와 함께 사용하면, 파드에서
@@ -243,20 +242,15 @@ tolerations:
   tolerationSeconds: 6000
 ```
 
-쿠버네티스는 사용자가 제공한 파드 구성에 이미 추가된
+{{< note >}}
-`node.kubernetes.io/not-ready` 에 대한 톨러레이션이 없는 경우
+쿠버네티스는 사용자나 컨트롤러에서 명시적으로 설정하지 않았다면, 자동으로
-`tolerationSeconds=300` 으로 `node.kubernetes.io/not-ready` 에 대한
+`node.kubernetes.io/not-ready` 와 `node.kubernetes.io/unreachable` 에 대해
-톨러레이션을 자동으로 추가한다.
+`tolerationSeconds=300` 으로
-마찬가지로 사용자가 제공한 파드 구성에 이미 추가된
-`node.kubernetes.io/unreachable` 에 대한 톨러레이션이 없는 경우
-`tolerationSeconds=300` 으로 `node.kubernetes.io/unreachable` 에 대한
 톨러레이션을 추가한다.
 
-자동으로 추가된 이 톨러레이션은 이러한 문제 중 하나가
+자동으로 추가된 이 톨러레이션은 이러한 문제 중 하나가 감지된 후 5분 동안
-감지된 후 5분 동안 바인딩 상태로 남아있는 기본 파드
+파드가 노드에 바인딩된 상태를 유지함을 의미한다.
-동작이 유지되도록 한다.
+{{< /note >}}
-[DefaultTolerationSecondsadmission controller](https://git.k8s.io/kubernetes/plugin/pkg/admission/defaulttolerationseconds)
-어드미션 컨트롤러에 의해 두 개의 기본 톨러레이션이 추가된다.
 
 [데몬셋](/ko/docs/concepts/workloads/controllers/daemonset/) 파드는 `tolerationSeconds` 가 없는
 다음 테인트에 대해 `NoExecute` 톨러레이션를 가지고 생성된다.
@@ -273,8 +267,7 @@ tolerations:
 마찬가지로 스케줄러는 노드 컨디션을 확인하지 않는다. 대신 스케줄러는 테인트를 확인한다. 이렇게 하면 노드 컨디션이 노드에 스케줄된 내용에 영향을 미치지 않는다. 사용자는 적절한 파드 톨러레이션을 추가하여 노드의 일부 문제(노드 컨디션으로 표시)를 무시하도록 선택할 수 있다.
 
 쿠버네티스 1.8 버전부터 데몬셋 컨트롤러는 다음의 `NoSchedule` 톨러레이션을
-모든 데몬에 자동으로 추가하여, 데몬셋이 중단되는 것을
+모든 데몬에 자동으로 추가하여, 데몬셋이 중단되는 것을 방지한다.
-방지한다.
 
   * `node.kubernetes.io/memory-pressure`
   * `node.kubernetes.io/disk-pressure`
@@ -284,3 +277,9 @@ tolerations:
 
 이러한 톨러레이션을 추가하면 이전 버전과의 호환성이 보장된다. 데몬셋에
 임의의 톨러레이션을 추가할 수도 있다.
+
+
+## {{% heading "whatsnext" %}}
+
+* [리소스 부족 다루기](/docs/tasks/administer-cluster/out-of-resource/)와 어떻게 구성하는지에 대해 알아보기
+* [파드 우선순위](/ko/docs/concepts/configuration/pod-priority-preemption/)에 대해 알아보기

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

@@ -87,6 +87,7 @@ etcd 암호화 | 가능한 모든 드라이브를 유휴 상태에서 암호화
 * 클러스터를 구성하는 설정 가능한 컴포넌트의 보안
 * 클러스터에서 실행되는 컴포넌트의 보안
 
+
 ### 클러스터_의_ 컴포넌트
 
 우발적이거나 악의적인 접근으로부터 클러스터를 보호하고,
@@ -159,4 +160,3 @@ TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 클라이
 * 컨트롤 플레인에 대한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/) 알아보기
 * [Rest에서 데이터 암호화](/docs/tasks/administer-cluster/encrypt-data/) 알아보기
 * [쿠버네티스 시크릿](/docs/concepts/configuration/secret/)에 대해 알아보기
-

content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md

@@ -59,11 +59,10 @@ fe00::2	ip6-allrouters
 
 ## HostAliases를 사용하여 추가 항목들 추가하기
 
-기본 상용구 이외에, `foo.local`, `bar.local`이 `127.0.0.1`로, `foo.remote`, 
+기본 상용구 이외에, `foo.local`, `bar.local`이 `127.0.0.1`로,
-`bar.remote`가 `10.1.2.3`로 해석될 수 있도록 추가 항목들을 `hosts` 파일에 추가할 수 있으며, 
+`foo.remote`, `bar.remote`가 `10.1.2.3`로 해석될 수 있도록
-이는 `.spec.hostAliases` 항목에서 정의하여 
+추가 항목들을 `hosts` 파일에 추가할 수 있으며,
-파드에 HostAliases를 추가하면 가능하다.
+이는 `.spec.hostAliases` 항목에서 정의하여 파드에 HostAliases를 추가하면 가능하다.
-
 
 {{< codenew file="service/networking/hostaliases-pod.yaml" >}}
 
@@ -113,14 +112,12 @@ fe00::2	ip6-allrouters
 
 ## 왜 Kubelet이 호스트 파일을 관리하는가?
 
-컨테이너가 이미 시작되고 난 후 Docker가 파일을 [수정](https://github.com/moby/moby/issues/17190)
+컨테이너가 이미 시작되고 난 후 도커가 파일을
-하는 것을 방지하기 위해 Kubelet은 파드의 각 컨테이너의 `hosts` 파일을 
+[수정](https://github.com/moby/moby/issues/17190)하는 것을 방지하기 위해
-[관리](https://github.com/kubernetes/kubernetes/issues/14633)
+Kubelet은 파드의 각 컨테이너의 `hosts` 파일을
-한다.
+[관리](https://github.com/kubernetes/kubernetes/issues/14633)한다.
 
 호스트 파일이 관리된다는 특성으로 인해, 컨테이너 재시작이나 파드 리스케줄 이벤트로
 `hosts` 파일이 Kubelet에 의해 다시 마운트될 때마다 사용자가 작성한 모든 내용이
-덮어쓰여진다. 따라서, 호스트 파일의 내용을 
+덮어 쓰인다. 따라서, 호스트 파일의 내용을
 직접 바꾸는 것은 권장하지 않는다.
-
-

content/ko/docs/concepts/services-networking/connect-applications-service.md

@@ -391,7 +391,7 @@ kubectl get svc my-nginx
 ```
 ```
 NAME       TYPE           CLUSTER-IP     EXTERNAL-IP        PORT(S)               AGE
-my-nginx   ClusterIP   10.0.162.149   162.222.184.144    80/TCP,81/TCP,82/TCP  21s
+my-nginx   LoadBalancer   10.0.162.149   xx.xxx.xxx.xxx     8080:30163/TCP        21s
 ```
 ```
 curl https://<EXTERNAL-IP> -k

content/ko/docs/concepts/services-networking/dns-pod-service.md

@@ -3,9 +3,6 @@ title: 서비스 및 파드용 DNS
 content_type: concept
 weight: 20
 ---
-
-
-
 <!-- overview -->
 이 페이지는 쿠버네티스의 DNS 지원에 대한 개요를 설명한다.
 
@@ -31,9 +28,9 @@ DNS 서비스의 IP를 사용하도록 kubelets를 구성한다.
 `foo.bar`를 조회하는 DNS 쿼리를 통해서 이 서비스를 찾을 수 있다.
 
 다음 절에서는 쿠버네티스 DNS에서 지원하는 레코드 유형과 레이아웃을 자세히 설명한다.
-이 외에 동작하는 레이아웃, 네임 또는 쿼리는 구현 세부 정보로 간주하며 경고 없이 변경될 수 있다. 
+이 외에 동작하는 레이아웃, 네임 또는 쿼리는 구현 세부 정보로 간주하며
+경고 없이 변경될 수 있다.
 최신 업데이트에 대한 자세한 설명은 다음 링크를 통해 참조할 수 있다.
-
 [쿠버네티스 DNS 기반 서비스 디스커버리](https://github.com/kubernetes/dns/blob/master/docs/specification.md).
 
 ## 서비스
@@ -66,6 +63,13 @@ SRV 레코드는 노멀 서비스 또는
 
 ## 파드
 
+### A/AAAA 레코드
+
+디플로이먼트나 데몬셋으로 생성되는 파드는 다음과 같은
+DNS 주소를 갖게 된다.
+
+`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example.`
+
 ### 파드의 hostname 및 subdomain 필드
 
 파드가 생성되면 hostname은 해당 파드의 `metadata.name` 값이 된다.
@@ -139,40 +143,39 @@ spec:
 DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 또는 AAAA 레코드를 제공한다.
 "`busybox1`"와 "`busybox2`" 파드 모두 각 파드를 구분 가능한 A 또는 AAAA 레코드를 가지고 있다.
 
-엔드포인트 객체는 `hostname` 필드를 임의의 엔드포인트 IP 주소로 지정할 수 있다.
+엔드포인트 객체는 `hostname` 필드를
+임의의 엔드포인트 IP 주소로 지정할 수 있다.
 
 {{< note >}}
 A 또는 AAAA 레코드는 파드의 이름으로 생성되지 않기 때문에
 파드의 A 또는 AAAA 레코드를 생성하기 위해서는 `hostname` 필드를 작성해야 한다.
 `hostname` 필드는 없고 `subdomain` 필드만 있는 파드는 파드의 IP 주소를 가리키는 헤드리스 서비스의
-A 또는 AAAA 레코드만 생성할 수 있다. 
+A 또는 AAAA 레코드만 생성할 수 있다. (`default-subdomain.my-namespace.svc.cluster-domain.example`)
-(`default-subdomain.my-namespace.svc.cluster-domain.example`)
+또한 서비스에서 `publishNotReadyAddresses=True` 를 설정하지 않았다면, 파드가 준비 상태가 되어야 레코드를 가질 수 있다.
-또한 레코드를 가지기 위해서는 파드가 준비되어야 한다. 
-그렇지 않은 경우, 서비스에서 `publishNotReadyAddresses=True`가 활성화된다.
 {{< /note >}}
 
 ### 파드의 DNS 정책
 
-DNS 정책은 파드별로 설정할 수 있다. 현재 쿠버네티스는 다음과 같은 파드별 DNS 정책을 지원한다. 
+DNS 정책은 파드별로 설정할 수 있다.
+현재 쿠버네티스는 다음과 같은 파드별 DNS 정책을 지원한다.
 이 정책들은 파드 스펙의 `dnsPolicy` 필드에서 지정할 수 있다.
 
 - "`Default`": 파드는 파드가 실행되고 있는 노드로부터 네임 해석 설정(the name resolution configuration)을 상속받는다.
   자세한 내용은
-  [관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node)
+  [관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node)에서
-  에서 확인할 수 있다.
+  확인할 수 있다.
 - "`ClusterFirst`": "`www.kubernetes.io`"와 같이 클러스터 도메인 suffix 구성과
   일치하지 않는 DNS 쿼리는 노드에서 상속된 업스트림 네임서버로 전달된다.
   클러스터 관리자는 추가 스텁-도메인(stub-domain)과 업스트림 DNS 서버를 구축할 수 있다.
   그러한 경우 DNS 쿼리를 어떻게 처리하는지에 대한 자세한 내용은
-  [관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#effects-on-pods)
+  [관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#effects-on-pods)에서
-  에서 확인할 수 있다.
+  확인할 수 있다.
 - "`ClusterFirstWithHostNet`": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인
   "`ClusterFirstWithHostNet`"을 명시적으로 설정해야 한다.
 - "`None`": 이 정책은 파드가 쿠버네티스 환경의 DNS 설정을 무시하도록 한다.
   모든 DNS 설정은 파드 스펙 내에 `dnsConfig`필드를 사용하여 제공해야 한다.
-  아래 절인 
+  아래 절인 [파드의 DNS 설정](#pod-dns-config)에서
-  [파드의 DNS 설정](#pod-dns-config)
+  자세한 내용을 확인할 수 있다.
-  에서 자세한 내용을 확인할 수 있다.
 
 {{< note >}}
 "Default"는 기본 DNS 정책이 아니다. `dnsPolicy`가 명시적으로 지정되어있지 않다면
@@ -207,7 +210,8 @@ spec:
 사용자들은 파드의 DNS 설정을 통해서 직접 파드의 DNS를 세팅할 수 있다.
 
 `dnsConfig` 필드는 선택적이고, `dnsPolicy` 세팅과 함께 동작한다.
-이때, 파드의 `dnsPolicy`의 값이 "`None`"으로 설정되어 있어야 `dnsConfig` 필드를 지정할 수 있다.
+이때, 파드의 `dnsPolicy`의 값이 "`None`"으로 설정되어 있어야
+`dnsConfig` 필드를 지정할 수 있다.
 
 사용자는 `dnsConfig` 필드에서 다음과 같은 속성들을 지정할 수 있다.
 
@@ -215,11 +219,13 @@ spec:
    파드의 `dnsPolicy`가 "`None`" 으로 설정된 경우에는
    적어도 하나의 IP 주소가 포함되어야 하며,
    그렇지 않으면 이 속성은 생략할 수 있다.
-   `nameservers`에 나열된 서버는 지정된 DNS 정책을 통해 생성된 기본 네임 서버와 합쳐지며 중복되는 주소는 제거된다.
+   `nameservers`에 나열된 서버는 지정된 DNS 정책을 통해 생성된 기본 네임 서버와 합쳐지며
+   중복되는 주소는 제거된다.
 - `searches`: 파드의 호스트네임을 찾기 위한 DNS 검색 도메인의 목록이다.
    이 속성은 생략이 가능하며,
    값을 지정한 경우 나열된 검색 도메인은 지정된 DNS 정책을 통해 생성된 기본 검색 도메인에 합쳐진다.
-   병합 시 중복되는 도메인은 제거되며, 쿠버네티스는 최대 6개의 검색 도메인을 허용하고 있다.
+   병합 시 중복되는 도메인은 제거되며,
+   쿠버네티스는 최대 6개의 검색 도메인을 허용하고 있다.
 - `options`: `name` 속성(필수)과 `value` 속성(선택)을 가질 수 있는 객체들의 선택적 목록이다.
    이 속성의 내용은 지정된 DNS 정책에서 생성된 옵션으로 병합된다.
    이 속성의 내용은 지정된 DNS 정책을 통해 생성된 옵션으로 합쳐지며,
@@ -243,9 +249,7 @@ IPv6 셋업을 위해서 검색 경로와 네임 서버 셋업은 다음과 같
 ```shell
 kubectl exec -it dns-example -- cat /etc/resolv.conf
 ```
-
 출력은 다음과 같은 형식일 것이다.
-
 ```shell
 nameserver fd00:79:30::a
 search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example
@@ -268,8 +272,4 @@ options ndots:5
 
 
 DNS 구성 관리에 대한 지침은
-[DNS 서비스 구성](/docs/tasks/administer-cluster/dns-custom-nameservers/)
+[DNS 서비스 구성](/docs/tasks/administer-cluster/dns-custom-nameservers/)에서 확인할 수 있다.
-에서 확인 할 수 있다.
-
-
-

content/ko/docs/concepts/services-networking/endpoint-slices.md

@@ -179,6 +179,5 @@ text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그
 
 
 * [엔드포인트슬라이스 활성화하기](/docs/tasks/administer-cluster/enabling-endpointslices)
-* [애플리케이션을 서비스와 함께 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 를 읽는다.
+* [애플리케이션을 서비스와 함께 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기
-
 

content/ko/docs/concepts/services-networking/ingress-controllers.md

@@ -9,7 +9,8 @@ weight: 40
 
 인그레스 리소스가 작동하려면, 클러스터는 실행 중인 인그레스 컨트롤러가 반드시 필요하다.
 
-kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 다른 타입과 달리 인그레스 컨트롤러는 클러스터와 함께 자동으로 실행되지 않는다. 
+kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 다른 타입과 달리 인그레스 컨트롤러는
+클러스터와 함께 자동으로 실행되지 않는다.
 클러스터에 가장 적합한 인그레스 컨트롤러 구현을 선택하는데 이 페이지를 사용한다.
 
 프로젝트로써 쿠버네티스는 현재 [GCE](https://git.k8s.io/ingress-gce/README.md) 와
@@ -27,26 +28,37 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의
   [Envoy](https://www.envoyproxy.io) 기반 인그레스 컨트롤러다.
 * [AppsCode Inc.](https://appscode.com) 는 가장 널리 사용되는 [HAProxy](http://www.haproxy.org/) 기반 인그레스 컨트롤러인 [Voyager](https://appscode.com/products/voyager)에 대한 지원 및 유지 보수를 제공한다.
 * [AWS ALB 인그레스 컨트롤러](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)는 [AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/)를 사용하여 인그레스를 활성화한다.
-* [Contour](https://projectcontour.io/)는 VMware에서 제공하고 지원하는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다.
+* [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러로
+  VMware에서 제공하고 지원한다.
 * Citrix는 [베어메탈](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)과 [클라우드](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) 배포를 위해 하드웨어 (MPX), 가상화 (VPX) 및 [무료 컨테이너화 (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html)를 위한 [인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller)를 제공한다.
-* F5 Networks는 [쿠버네티스를 위한 F5 BIG-IP 컨트롤러](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)에 대한 [지원과 유지 보수](https://support.f5.com/csp/article/K86859508)를 제공한다.
+* F5 Networks는 [쿠버네티스를 위한 F5 BIG-IP 컨트롤러](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)에 대한
+  [지원과 유지 보수](https://support.f5.com/csp/article/K86859508)를 제공한다.
 * [Gloo](https://gloo.solo.io)는 [solo.io](https://www.solo.io)의 엔터프라이즈 지원과 함께 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의 오픈 소스 인그레스 컨트롤러다.
 * [HAProxy 인그레스](https://haproxy-ingress.github.io)는 HAProxy를 위한 고도로 커스터마이징 가능한 커뮤니티 주도형 인그레스 컨트롤러다.
 * [HAProxy Technologies](https://www.haproxy.com/)는 [쿠버네티스를 위한 HAProxy 인그레스 컨트롤러](https://github.com/haproxytech/kubernetes-ingress)를 지원하고 유지 보수한다. [공식 문서](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/)를 통해 확인할 수 있다.
 * [Istio](https://istio.io/)는 인그레스 컨트롤러 기반으로
   [인그레스 트래픽을 제어](https://istio.io/docs/tasks/traffic-management/ingress/).
-* [Kong](https://konghq.com/)은 [쿠버네티스를 위한 Kong 인그레스 컨트롤러](https://github.com/Kong/kubernetes-ingress-controller)에 대한 [커뮤니티](https://discuss.konghq.com/c/kubernetes) 또는 [상업적](https://konghq.com/kong-enterprise/) 지원과 유지 보수를 제공한다.
+* [Kong](https://konghq.com/)은 [쿠버네티스를 위한 Kong 인그레스 컨트롤러](https://github.com/Kong/kubernetes-ingress-controller)에 대한
-* [NGINX, Inc.](https://www.nginx.com/) 는 [쿠버네티스를 위한 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)에 대한 지원과 유지 보수를 제공한다.
+  [커뮤니티](https://discuss.konghq.com/c/kubernetes) 또는
-* 쿠버네티스 인그레스와 같이 사용 사례를 포함하는 서비스 구성을 위한 [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP 라우터와 리버스 프록시는 사용자 정의 프록시를 빌드하기 위한 라이브러리로 설계되었다.
+  [상업적](https://konghq.com/kong-enterprise/) 지원과 유지 보수를 제공한다.
-* [Traefik](https://github.com/containous/traefik)은 완벽한 기능([암호화](https://letsencrypt.org), secrets, http2, 웹 소켓)을 갖춘 인그레스 컨트롤러로, [Containous](https://containo.us/services)에서 상업적인 지원을 제공한다.
+* [NGINX, Inc.](https://www.nginx.com/)는
+  [쿠버네티스를 위한 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)에 대한 지원과 유지 보수를 제공한다.
+* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 쿠버네티스 인그레스와 같은 유스케이스를 포함하는 서비스 구성을 위한 HTTP 라우터와 리버스 프록시는 사용자 정의 프록시를 빌드하기 위한 라이브러리로 설계되었다.
+* [Traefik](https://github.com/containous/traefik)은
+  모든 기능([Let's Encrypt](https://letsencrypt.org), secrets, http2, 웹 소켓)을 갖춘 인그레스 컨트롤러로,
+  [Containous](https://containo.us/services)에서 상업적인 지원을 제공한다.
 
 ## 여러 인그레스 컨트롤러 사용
 
-하나의 클러스터 내에 [여러 개의 인그레스 컨트롤러](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)를 배포할 수 있다. 인그레스를 생성할 때,  클러스터 내에 둘 이상의 인그레스 컨트롤러가 존재하는 경우 어떤 인그레스 컨트롤러를 사용해야하는지 표시해주는 적절한 [`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) 어노테이션을 각각의 인그레스에 달아야 한다. 
+하나의 클러스터 내에 [여러 개의 인그레스 컨트롤러](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)를 배포할 수 있다.
+인그레스를 생성할 때,  클러스터 내에 둘 이상의 인그레스 컨트롤러가 존재하는 경우
+어떤 인그레스 컨트롤러를 사용해야 하는지 표시해주는 적절한 [`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)
+어노테이션을 각각의 인그레스에 달아야 한다.
 
 만약 클래스를 정의하지 않으면, 클라우드 제공자는 기본 인그레스 컨트롤러를 사용할 수 있다.
 
-이상적으로는 모든 인그레스 컨트롤러가 이 사양을 충족해야하지만, 다양한 인그레스 컨트롤러는 약간 다르게 작동한다.
+이상적으로는 모든 인그레스 컨트롤러가 이 사양을 충족해야 하지만,
+다양한 인그레스 컨트롤러는 약간 다르게 작동한다.
 
 {{< note >}}
 인그레스 컨트롤러의 설명서를 검토하여 선택 시 주의 사항을 이해해야한다.
@@ -58,6 +70,4 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의
 
 
 * [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 자세히 알아보기.
-* [NGINX 컨트롤러로 Minikube에서 Ingress를 설정하기](/docs/tasks/access-application-cluster/ingress-minikube).
+* [NGINX 컨트롤러로 Minikube에서 인그레스를 설정하기](/docs/tasks/access-application-cluster/ingress-minikube).
-
-

content/ko/docs/concepts/services-networking/ingress.md

@@ -1,5 +1,5 @@
 ---
-title: 인그레스
+title: 인그레스(Ingress)
 content_type: concept
 weight: 40
 ---
@@ -15,11 +15,11 @@ weight: 40
 
 이 가이드는 용어의 명확성을 위해 다음과 같이 정의한다.
 
-노드(Node): 클러스터의 일부이며, 쿠버네티스에 속한 워커 머신.
+* 노드(Node): 클러스터의 일부이며, 쿠버네티스에 속한 워커 머신.
-클러스터(Cluster): 쿠버네티스에서 관리되는 컨테이너화 된 애플리케이션을 실행하는 노드 집합. 이 예시와 대부분의 일반적인 쿠버네티스 배포에서 클러스터에 속한 노드는 퍼블릭 인터넷의 일부가 아니다.
+* 클러스터(Cluster): 쿠버네티스에서 관리되는 컨테이너화 된 애플리케이션을 실행하는 노드 집합. 이 예시와 대부분의 일반적인 쿠버네티스 배포에서 클러스터에 속한 노드는 퍼블릭 인터넷의 일부가 아니다.
-에지 라우터(Edge router): 클러스터에 방화벽 정책을 적용하는 라우터. 이것은 클라우드 공급자 또는 물리적 하드웨어의 일부에서 관리하는 게이트웨이일 수 있다.
+* 에지 라우터(Edge router): 클러스터에 방화벽 정책을 적용하는 라우터. 이것은 클라우드 공급자 또는 물리적 하드웨어의 일부에서 관리하는 게이트웨이일 수 있다.
-클러스터 네트워크(Cluster network): 쿠버네티스 [네트워킹 모델](/docs/concepts/cluster-administration/networking/)에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합.
+* 클러스터 네트워크(Cluster network): 쿠버네티스 [네트워킹 모델](/docs/concepts/cluster-administration/networking/)에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합.
-서비스(Service): {{< glossary_tooltip text="레이블" term_id="label" >}} 셀렉터를 사용해서 파드 집합을 식별하는 쿠버네티스 {{< glossary_tooltip term_id="service" >}}. 달리 언급하지 않으면 서비스는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가지고 있다고 가정한다.
+* 서비스: {{< glossary_tooltip text="레이블" term_id="label" >}} 셀렉터를 사용해서 파드 집합을 식별하는 쿠버네티스 {{< glossary_tooltip text="서비스" term_id="service" >}}. 달리 언급하지 않으면 서비스는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가지고 있다고 가정한다.
 
 ## 인그레스란?
 
@@ -134,8 +134,7 @@ spec:
   요청은 _p_ 경로에 일치한다.
 
   {{< note >}}
-  경로의 마지막 요소가 요청 경로에 있는 마지막 요소의 하위 문자열인 경우에는 일치하지 않는다(예시: 
+  경로의 마지막 요소가 요청 경로에 있는 마지막 요소의 하위 문자열인 경우에는 일치하지 않는다(예시: `/foo/bar` 와 `/foo/bar/baz` 와 일치하지만, `/foo/barbaz` 는 일치하지 않는다).
-  `/foo/bar` 와 `/foo/bar/baz` 와 일치하지만, `/foo/barbaz` 는 일치하지 않는다).
   {{< /note >}}
 
 #### 다중 일치

content/ko/docs/concepts/services-networking/network-policies.md

@@ -9,28 +9,28 @@ weight: 50
 <!-- overview -->
 네트워크 정책은 {{< glossary_tooltip text="파드" term_id="pod">}} 그룹이 서로 간에 또는 다른 네트워크 엔드포인트와 통신할 수 있도록 허용하는 방법에 대한 명세이다.
 
-`NetworkPolicy` 리소스는 {{< glossary_tooltip text="레이블" term_id="label">}}을 사용해서 파드를 선택하고 선택한 파드에 허용되는 트래픽을 지정하는 규칙을 정의한다.
+`네트워크폴리시(NetworkPolicy)` 리소스는 {{< glossary_tooltip text="레이블" term_id="label">}}을 사용해서 파드를 선택하고 선택한 파드에 허용되는 트래픽을 지정하는 규칙을 정의한다.
 
 
 
 <!-- body -->
 ## 전제 조건
 
-네트워크 정책은 [네트워크 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)으로 구현된다. 네트워크 정책을 사용하려면 NetworkPolicy를 지원하는 네트워킹 솔루션을 사용해야만 한다. 이를 구현하는 컨트롤러 없이 NetworkPolicy 리소스를 생성해도 아무런 효과가 없기 때문이다.
+네트워크 정책은 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)으로 구현된다. 네트워크 정책을 사용하려면 네트워크폴리시를 지원하는 네트워킹 솔루션을 사용해야만 한다. 이를 구현하는 컨트롤러 없이 네트워크폴리시 리소스를 생성해도 아무런 효과가 없기 때문이다.
 
 ## 격리 및 격리되지 않은 파드
 
 기본적으로, 파드는 격리되지 않는다. 이들은 모든 소스에서 오는 트래픽을 받아들인다.
 
-파드는 파드를 선택한 NetworkPolicy에 의해서 격리된다. 네임스페이스에 특정 파드를 선택하는 NetworkPolicy가 있으면 해당 파드는 NetworkPolicy에서 허용하지 않는 모든 연결을 거부한다. (네임스페이스 내에서 어떠한 NetworkPolicy에도 선택 받지 않은 다른 파드들은 계속해서 모든 트래픽을 받아들인다.)
+파드는 파드를 선택한 네트워크폴리시에 의해서 격리된다. 네임스페이스에 특정 파드를 선택하는 네트워크폴리시가 있으면 해당 파드는 네트워크폴리시에서 허용하지 않는 모든 연결을 거부한다. (네임스페이스 내에서 어떠한 네트워크폴리시에도 선택 받지 않은 다른 파드들은 계속해서 모든 트래픽을 받아들인다.)
 
 네트워크 정책은 충돌하지 않으며, 추가된다. 만약 어떤 정책 또는 정책들이 파드를 선택하면, 해당 정책의 인그레스(수신)/이그레스(송신) 규칙을 통합하여 허용되는 범위로 파드가 제한된다. 따라서 평가 순서는 정책 결과에 영향을 미치지 않는다.
 
-## NetworkPolicy 리소스 {#networkpolicy-resource}
+## 네트워크폴리시 리소스 {#networkpolicy-resource}
 
-리소스에 대한 전체 정의에 대한 참조는 [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 를 본다.
+리소스에 대한 전체 정의에 대한 참조는 [네트워크폴리시](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 를 본다.
 
-NetworkPolicy 의 예시는 다음과 같다.
+네트워크폴리시 의 예시는 다음과 같다.
 
 ```yaml
 apiVersion: networking.k8s.io/v1
@@ -73,23 +73,23 @@ spec:
 선택한 네트워킹 솔루션이 네트워킹 정책을 지원하지 않으면 클러스터의 API 서버에 이를 POST 하더라도 효과가 없다.
 {{< /note >}}
 
-__필수 필드들__: 다른 모든 쿠버네티스 설정과 마찬가지로 NetworkPolicy 에는
+__필수 필드들__: 다른 모든 쿠버네티스 설정과 마찬가지로 네트워크폴리시 에는
 `apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다. 구성 파일
 작업에 대한 일반적인 정보는
 [컨피그 맵을 사용해서 컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/),
 그리고 [오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management) 를 본다.
 
-__spec__: NetworkPolicy [사양](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)에는 지정된 네임스페이스에서 특정 네트워크 정책을 정의하는데 필요한 모든 정보가 있다.
+__spec__: 네트워크폴리시 [사양](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)에는 지정된 네임스페이스에서 특정 네트워크 정책을 정의하는데 필요한 모든 정보가 있다.
 
-__podSelector__: 각 NetworkPolicy 에는 정책이 적용되는 파드 그룹을 선택하는 `podSelector` 가 포함된다. 예시 정책은 "role=db" 레이블이 있는 파드를 선택한다. 비어있는 `podSelector` 는 네임스페이스의 모든 파드를 선택한다.
+__podSelector__: 각 네트워크폴리시에는 정책이 적용되는 파드 그룹을 선택하는 `podSelector` 가 포함된다. 예시 정책은 "role=db" 레이블이 있는 파드를 선택한다. 비어있는 `podSelector` 는 네임스페이스의 모든 파드를 선택한다.
 
-__policyTypes__: 각 NetworkPolicy 에는 `Ingress`, `Egress` 또는 두 가지 모두를 포함할 수 있는 `policyTypes` 목록이 포함된다. `policyTypes` 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 NetworkPolicy에 `policyTypes` 가 지정되어 있지 않으면 기본적으로 `Ingress` 가 항상 설정되고, NetworkPolicy에 `Egress` 가 있으면 이그레스 규칙이 설정된다.
+__policyTypes__: 각 네트워크폴리시에는 `Ingress`, `Egress` 또는 두 가지 모두를 포함할 수 있는 `policyTypes` 목록이 포함된다. `policyTypes` 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 네트워크폴리시에 `policyTypes` 가 지정되어 있지 않으면 기본적으로 `Ingress` 가 항상 설정되고, 네트워크폴리시에 `Egress` 가 있으면 이그레스 규칙이 설정된다.
 
-__ingress__: 각 NetworkPolicy 에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다.
+__ingress__: 각 네트워크폴리시에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다.
 
-__egress__: 각 NetworkPolicy 에는 화이트리스트 `egress` 규칙이 포함될 수 있다. 각 규칙은 `to` 와 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 `10.0.0.0/24` 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다.
+__egress__: 각 네트워크폴리시에는 화이트리스트 `egress` 규칙이 포함될 수 있다. 각 규칙은 `to` 와 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 `10.0.0.0/24` 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다.
 
-따라서 예시의 NetworkPolicy는 다음과 같이 동작한다.
+따라서 예시의 네트워크폴리시는 다음과 같이 동작한다.
 
 1. 인그레스 및 이그레스 트래픽에 대해 "default" 네임스페이스에서 "role=db"인 파드를 격리한다(아직 격리되지 않은 경우).
 2. (인그레스 규칙)은 "role=db" 레이블을 사용하는 "default" 네임스페이스의 모든 파드에 대해서 TCP 포트 6397로의 연결을 허용한다. 인그레스을 허용 할 대상은 다음과 같다.
@@ -105,7 +105,7 @@ __egress__: 각 NetworkPolicy 에는 화이트리스트 `egress` 규칙이 포
 
 `ingress` `from` 부분 또는 `egress` `to` 부분에 지정할 수 있는 네 종류의 셀렉터가 있다.
 
-__podSelector__: NetworkPolicy 을 통해서, 인그레스 소스 또는 이그레스 목적지로 허용되야 하는 동일한 네임스페이스에 있는 특정 파드들을 선택한다.
+__podSelector__: 네트워크폴리시를 통해서, 인그레스 소스 또는 이그레스 목적지로 허용되야 하는 동일한 네임스페이스에 있는 특정 파드들을 선택한다.
 
 __namespaceSelector__: 모든 파드가 인그레스 소스 또는 이그레스를 대상으로 허용되어야 하는 특정 네임스페이스를 선택한다.
 
@@ -146,12 +146,12 @@ __namespaceSelector__ *와* __podSelector__: `namespaceSelector` 와 `podSelecto
 __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP CIDR 범위를 선택한다. 파드 IP는 임시적이고 예측할 수 없기에 클러스터 외부 IP이어야 한다.
 
 클러스터 인그레스 및 이그레스 매커니즘은 종종 패킷의 소스 또는 대상 IP의 재작성을
-필요로 한다. 이러한 상황이 발생하는 경우, NetworkPolicy의 처리 전 또는 후에
+필요로 한다. 이러한 상황이 발생하는 경우, 네트워크폴리시의 처리 전 또는 후에
 발생한 것인지 정의되지 않으며, 네트워크 플러그인, 클라우드 공급자,
 `서비스` 구현 등의 조합에 따라 동작이 다를 수 있다.
 
 인그레스 사례에서의 의미는 실제 원본 소스 IP를 기준으로 들어오는 패킷을
-필터링할 수 있는 반면에 다른 경우에는 NetworkPolicy가 작동하는 
+필터링할 수 있는 반면에 다른 경우에는 네트워크폴리시가 작동하는
 "소스 IP"는 `LoadBalancer` 또는 파드가 속한 노드 등의 IP일 수 있다.
 
 이그레스의 경우 파드에서 클러스터 외부 IP로 다시 작성된 `서비스` IP로의 연결은
@@ -164,11 +164,11 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C
 
 ### 기본적으로 모든 인그레스 트래픽 거부
 
-모든 파드를 선택하지만 해당 파드에 대한 인그레스 트래픽은 허용하지 않는 NetworkPolicy를 생성해서 네임스페이스에 대한 "기본" 격리 정책을 생성할 수 있다.
+모든 파드를 선택하지만 해당 파드에 대한 인그레스 트래픽은 허용하지 않는 네트워크폴리시를 생성해서 네임스페이스에 대한 "기본" 격리 정책을 생성할 수 있다.
 
 {{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}}
 
-이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드도 여전히 격리된다. 이 정책은 기본 이그레스 격리 동작을 변경하지 않는다.
+이렇게 하면 다른 네트워크폴리시에서 선택하지 않은 파드도 여전히 격리된다. 이 정책은 기본 이그레스 격리 동작을 변경하지 않는다.
 
 ### 기본적으로 모든 인그레스 트래픽 허용
 
@@ -178,11 +178,11 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C
 
 ### 기본적으로 모든 이그레스 트래픽 거부
 
-모든 파드를 선택하지만, 해당 파드의 이그레스 트래픽을 허용하지 않는 NetworkPolicy를 생성해서 네임스페이스에 대한 "기본" 이그레스 격리 정책을 생성할 수 있다.
+모든 파드를 선택하지만, 해당 파드의 이그레스 트래픽을 허용하지 않는 네트워크폴리시를 생성해서 네임스페이스에 대한 "기본" 이그레스 격리 정책을 생성할 수 있다.
 
 {{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}}
 
-이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드조차도 이그레스 트래픽을 허용하지 않는다. 이 정책은 
+이렇게 하면 다른 네트워크폴리시에서 선택하지 않은 파드조차도 이그레스 트래픽을 허용하지 않는다. 이 정책은
 기본 인그레스 격리 정책을 변경하지 않는다.
 
 ### 기본적으로 모든 이그레스 트래픽 허용
@@ -193,21 +193,21 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C
 
 ### 기본적으로 모든 인그레스와 모든 이그레스 트래픽 거부
 
-해당 네임스페이스에 아래의 NetworkPolicy를 만들어 모든 인그레스와 이그레스 트래픽을 방지하는 네임스페이스에 대한 "기본" 정책을 만들 수 있다.
+해당 네임스페이스에 아래의 네트워크폴리시를 만들어 모든 인그레스와 이그레스 트래픽을 방지하는 네임스페이스에 대한 "기본" 정책을 만들 수 있다.
 
 {{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}}
 
-이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드도 인그레스 또는 이그레스 트래픽을 허용하지 않는다.
+이렇게 하면 다른 네트워크폴리시에서 선택하지 않은 파드도 인그레스 또는 이그레스 트래픽을 허용하지 않는다.
 
 ## SCTP 지원
 
 {{< feature-state for_k8s_version="v1.12" state="alpha" >}}
 
 이 기능을 사용하려면 사용자(또는 클러스터 관리자가) API 서버에 `--feature-gates=SCTPSupport=true,…` 를 사용해서 `SCTPSupport` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다.
-기능 게이트가 활셩화 되면, NetworkPolicy의 `protocol` 필드를 `SCTP` 로 설정할 수 있다.
+기능 게이트가 활셩화 되면, 네트워크폴리시의 `protocol` 필드를 `SCTP` 로 설정할 수 있다.
 
 {{< note >}}
-SCTP 프로토콜 NetworkPolicy을 지원하는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용하고 있어야 한다.
+SCTP 프로토콜 네트워크폴리시를 지원하는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용하고 있어야 한다.
 {{< /note >}}
 
 
@@ -218,6 +218,4 @@ SCTP 프로토콜 NetworkPolicy을 지원하는 {{< glossary_tooltip text="CNI"
 
 - 자세한 설명과 추가 예시는
   [네트워크 정책 선언](/docs/tasks/administer-cluster/declare-network-policy/)을 본다.
-- NetworkPolicy 리소스에서 사용되는 일반적인 시나리오는 [레시피](https://github.com/ahmetb/kubernetes-network-policy-recipes)를 본다.
+- 네트워크폴리시 리소스에서 사용되는 일반적인 시나리오는 [레시피](https://github.com/ahmetb/kubernetes-network-policy-recipes)를 본다.
-
-

content/ko/docs/concepts/services-networking/service-topology.md

@@ -194,7 +194,7 @@ spec:
 ## {{% heading "whatsnext" %}}
 
 
-* [서비스 토폴로지 활성화하기](/docs/tasks/administer-cluster/enabling-service-topology)를 읽는다.
+* [서비스 토폴로지 활성화하기](/docs/tasks/administer-cluster/enabling-service-topology)를 읽어보기.
-* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽는다.
+* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기.
 
 

content/ko/docs/concepts/services-networking/service.md

@@ -10,8 +10,6 @@ weight: 10
 ---
 
 
-
-
 <!-- overview -->
 
 {{< glossary_definition term_id="service" length="short" >}}
@@ -242,7 +240,8 @@ DNS 레코드를 구성하고, 라운드-로빈 이름 확인 방식을
 추가와 제거를 감시한다. 각 서비스는 로컬 노드에서
 포트(임의로 선택됨)를 연다. 이 "프록시 포트"에 대한 모든
 연결은 (엔드포인트를 통해 보고된대로) 서비스의 백엔드 파드 중 하나로
-프록시된다. kube-proxy는 사용할 백엔드 파드를 결정할 때 서비스의
+프록시된다.
+kube-proxy는 사용할 백엔드 파드를 결정할 때 서비스의
 `SessionAffinity` 설정을 고려한다.
 
 마지막으로, 유저-스페이스 프록시는 서비스의
@@ -497,15 +496,15 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
      서비스를 외부에 노출시킨다. 외부 로드 밸런서가 라우팅되는
      `NodePort`와 `ClusterIP` 서비스가 자동으로 생성된다.
    * [`ExternalName`](#externalname): 값과 함께 CNAME 레코드를 리턴하여, 서비스를
-     `externalName` 필드의 컨텐츠 (예:`foo.bar.example.com`)에
+     `externalName` 필드의 콘텐츠 (예:`foo.bar.example.com`)에
-     맵핑한다. 어떤 종류의 프록시도 설정되어 있지 않다.
+     매핑한다.
+     어떤 종류의 프록시도 설정되어 있지 않다.
      {{< note >}}
      `ExternalName` 유형을 사용하려면 kube-dns 버전 1.7 또는 CoreDNS 버전 1.7 이상이 필요하다.
      {{< /note >}}
 
 [인그레스](/ko/docs/concepts/services-networking/ingress/)를 사용하여 서비스를 노출시킬 수도 있다. 인그레스는 서비스 유형이 아니지만, 클러스터의 진입점 역할을 한다. 동일한 IP 주소로 여러 서비스를 노출시킬 수 있기 때문에 라우팅 규칙을 단일 리소스로 통합할 수 있다.
 
-
 ### NodePort 유형 {#nodeport}
 
 `type` 필드를 `NodePort`로 설정하면, 쿠버네티스 컨트롤 플레인은
@@ -1234,5 +1233,3 @@ kube-proxy는 유저스페이스 모드에 있을 때 SCTP 연결 관리를 지
 * [서비스와 애플리케이션 연결](/ko/docs/concepts/services-networking/connect-applications-service/) 알아보기
 * [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 알아보기
 * [엔드포인트슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)에 대해 알아보기
-
-

content/ko/docs/concepts/storage/dynamic-provisioning.md

@@ -33,15 +33,15 @@ API 오브젝트를 기반으로 한다. 클러스터 관리자는 볼륨을 프
 여전히 여러 스토리지 옵션들을 선택할 수 있다.
 
 스토리지 클래스에 대한 자세한 정보는
-[여기](/docs/concepts/storage/storage-classes/)에서 찾을 수 있다.
+[여기](/ko/docs/concepts/storage/storage-classes/)에서 찾을 수 있다.
 
 ## 동적 프로비저닝 활성화하기
 
-동적 프로비저닝을 활성화하려면 클러스터 관리자가 사용자를 위해 하나 이상의 StorageClass
+동적 프로비저닝을 활성화하려면 클러스터 관리자가 사용자를 위해 하나 이상의 스토리지클래스(StorageClass)
 오브젝트를 사전 생성해야 한다.
-StorageClass 오브젝트는 동적 프로비저닝이 호출될 때 사용할 프로비저너와
+스토리지클래스 오브젝트는 동적 프로비저닝이 호출될 때 사용할 프로비저너와
 해당 프로비저너에게 전달할 파라미터를 정의한다.
-StorageClass 오브젝트의 이름은 유효한
+스토리지클래스 오브젝트의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
 
 다음 매니페스트는 표준 디스크와 같은 퍼시스턴트 디스크를 프로비전하는
@@ -125,7 +125,6 @@ spec:
 
 [다중 영역](/ko/docs/setup/best-practices/multiple-zones/) 클러스터에서 파드는 한 지역 내
 여러 영역에 걸쳐 분산될 수 있다. 파드가 예약된 영역에서 단일 영역 스토리지 백엔드를
-프로비전 해야 한다. [볼륨 바인딩 모드](/docs/concepts/storage/storage-classes/#volume-binding-mode)를
+프로비전해야 한다. [볼륨 바인딩 모드](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드)를
 설정해서 수행할 수 있다.
 
-

content/ko/docs/concepts/storage/persistent-volumes.md

@@ -22,7 +22,7 @@ weight: 20
 
 스토리지 관리는 컴퓨트 인스턴스 관리와는 별개의 문제다. 퍼시스턴트볼륨 서브시스템은 사용자 및 관리자에게 스토리지 사용 방법에서부터 스토리지가 제공되는 방법에 대한 세부 사항을 추상화하는 API를 제공한다. 이를 위해 퍼시스턴트볼륨 및 퍼시스턴트볼륨클레임이라는 두 가지 새로운 API 리소스를 소개한다.
 
-_퍼시스턴트볼륨_ (PV)은 관리자가 프로비저닝하거나 [스토리지 클래스](/docs/concepts/storage/storage-classes/)를 사용하여 동적으로 프로비저닝한 클러스터의 스토리지이다. 노드가 클러스터 리소스인 것처럼 PV는 클러스터 리소스이다. PV는 Volumes와 같은 볼륨 플러그인이지만, PV를 사용하는 개별 파드와는 별개의 라이프사이클을 가진다. 이 API 오브젝트는 NFS, iSCSI 또는 클라우드 공급자별 스토리지 시스템 등 스토리지 구현에 대한 세부 정보를 담아낸다.
+_퍼시스턴트볼륨_ (PV)은 관리자가 프로비저닝하거나 [스토리지 클래스](/ko/docs/concepts/storage/storage-classes/)를 사용하여 동적으로 프로비저닝한 클러스터의 스토리지이다. 노드가 클러스터 리소스인 것처럼 PV는 클러스터 리소스이다. PV는 Volumes와 같은 볼륨 플러그인이지만, PV를 사용하는 개별 파드와는 별개의 라이프사이클을 가진다. 이 API 오브젝트는 NFS, iSCSI 또는 클라우드 공급자별 스토리지 시스템 등 스토리지 구현에 대한 세부 정보를 담아낸다.
 
 _퍼시스턴트볼륨클레임_ (PVC)은 사용자의 스토리지에 대한 요청이다. 파드와 비슷하다. 파드는 노드 리소스를 사용하고 PVC는 PV 리소스를 사용한다. 파드는 특정 수준의 리소스(CPU 및 메모리)를 요청할 수 있다. 클레임은 특정 크기 및 접근 모드를 요청할 수 있다(예: 한 번 읽기/쓰기 또는 여러 번 읽기 전용으로 마운트 할 수 있음).
 
@@ -47,7 +47,7 @@ PV를 프로비저닝 할 수 있는 두 가지 방법이 있다: 정적(static)
 관리자가 생성한 정적 PV가 사용자의 퍼시스턴트볼륨클레임과 일치하지 않으면
 클러스터는 PVC를 위해 특별히 볼륨을 동적으로 프로비저닝 하려고 시도할 수 있다.
 이 프로비저닝은 스토리지클래스를 기반으로 한다. PVC는
-[스토리지 클래스](/docs/concepts/storage/storage-classes/)를
+[스토리지 클래스](/ko/docs/concepts/storage/storage-classes/)를
 요청해야 하며 관리자는 동적 프로비저닝이 발생하도록 해당 클래스를 생성하고 구성해야 한다.
 `""` 클래스를 요청하는 클레임은 동적 프로비저닝을 효과적으로
 비활성화한다.
@@ -244,7 +244,7 @@ FlexVolume의 크기 조정은 기본 드라이버가 크기 조정을 지원하
 {{< /note >}}
 
 {{< note >}}
-EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마다 한 번의 수정을 할 수 있는 볼륨별 쿼터(quota)가 있다.
+EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마다 한 번의 수정을 할 수 있는 볼륨별 쿼터가 있다.
 {{< /note >}}
 
 
@@ -376,7 +376,7 @@ CLI에서 접근 모드는 다음과 같이 약어로 표시된다.
 ### 클래스
 
 PV는 `storageClassName` 속성을
-[스토리지클래스](/docs/concepts/storage/storage-classes/)의
+[스토리지클래스](/ko/docs/concepts/storage/storage-classes/)의
 이름으로 설정하여 지정하는 클래스를 가질 수 있다.
 특정 클래스의 PV는 해당 클래스를 요청하는 PVC에만 바인딩될 수 있다.
 `storageClassName`이 없는 PV에는 클래스가 없으며 특정 클래스를 요청하지 않는 PVC에만
@@ -449,8 +449,7 @@ CLI는 PV에 바인딩된 PVC의 이름을 표시한다.
 
 각 PVC에는 스펙과 상태(클레임의 명세와 상태)가 포함된다.
 퍼시스턴트볼륨클레임 오브젝트의 이름은 유효한
-[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야
+[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
-한다.
 
 ```yaml
 apiVersion: v1
@@ -496,7 +495,7 @@ spec:
 ### 클래스
 
 클레임은 `storageClassName` 속성을 사용하여
-[스토리지클래스](/docs/concepts/storage/storage-classes/)의 이름을 지정하여
+[스토리지클래스](/ko/docs/concepts/storage/storage-classes/)의 이름을 지정하여
 특정 클래스를 요청할 수 있다.
 요청된 클래스의 PV(PVC와 동일한 `storageClassName`을 갖는 PV)만 PVC에
 바인딩될 수 있다.
@@ -747,7 +746,7 @@ spec:
 
 * [퍼시스턴트볼륨 생성](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume)에 대해 자세히 알아보기
 * [퍼시스턴트볼륨클레임 생성](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim)에 대해 자세히 알아보기
-* [퍼시스턴트 스토리지 설계 문서](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md) 읽기
+* [퍼시스턴트 스토리지 설계 문서](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md) 읽어보기
 
 ### 참고
 
@@ -755,4 +754,3 @@ spec:
 * [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core)
 * [퍼시스턴트볼륨클레임](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
 * [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core)
-

content/ko/docs/concepts/storage/storage-classes.md

@@ -162,8 +162,8 @@ CSI | 1.14 (alpha), 1.16 (beta)
 클러스터 관리자는 `WaitForFirstConsumer` 모드를 지정해서 이 문제를 해결할 수 있는데
 이 모드는 퍼시스턴트볼륨클레임을 사용하는 파드가 생성될 때까지 퍼시스턴트볼륨의 바인딩과 프로비저닝을 지연시킨다.
 퍼시스턴트볼륨은 파드의 스케줄링 제약 조건에 의해 지정된 토폴로지에
-따라 선택되거나 프로비전된다. 여기에는 [리소스
+따라 선택되거나 프로비전된다. 여기에는
-요구 사항](/docs/concepts/configuration/manage-compute-resources-container/),
+[리소스 요구 사항](/ko/docs/concepts/configuration/manage-resources-containers/),
 [노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector),
 [파드 어피니티(affinity)와
 안티-어피니티(anti-affinity)](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)
@@ -816,4 +816,3 @@ volumeBindingMode: WaitForFirstConsumer
 적절한 퍼시스턴트볼륨을 선택할 때 파드의 모든 스케줄링
 제약 조건을 고려할 수 있다.
 
-

content/ko/docs/concepts/storage/volume-pvc-datasource.md

@@ -6,8 +6,7 @@ weight: 30
 
 <!-- overview -->
 
-이 문서에서는 쿠버네티스의 기존 CSI 볼륨 복제의 개념을 설명한다.  [볼륨]
+이 문서에서는 쿠버네티스의 기존 CSI 볼륨 복제의 개념을 설명한다. [볼륨](/ko/docs/concepts/storage/volumes)을 숙지하는 것을 추천한다.
-(/ko/docs/concepts/storage/volumes)을 숙지하는 것을 추천한다.
 
 
 

content/ko/docs/concepts/storage/volume-snapshot-classes.md

@@ -7,8 +7,8 @@ weight: 30
 <!-- overview -->
 
 이 문서는 쿠버네티스의 `VolumeSnapshotClass` 개요를 설명한다.
-[볼륨 스냅샷](/docs/concepts/storage/volume-snapshots/)과
+[볼륨 스냅샷](/ko/docs/concepts/storage/volume-snapshots/)과
-[스토리지 클래스](/docs/concepts/storage/storage-classes)의 숙지를 추천한다.
+[스토리지 클래스](/ko/docs/concepts/storage/storage-classes)의 숙지를 추천한다.
 
 
 
@@ -32,7 +32,7 @@ weight: 30
 처음 생성할 때 클래스의 이름과 기타 파라미터를 설정하고, 오브젝트가
 생성된 이후에는 업데이트할 수 없다.
 
-관리자는 특정 클래스의 바인딩을 요청하지 않는 VolumeSnapshots에만
+관리자는 특정 클래스의 바인딩을 요청하지 않는 볼륨스냅샷에만
 기본 `VolumeSnapshotClass` 를 지정할 수 있다.
 
 ```yaml
@@ -47,7 +47,7 @@ parameters:
 
 ### 드라이버
 
-볼륨 스냅샷 클래스에는 VolumeSnapshots의 프로비저닝에 사용되는 CSI 볼륨 플러그인을
+볼륨 스냅샷 클래스에는 볼륨스냅샷의 프로비저닝에 사용되는 CSI 볼륨 플러그인을
 결정하는 드라이버를 가지고 있다. 이 필드는 반드시 지정해야한다.
 
 ### 삭제정책(DeletionPolicy)
@@ -61,5 +61,3 @@ parameters:
 볼륨 스냅샷 클래스에는 볼륨 스냅샷 클래스에 속하는 볼륨 스냅샷을
 설명하는 파라미터를 가지고 있다. `driver` 에 따라 다른 파라미터를 사용할
 수 있다.
-
-

content/ko/docs/concepts/storage/volume-snapshots.md

@@ -41,8 +41,7 @@ API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가 사용자 및
 스냅샷을 프로비저닝할 수 있는 방법에는 사전 프로비저닝 혹은 동적 프로비저닝의 두 가지가 있다: .
 
 #### 사전 프로비전 {#static}
-클러스터 관리자는 많은 `VolumeSnapshotContents` 을 생성한다. 그들은 클러스터 사용자들이 사용 가능한 스토리지 시스템의 실제 볼륨 스냅샷 세부 정보를 제공한다.
+클러스터 관리자는 많은 `VolumeSnapshotContents` 을 생성한다. 그들은 클러스터 사용자들이 사용 가능한 스토리지 시스템의 실제 볼륨 스냅샷 세부 정보를 제공한다. 이것은 쿠버네티스 API에 있고 사용 가능하다.
-이것은 쿠버네티스 API에 있고 사용 가능하다.
 
 #### 동적
 사전 프로비저닝을 사용하는 대신 퍼시스턴트볼륨클레임에서 스냅샷을 동적으로 가져오도록 요청할 수 있다. [볼륨스냅샷클래스](/docs/concepts/storage/volume-snapshot-classes/)는 스냅샷 사용 시 스토리지 제공자의 특정 파라미터를 명세한다.

content/ko/docs/concepts/storage/volumes.md

@@ -451,15 +451,13 @@ spec:
 ```
 
 #### 지역(Regional) 퍼시스턴트 디스크
-{{< feature-state for_k8s_version="v1.10" state="beta" >}}
-
 [지역(Regional) 퍼시스턴트 디스크](https://cloud.google.com/compute/docs/disks/#repds) 기능을 사용하면 동일한 영역 내의 두 영역에서 사용할 수 있는 퍼시스턴트 디스크를 생성할 수 있다. 이 기능을 사용하려면 볼륨을 퍼시스턴트볼륨으로 프로비저닝 해야 한다. 파드에서 직접 볼륨을 참조하는 것은 지원되지 않는다.
 
 #### 지역(Regional) PD 퍼시스턴트볼륨을 수동으로 프로비저닝하기
-[GCE PD 용 StorageClass](/docs/concepts/storage/storage-classes/#gce) 를 사용해서 동적 프로비저닝이 가능하다.
+[GCE PD용 스토리지클래스](/ko/docs/concepts/storage/storage-classes/#gce-pd)를 사용해서 동적 프로비저닝이 가능하다.
 PersistentVolume을 생성하기 전에 PD를 생성해야만 한다.
 ```shell
-gcloud beta compute disks create --size=500GB my-data-disk
+gcloud compute disks create --size=500GB my-data-disk
     --region us-central1
     --replica-zones us-central1-a,us-central1-b
 ```
@@ -470,8 +468,6 @@ apiVersion: v1
 kind: PersistentVolume
 metadata:
   name: test-volume
-  labels:
-    failure-domain.beta.kubernetes.io/zone: us-central1-a__us-central1-b
 spec:
   capacity:
     storage: 400Gi
@@ -480,6 +476,15 @@ spec:
   gcePersistentDisk:
     pdName: my-data-disk
     fsType: ext4
+      nodeAffinity:
+    required:
+      nodeSelectorTerms:
+      - matchExpressions:
+        - key: failure-domain.beta.kubernetes.io/zone
+          operator: In
+          values:
+          - us-central1-a
+          - us-central1-b
 ```
 
 #### CSI 마이그레이션
@@ -574,12 +579,13 @@ glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드간에 데
 다음과 같은 이유로 이 유형의 볼륨 사용시 주의해야 한다.
 
 * 동일한 구성(파드템플릿으로 생성한 것과 같은)을
-  가진 파드는 노드에 있는 파일이 다르기 때문에 노드마다 다르게 동작할 수 있음
+  가진 파드는 노드에 있는 파일이 다르기 때문에 노드마다 다르게 동작할 수 있다.
 * 쿠버네티스가 계획한 대로 리소스 인식 스케줄링을 추가하면 `hostPath` 에서
-  사용되는 리소스를 설명할 수 없음
+  사용되는 리소스를 설명할 수 없다.
-* 기본 호스트에 생성된 파일 또는 디렉터리는 root만 쓸 수 있다. 프로세스를
+* 기본 호스트에 생성된 파일 또는 디렉터리는 root만 쓸 수 있다.
-  [특권 컨테이너](/docs/user-guide/security-context) 에서 루트로 실행하거나
+  프로세스를 [특권을 가진(privileged) 컨테이너](/docs/user-guide/security-context)에서
-  `hostPath` 볼륨에 쓸 수 있도록 호스트의 파일 권한을 수정해야 함
+  루트로 실행하거나
+  `hostPath` 볼륨에 쓸 수 있도록 호스트의 파일 권한을 수정해야 한다.
 
 #### 파드 예시
 
@@ -714,7 +720,7 @@ spec:
 
 로컬 볼륨을 사용할 때는 `volumeBindingMode` 가 `WaitForFirstConsumer` 로 설정된
 스토리지클래스(StorageClass)를 생성하는 것을 권장한다.
-[예시](/docs/concepts/storage/storage-classes/#local)를 본다. 볼륨 바인딩을 지연시키는 것은
+[예시](/ko/docs/concepts/storage/storage-classes/#local)를 본다. 볼륨 바인딩을 지연시키는 것은
 퍼시스턴트볼륨클래임 바인딩 결정도 노드 리소스 요구사항, 노드 셀렉터,
 파드 어피니티 그리고 파드 안티 어피니티와
 같이 파드가 가질 수 있는 다른 노드 제약 조건으로 평가되도록 만든다.
@@ -1473,4 +1479,3 @@ sudo systemctl restart docker
 ## {{% heading "whatsnext" %}}
 
 * [퍼시스턴트 볼륨과 함께 워드프레스와 MySQL 배포하기](/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)의 예시를 따른다.
-

content/ko/docs/concepts/workloads/controllers/cron-jobs.md

@@ -10,19 +10,20 @@ weight: 80
 
 _크론잡은_ 반복 일정에 따라 {{< glossary_tooltip term_id="job" text="잡" >}}을 만든다.
 
-하나의 크론잡 객체는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다. 크론잡은 잡을 [크론](https://en.wikipedia.org/wiki/Cron)형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다.
+하나의 크론잡 오브젝트는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다.
-
+크론잡은 잡을 [크론](https://ko.wikipedia.org/wiki/Cron) 형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다.
 
 {{< caution >}}
 모든 **크론잡** `일정:` 시간은
 {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}의 시간대를 기준으로 한다.
 
 컨트롤 플레인이 파드 또는 베어 컨테이너에서 kube-controller-manager를 실행하는 경우,
-kube-controller-manager 컨테이너에 설정된 시간대는 크론잡 컨트롤러가 사용하는 시간대로 결정한다.
+kube-controller-manager 컨테이너에 설정된 시간대는
+크론잡 컨트롤러가 사용하는 시간대로 결정한다.
 {{< /caution >}}
 
 크론잡 리소스에 대한 매니페스트를 생성할 때에는 제공하는 이름이
-유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
+유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
 이름은 52자 이하여야 한다. 이는 크론잡 컨트롤러는 제공된 잡 이름에
 11자를 자동으로 추가하고, 작업 이름의 최대 길이는
 63자라는 제약 조건이 있기 때문이다.
@@ -37,7 +38,7 @@ kube-controller-manager 컨테이너에 설정된 시간대는 크론잡 컨트
 작업을 만드는데 유용하다. 또한 크론잡은 클러스터가 유휴 상태일 때 잡을
 스케줄링하는 것과 같이 특정 시간 동안의 개별 작업을 스케줄할 수 있다.
 
-### 예제
+### 예시
 
 이 크론잡 매니페스트 예제는 현재 시간과 hello 메시지를 1분마다 출력한다.
 
@@ -48,7 +49,7 @@ kube-controller-manager 컨테이너에 설정된 시간대는 크론잡 컨트
 
 ## 크론잡의 한계 {#cron-job-limitations}
 
-크론 잡은 일정의 실행시간 마다 _약_ 한 번의 잡을 생성한다. "약" 이라고 하는 이유는
+크론잡은 일정의 실행시간 마다 _약_ 한 번의 잡 오브젝트를 생성한다. "약" 이라고 하는 이유는
 특정 환경에서는 두 개의 잡이 만들어지거나, 잡이 생성되지 않기도 하기 때문이다. 보통 이렇게 하지
 않도록 해야겠지만, 완벽히 그럴 수는 없다. 따라서 잡은 _멱등원_ 이 된다.
 
@@ -56,7 +57,7 @@ kube-controller-manager 컨테이너에 설정된 시간대는 크론잡 컨트
 `concurrencyPolicy` 가 `Allow` 로 설정될 경우, 잡은 항상 적어도 한 번은
 실행될 것이다.
 
-모든 크론 잡에 대해 크론잡 {{< glossary_tooltip term_id="controller" >}} 는 마지막 일정부터 지금까지 얼마나 많은 일정이 누락되었는지 확인한다. 만약 100회 이상의 일정이 누락되었다면, 잡을 실행하지 않고 아래와 같은 에러 로그를 남긴다.
+모든 크론잡에 대해 크론잡 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}} 는 마지막 일정부터 지금까지 얼마나 많은 일정이 누락되었는지 확인한다. 만약 100회 이상의 일정이 누락되었다면, 잡을 실행하지 않고 아래와 같은 에러 로그를 남긴다.
 
 ````
 Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew.
@@ -85,5 +86,3 @@ Cannot determine if job needs to be started. Too many missed start time (> 100).
 
 크론잡 생성과 작업에 대한 지침과 크론잡 매니페스트의
 예는 [크론잡으로 자동화된 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs/)를 참조한다.
-
-

content/ko/docs/concepts/workloads/controllers/daemonset.md

@@ -12,9 +12,9 @@ _데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도
 
 데몬셋의 일부 대표적인 용도는 다음과 같다.
 
-- 각 노드에서 `glusterd`, `ceph` 와 같은 클러스터 스토리지 데몬의 실행.
+- 모든 노드에서 클러스터 스토리지 데몬 실행
-- 모든 노드에서 `fluentd` 또는 `filebeat` 와 같은 로그 수집 데몬의 실행.
+- 모든 노드에서 로그 수집 데몬 실행
-- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Flowmill](https://github.com/Flowmill/flowmill-k8s/), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 또는 [Elastic Metricbeat](https://www.elastic.co/guide/en/beats/metricbeat/current/running-on-kubernetes.html)와 같은 노드 모니터링 데몬의 실행.
+- 모든 노드에서 노드 모니터링 데몬 실행
 
 단순한 케이스에서는, 각 데몬 유형의 처리를 위해서 모든 노드를 커버하는 하나의 데몬셋이 사용된다.
 더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만,
@@ -42,11 +42,12 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
 ### 필수 필드
 
 다른 모든 쿠버네티스 설정과 마찬가지로 데몬셋에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다.
-일반적인 설정파일 작업에 대한 정보는 [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/), 
+일반적인 설정파일 작업에 대한 정보는 [애플리케이션 배포하기](/docs/user-guide/deploying-applications/),
 [컨테이너 구성하기](/ko/docs/tasks/) 그리고 [kubectl을 사용한 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다.
 
 데몬셋 오브젝트의 이름은 유효한
-[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
+[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
+
 데몬셋에는 [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 섹션도 필요하다.
 
 ### 파드 템플릿
@@ -84,7 +85,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
 
 또한 일반적으로 다른 데몬셋이나 레플리카셋과 같은 다른 컨트롤러를 통해 직접적으로
 레이블이 셀렉터와 일치하는 다른 파드를 생성하지 않아야 한다. 그렇지 않으면 데몬셋
-{{< glossary_tooltip term_id="controller" >}} 는 해당 파드가 생성된 것으로 생각한다. 쿠버네티스는 이런 일을 하는 것을 
+{{< glossary_tooltip term_id="controller" text="컨트롤러" >}}는 해당 파드가 생성된 것으로 생각한다. 쿠버네티스는 이런 일을 하는 것을
 막지 못한다. 사용자가 이와 같은 일을 하게 되는 한 가지 경우는 테스트를 목적으로 한 노드에서 다른 값을 가지는 파드들을
 수동으로 생성하는 것이다.
 
@@ -93,7 +94,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
 만약 `.spec.template.spec.nodeSelector` 를 명시하면 데몬셋 컨트롤러는
 [노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector)와
 일치하는 노드에 파드를 생성한다. 마찬가지로 `.spec.template.spec.affinity` 를 명시하면
-데몬셋 컨트롤러는 [노트 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)와 일치하는 노드에 파드를 생성한다. 
+데몬셋 컨트롤러는 [노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)와 일치하는 노드에 파드를 생성한다.
 만약 둘 중 하나를 명시하지 않으면 데몬셋 컨트롤러는 모든 노드에서 파드를 생성한다.
 
 ## 데몬 파드가 스케줄 되는 방법
@@ -110,8 +111,8 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
  * 파드 동작의 불일치: 스케줄 되기 위해서 대기 중인 일반 파드는 `Pending` 상태로 생성된다.
    그러나 데몬셋 파드는 `Pending` 상태로 생성되지 않는다.
    이것은 사용자에게 혼란을 준다.
- * [파드 선점](/docs/concepts/configuration/pod-priority-preemption/)
+ * [파드 선점](/ko/docs/concepts/configuration/pod-priority-preemption/)은
-   은 기본 스케줄러에서 처리한다. 선점이 활성화되면 데몬셋 컨트롤러는 
+   기본 스케줄러에서 처리한다. 선점이 활성화되면 데몬셋 컨트롤러는
    파드 우선순위와 선점을 고려하지 않고 스케줄 한다.
 
 `ScheduleDaemonSetPods` 로 데몬셋 파드에 `.spec.nodeName` 용어 대신
@@ -137,11 +138,10 @@ nodeAffinity:
 자동으로 추가된다. 기본 스케줄러는 데몬셋 파드를
 스케줄링시 `unschedulable` 노드를 무시한다.
 
-
 ### 테인트(taints)와 톨러레이션(tolerations)
 
 데몬 파드는
-[테인트와 톨러레이션](/docs/concepts/configuration/taint-and-toleration)을 존중하지만, 
+[테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 존중하지만,
 다음과 같이 관련 기능에 따라 자동적으로 데몬셋 파드에
 톨러레이션을 추가한다.
 
@@ -154,9 +154,6 @@ nodeAffinity:
 | `node.kubernetes.io/unschedulable`       | NoSchedule | 1.12+   | 데몬셋 파드는 기본 스케줄러의 스케줄할 수 없는(unschedulable) 속성을 극복한다. |
 | `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+   | 호스트 네트워크를 사용하는 데몬셋 파드는 기본 스케줄러에 의해 이용할 수 없는 네트워크(network-unavailable) 속성을 극복한다. |
 
-
-
-
 ## 데몬 파드와 통신
 
 데몬셋의 파드와 통신할 수 있는 몇 가지 패턴은 다음과 같다.
@@ -184,7 +181,7 @@ nodeAffinity:
 새 데몬셋은 기존 파드를 채택한다. 만약 파드를 교체해야 하는 경우 데몬셋은
 `updateStrategy` 에 따라 파드를 교체한다.
 
-사용자는 데몬셋에서 [롤링 업데이트를 수행](/docs/tasks/manage-daemon/update-daemon-set/) 할 수 있다.
+사용자는 데몬셋에서 [롤링 업데이트를 수행](/ko/docs/tasks/manage-daemon/update-daemon-set/)할 수 있다.
 
 ## 데몬셋의 대안
 
@@ -210,10 +207,10 @@ nodeAffinity:
 ### 스태틱(static) 파드
 
 Kubelet이 감시하는 특정 디렉토리에 파일을 작성하는 파드를 생성할 수 있다. 이것을
-[스태틱 파드](/docs/tasks/configure-pod-container/static-pod/)라고 부른다.
+[스태틱 파드](/ko/docs/tasks/configure-pod-container/static-pod/)라고 부른다.
 데몬셋과는 다르게 스태틱 파드는 kubectl
 또는 다른 쿠버네티스 API 클라이언트로 관리할 수 없다.  스태틱 파드는 API 서버에 의존하지
-않기 때문에 클러스터 부트스트랩(bootstraping)하는 경우에 유용하다.  또한 스태틱 파드는 향후에 사용 중단(deprecated)될 수 있다.
+않기 때문에 클러스터 부트스트랩(bootstraping)하는 경우에 유용하다.  또한 스태틱 파드는 향후에 사용 중단될 수 있다.
 
 ### 디플로이먼트
 
@@ -225,5 +222,3 @@ Kubelet이 감시하는 특정 디렉토리에 파일을 작성하는 파드를
 업데이트 롤아웃이 더 중요한 프런트 엔드와 같은 것은 스테이트리스 서비스의
 디플로이먼트를 사용한다. 파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요하고,
 다른 파드의 실행 이전에 필요한 경우에는 데몬셋을 사용한다.
-
-

content/ko/docs/concepts/workloads/controllers/deployment.md

@@ -1,4 +1,6 @@
 ---
+
+
 title: 디플로이먼트
 feature:
   title: 자동화된 롤아웃과 롤백
@@ -72,7 +74,6 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와
 
 1. 다음 명령어를 실행해서 디플로이먼트를 생성한다.
 
-
 ```shell
 kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
 ```
@@ -145,7 +146,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
 디플로이먼트에는 파드 템플릿 레이블과 적절한 셀렉터를 반드시 명시해야 한다
 (이 예시에서는 `app: nginx`).
 
-레이블 또는 셀렉터는 다른 컨트롤러(다른 디플로이먼트와 스테이트풀 셋 포함)와 겹치지 않아야 한다. 쿠버네티스는 겹치는 것을 막지 않으며, 만약 다중 컨트롤러가 겹치는 셀렉터를 가지는 경우 해당 컨트롤러의 충돌 또는 예기치 않은 동작을 야기할 수 있다.
+레이블 또는 셀렉터는 다른 컨트롤러(다른 디플로이먼트와 스테이트풀셋(StatefulSet) 포함)와 겹치지 않아야 한다. 쿠버네티스는 겹치는 것을 막지 않으며, 만약 다중 컨트롤러가 겹치는 셀렉터를 가지는 경우 해당 컨트롤러의 충돌 또는 예기치 않은 동작을 야기할 수 있다.
 {{< /note >}}
 
 ### Pod-template-hash 레이블
@@ -1064,7 +1065,6 @@ $ echo $?
 
 API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설정되지 않으면 `.spec.template.metadata.labels` 은 기본 설정되지 않는다. 그래서 이것들은 명시적으로 설정되어야 한다. 또한 `apps/v1` 에서는 디플로이먼트를 생성한 후에는 `.spec.selector` 이 변경되지 않는 점을 참고한다.
 
-
 디플로이먼트는 템플릿의 `.spec.template` 와 다르거나 파드의 수가 `.spec.replicas` 를 초과할 경우
 셀렉터와 일치하는 레이블을 가진 파드를 종료할 수 있다.
 파드의 수가 의도한 수량보다 적을 경우 `.spec.template` 에 맞는 새 파드를 띄운다.
@@ -1112,7 +1112,8 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설
 
 예를 들어 이 값을 30%로 설정하면 롤링업데이트 시작시 즉각 이전 레플리카셋의 크기를
 의도한 파드 중 70%를 스케일 다운할 수 있다. 새 파드가 준비되면 기존 레플리카셋을 스케일 다운할 수 있으며,
-업데이트 중에 항상 사용가능한 전체 파드의 수는  의도한 파드의 수의 70%이상이 되도록 새 레플리카셋을 스케일을 업 할수 있다.
+업데이트 중에 항상 사용 가능한 전체 파드의 수는
+의도한 파드의 수의 70% 이상이 되도록 새 레플리카셋을 스케일 업할 수 있다.
 
 ##### 최대 서지(Max Surge)
 
@@ -1164,5 +1165,3 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설
 일시 중지 된 디플로이먼트와 일시 중지 되지 않은 디플로이먼트 사이의 유일한 차이점은
 일시 중지된 디플로이먼트는 PodTemplateSpec에 대한 변경 사항이 일시중지 된 경우 새 롤아웃을 트리거 하지 않는다.
 디플로이먼트는 생성시 기본적으로 일시 중지되지 않는다.
-
-

content/ko/docs/concepts/workloads/controllers/garbage-collection.md

@@ -148,7 +148,7 @@ curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-rep
 
 kubectl도 캐스케이딩 삭제를 지원한다.
 kubectl을 사용해서 종속 항목을 자동으로 삭제하려면 `--cascade` 를 true로 설정한다. 종속 항목을
-분리하기 위해서는 `--cascase` 를 false로 설정한다. `--cascade` 의 기본값은
+분리하기 위해서는 `--cascade` 를 false로 설정한다. `--cascade` 의 기본값은
 true 이다.
 
 여기에 레플리카셋의 종속 항목을 분리로 만드는 예시가 있다.
@@ -181,3 +181,4 @@ kubectl delete replicaset my-repset --cascade=false
 
 
 
+

content/ko/docs/concepts/workloads/controllers/jobs-run-to-completion.md

@@ -111,7 +111,7 @@ kubectl logs $pods
 ## 잡 사양 작성하기
 
 다른 쿠버네티스의 설정과 마찬가지로 잡에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다.
-잡의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
+잡의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
 
 잡에는 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다.
 
@@ -175,8 +175,8 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
 - _고정적인 완료 횟수(fixed completion count)_ 잡의 경우, 병렬로 실행 중인 파드의 수는 남은 완료 수를
   초과하지 않는다.  `.spec.parallelism` 의 더 큰 값은 사실상 무시된다.
 - _작업 큐_ 잡은 파드가 성공한 이후에 새로운 파드가 시작되지 않는다. 그러나 나머지 파드는 완료될 수 있다.
-- 만약 잡 {{< glossary_tooltip term_id="controller" >}} 가 반응할 시간이 없는 경우
+- 만약 잡 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}} 가 반응할 시간이 없는 경우
-- 만약 잡 컨트롤러가 어떤 이유(`리소스 쿼터` 의 부족, 권한 부족 등)로든 파드 생성에 실패한 경우, 
+- 만약 잡 컨트롤러가 어떤 이유(`ResourceQuota` 의 부족, 권한 부족 등)로든 파드 생성에 실패한 경우,
   요청한 것보다 적은 수의 파드가 있을 수 있다.
 - 잡 컨트롤러는 동일한 잡에서 과도하게 실패한 이전 파드들로 인해 새로운 파드의 생성을 조절할 수 있다.
 - 파드가 정상적으로(gracefully) 종료되면, 중지하는데 시간이 소요된다.
@@ -473,6 +473,4 @@ spec:
 
 ## 크론잡 {#cron-jobs}
 
-[`크론잡`](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 사용해서 Unix 도구인 `cron`과 유사하게 지정된 시간/일자에 실행되는 잡을 생성할 수 있다.
+[`CronJob`](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 사용해서 Unix 도구인 `cron`과 유사하게 지정된 시간/일자에 실행되는 잡을 생성할 수 있다.
-
-

content/ko/docs/concepts/workloads/controllers/replicationcontroller.md

@@ -13,7 +13,7 @@ weight: 20
 <!-- overview -->
 
 {{< note >}}
-[`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/) 을 구성하는 [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/) 가 현재 권장되는 레플리케이션 설정 방법이다.
+[`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/)을 구성하는 [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/)가 현재 권장하는 레플리케이션 설정 방법이다.
 {{< /note >}}
 
 _레플리케이션컨트롤러_ 는 언제든지 지정된 수의 파드 레플리카가
@@ -123,7 +123,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
 
 `.spec.template` 는 오직 `.spec` 필드에서 요구되는 것이다.
 
-`.spec.template` 는 [파드(Pod) 개요](/ko/docs/concepts/workloads/pods/pod-overview/#pod-templates) 이다. 정확하게 [파드](/ko/docs/concepts/workloads/pods/pod/) 스키마와 동일하나, 중첩되어 있고 `apiVersion` 혹은 `kind`를 갖지 않는다.
+`.spec.template` 는 [파드 개요](/ko/docs/concepts/workloads/pods/pod-overview/#pod-templates) 이다. 정확하게 [파드](/ko/docs/concepts/workloads/pods/pod/) 스키마와 동일하나, 중첩되어 있고 `apiVersion` 혹은 `kind`를 갖지 않는다.
 
 파드에 필요한 필드 외에도 레플리케이션 컨트롤러의 파드 템플릿은 적절한 레이블과 적절한 재시작 정책을 지정해야 한다. 레이블의 경우 다른 컨트롤러와
 중첩되지 않도록 하라. [파드 셀렉터](#파드-셀렉터)를 참조하라.
@@ -225,10 +225,10 @@ REST API나 go 클라이언트 라이브러리를 사용하는 경우 간단히
 
 ### 서비스와 레플리케이션컨트롤러 사용
 
-하나의 서비스 뒤에 여러 개의 레플리케이션 컨트롤러가 있을 수 있다. 예를 들어 일부 트래픽은 이전 버전으로 이동하고 일부는 새 버전으로 이동한다.
+하나의 서비스 뒤에 여러 개의 레플리케이션컨트롤러가 있을 수 있다.
+예를 들어 일부 트래픽은 이전 버전으로 이동하고 일부는 새 버전으로 이동한다.
 
-레플리케이션 컨트롤러는 자체적으로 종료되지 않지만 서비스만큼 오래 지속될 것으로 기대되지는 않는다. 서비스는 여러 레플리케이션 컨트롤러에 의해 제어되는 파드로 구성될 수 있으며 서비스 라이프사이클 동안 (예를 들어 서비스를 실행하는 파드 업데이트 수행을 위해)
+레플리케이션컨트롤러는 자체적으로 종료되지 않지만, 서비스만큼 오래 지속될 것으로 기대되지는 않는다. 서비스는 여러 레플리케이션컨트롤러에 의해 제어되는 파드로 구성될 수 있으며, 서비스 라이프사이클 동안(예를 들어, 서비스를 실행하는 파드 업데이트 수행을 위해) 많은 레플리케이션컨트롤러가 생성 및 제거될 것으로 예상된다. 서비스 자체와 클라이언트 모두 파드를 유지하는 레플리케이션컨트롤러를 의식하지 않는 상태로 남아 있어야 한다.
-많은 레플리케이션 컨트롤러가 생성 및 제거될 것으로 예상된다. 서비스 자체와 클라이언트 모두 파드를 유지하는 레플리케이션 컨트롤러를 의식하지 않는 상태로 남아 있어야 한다.
 
 ## 레플리케이션을 위한 프로그램 작성
 
@@ -280,6 +280,4 @@ API 오브젝트에 대한 더 자세한 것은
 
 ## 더 자세한 정보는
 
-[스테이트리스 애플리케이션 레플리케이션 컨트롤러 실행하기](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/) 를 참조하라.
+[스테이트리스 애플리케이션 레플리케이션 컨트롤러 실행하기](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/)를 참고한다.
-
-

content/ko/docs/concepts/workloads/controllers/statefulset.md

@@ -42,6 +42,7 @@ weight: 40
   필요한 파손 상태로 빠질 수 있다.
 
 ## 구성 요소
+
 아래의 예시에서는 스테이트풀셋의 구성요소를 보여 준다.
 
 ```yaml
@@ -100,9 +101,9 @@ spec:
 * 이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다.
 * 이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다.
 * volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 사용해서 안정적인 스토리지를 제공한다.
-스테이트풀셋 오브젝트의 이름은 유효한
-[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
 
+스테이트풀셋 오브젝트의 이름은 유효한
+[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
 
 ## 파드 셀렉터
 
@@ -110,9 +111,9 @@ spec:
 
 ## 파드 신원
 
-스테이트풀셋 파드는 순서, 안정적인 네트워크 신원 그리고
+스테이트풀셋 파드는 순서, 안정적인 네트워크 신원
-안정적인 스토리지로 구성되는 고유한 신원을 가진다. 신원은 
+그리고 안정적인 스토리지로 구성되는 고유한 신원을 가진다.
-파드가 어떤 노드에 있고, (재)스케줄과도 상관없이 파드에 붙어있다.
+신원은 파드가 어떤 노드에 있고, (재)스케줄과도 상관없이 파드에 붙어있다.
 
 ### 순서 색인
 
@@ -130,7 +131,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
 이 서비스가 관리하는 도메인은 `$(service name).$(namespace).svc.cluster.local` 의 형식을 가지며,
 여기서 "cluster.local"은 클러스터 도메인이다.
 각 파드는 생성되면 `$(podname).$(governing service domain)` 형식을 가지고
-일치되는 DNS 서브도메인을 가지며, 여기서 governing service는 
+일치되는 DNS 서브도메인을 가지며, 여기서 거버닝 서비스(governing service)는
 스테이트풀셋의 `serviceName` 필드에 의해 정의된다.
 
 [제한사항](#제한사항) 섹션에서 언급한 것처럼 사용자는
@@ -156,7 +157,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
 쿠버네티스는 각 VolumeClaimTemplate마다 하나의 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)을
 생성한다. 위의 nginx 예시에서 각 파드는 `my-storage-class` 라는 스토리지 클래스와
 1 Gib의 프로비전된 스토리지를 가지는 단일 퍼시스턴트 볼륨을 받게 된다. 만약 스토리지 클래스가
-명시되지 않은 경우 기본 스토리지 클래스를 사용된다. 파드가 노드에서 스케줄 혹은 재스케줄이되면 
+명시되지 않은 경우, 기본 스토리지 클래스가 사용된다. 파드가 노드에서 스케줄 혹은 재스케줄이 되면
 파드의 `volumeMounts` 는 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨이 마운트 된다.
 참고로, 파드 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨은
 파드 또는 스테이트풀셋이 삭제되더라도 삭제되지 않는다.
@@ -269,6 +270,3 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
 * [스테이트풀 애플리케이션의 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/)의 예시를 따른다.
 * [카산드라와 스테이트풀셋 배포](/ko/docs/tutorials/stateful-application/cassandra/)의 예시를 따른다.
 * [레플리케이티드(replicated) 스테이트풀 애플리케이션 실행하기](/docs/tasks/run-application/run-replicated-stateful-application/)의 예시를 따른다.
-
-
-

content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md

@@ -14,7 +14,8 @@ TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을
 처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를
 처리하도록 확장될 수 있다.
 
-알파(Alpha) 고지 사항: 이 기능은 현재 알파이다, 그리고 kube-apiserver 와 kube-controller-manager 와 함께
+알파(Alpha) 고지 사항: 이 기능은 현재 알파이고,
+kube-apiserver와 kube-controller-manager와 함께
 [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)로 `TTLAfterFinished` 를 활성화할 수 있다.
 
 
@@ -83,5 +84,3 @@ TTL 컨트롤러는 쿠버네티스 리소스에
 [자동으로 잡 정리](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/#완료된-잡을-자동으로-정리)
 
 [디자인 문서](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
-
-

content/ko/docs/concepts/workloads/pods/disruptions.md

@@ -33,7 +33,8 @@ weight: 60
 - 노드의 [리소스 부족](/docs/tasks/administer-cluster/out-of-resource/)으로 파드가 축출됨
 
 리소스 부족을 제외한 나머지 조건은 대부분의 사용자가 익숙할 것이다.
-왜냐하면 그 조건은 쿠버네티스에 국한되지 않기 때문이다.
+왜냐하면
+그 조건은 쿠버네티스에 국한되지 않기 때문이다.
 
 우리는 다른 상황을 *자발적인 중단* 으로 부른다.
 여기에는 애플리케이션 소유자의 작업과 클러스터 관리자의 작업이 모두 포함된다.
@@ -46,7 +47,9 @@ weight: 60
 클러스터 관리자의 작업:
 
 - 복구 또는 업그레이드를 위한 [노드 드레이닝](/docs/tasks/administer-cluster/safely-drain-node/).
-- 클러스터의 스케일 축소를 위한 노드 드레이닝([클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaler)에 대해 알아보기).
+- 클러스터의 스케일 축소를 위한
+  노드 드레이닝([클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)에 대해 알아보기
+  ).
 - 노드에 다른 무언가를 추가하기 위해 파드를 제거.
 
 위 작업은 클러스터 관리자가 직접 수행하거나 자동화를 통해 수행하며,
@@ -58,7 +61,7 @@ weight: 60
 
 {{< caution >}}
 모든 자발적인 중단이 Pod Disruption Budget에 연관되는 것은 아니다.
-예를 들어 디플로이먼트 또는 파드의 삭제는 Pod Disruption Budget를 무시한다.
+예를 들어 디플로이먼트 또는 파드의 삭제는 Pod Disruption Budget을 무시한다.
 {{< /caution >}}
 
 ## 중단 다루기
@@ -66,27 +69,35 @@ weight: 60
 비자발적인 중단으로 인한 영향을 경감하기 위한 몇 가지 방법은 다음과 같다.
 
 - 파드가 필요로 하는 [리소스를 요청](/docs/tasks/configure-pod-container/assign-cpu-ram-container)하는지 확인한다.
-- 고가용성이 필요한 경우 애플리케이션을 복제한다. (복제된 [스테이트리스](/docs/tasks/run-application/run-stateless-application-deployment/) 및 [스테이트풀](/docs/tasks/run-application/run-replicated-stateful-application/)애플리케이션에 대해 알아보기.)
+- 고가용성이 필요한 경우 애플리케이션을 복제한다.
-- 복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체([안티-어피니티](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature) 이용) 또는 
+  (복제된 [스테이트리스](/docs/tasks/run-application/run-stateless-application-deployment/) 및
-영역 간(또는 [다중 영역 클러스터](/ko/docs/setup/best-practices/multiple-zones/)를 이용한다.)에 
+  [스테이트풀](/docs/tasks/run-application/run-replicated-stateful-application/) 애플리케이션에 대해 알아보기.)
+- 복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체
+  ([안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티) 이용)
+  또는 영역 간
+  ([다중 영역 클러스터](/docs/setup/multiple-zones)를 이용한다면)에
   애플리케이션을 분산해야 한다.
 
 자발적 중단의 빈도는 다양하다. 기본적인 쿠버네티스 클러스터에서는 자발적인 운영 중단이 전혀 없다.
 그러나 클러스터 관리자 또는 호스팅 공급자가 자발적 중단이 발생할 수 있는 일부 부가 서비스를 운영할 수 있다.
 예를 들어 노드 소프트웨어의 업데이트를 출시하는 경우 자발적 중단이 발생할 수 있다.
-또한 클러스터(노드) 오토스케일링의 일부 구현에서는 단편화를 제거하고 노드의 효율을 높이는 과정에서 자발적 중단을 야기할 수 있다.
+또한 클러스터(노드) 오토스케일링의 일부 구현에서는
-클러스터 관리자 또는 호스팅 공급자는 예측 가능한 자발적 중단 수준에 대해 문서화해야 한다.
+단편화를 제거하고 노드의 효율을 높이는 과정에서 자발적 중단을 야기할 수 있다.
+클러스터 관리자 또는 호스팅 공급자는
+예측 가능한 자발적 중단 수준에 대해 문서화해야 한다.
 
 쿠버네티스는 자주 발생하는 자발적 중단에도 고가용성 애플리케이션을
 실행 할 수 있는 기능을 제공한다.
 우리는 이 기능을 *Disruption Budgets* 이라 부른다.
 
+
 ## Disruption Budgets의 작동 방식
 
 {{< feature-state for_k8s_version="v1.5" state="beta" >}}
 
 애플리케이션 소유자는 각 애플리케이션에 대해 `PodDisruptionBudget` 오브젝트(PDB)를 만들 수 있다.
-PDB는 자발적 중단으로 일시에 중지되는 복제된 애플리케이션 파드의 수를 제한한다.
+PDB는 자발적 중단으로
+일시에 중지되는 복제된 애플리케이션 파드의 수를 제한한다.
 예를 들어 정족수 기반의 애플리케이션이
 실행 중인 레플리카의 수가 정족수 이하로 떨어지지 않도록 한다.
 웹 프런트 엔드는 부하를 처리하는 레플리카의 수가
@@ -94,17 +105,19 @@ PDB는 자발적 중단으로 일시에 중지되는 복제된 애플리케이
 
 클러스터 관리자와 호스팅 공급자는 직접적으로 파드나 디플로이먼트를 제거하는 대신
 [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)로
-불리는 Pod Disruption Budgets를 준수하는 도구를 이용해야 한다. 
+불리는 Pod Disruption Budget을 준수하는 도구를 이용해야 한다.
 예를 들어 `kubectl drain` 명령어나 Kubernetes-on-GCE 클러스터 업그레이드 스크립트(`cluster/gce/upgrade.sh`)이다.
 
 클러스터 관리자가 노드를 비우고자 할 경우에는 `kubectl drain` 명령어를 사용한다.
 해당 도구는 머신에 존재하는 모든 파드를 축출하려는 시도를 한다.
-축출 요청은 일시적으로 거부될 수 있으며, 도구는 모든 파드가 종료되거나 
+축출 요청은 일시적으로 거부될 수 있으며,
+도구는 모든 파드가 종료되거나
 설정 가능한 타임아웃이 도래할 때까지 주기적으로 모든 실패된 요청을 다시 시도한다.
 
 PDB는 애플리케이션이 필요로 하는 레플리카의 수에 상대적으로, 용인할 수 있는 레플리카의 수를 지정한다.
 예를 들어 `.spec.replicas: 5` 의 값을 갖는 디플로이먼트는 어느 시점에든 5개의 파드를 가져야 한다.
-만약 해당 디플로이먼트의 PDB가 특정 시점에 파드를 4개 허용한다면, Eviction API는 한 번에 2개의 파드가 아닌, 1개의 파드의 자발적인 중단을 허용한다.
+만약 해당 디플로이먼트의 PDB가 특정 시점에 파드를 4개 허용한다면,
+Eviction API는 한 번에 2개의 파드가 아닌, 1개의 파드의 자발적인 중단을 허용한다.
 
 파드 그룹은 레이블 셀렉터를 사용해서 지정한 애플리케이션으로 구성되며
 애플리케이션 컨트롤러(디플로이먼트, 스테이트풀셋 등)를 사용한 것과 같다.
@@ -116,7 +129,8 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생
 버짓이 차감된다.
 
 애플리케이션의 롤링 업그레이드로 파드가 삭제되거나 사용할 수 없는 경우 중단 버짓에 영향을 준다.
-그러나 컨트롤러(디플로이먼트, 스테이트풀 셋과 같은)는 롤링 업데이트시 PDB의 제한을 받지 않는다.
+그러나 컨트롤러(디플로이먼트, 스테이트풀셋과 같은)는
+롤링 업데이트시 PDB의 제한을 받지 않는다.
 애플리케이션 업데이트 진행 중 발생하는 중단 처리는 컨트롤러 사양에 구성되어있다.
 ([디플로이먼트 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-업데이트)에 대해 알아보기.)
 
@@ -135,7 +149,8 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생
 | pod-a  *available*   | pod-b *available*   | pod-c *available*  |
 | pod-x  *available*   |                     |                    |
 
-전체 3개 파드는 디플로이먼트의 일부분으로 전체적으로 항상 3개의 파드 중 최소 2개의 파드를 사용할 수 있도록 하는 PDB를 가지고 있다.
+전체 3개 파드는 디플로이먼트의 일부분으로
+전체적으로 항상 3개의 파드 중 최소 2개의 파드를 사용할 수 있도록 하는 PDB를 가지고 있다.
 
 예를 들어, 클러스터 관리자가 커널 버그를 수정하기위해 새 커널 버전으로 재부팅하려는 경우를 가정해보자.
 클러스터 관리자는 첫째로 `node-1` 을 `kubectl drain` 명령어를 사용해서 비우려 한다.
@@ -217,13 +232,14 @@ drain 커멘드는 `pod-b`를 축출하는데 성공했다.
 다음의 시나리오에서 타당할 수 있다.
 
 - 쿠버네티스 클러스터를 공유하는 애플리케이션 팀이 많고, 자연스럽게 역할이 나누어진 경우
-- 타사 도구 또는 타사 서비스를 이용해서 클러스터 관리를 자동화 하는 경우
+- 타사 도구 또는 타사 서비스를 이용해서
+  클러스터 관리를 자동화 하는 경우
 
-Pod Disruption Budgets는 역할 분리에 따라 
+Pod Disruption Budget은 역할 분리에 따라
 역할에 맞는 인터페이스를 제공한다.
 
 만약 조직에 역할 분리에 따른 책임의 분리가 없다면
-Pod Disruption Budgets를 사용할 필요가 없다.
+Pod Disruption Budget을 사용할 필요가 없다.
 
 ## 클러스터에서 중단이 발생할 수 있는 작업을 하는 방법
 
@@ -251,5 +267,3 @@ Pod Disruption Budgets를 사용할 필요가 없다.
 * [Pod Disruption Budget 설정하기](/docs/tasks/run-application/configure-pdb/)의 단계를 따라서 애플리케이션을 보호한다.
 
 * [노드 비우기](/docs/tasks/administer-cluster/safely-drain-node/)에 대해 자세히 알아보기
-
-

content/ko/docs/concepts/workloads/pods/ephemeral-containers.md

@@ -9,13 +9,14 @@ weight: 80
 {{< feature-state state="alpha" for_k8s_version="v1.16" >}}
 
 이 페이지는 임시 컨테이너에 대한 개요를 제공한다: 이 특별한 유형의 컨테이너는 
-트러블 슈팅과 같은 사용자가 시작한 작업을 완료하기위해 기존 {{< glossary_tooltip term_id="pod" >}} 에서 
+트러블 슈팅과 같은 사용자가 시작한 작업을 완료하기위해 기존 {{< glossary_tooltip text="파드" term_id="pod" >}} 에서 
 임시적으로 실행된다. 사용자는 애플리케이션 빌드보다는 서비스를 점검할 때 임시 
 컨테이너를 사용한다.
 
 {{< warning >}}
-임시 컨테이너는 초기 알파 상태이며, 프로덕션 클러스터에는 
+임시 컨테이너는 초기 알파 상태이며,
-적합하지 않다. [쿠버네티스 사용중단(deprecation) 정책](/docs/reference/using-api/deprecation-policy/)에 따라
+프로덕션 클러스터에는 적합하지 않다.
+[쿠버네티스 사용 중단(deprecation) 정책](/docs/reference/using-api/deprecation-policy/)에 따라
 이 알파 기능은 향후 크게 변경되거나, 완전히 제거될 수 있다.
 {{< /warning >}}
 
@@ -65,7 +66,7 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지
 
 특히, [distroless 이미지](https://github.com/GoogleContainerTools/distroless)
 를 사용하면 공격 표면(attack surface)과 버그 및 취약점의 노출을 줄이는 최소한의
-컨테이너 이미지를 배포할 수 있다. distroless 이미지는 쉘 또는 어떤 디버깅 도구를 
+컨테이너 이미지를 배포할 수 있다. distroless 이미지는 셸 또는 어떤 디버깅 도구를
 포함하지 않기 때문에, `kubectl exec` 만으로는 distroless
 이미지의 문제 해결이 어렵다.
 
@@ -81,13 +82,13 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지
 
 {{< note >}}
 이 섹션의 예시는 `EphemeralContainers` [기능
-게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 
+게이트](/docs/reference/command-line-tools-reference/feature-gates/)의
 활성화를 필요로 하고, 쿠버네티스 클라이언트와 서버는 v1.16 또는 이후의 버전이어야 한다.
 {{< /note >}}
 
-이 섹션의 에시는 임시 컨테이너가 어떻게 API에 나타나는지 
+이 섹션의 예시는 임시 컨테이너가 어떻게 API에 나타나는지
 보여준다. 일반적으로 `kubectl alpha debug` 또는
-다른 `kubectl` [플러그인](/docs/tasks/extend-kubectl/kubectl-plugins/)을
+다른 `kubectl` [플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)을
 사용해서 API를 직접 호출하지 않고 이런 단계들을 자동화 한다.
 
 임시 컨테이너는 파드의 `ephemeralcontainers` 하위 리소스를
@@ -187,5 +188,3 @@ Ephemeral Containers:
 ```shell
 kubectl attach -it example-pod -c debugger
 ```
-
-

content/ko/docs/concepts/workloads/pods/init-containers.md

@@ -27,7 +27,7 @@ weight: 40
 * 각 초기화 컨테이너는 다음 초기화 컨테이너가 시작되기 전에 성공적으로 완료되어야 한다.
 
 만약 파드를 위한 초기화 컨테이너가 실패한다면, 쿠버네티스는 초기화 컨테이너가 성공할 때까지 파드를
-반복적으로 재시작한다. 그러나, 만약 파드의 `restartPolicy`을 절대 하지 않음(Never)으로 설정했다면, 파드는 재시작되지 않는다.
+반복적으로 재시작한다. 그러나, 만약 파드의 `restartPolicy` 를 절대 하지 않음(Never)으로 설정했다면, 파드는 재시작되지 않는다.
 
 컨테이너를 초기화 컨테이너로 지정하기 위해서는,
 파드 스펙에 앱 `containers` 배열과 나란히 `initContainers` 필드를
@@ -227,7 +227,7 @@ service/myservice created
 service/mydb created
 ```
 
-초기화 컨테이너들이 완료되는 것과 `myapp-pod` 파드가 Runnning 상태로
+초기화 컨테이너들이 완료되는 것과 `myapp-pod` 파드가 Running 상태로
 변경되는 것을 볼 것이다.
 
 ```shell
@@ -250,12 +250,12 @@ myapp-pod   1/1       Running   0          9m
 각 초기화 컨테이너는 다음 컨테이너가 시작되기 전에 성공적으로
 종료되어야 한다. 만약 런타임 문제나 실패 상태로 종료되는 문제로인하여 초기화 컨테이너의 시작이
 실패된다면, 초기화 컨테이너는 파드의 `restartPolicy` 에 따라서 재시도 된다. 다만,
-파드의 `restartPolicy`이 항상(Always)으로 설정된 경우, 해당 초기화 컨테이너는
+파드의 `restartPolicy` 가 항상(Always)으로 설정된 경우, 해당 초기화 컨테이너는
-`restartPolicy`을 실패 시(OnFailure)로 사용한다.
+`restartPolicy` 를 실패 시(OnFailure)로 사용한다.
 
 파드는 모든 초기화 컨테이너가 성공되기 전까지 `Ready` 될 수 없다. 초기화 컨테이너의 포트는
 서비스 하에 합쳐지지 않는다. 초기화 중인 파드는 `Pending` 상태이지만
-`Initialized`이 참이 되는 조건을 가져야 한다.
+`Initialized` 가 참이 되는 조건을 가져야 한다.
 
 만약 파드가 [재시작](#파드-재시작-이유)되었다면, 모든 초기화 컨테이너는
 반드시 다시 실행된다.
@@ -264,14 +264,15 @@ myapp-pod   1/1       Running   0          9m
 초기화 컨테이너 이미지 필드를 변경하는 것은 파드를 재시작하는 것과 같다.
 
 초기화 컨테이너는 재시작되거나, 재시도, 또는 재실행 될 수 있기 때문에, 초기화 컨테이너
-코드는 멱등성(indempotent)을 유지해야 한다. 특히, `EmptyDirs`에 있는 파일에 쓰기를 수행하는 코드는
+코드는 멱등성(idempotent)을 유지해야 한다. 특히, `EmptyDirs` 에 있는 파일에 쓰기를 수행하는 코드는
 출력 파일이 이미 존재할 가능성에 대비해야 한다.
 
 초기화 컨테이너는 앱 컨테이너의 필드를 모두 가지고 있다. 그러나, 쿠버네티스는
 `readinessProbe` 가 사용되는 것을 금지한다. 초기화 컨테이너가 완료 상태와 준비성을
 구분해서 정의할 수 없기 때문이다. 이것은 유효성 검사 중에 시행된다.
 
-초기화 컨테이너들이 실패를 영원히 지속하는 상황을 방지하기 위해서
+초기화 컨테이너들이 실패를
+영원히 지속하는 상황을 방지하기 위해서
 파드의 `activeDeadlineSeconds` 와 컨테이너의 `livenessProbe` 를 사용한다.
 
 파드 내의 각 앱과 초기화 컨테이너의 이름은 유일해야 한다. 어떤
@@ -310,7 +311,7 @@ myapp-pod   1/1       Running   0          9m
   이미지의 변경은 앱 컨테이너만 재시작시킨다.
 * 파드 인프라스트럭처 컨테이너가 재시작되었다. 이는 일반적인 상황이 아니며 노드에
   대해서 root 접근 권한을 가진 누군가에 의해서 수행됐을 것이다.
-* 파드 내의 모든 컨테이너들이, 재시작을 강제하는 `restartPolicy`이 항상으로 설정되어 있는,
+* 파드 내의 모든 컨테이너들이, 재시작을 강제하는 `restartPolicy` 가 항상(Always)으로 설정되어 있는,
   동안 종료되었다. 그리고 초기화 컨테이너의 완료 기록이 가비지 수집
   때문에 유실되었다.
 
@@ -320,7 +321,5 @@ myapp-pod   1/1       Running   0          9m
 ## {{% heading "whatsnext" %}}
 
 
-* [초기화 컨테이너를 가진 파드 생성하기](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container)
+* [초기화 컨테이너를 가진 파드 생성하기](/ko/docs/tasks/configure-pod-container/configure-pod-initialization/#초기화-컨테이너를-갖는-파드-생성)
 * [초기화 컨테이너 디버깅](/docs/tasks/debug-application-cluster/debug-init-containers/) 알아보기
-
-

content/ko/docs/concepts/workloads/pods/pod-lifecycle.md

@@ -193,8 +193,7 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지
    ...
    ```
 
-* `Terminated`:  컨테이너가 실행이 완료되어 구동을 멈추었다는 뜻이다. 컨테이너가 성공적으로 작업을 완료했을 때나 어떤 이유에서 실패했을 때 이 상태가 된다. 원인과 종료 코드(exit code)가 컨테이너의 시작과 종료 시간과 함께 무조건 출력된다.
+* `Terminated`:  컨테이너가 실행이 완료되어 구동을 멈추었다는 뜻이다. 컨테이너가 성공적으로 작업을 완료했을 때나 어떤 이유에서 실패했을 때 이 상태가 된다. 원인과 종료 코드(exit code)가 컨테이너의 시작과 종료 시간과 함께 무조건 출력된다. 컨테이너가 Terminated 상태가 되기 전에, `preStop` 훅이 (존재한다면) 실행된다.
-  컨테이너가 Terminated 상태가 되기 전에, `preStop` 훅이 (존재한다면) 실행된다.
 
    ```yaml
    ...
@@ -261,6 +260,9 @@ status:
 * 파드 내의 모든 컨테이너들이 준비 상태이다.
 * `ReadinessGates`에 지정된 모든 조건들이 `True` 이다.
 
+파드의 컨테이너가 Ready 이나 적어도 한 개의 사용자 지정 조건이 빠졌거나 `False` 이면,
+Kubelet은 파드의 상태를 `ContainerReady`로 설정한다.
+
 ## 재시작 정책
 
 PodSpec은 항상(Always), 실패 시(OnFailure), 절대 안 함(Never) 값으로 설정 가능한 `restartPolicy` 필드를 가지고 있다.

content/ko/docs/concepts/workloads/pods/pod-overview.md

@@ -26,6 +26,7 @@ card:
 
 * **단일 컨테이너만 동작하는 파드**. "단일 컨테이너 당 한 개의 파드" 모델은 쿠버네티스 사용 사례 중 가장 흔하다. 이 경우, 한 개의 파드가 단일 컨테이너를 감싸고 있다고 생각할 수 있으며, 쿠버네티스는 컨테이너가 아닌 파드를 직접 관리한다고 볼 수 있다.
 * **함께 동작하는 작업이 필요한 다중 컨테이너가 동작하는 파드**. 아마 파드는 강하게 결합되어 있고 리소스 공유가 필요한 다중으로 함께 배치된 컨테이너로 구성되어 있을 것이다. 이렇게 함께 배치되어 설치된 컨테이너는 단일 결합 서비스 단위일 것이다. 한 컨테이너는 공유 볼륨에서 퍼블릭으로 파일들을 옮기고, 동시에 분리되어 있는 "사이드카" 컨테이너는 그 파일들을 업데이트 하거나 복구한다. 파드는 이 컨테이너와 저장소 리소스들을 한 개의 관리 가능한 요소로 묶는다.
+
 각각의 파드는 주어진 애플리케이션에서 단일 인스턴스로 동작하는 것을 말한다. 만약 애플리케이션을 수평적으로 스케일하기를 원하면(더 많은 인스턴스를 실행해서 더 많은 전체 리소스를 제공하는 것), 각 인스턴스 당 한 개씩 다중 파드를 사용해야 한다. 쿠버네티스에서는, 일반적으로 이것을 _복제_ 라고 한다.
 복제된 파드는 일반적으로 워크로드 리소스와 해당 {{< glossary_tooltip text="_컨트롤러_" term_id="controller" >}}에 의해 그룹으로 생성과 관리된다.
 쿠버네티스가 컨트롤러를 사용해서 워크로드의 확장과 복구를 구현하는 방법에 대한 자세한 내용은 [파드와 컨트롤러](#파드와-컨트롤러)를 참고한다.
@@ -48,7 +49,7 @@ card:
 
 #### 저장소
 
-파드는 공유 저장소 집합인 {{< glossary_tooltip text="Volumes" term_id="volume" >}} 을 명시할 수 있다. 파드 내부의 모든 컨테이너는 공유 볼륨에 접근할 수 있고, 그 컨테이너끼리 데이터를 공유하는 것을 허용한다. 또한 볼륨은 컨테이너가 재시작되어야 하는 상황에도 파드 안의 데이터가 영구적으로 유지될 수 있게 한다. 쿠버네티스가 어떻게 파드 안의 공유 저장소를 사용하는지 보려면 [볼륨](/ko/docs/concepts/storage/volumes/)를 참고하길 바란다.
+파드는 공유 저장소 집합인 {{< glossary_tooltip text="볼륨" term_id="volume" >}}을 명시할 수 있다. 파드 내부의 모든 컨테이너는 공유 볼륨에 접근할 수 있고, 그 컨테이너끼리 데이터를 공유하는 것을 허용한다. 또한 볼륨은 컨테이너가 재시작되어야 하는 상황에도 파드 안의 데이터가 영구적으로 유지될 수 있게 한다. 쿠버네티스가 어떻게 파드 안의 공유 저장소를 사용하는지 보려면 [볼륨](/ko/docs/concepts/storage/volumes/)을 참고하길 바란다.
 
 ## 파드 작업
 
@@ -64,13 +65,16 @@ card:
 
 워크로드 리소스를 사용해서 여러 파드를 생성하고 관리할 수 있다. 리소스 컨트롤러는 파드 장애 발생 시 복제, 롤아웃, 자동 복구를 처리한다. 예를 들어, 노드에 장애가 발생하면, 컨트롤러는 해당 노드의 파드는 작동을 멈추고 교체용 파드를 생성한다는 것을 알게 된다. 스케줄러는 교체용 파드를 정상적인 노드에 배치하게 된다.
 
+다음은 하나 이상의 파드를 관리하는 워크로드 리소스의 예이다.
+
 * {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}
 * {{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}}
 * {{< glossary_tooltip text="데몬셋" term_id="daemonset" >}}
 
+
 ## 파드 템플릿
 
-워크로드 리소스에 대한 컨트롤러는 파드 템플릿으로 파드를 생성하고
+{{< glossary_tooltip text="워크로드" term_id="workload" >}} 리소스에 대한 컨트롤러는 파드 템플릿으로 파드를 생성하고
 사용자를 대신해서 이러한 파드를 관리한다.
 
 파드템플릿은 파드를 생성하기 위한 명세이며
@@ -87,6 +91,7 @@ apiVersion: batch/v1
 kind: Job
 metadata:
   name: hello
+spec:
   template:
     # 이것이 파드 템플릿이다.
     spec:
@@ -113,4 +118,3 @@ metadata:
 * 파드의 동작에 대해 더 알아보자.
   * [파드 종료](/ko/docs/concepts/workloads/pods/pod/#파드의-종료)
   * [파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)
-

content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md

@@ -19,9 +19,9 @@ weight: 50
 ### 기능 게이트 활성화
 
 를 참조한다. {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} **와**
-{{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}에 
+{{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}에 대해
-대해 `EvenPodsSpread`
+`EvenPodsSpread` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)가
-[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어야 한다.
+활성화되어야 한다.
 
 ### 노드 레이블
 
@@ -160,6 +160,7 @@ spec:
 - 신규 파드와 같은 네임스페이스를 갖는 파드만이 매칭의 후보가 된다.
 
 - `topologySpreadConstraints[*].topologyKey` 가 없는 노드는 무시된다. 이것은 다음을 의미한다.
+
   1. 이러한 노드에 위치한 파드는 "maxSkew" 계산에 영향을 미치지 않는다. - 위의 예시에서, "node1"은 "zone" 레이블을 가지고 있지 않다고 가정하면, 파드 2개는 무시될 것이고, 이런 이유로 신규 파드는 "zoneA"로 스케줄된다.
   2. 신규 파드는 이런 종류의 노드에 스케줄 될 기회가 없다. - 위의 예시에서, 레이블로 `{zone-typo: zoneC}` 를 가지는 "node5"가 클러스터에 편입한다고 가정하면, 레이블 키에 "zone"이 없기 때문에 무시하게 된다.
 
@@ -191,7 +192,7 @@ spec:
 토폴로지 분배 제약 조건은 다음과 같은 경우에만 파드에 적용된다.
 
 - `.spec.topologySpreadConstraints` 에는 어떠한 제약도 정의되어 있지 않는 경우.
-- 서비스, 레플리케이션 컨트롤러, 레플리카 셋 또는 스테이트풀 셋에 속해있는 경우.
+- 서비스, 레플리케이션컨트롤러(ReplicationController), 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)에 속해있는 경우.
 
 기본 제약 조건은 [스케줄링 프로파일](/docs/reference/scheduling/profiles)에서
 `PodTopologySpread` 플러그인의 일부로 설정할 수 있다.
@@ -234,9 +235,8 @@ profiles:
   단 하나의 파드만 스케줄 될 수 있다.
 
 "EvenPodsSpread" 기능은 다양한 토폴로지 도메인에 파드를 균등하게 분배해서
-고 가용성 또는 비용 절감을 달성할 수 있는 유연한 옵션을 제공한다. 또한 워크로드의 롤링 업데이트와
+고 가용성 또는 비용 절감을 달성할 수 있는 유연한 옵션을 제공한다. 또한 워크로드의 롤링 업데이트와 레플리카의 원활한 스케일링 아웃에 도움이 될 수 있다.
-레플리카의 원활한 스케일링 아웃에 도움이 될 수 있다.
+더 자세한 내용은 [모티베이션(Motivation)](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/895-pod-topology-spread#motivation)를 참조한다.
-더 자세한 내용은 [모티베이션(Motivation)](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-pod-topology-spread.md#motivation)를 참조한다.
 
 ## 알려진 제한사항
 

content/ko/docs/concepts/workloads/pods/pod.md

@@ -5,15 +5,21 @@ weight: 20
 ---
 
 <!-- overview -->
-_파드_ 는 쿠버네티스에서 생성되고 관리될 수 있는 배포 가능한 최소 컴퓨팅 단위이다.
+
+_파드_ 는 쿠버네티스에서 생성되고 관리될 수 있는
+배포 가능한 최소 컴퓨팅 단위이다.
+
 
 
 
 <!-- body -->
 
 ## 파드는 무엇인가?
-_파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로) 하나 이상의(도커 컨테이너 같은) 컨테이너 그룹이다.
+
-이 그룹은 스토리지/네트워크를 공유하고, 해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다.
+_파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로) 하나 이상의(도커 컨테이너 같은)
+{{< glossary_tooltip text="컨테이너" term_id="container" >}} 그룹이다.
+이 그룹은 스토리지/네트워크를 공유하고,
+해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다.
 파드의 콘텐츠들은 항상 함께 배치되고 같이 스케줄되며, 공유 컨텍스트 내에서 구동된다.
 파드는 애플리케이션에 특화된 "논리 호스트"를 모델로 하고 있다.
 이것은 하나 또는 강하게 서로 결합되어 있는 여러 애플리케이션 컨테이너를 포함한다.
@@ -49,7 +55,8 @@ _파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지
 파드가 만들어지고 고유한 ID(UID)가 할당되고,
 재시작 정책에 따라서 종료 또는 삭제될 때 까지 노드에 스케줄된다.
 노드가 종료되면 해당 노드로 스케줄 된 파드는 제한시간이 지나면 삭제되도록 스케줄된다.
-해당 파드(UID로 정의된)는 새로운 노드에 "리스케줄(reschedule)" 되지 않는다. 대신, 동일한 파드로,
+해당 파드(UID로 정의된)는 새로운 노드에 "리스케줄(reschedule)" 되지 않는다.
+대신, 동일한 파드로,
 원한다면 이름도 동일하게, 교체될 수 있지만, 새로운 UID가 부여된다.
 더 자세한 내용은 [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)를 참조한다.
 
@@ -59,6 +66,7 @@ UID를 포함한 해당 파드가 존재하는 한 그것도 존재한다는 것
 동일한 대체품이 만들어 지더라도 관련된 것(예 : 볼륨) 또한 삭제되고 새로 만들어진다.
 
 {{< figure src="/images/docs/pod.svg" title="파드 다이어그램" width="50%" >}}
+
 *파일 풀러(Puller)와 컨테이너 간 공유 스토리지로 퍼시스턴트 볼륨을 사용하는
 웹 서버를 포함하는 멀티 컨테이너 파드.*
 
@@ -70,7 +78,8 @@ UID를 포함한 해당 파드가 존재하는 한 그것도 존재한다는 것
 파드는 그 구성 요소 집합보다 높은 수준의 추상화를 제공함으로써
 애플리케이션 배포 및 관리를 단순화한다.
 파드는 전개 단위, 수평 확장 및 복제를 한다.
-공동 스케줄링, 공유 된 생애주기 (예 : 종료), 조정 된 복제, 자원 공유 및 종속성 관리는
+공동 스케줄링,
+공유된 생애주기(예: 종료), 조정된 복제, 자원 공유 및 종속성 관리는
 파드의 컨테이너에 대해 자동으로 처리된다.
 
 ### 리소스 공유 및 통신
@@ -80,10 +89,12 @@ UID를 포함한 해당 파드가 존재하는 한 그것도 존재한다는 것
 파드의 모든 애플리케이션은 동일한 네트워크 네임스페이스(동일한 IP 및 포트 공간)를 사용하므로
 서로를 찾고 통신하는데 `localhost`를 사용할 수 있다.
 이 때문에 파드의 애플리케이션은 포트 사용을 조정 해야한다.
-각 파드에는 다른 물리적 컴퓨터 및 파드들과 네트워크를 통해 통신할 수 있는 공유 네트워크 공간의 IP 주소가 있다.
+각 파드에는 다른 물리적 컴퓨터 및 파드들과
+네트워크를 통해 통신할 수 있는 공유 네트워크 공간의 IP 주소가 있다.
 
 호스트 이름은 파드 안에있는 애플리케이션 컨테이너의 파드 이름으로 설정된다.
-더 자세한 내용은 [네트워킹의 더 자세한 내용](/docs/concepts/cluster-administration/networking/)을 참조한다.
+더 자세한 내용은
+[네트워킹](/ko/docs/concepts/cluster-administration/networking/) 섹션을 참조한다.
 
 파드는 파드 안의 애플리케이션 컨테이너를 정의하는 것 이외에도 공유 저장 볼륨의 집합을 지정한다.
 볼륨은 컨테이너가 재시작되어도 데이터가 생존할 수 있도록 하고,
@@ -104,14 +115,17 @@ UID를 포함한 해당 파드가 존재하는 한 그것도 존재한다는 것
 일반적으로 하나의 파드는
 동일한 애플리케이션의 여러 인스턴스를 실행하도록 사용하지 않는다.
 
-더 자세한 설명을 보려면 [분산 시스템 툴킷: 복합 컨테이너를 위한 패턴] (https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)을 참조한다.
+더 자세한 설명을 보려면
+[분산 시스템 툴킷: 복합 컨테이너를 위한 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)을
+참조한다.
 
 ## 고려된 대안
 
 _싱글 (도커)컨테이너에서 다중 프로그램을 실행하지 않는 이유는 무엇인가?_
 
 1. 투명도. 인프라에 파드 내의 컨테이너를 표시하면,
-   인프라에서 프로세스 관리와 리소스 모니터링과 같은 기능을 제공할 수 있다.
+   인프라에서 프로세스 관리와 리소스 모니터링과 같은 기능을
+   제공할 수 있다.
    이 기능들은 사용자에게 편의를 제공한다.
 1. 소프트웨어 의존성 분리. 각각의 컨테이너는 독립적으로 버전 관리,
    재빌드, 재배포될 수 있다.
@@ -129,19 +143,18 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하
 
 ## 파드의 내구성 (또는 결핍)
 
-파드는 내구성이 강한 엔터티로 취급하지는 않는다. 파드는 스케줄링 실패,
+파드는 내구성이 강한 엔터티로 취급하지는 않는다. 파드는 스케줄링 실패, 노드 장애 또는 그 밖에 리소스가 부족해서, 또는 노드 정비를 위한 경우와 같이 축출(eviction)되는 상황에서는 살아남을 수 없을 것이다.
-노드 장애 또는 그 밖에 리소스가 부족해서, 또는 노드 정비를 위한 경우와 같이 축출(eviction)되는 상황에서는 살아남을 수 없을 것이다.
 
 일반적으로 사용자는 파드를 직접 만들 필요가 없다.
-싱글톤이라도 대부분 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)와 같은 컨트롤러를 사용한다.
+싱글톤이라도 대부분 [디플로이먼트(Deployment)](/ko/docs/concepts/workloads/controllers/deployment/)와 같은 컨트롤러를 사용한다.
 컨트롤러는 클러스터 범위에서
 복제와 롤아웃 관리 뿐 만 아니라 자가치료 기능도 제공한다.
-[StatefulSet](/ko/docs/concepts/workloads/controllers/statefulset.md)과 같은 컨트롤러는 상태를 저장하는 파드에도
+[스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)과 같은
+컨트롤러는 상태를 저장하는 파드에도
 위와 같은 기능 제공을 할 수 있다.
 
 사용자 지향적으로 선정된 API를 사용하는 것은 [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)와 [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)를 비롯한 클러스터 스케줄링 시스템에서 비교적 일반적이다.
 
-
 파드는 아래와 같은 사항들을 용이하게 하기 위해 노출이 된다:
 
 * 스케줄러 및 컨트롤러 연결 가능
@@ -149,58 +162,45 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하
 * 부트스트랩과 같이 컨트롤러의 생애와 파드의 생애 분리
 * 컨트롤러와 서비스의 분리 &mdash; 파드를 감시하는 엔드 포인트 컨트롤러
 * 클러스터 레벨과 kubelet 레벨 기능의 깔끔한 구성 &mdash; Kubelet은 효과적인 "파드 컨트롤러" 이다.
-* 계획된 삭제 또는 이미지 프리페칭과 같이 파드가 종료되기 전에 교체가 될 것이고,
+* 계획된 삭제 또는 이미지 프리페칭과 같이 파드가 종료되기 전에 교체가 될 것이고, 삭제 전에는 확실히 교체되는 고가용성 애플리케이션.
-삭제 전에는 확실히 교체되는 고가용성 애플리케이션.
 
 ## 파드의 종료
 
-파드는 클러스터의 노드에서 실행 중인 프로세스를 나타내므로 이러한 프로세스가 더 이상 필요하지 않을 때 (KILL 시그널로 강제로 죽여서 정리할 기회를 주지 않는 것과 대조적으로) 정상적으로 종료 되도록 허용하는 것이 중요하다.
+파드는 클러스터의 노드에서 실행 중인 프로세스를 나타내므로, 이러한 프로세스가 더 이상 필요하지 않을 때(KILL 시그널로 강제로 죽여서 정리할 기회를 주지 않는 것과 대조적으로) 정상적으로 종료 되도록 허용하는 것이 중요하다. 사용자는 삭제를 요청할 수 있어야 하며, 프로세스가 종료 될 때 알 수 있어야 할 뿐만 아니라, 삭제가 결국 완료되는 것을 확인할 수 있어야 한다. 사용자가 파드를 삭제하도록 요청하면, 시스템은 파드가 강제로 종료되기 전에 예정된 유예 기간을 기록하고, TERM 시그널이 각 컨테이너의 주 프로세스로 전송된다. 유예 기간이 만료되면, KILL 신호가 해당 프로세스로 전송되고, 파드가 API 서버에서 삭제된다. 프로세스가 종료되기를 기다리는 동안 Kubelet 또는 컨테이너 관리자가 다시 시작되면, 종료가 전체 유예 기간과 함께 재시도된다.
-사용자는 삭제를 요청할 수 있어야 하며, 프로세스가 종료 될 때 알 수 있어야 할 뿐 만 아니라, 삭제가 결국 완료되는 것을 확인 할 수 있어야 한다.
-사용자가 파드를 삭제하도록 요청하면 시스템은 파드가 강제로 종료되기 전에 예정된 유예 기간을 기록하고 TERM 시그널이 각 컨테이너의 주 프로세스로 전송된다.
-유예 기간이 만료되면 KILL 신호가 해당 프로세스로 전송되고 파드가 API 서버에서 삭제된다. 프로세스가 종료되기를 기다리는 동안 Kubelet 또는 컨테이너 관리자가 다시 시작되면 종료가 전체 유예 기간과 함께 재시도된다.
 
 흐름 예시:
 
 1. 사용자가 파드 삭제 명령을 내린다. (기본 유예 기간 30초)
-1. API 서버 안의 파드는 유예 기간에 따라, 시간을 넘은 것(죽은)것으로 간주되는 파드가 업데이트 된다.  
+1. API 서버 안의 파드는 유예 기간에 따라, 시간을 넘은(죽은) 것으로 간주되는 파드가 업데이트된다.
 1. 클라이언트 명령에서 파드는 "Terminating" 이라는 문구를 나타낸다.
 1. (3번 단계와 동시에) Kubelet은 파드가 2번 단계에서 설정된 시간으로 인해 Terminating으로 표시되는 것을 확인하면 파드 종료 단계를 시작한다.
     1. 파드의 컨테이너 중 하나에 [preStop hook](/ko/docs/concepts/containers/container-lifecycle-hooks/#hook-details)이 정의된 경우, 해당 컨테이너 내부에서 실행된다. 유예 기간이 만료된 후에도 `preStop` 훅이 계속 실행 중이면, 유예 기간을 짧게(2초)를 1회 연장해서 2번 단계를 실행한다.
     1. 파드의 프로세스에 TERM 시그널이 전달된다. 파드의 모든 컨테이너가 TERM 시그널을 동시에 받기 때문에 컨테이너의 종료 순서가 중요한 경우에는 `preStop` 훅이 각각 필요할 수 있음을 알아두자. 만약 `preStop` 훅을 완료하는 데 더 오랜 시간이 필요한 경우 `terminationGracePeriodSeconds` 를 수정해야 한다.
-1. (3번 단계와 동시에) 파드는 서비스를 위해 엔드포인트 목록에서 제거되며, 더 이상 레플리케이션 컨트롤러가 실행중인 파드로 고려하지 않는다.
+1. (3번 단계와 동시에) 파드는 서비스를 위해 엔드포인트 목록에서 제거되며, 더 이상 레플리케이션 컨트롤러가 실행 중인 파드로 고려하지 않는다. 느리게 종료되는 파드는 로드밸런서(서비스 프록시와 같은)의 로테이션에서 지워지기 때문에 트래픽을 계속 처리할 수 없다.
-느리게 종료되는 파드는 로드밸런서(서비스 프록시와 같은)의 로테이션에서 지워지기 때문에 트래픽을 계속 처리할 수 없다.
 1. 유예 기간이 만료되면, 파드에서 실행중이던 모든 프로세스가 SIGKILL로 종료된다.
 1. Kubelet은 유예기간 0(즉시 삭제)을 세팅하여 API 서버에서 파드 삭제를 끝낼 것이다. API 서버에서 사라진 파드는 클라이언트에게서 더 이상 보이지 않는다.
 
-기본적으로 모든 삭제는 30초 이내에 끝이난다. `kubectl delete` 명령은 사용자가 기본 설정을 오버라이드 하고 자신이 원하는 값을 설정할 수 있게 해주는 `--grace-period=<seconds>` 옵션을 지원한다. `0`값은 파드를 [강제로 삭제한다](/ko/docs/concepts/workloads/pods/pod/#파드-강제-삭제). kubectl 버전 >= 1.5 에서는, 강제 삭제 수행을 위해서 반드시 `--grace-period=0`와 함께 추가 플래그인 `--force`를 지정해야 한다.
+기본적으로 모든 삭제는 30초 이내에 끝이 난다. `kubectl delete` 명령은 사용자가 기본 설정을 오버라이드하고 자신이 원하는 값을 설정할 수 있게 해주는 `--grace-period=<seconds>` 옵션을 지원한다. `0` 값은 파드를 [강제로 삭제한다](/ko/docs/concepts/workloads/pods/pod/#파드-강제-삭제). 
+kubectl 1.5 버전 이상에서는, 강제 삭제 수행을 위해서 반드시 `--grace-period=0` 와 함께 추가 플래그인 `--force` 를 지정해야 한다.
 
 ### 파드 강제 삭제
 
-파드 강제 삭제는 클러스터 및 etcd에서 즉시 삭제하는 것으로 정의된다. 강제 삭제가 수행되면, API 서버는 kubelet에서 실행중이던 노드에서 파드가 종료되었다는 확인을 기다리지 않는다.
+파드 강제 삭제는 클러스터 및 etcd에서 즉시 삭제하는 것으로 정의된다. 강제 삭제가 수행되면, API 서버는 kubelet에서 실행 중이던 노드에서 파드가 종료되었다는 확인을 기다리지 않는다. API에서 파드를 즉시 제거하므로 동일한 이름으로 새 파드를 만들 수 있다. 노드에서 즉시 종결되도록 설정된 파드에는 강제 삭제되기 전에 짧은 유예 기간이 주어진다.
-API에서 파드를 즉시 제거하므로 동일한 이름으로 새 파드를 만들 수 있다.
-노드에서 즉시 종결되도록 설정된 파드에는 강제 삭제되기 전에 짧은 유예 기간이 주어진다.
-
-강제 삭제는 일부 파드의 경우 잠재적으로 위험 할 수 있으므로 주의해서 수행해야 한다.
-스테이트풀셋 파드의 경우 [스테이트풀셋 파드 삭제](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대한 작업문서를 참조한다.
 
+강제 삭제는 일부 파드의 경우 잠재적으로 위험할 수 있으므로 주의해서 수행해야 한다. 스테이트풀셋 파드의 경우 [스테이트풀셋 파드 삭제](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대한 작업 문서를 참조한다.
 
 ## 파드 컨테이너의 특권(Privileged) 모드
 
-Kubernetes v1.1부터, 파드의 모든 컨테이너는 컨테이너 스펙의 `SecurityContext`의 `privileged` 플래그를 사용하여 특권 모드를 사용할 수 있다. 이것은 네트워크 스택을 조작하고 장치에 액세스하는 것과 같은 Linux 기능을 사용하려는 컨테이너에 유용하다. 컨테이너 내의 프로세스는 컨테이너 외부의 프로세스에서 사용할 수 있는 거의 동일한 권한을 갖는다. 특권 모드를 사용하면 네트워크 및 볼륨 플러그인을 kubelet에 컴파일 할 필요가 없는 별도의 파드로 쉽게 만들 수 있다.
+파드의 모든 컨테이너는 컨테이너 스펙의 [시큐리티 콘텍스트(security context)](/docs/tasks/configure-pod-container/security-context/)의 `privileged` 플래그를 사용하여 특권 모드를 사용할 수 있다. 이것은 네트워크 스택을 조작하고 장치에 액세스하는 것과 같은 리눅스 기능을 사용하려는 컨테이너에 유용하다. 컨테이너 내의 프로세스는 컨테이너 외부의 프로세스에서 사용할 수 있는 거의 동일한 권한을 갖는다. 특권 모드를 사용하면 네트워크 및 볼륨 플러그인을 kubelet에 컴파일할 필요가 없는 별도의 파드로 쉽게 만들 수 있다.
 
-마스터가 Kubernetes v1.1 이상에서 실행 중이고, 노드가 v1.1 보다 낮은 버전을 실행중인 경우 새 권한이 부여 된 파드는 api-server에 의해 승인되지만 시작되지는 않는다. 이것들은 pending 상태가 될 것이다.
+{{< note >}}
-사용자가 `kubectl describe pod FooPodName` 을 호출하면 사용자는 파드가 pending 상태에 있는 이유를 볼 수 있다. describe 명령 출력의 이벤트 테이블은 다음과 같다.
+이와 같은 설정을 위해서는 컨테이너 런타임에서 반드시 특권 컨테이너 개념을 지원해야 한다.
-`Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'`
+{{< /note >}}
-
-마스터가 v1.1보다 낮은 버전에서 실행중인 경우 특권을 갖는 파드를 만들 수 없다. 유저가 특권을 갖는 컨테이너가 있는 파드를 만들려고 하면 다음과 같은 오류가 발생한다.
-`The Pod "FooPodName" is invalid.
-spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'`
 
 ## API 오브젝트
 
-파드는 쿠버네티스 REST API에서 최상위 리소스이다. API 오브젝트에 더 자세한 정보는 아래 내용을 참조한다:
+파드는 쿠버네티스 REST API에서 최상위 리소스이다.
+API 오브젝트에 더 자세한 정보는 아래 내용을 참조한다:
 [파드 API 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core).
 파드 오브젝트에 대한 매니페스트를 생성할때는 지정된 이름이 유효한
-[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)인지 확인해야 한다.
+[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)인지 확인해야 한다.
-
-

content/ko/docs/concepts/workloads/pods/podpreset.md

@@ -1,4 +1,6 @@
 ---
+
+
 title: 파드 프리셋
 content_type: concept
 weight: 50
@@ -25,6 +27,7 @@ weight: 50
 제공하지는 않아도 되도록 한다. 이렇게 하면, 어떤 특정 서비스를 사용할 파드의 파드
 템플릿 작성자는 해당 서비스에 대한 모든 세부 사항을 알 필요가 없다.
 
+
 ## 클러스터에서 파드프리셋 활성화하기 {#enable-pod-preset}
 
 클러스터에서 파드 프리셋을 사용하기 위해서는 다음 사항이 반드시 이행되어야 한다.

content/ko/docs/contribute/_index.md

@@ -47,8 +47,8 @@ card:
 - [kubernetes/website에 기여하기](https://github.com/kubernetes/website/contribute)를 참조하여 좋은 진입점이 되는 이슈를 찾을 수 있습니다.
 - 기존 문서에 대해 [GitHub을 사용해서 풀 리퀘스트 열거나](/docs/contribute/new-content/new-content/#changes-using-github) GitHub에서의 이슈 제기에 대해 자세히 알아봅니다.
 - 정확성과 언어에 대해 다른 쿠버네티스 커뮤니티 맴버의 [풀 리퀘스트 검토](/docs/contribute/review/reviewing-prs/)를 합니다.
-- 쿠버네티스 [컨텐츠](/docs/contribute/style/content-guide/)와 [스타일 가이드](/docs/contribute/style/style-guide/)를 읽고 정보에 대한 코멘트를 남길 수 있습니다.
+- 쿠버네티스 [콘텐츠](/docs/contribute/style/content-guide/)와 [스타일 가이드](/docs/contribute/style/style-guide/)를 읽고 정보에 대한 코멘트를 남길 수 있습니다.
-- [페이지 템플릿 사용](/docs/contribute/style/page-templates/)과 [휴고(Hugo) 단축코드(shortcodes)](/docs/contribute/style/hugo-shortcodes/)를 사용해서 큰 변경을 하는 방법에 대해 배워봅니다.
+- [페이지 템플릿 사용](/docs/contribute/style/page-content-types/)과 [휴고(Hugo) 단축코드(shortcodes)](/docs/contribute/style/hugo-shortcodes/)를 사용해서 큰 변경을 하는 방법에 대해 배워봅니다.
 
 ## 다음 단계
 
@@ -67,12 +67,10 @@ SIG Docs는 여러가지 방법으로 의견을 나누고 있습니다.
   자신을 소개하세요!
 - 더 광범위한 토론이 이루어지고 공식적인 결정이 기록이 되는
   [`kubernetes-sig-docs` 메일링 리스트에 가입](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) 하세요.
-- [주간 SIG Docs 화상 회의](https://github.com/kubernetes/community/tree/master/sig-docs)에 참여하세요. 회의는 항상 `#sig-docs` 에 발표되며 [쿠버네티스 커뮤니티 회의 일정](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles)에 추가됩니다. [줌(Zoon) 클라이언트](https://zoom.us/download)를 다운로드 하거나 전화를 이용하여 전화 접속해야 합니다.
+- [주간 SIG Docs 화상 회의](https://github.com/kubernetes/community/tree/master/sig-docs)에 참여하세요. 회의는 항상 `#sig-docs` 에 발표되며 [쿠버네티스 커뮤니티 회의 일정](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles)에 추가됩니다. [줌(Zoom) 클라이언트](https://zoom.us/download)를 다운로드하거나 전화를 이용하여 전화 접속해야 합니다.
 
 ## 다른 기여 방법들
 
 - [쿠버네티스 커뮤니티 사이트](/community/)를 방문하십시오. 트위터 또는 스택 오버플로우에 참여하고, 현지 쿠버네티스 모임과 이벤트 등에 대해 알아봅니다.
 - [기여자 치트시트](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet)를 읽고 쿠버네티스 기능 개발에 참여합니다.
 - [블로그 게시물 또는 사례 연구](/docs/contribute/new-content/blogs-case-studies/)를 제출합니다.
-
-

content/ko/docs/contribute/localization_ko.md

@@ -132,21 +132,29 @@ weight: 10
 
 ### API 오브젝트 용어 한글화 방침
 
-API 오브젝트 중 `kubectl api-resources` 결과의 `kind`에 해당하는 오브젝트는
+일반적으로 `kubectl api-resources` 결과의 `kind` 에 해당하는 API 오브젝트는
 [국립국어원 외래어 표기법](http://kornorms.korean.go.kr/regltn/regltnView.do?regltn_code=0003#a)에
-따라 한글 표기한다. 예를 들면 다음과 같다.
+따라 한글로 표기하고 영문을 병기한다. 예를 들면 다음과 같다.
+
+API 오브젝트(kind)      | 한글화(외래어 표기 및 영문 병기)
+---                   | ---
+ClusterRoleBinding    | 클러스터롤바인딩(ClusterRoleBinding)
+ConfigMap             | 컨피그맵(ConfigMap)
+Deployment            | 디플로이먼트(Deployment)
+PersistentVolumeClaim | 퍼시스턴트볼륨클레임(PersistentVolumeClaim)
+...                   | ...
+
+`kind` 에 속하는 API 오브젝트 중에서도 일부는 표현의 간결함을 위해 한영병기를 하지 않는 등의 예외가 있으며,
+예외에 대해서는 [한글화 용어집](#한글화-용어집)에 등록된 방식을 준용한다. 예를 들면 다음과 같다.
 
 API 오브젝트(kind)      | 한글화(외래어 표기)
 ---                   | ---
-ClusterRoleBinding    | 클러스터롤바인딩
-ConfigMap             | 컨피그맵
-Deployment            | 디플로이먼트
 Pod                   | 파드
-PersistentVolumeClaim | 퍼시스턴트볼륨클레임
 Service               | 서비스
 ...                   | ...
 
-그 이외의 API 오브젝트는, [한글화 용어집](#한글화-용어집)에 등록된 용어인 경우를 제외하고,
+
+`kind` 에 속하지 않는 API 오브젝트는, [한글화 용어집](#한글화-용어집)에 등록된 용어인 경우를 제외하고,
 모두 원문 그대로 표기한다. 예를 들면 다음과 같다.
 
 API 오브젝트(kind가 아닌 경우) | 한글화(원문 유지)
@@ -162,7 +170,7 @@ PersistentVolumeClaimSpec  | PersistentVolumeClaimSpec
 {{% note %}}
 단, API 오브젝트 한글화 원칙에 예외가 있을 수 있으며, 이 경우에는 가능한
 [한글화 용어집](#한글화-용어집)을 준용한다. (예를 들면, Horizontal Pod Autoscaler
-는 API 오브젝트에 대해 외래어 표기법 적용하지 않고 원문 그대로 표기한다.)
+는 API 오브젝트에 대해 외래어 표기법을 적용하지 않고 원문 그대로 표기한다.)
 {{% /note %}}
 
 {{% note %}}
@@ -239,6 +247,7 @@ Age | 기간 |
 Allocation | 할당량 |
 alphanumeric | 영숫자 |
 Annotation | 어노테이션 |
+APIService | API서비스(APIService) | API 오브젝트인 경우
 App | 앱 |
 Appendix | 부록 |
 Application | 애플리케이션 |
@@ -248,6 +257,7 @@ autoscaler | 오토스케일러 |
 availability zone | 가용성 영역(availability zone) |
 bare pod | 베어(bare) 파드 |
 beta | 베타 |
+Binding | 바인딩(Binding) | API 오브젝트인 경우
 boilerplate | 상용구 |
 Boot | 부트 |
 Build | 빌드 |
@@ -255,31 +265,37 @@ Cache | 캐시 |
 Calico | 캘리코(Calico) |
 canary | 카나리(canary) | 릴리스 방식에 관련한 용어인 경우에 한함
 cascading | 캐스케이딩(cascading) |
+CertificateSigningRequest | CertificateSigningRequest | API 오브젝트인 경우
 character set | 캐릭터 셋 |
 Charts | 차트 |
 checkpoint | 체크포인트 |
 Cilium | 실리움(Cilium) |
 CLI | CLI |
 Cluster | 클러스터 |
+ClusterRole | 클러스터롤(ClusterRole) | API 오브젝트인 경우
+ClusterRoleBinding | 클러스터롤바인딩(ClusterRoleBinding) | API 오브젝트인 경우
 Command Line Tool | 커맨드라인 툴 |
-Config Map | 컨피그 맵 |
+ComponentStatus | 컴포넌트스테이터스(ComponentStatus) | API 오브젝트인 경우
+ConfigMap | 컨피그맵(ConfigMap) | API 오브젝트인 경우
 configuration | 구성, 설정 |
 Connection | 연결 |
 containerized | 컨테이너화 된 |
 Context | 컨텍스트  |
 Control Plane | 컨트롤 플레인 |
 controller | 컨트롤러 |
-Cron Job | 크론 잡 |
+ControllerRevision | 컨트롤러리비전(ControllerRevision) | API 오브젝트인 경우
+cron job | 크론 잡 |
+CronJob | 크론잡(CronJob) | API 오브젝트인 경우
+CSIDriver | CSI드라이버(CSIDriver) | API 오브젝트인 경우
+CSINode | CSI노드(CSINode) | API 오브젝트인 경우
 custom metrics | 사용자 정의 메트릭 |
-Custom resource | 사용자 정의 리소스 |
+custom resource | 사용자 정의 리소스 |
-CustomResourceDefinition | 커스텀 리소스 데피니션 |
+CustomResourceDefinition | 커스텀리소스데피니션(CustomResourceDefinition) | API 오브젝트인 경우
 Daemon | 데몬 |
-Daemon Set | 데몬 셋 |
+DaemonSet | 데몬셋(DaemonSet) | API 오브젝트인 경우
 Dashboard | 대시보드 |
 Data Plane | 데이터 플레인 |
-Default Limit | 기본 상한 |
+Deployment | 디플로이먼트(Deployment) | API 오브젝트인 경우
-Default Request | 기본 요청량 |
-Deployment | 디플로이먼트 |
 deprecated | 사용 중단(deprecated) |
 descriptor | 디스크립터, 식별자 |
 Desired number of pods | 의도한 파드의 수 |
@@ -292,9 +308,11 @@ Docker Swarm | Docker Swarm |
 Downward API | 다운워드(Downward) API |
 draining | 드레이닝(draining) |
 egress | 이그레스, 송신(egress) |
-Endpoint | 엔드포인트 |
+endpoint | 엔드포인트 |
+EndpointSlice | 엔드포인트슬라이스(EndpointSlice) | API 오브젝트인 경우
+Endpoints | 엔드포인트(Endpoints) | API 오브젝트인 경우
 entry point | 진입점 |
-Event | 이벤트 |
+Event | 이벤트(Event) | API 오브젝트인 경우
 evict | 축출하다 |
 eviction | 축출 |
 Exec | Exec |
@@ -321,27 +339,31 @@ Hypervisor | 하이퍼바이저 |
 idempotent | 멱등성 |
 Image | 이미지 |
 Image Pull Secrets | 이미지 풀(Pull) 시크릿 |
-Ingress | 인그레스 |
+Ingress | 인그레스(Ingress) | API 오브젝트인 경우
+IngressClass | 인그레스클래스(IngressClass) | API 오브젝트인 경우
 Init Container | 초기화 컨테이너 |
 Instance group | 인스턴스 그룹 |
 introspection | 인트로스펙션(introspection) |
 Istio | 이스티오(Istio) |
-Job | 잡 |
+Job | 잡(Job) | API 오브젝트인 경우
 kube-proxy | kube-proxy |
 Kubelet | Kubelet |
 Kubernetes | 쿠버네티스 |
 Kube-router | Kube-router |
 label | 레이블 |
+Lease | 리스(Lease) | API 오브젝트인 경우
 lifecycle | 라이프사이클 |
+LimitRange | 리밋레인지(LimitRange) | API 오브젝트인 경우
+limit | 한도(limit) | 리소스의 개수나 용량을 한정하기 위한 수치로 사용된 경우 선택적으로 사용 (API 오브젝트의 속성으로 limit을 사용한 경우는 가능한 영문 유지)
 Linux | 리눅스 |
 load | 부하 |
+LocalSubjectAccessReview | 로컬서브젝트액세스리뷰(LocalSubjectAccessReview) | API 오브젝트인 경우
 Log | 로그 |
 loopback | 루프백(loopback) |
 Lost | Lost | 클레임의 상태에 한함
 Machine | 머신 |
 manifest | 매니페스트 |
 Master | 마스터 |
-max limit/request ratio | 최대 상한/요청량 비율 |
 metadata | 메타데이터 |
 metric | 메트릭 |
 masquerading | 마스커레이딩 |
@@ -349,11 +371,12 @@ Minikube | Minikube |
 Mirror pod | 미러 파드(mirror pod) |
 monitoring | 모니터링 |
 multihomed | 멀티홈드(multihomed) |
+MutatingWebhookConfiguration | MutatingWebhookConfiguration | API 오브젝트인 경우
 naked pod | 네이키드(naked) 파드 |
-Namespace | 네임스페이스 |
+Namespace | 네임스페이스(Namespace) | API 오브젝트인 경우
 netfilter | 넷필터(netfilter) |
-Network Policy | 네트워크 폴리시 |
+NetworkPolicy | 네트워크폴리시(NetworkPolicy) | API 오브젝트인 경우
-Node | 노드 |
+Node | 노드(Node) | API 오브젝트인 경우
 node lease | 노드 리스(lease)
 Object | 오브젝트 |
 Orchestrate | 오케스트레이션하다 |
@@ -361,16 +384,19 @@ Output | 출력 |
 parameter | 파라미터 |
 patch | 패치 |
 Pending | Pending | 파드, 클레임의 상태에 한함
-Persistent Volume | 퍼시스턴트 볼륨 |
+PersistentVolume | 퍼시스턴트볼륨(PersistentVolume) | API 오브젝트인 경우
-Persistent Volume Claim | 퍼시스턴트 볼륨 클레임 |
+PersistentVolumeClaim | 퍼시스턴트볼륨클레임(PersistentVolumeClaim) | API 오브젝트인 경우
 pipeline | 파이프라인 |
 placeholder pod | 플레이스홀더(placeholder) 파드 |
-Pod | 파드 |
+Pod | 파드 | API 오브젝트인 경우에도 표현의 간결함을 위해 한영병기를 하지 않음
 Pod Preset | 파드 프리셋 |
 PodAntiAffinity | 파드안티어피니티(PodAntiAffinity) |
-PodDisruptionBudget | PodDisruptionBudget |
+PodDisruptionBudget | PodDisruptionBudget | API 오브젝트인 경우
+PodSecurityPolicy | 파드시큐리티폴리시(PodSecurityPolicy) | API 오브젝트인 경우
+PodTemplate | 파드템플릿(PodTemplate) | API 오브젝트인 경우
 postfix | 접미사 |
 prefix | 접두사 |
+PriorityClass | 프라이어리티클래스(PriorityClass) | API 오브젝트인 경우
 Privileged | 특권을 가진(privileged) |
 Prometheus | 프로메테우스 |
 proof of concept | 개념 증명 |
@@ -386,29 +412,33 @@ redirect | 리다이렉트(redirect) |
 redirection | 리다이렉션 |
 Registry | 레지스트리 |
 Release | 릴리스 |
-Replica Set | 레플리카 셋 |
+ReplicaSet | 레플리카셋(ReplicaSet) | API 오브젝트인 경우
 replicas | 레플리카 |
-Replication Controller | 레플리케이션 컨트롤러 |
+ReplicationController | 레플리케이션컨트롤러(ReplicationController) | API 오브젝트인 경우
 repository | 리포지터리 |
+request | 요청(request) | 리소스의 개수나 용량에 대한 요청 수치를 표현하기 위해 사용된 경우 선택적으로 사용 (API 오브젝트 속성으로 request를 사용한 경우는 가능한 영문을 유지)
 resource | 리소스 |
-Resource Limit | 리소스 상한 |
+ResourceQuota | 리소스쿼터(ResourceQuota) | API 오브젝트인 경우
-Resource Quota | 리소스 쿼터 |
 return | 반환하다 |
 revision | 리비전 |
-Role | 롤 |
+Role | 롤(Role) | API 오브젝트인 경우
+RoleBinding | 롤바인딩(RoleBinding) | API 오브젝트인 경우
 rollback | 롤백 |
 rolling update | 롤링 업데이트 |
 rollout | 롤아웃 |
 Romana | 로마나(Romana) |
 Running | Running | 파드의 상태에 한함
 runtime | 런타임 |
+RuntimeClass | 런타임클래스(RuntimeClass) | API 오브젝트인 경우
 Scale | 스케일 |
-Secret | 시크릿 |
+Secret | 시크릿(Secret) | API 오브젝트인 경우
 segment | 세그먼트 |
 Selector | 셀렉터 |
 Self-healing | 자가 치유 |
-Service | 서비스 |
+SelfSubjectAccessReview | 셀프서브젝트액세스리뷰(SelfSubjectAccessReview) | API 오브젝트인 경우
-Service Account | 서비스 어카운트 |
+SelfSubjectRulesReview | SelfSubjectRulesReview | API 오브젝트이지만 용어를 구성하는 단어 중 복수형 Rules를 '룰스'로 외래어 표기하는 경우 한국어 독자에게 다소 생경할 수 있어 예외적으로 영문 용어를 사용함
+Service | 서비스 | API 오브젝트인 경우에도 표현의 간결함을 위해 한영병기를 하지 않음
+ServiceAccount | 서비스어카운트(ServiceAccount) | API 오브젝트인 경우
 service discovery | 서비스 디스커버리 |
 service mesh | 서비스 메시 |
 Session | 세션 |
@@ -421,10 +451,11 @@ skew | 차이(skew) |
 snippet | 스니펫(snippet) |
 spec | 명세, 스펙, 사양 |
 specification | 명세 |
-Stateful Set | 스테이트풀 셋 |
+StatefulSet | 스테이트풀셋(StatefulSet) | API 오브젝트인 경우
 stateless | 스테이트리스 |
 Static pod | 스태틱(static) 파드 |
-Storage Class | 스토리지 클래스 |
+StorageClass | 스토리지클래스(StorageClass) | API 오브젝트인 경우
+SubjectAccessReview | 서브젝트액세스리뷰(SubjectAccessReview) | API 오브젝트인 경우
 Sub-Object | 서브-오브젝트 |
 support | 지원 |
 Surge | 증가율 | 롤링업데이트 전략에 한함
@@ -432,6 +463,7 @@ System | 시스템 |
 taint | 테인트(taint) |
 Task | 태스크 |
 Terminated | Terminated | 파드의 상태에 한함
+TokenReview | 토큰리뷰(TokenReview) | API 오브젝트인 경우
 tolerations | 톨러레이션(toleration) |
 Topology spread constraints | 토폴로지 분배 제약 조건 |
 Tools  | 도구 |
@@ -441,9 +473,11 @@ ubuntu | 우분투 |
 use case | 유스케이스 |
 userspace | 유저스페이스(userspace) |
 Utilization | 사용량, 사용률 |
+ValidatingWebhookConfiguration | ValidatingWebhookConfiguration | API 오브젝트인 경우
 verbosity | 로그 상세 레벨(verbosity) |
 virtualization | 가상화 |
 Volume | 볼륨 |
+VolumeAttachment | 볼륨어태치먼트(VolumeAttachment) | API 오브젝트인 경우
 Waiting | Waiting | 파드의 상태에 한함
 Walkthrough | 연습 |
 Weave-net | 위브넷(Weave Net) | Weaveworks 사의 솔루션 공식 명칭은 'Weave Net'이므로 한영병기 시 공식 명칭 사용
@@ -451,5 +485,3 @@ Windows | 윈도우 |
 Worker | 워커 | 노드의 형태에 한함
 Workload | 워크로드 |
 YAML | YAML |
-
-

content/ko/docs/contribute/new-content/open-a-pr.md

@@ -408,7 +408,7 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을
     git rebase -i HEAD~<number_of_commits_in_branch>
     ```
 
-    커밋을 스쿼시하는 것은 일종의 리베이스이다. git의 `-i` 스위치는 리베이스를 대화형으로 할 수 있게 한다. `HEAD~<number_of_commits_in_branch` 는 리베이스를 위해 살펴볼 커밋 수를 나타낸다.
+    커밋을 스쿼시하는 것은 일종의 리베이스이다. git의 `-i` 스위치는 리베이스를 대화형으로 할 수 있게 한다. `HEAD~<number_of_commits_in_branch>` 는 리베이스를 위해 살펴볼 커밋 수를 나타낸다.
 
     출력은 다음과 비슷하다.
 

content/ko/docs/contribute/new-content/overview.md

@@ -19,7 +19,7 @@ weight: 5
 
 - 마크다운(Markdown)으로 쿠버네티스 문서를 작성하고 [Hugo](https://gohugo.io/)를 사용하여 쿠버네티스 사이트를 구축한다.
 - 소스는 [GitHub](https://github.com/kubernetes/website)에 있다. 쿠버네티스 문서는 `/content/ko/docs/` 에서 찾을 수 있다. 일부 참조 문서는 `update-imported-docs/` 디렉터리의 스크립트에서 자동으로 생성된다.
-- [페이지 템플릿](/docs/contribute/style/page-templates/)은 Hugo에서 문서 콘텐츠의 프리젠테이션을 제어한다.
+- [페이지 템플릿](/docs/contribute/style/page-content-types/)은 Hugo에서 문서 콘텐츠의 프리젠테이션을 제어한다.
 - 표준 Hugo 단축코드(shortcode) 이외에도 설명서에서 여러 [사용자 정의 Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 사용하여 콘텐츠 표시를 제어한다.
 - 문서 소스는 `/content/` 에서 여러 언어로 제공된다. 각 언어는 [ISO 639-1 표준](https://www.loc.gov/standards/iso639-2/php/code_list.php)에 의해 결정된 2문자 코드가 있는 자체 폴더가 있다. 예를 들어, 한글 문서의 소스는 `/content/ko/docs/` 에 저장된다.
 - 여러 언어로 문서화에 기여하거나 새로운 번역을 시작하는 방법에 대한 자세한 내용은 [현지화](/ko/docs/contribute/localization_ko/)를 참고한다.

content/ko/docs/contribute/participating.md

@@ -36,7 +36,7 @@ SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다.
 
 ## 역할과 책임
 
-- **모든 사람** 은 쿠버네티스 문서에 기여할 수 있다. 기여시 [CLA에 서명](/docs/contribute/new-content/overview/#sign-the-cla))하고 GitHub 계정을 가지고 있어야 한다.
+- **모든 사람** 은 쿠버네티스 문서에 기여할 수 있다. 기여 시 [CLA에 서명](/docs/contribute/new-content/overview/#sign-the-cla)하고 GitHub 계정을 가지고 있어야 한다.
 - 쿠버네티스 조직의 **멤버** 는 쿠버네티스 프로젝트에 시간과 노력을 투자한 기여자이다. 일반적으로 승인되는 변경이 되는 풀 리퀘스트를 연다. 멤버십 기준은 [커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md)을 참조한다.
 - SIG Docs의 **리뷰어** 는 쿠버네티스 조직의 일원으로
   문서 풀 리퀘스트에 관심을 표명했고, SIG Docs 승인자에
@@ -75,7 +75,7 @@ SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다.
 - [모든 사람](#모든-사람) 하위에 나열된 모든 것
 - 풀 리퀘스트 코멘트에 `/lgtm` 을 사용해서 LGTM(looks good to me) 레이블을 붙일 수 있다.
 - 풀 리퀘스트에 이미 LGTM 과 승인 레이블이 있는 경우에 풀 리퀘스트가 병합되지 않도록 코멘트에 `/hold` 를 사용할 수 있다.
-- 코멘트에 `/assgin` 을 사용해서 풀 리퀘스트에 리뷰어를 배정한다.
+- 코멘트에 `/assign` 을 사용해서 풀 리퀘스트에 리뷰어를 배정한다.
 
 ### 멤버 되기
 
@@ -309,9 +309,6 @@ PR 소유자에게 조언하는데 활용된다.
 
 쿠버네티스 문서화에 기여하는 일에 대한 보다 많은 정보는 다음 문서를 참고한다.
 
-- [신규 컨텐츠 기여하기](/docs/contribute/overview/)
+- [신규 콘텐츠 기여하기](/ko/docs/contribute/new-content/overview/)
-- [컨텐츠 검토하기](/docs/contribute/review/reviewing-prs)
+- [콘텐츠 검토하기](/ko/docs/contribute/review/reviewing-prs/)
-- [문서 스타일 가이드](/docs/contribute/style/)
+- [문서 스타일 가이드](/ko/docs/contribute/style/)
-
-
-

content/ko/docs/contribute/review/reviewing-prs.md

@@ -86,7 +86,7 @@ weight: 10
 
 - 이 PR이 페이지 제목, slug/alias 또는 앵커(anchor) 링크를 변경 또는 제거하는가? 그렇다면, 이 PR의 결과로 끊어진 링크가 있는가? slug를 변경 없이 페이지 제목을 변경하는 등의 다른 옵션이 있는가?
 - PR이 새로운 페이지를 소개하는가? 그렇다면,
-  - 페이지가 올바른 [페이지 템플릿](/docs/contribute/style/page-templates/)과 연관된 Hugo 단축 코드를 사용하는가?
+  - 페이지가 올바른 [페이지 콘텐츠 타입](/docs/contribute/style/page-content-types/)과 연관된 Hugo 단축 코드를 사용하는가?
   - 섹션의 측면 탐색에 페이지가 올바르게 나타나는가?
   - 페이지가 [문서 홈](/ko/docs/home/) 목록에 나타나야 하는가?
 - 변경 사항이 Netlify 미리보기에 표시되는가? 목록, 코드 블록, 표, 메모 및 이미지에 특히 주의한다.

content/ko/docs/contribute/style/write-new-topic.md

@@ -28,9 +28,8 @@ weight: 20
 튜토리얼 | 튜토리얼 페이지는 여러 쿠버네티스의 특징들을 하나로 묶어서 목적을 달성하는 방법을 보여준다. 튜토리얼은 독자들이 페이지를 읽을 때 실제로 할 수 있는 몇 가지 단계의 순서를 제공한다. 또는 관련 코드 일부에 대한 설명을 제공할 수도 있다. 예를 들어 튜토리얼은 코드 샘플의 연습을 제공할 수 있다. 튜토리얼에는 쿠버네티스의 특징에 대한 간략한 설명이 포함될 수 있지만 개별 기능에 대한 자세한 설명은 관련 개념 문서과 연결지어야 한다.
 {{< /table >}}
 
-새 페이지에 대한 템플릿을 사용하자. 각 페이지 타입에 있는
+작성하는 각각의 새 페이지에 대해 [콘텐츠 타입](/docs/contribute/style/page-content-types/)을
-[템플릿](/docs/contribute/style/page-templates/)
+사용하자. 페이지 타입을 사용하면
-은 문서를 작성할 때 사용할 수 있다. 템플릿을 사용하면
 지정된 타입의 문서 간에 일관성을 보장할 수 있다.
 
 ## 제목과 파일 이름 선택
@@ -38,12 +37,12 @@ weight: 20
 검색 엔진에서 찾을 키워드가 있는 제목을 선택하자.
 제목에 있는 단어를 하이픈으로 구분하여 사용하는 파일 이름을 만들자.
 예를 들어
-[HTTP 프록시를 사용하여 쿠버네티스 API에 접근](/docs/tasks/access-kubernetes-api/http-proxy-access-api/)
+[HTTP 프록시를 사용하여 쿠버네티스 API에 접근](/docs/tasks/extend-kubernetes/http-proxy-access-api/)
 이라는 제목의 문서는 `http-proxy-access-api.md`라는 이름의 파일을 가진다.
 "쿠버네티스"가 이미 해당 주제의 URL에 있기 때문에 파일 이름에 "쿠버네티스" 를 넣을 필요가 없다.
 예를 들면 다음과 같다.
 
-       /docs/tasks/access-kubernetes-api/http-proxy-access-api/
+       /docs/tasks/extend-kubernetes/http-proxy-access-api/
 
 ## 전문에 항목 제목 추가
 
@@ -164,6 +163,6 @@ kubectl create -f https://k8s.io/examples/pods/storage/gce-volume.yaml
 
 ## {{% heading "whatsnext" %}}
 
-* [페이지 템플릿 사용](/docs/contribute/page-templates/))에 대해 알아보기.
+* [페이지 콘텐츠 타입 사용](/docs/contribute/style/page-content-types/)에 대해 알아보기.
 * [풀 리퀘스트 작성](/docs/contribute/new-content/open-a-pr/)에 대해 알아보기.
 

content/ko/docs/home/_index.md

@@ -54,8 +54,8 @@ cards:
   description: 이 프로젝트가 처음인 사람이든, 오래 활동한 사람이든 상관없이 누구나 기여할 수 있다.
   button: 문서에 기여하기
   button_path: "/ko/docs/contribute"
-- name: download
+- name: release-notes
-  title: 쿠버네티스 내려받기
+  title: 릴리스 노트
   description: 쿠버네티스를 설치하거나 최신의 버전으로 업그레이드하는 경우, 현재 릴리스 노트를 참고한다.
 - name: about
   title: 문서에 대하여

content/ko/docs/reference/glossary/aggregation-layer.md

@@ -16,4 +16,4 @@ tags:
 
 <!--more-->
 
-{{< glossary_tooltip text="쿠버네티스 API 서버" term_id="kube-apiserver" >}}에서 [추가 API 지원](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)을 구성하였으면, 쿠버네티스 API의 URL 경로를 "요구하는" `APIService` 오브젝트 추가할 수 있다.
+{{< glossary_tooltip text="쿠버네티스 API 서버" term_id="kube-apiserver" >}}에서 [추가 API 지원](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)을 구성하였으면, 쿠버네티스 API의 URL 경로를 "요구하는" `APIService` 오브젝트 추가할 수 있다.

content/ko/docs/reference/glossary/container-env-variables.md

@@ -2,7 +2,7 @@
 title: 컨테이너 환경 변수(Container Environment Variables)
 id: container-env-variables
 date: 2018-04-12
-full_link: /ko/docs/concepts/containers/container-environment-variables/
+full_link: /ko/docs/concepts/containers/container-environment/
 short_description: >
   컨테이너 환경 변수는 파드에서 동작 중인 컨테이너에 유용한 정보를 제공하기 위한 이름=값 쌍이다.
 

content/ko/docs/reference/glossary/customresourcedefinition.md

@@ -2,7 +2,7 @@
 title: 커스텀 리소스 데피니션(CustomResourceDefinition)
 id: CustomResourceDefinition
 date: 2018-04-12
-full_link: /docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/
+full_link: /docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/
 short_description: >
   사용자 정의 서버를 완전히 새로 구축할 필요가 없도록 쿠버네티스 API 서버에 추가할 리소스를 정의하는 사용자 정의 코드.
 

content/ko/docs/reference/glossary/image.md

@@ -10,7 +10,7 @@ aka:
 tags:
 - fundamental
 ---
- {{< glossary_tooltip term_id="container" >}}의 저장된 인스턴스이며, 애플리케이션 구동에 필요한 소프트웨어 집합을 가지고 있다.
+ {{< glossary_tooltip text="컨테이너" term_id="container" >}}의 저장된 인스턴스이며, 애플리케이션 구동에 필요한 소프트웨어 집합을 가지고 있다.
 
 <!--more--> 
 

content/ko/docs/reference/glossary/volume.md

@@ -11,7 +11,7 @@ tags:
 - core-object
 - fundamental
 ---
- 데이터를 포함하고 있는 디렉토리이며, {{< glossary_tooltip term_id="pod" >}}의 {{< glossary_tooltip text="컨테이너" term_id="container" >}}에서 접근 가능하다.
+ 데이터를 포함하고 있는 디렉토리이며, {{< glossary_tooltip text="파드" term_id="pod" >}}의 {{< glossary_tooltip text="컨테이너" term_id="container" >}}에서 접근 가능하다.
 
 <!--more--> 
 

content/ko/docs/reference/kubectl/overview.md

@@ -7,14 +7,13 @@ card:
   weight: 20
 ---
 
-{{% capture overview %}}
+<!-- overview -->
 Kubectl은 쿠버네티스 클러스터를 제어하기 위한 커맨드 라인 도구이다. `kubectl` 은 config 파일을 $HOME/.kube 에서 찾는다. KUBECONFIG 환경 변수를 설정하거나 [`--kubeconfig`](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 플래그를 설정하여 다른 [kubeconfig](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 파일을 지정할 수 있다.
 
 이 개요는 `kubectl` 구문을 다루고, 커맨드 동작을 설명하며, 일반적인 예제를 제공한다. 지원되는 모든 플래그 및 하위 명령을 포함한 각 명령에 대한 자세한 내용은 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 참조 문서를 참고한다. 설치 방법에 대해서는 [kubectl 설치](/ko/docs/tasks/tools/install-kubectl/)를 참고한다.
 
-{{% /capture %}}
 
-{{% capture body %}}
+<!-- body -->
 
 ## 구문
 
@@ -486,10 +485,9 @@ Current user: plugins-user
 
 플러그인에 대한 자세한 내용은 [cli plugin 예제](https://github.com/kubernetes/sample-cli-plugin)를 참고한다.
 
-{{% /capture %}}
 
-{{% capture whatsnext %}}
+## {{% heading "whatsnext" %}}
 
 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 명령을 사용하여 시작한다.
 
-{{% /capture %}}
+

content/ko/docs/reference/using-api/api-overview.md

@@ -83,7 +83,7 @@ API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다.
 [사용자 정의 리소스](/docs/concepts/api-extension/custom-resources/)로 API를 확장하는 경우에는 다음 두 종류의 경로가 지원된다.
 
  - 기본적인 CRUD 요구에는
-   [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)
+   [커스텀리소스데피니션(CustomResourceDefinition)](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
  - 쿠버네티스 API의 의미론적 전체 집합으로 사용자만의 Apiserver를 구현하려는 경우에는 [aggregator](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)
 
 

content/ko/docs/reference/using-api/client-libraries.md

@@ -47,6 +47,7 @@ Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery
 | Go                   | [github.com/ericchiang/k8s](https://github.com/ericchiang/k8s) |
 | Java (OSGi)          | [bitbucket.org/amdatulabs/amdatu-kubernetes](https://bitbucket.org/amdatulabs/amdatu-kubernetes) |
 | Java (Fabric8, OSGi) | [github.com/fabric8io/kubernetes-client](https://github.com/fabric8io/kubernetes-client) |
+| Java                 | [github.com/manusa/yakc](https://github.com/manusa/yakc) |
 | Lisp                 | [github.com/brendandburns/cl-k8s](https://github.com/brendandburns/cl-k8s) |
 | Lisp                 | [github.com/xh4/cube](https://github.com/xh4/cube) |
 | Node.js (TypeScript) | [github.com/Goyoo/node-k8s-client](https://github.com/Goyoo/node-k8s-client) |

content/ko/docs/setup/best-practices/certificates.md

@@ -29,7 +29,7 @@ weight: 40
 * [front-proxy][proxy]를 위한 클라이언트와 서버 인증서
 
 {{< note >}}
-`front-proxy` 인증서는 kube-proxy에서 [API 서버 확장](/docs/tasks/access-kubernetes-api/setup-extension-api-server/)을 지원할 때만 kube-proxy에서 필요하다.
+`front-proxy` 인증서는 kube-proxy에서 [API 서버 확장](/docs/tasks/extend-kubernetes/setup-extension-api-server/)을 지원할 때만 kube-proxy에서 필요하다.
 {{< /note >}}
 
 etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다.
@@ -160,6 +160,6 @@ KUBECONFIG=<filename> kubectl config use-context default-system
 
 [usage]: https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage
 [kubeadm]: /docs/reference/setup-tools/kubeadm/kubeadm/
-[proxy]: /docs/tasks/access-kubernetes-api/configure-aggregation-layer/
+[proxy]: /docs/tasks/extend-kubernetes/configure-aggregation-layer/
 
 

content/ko/docs/setup/learning-environment/minikube.md

@@ -204,8 +204,8 @@ https_proxy=<my proxy> minikube start --docker-env http_proxy=<my proxy> --docke
 ```
 불행하게도, 환경 변수 설정만으로는 되지 않는다.
 
-Minikube는 또한 "minikube" 컨텍스트를 생성하고 이를 kubectl의 기본값으로 설정한다.
+Minikube는 또한 "minikube" 콘텍스트를 생성하고 이를 kubectl의 기본값으로 설정한다.
-이 컨텍스트로 돌아오려면, 다음의 코멘드를 입력한다. `kubectl config use-context minikube`.
+이 콘텍스트로 돌아오려면, 다음의 코멘드를 입력한다. `kubectl config use-context minikube`.
 {{< /note >}}
 
 #### 쿠버네티스 버전 지정하기
@@ -357,27 +357,34 @@ Minikube는 사용자가 쿠버네티스 컴포넌트를 다양한 값으로 설
 ### 클러스터 중지
 `minikube stop` 명령어는 클러스터를 중지하는데 사용할 수 있다.
 이 명령어는 Minikube 가상 머신을 종료하지만, 모든 클러스터 상태와 데이터를 보존한다.
-클러스터를 다시 시작하면 이전의 상태로 돌려줍니다. 
+클러스터를 다시 시작하면 이전의 상태로 돌려준다.
 
 ### 클러스터 삭제
 `minikube delete` 명령은 클러스터를 삭제하는데 사용할 수 있다.
 이 명령어는 Minikube 가상 머신을 종료하고 삭제한다. 어떤 데이터나 상태도 보존되지 않다.
 
 ### Minikube 업그레이드
-macOS를 사용하는 경우 기존에 설치된 Minikube를 업그레이드하려면 [Minikube 업그레이드](https://minikube.sigs.k8s.io/docs/start/macos/#upgrading-minikube)를 참조한다.
+macOS를 사용하고 있고 [Brew 패키지 관리자](https://brew.sh/)가 설치되어 있다면 다음과 같이 실행한다.
+
+```shell
+brew update
+brew upgrade minikube
+```
 
 ## 클러스터와 상호 작용하기
 
 ### Kubectl
 
-`minikube start` 명령어는 Minikube로 부르는 [kubectl 컨텍스트](/docs/reference/generated/kubectl/kubectl-commands/#-em-set-context-em-)를 생성한다.
+`minikube start` 명령어는 Minikube로 부르는 [kubectl 콘텍스트](/docs/reference/generated/kubectl/kubectl-commands/#-em-set-context-em-)를 생성한다.
-이 컨텍스트는 Minikube 클러스터와 통신하는 설정을 포함한다.
+이 콘텍스트는 Minikube 클러스터와 통신하는 설정을 포함한다.
 
-Minikube는 이 컨텍스트를 자동적으로 기본으로 설정한다. 만약 미래에 이것을 바꾸고 싶다면 
+Minikube는 이 콘텍스트를 자동적으로 기본으로 설정한다. 만약 미래에 이것을 바꾸고 싶다면 다음을 실행하자.
 
-`kubectl config use-context minikube`을 실행하자.
+`kubectl config use-context minikube`
 
-혹은 `kubectl get pods --context=minikube`처럼 코멘드를 실행할때마다 매번 컨텍스트를 전달한다.
+혹은 다음과 같이 커맨드를 실행할 때마다 매번 콘텍스트를 전달한다.
+
+`kubectl get pods --context=minikube`
 
 ### 대시보드
 

content/ko/docs/setup/release/notes.md

@@ -2,7 +2,7 @@
 title: v1.18 릴리스 노트
 weight: 10
 card:
-  name: 다운로드
+  name: release-notes
   weight: 20
   anchors:
   - anchor: "#"

content/ko/docs/tasks/_index.md

@@ -59,7 +59,7 @@ content_type: concept
 
 ## 스테이트풀 애플리케이션 관리하기
 
-스테이트풀 셋의 스케일링, 삭제하기, 디버깅을 포함하는 스테이트풀 애플리케이션 관리를 위한 일반적인 태스크를 수행한다.
+스테이트풀셋(StatefulSet)의 스케일링, 삭제하기, 디버깅을 포함하는 스테이트풀 애플리케이션 관리를 위한 일반적인 태스크를 수행한다.
 
 ## 클러스터 데몬
 

content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md

@@ -6,7 +6,7 @@ weight: 110
 
 <!-- overview -->
 
-이 페이지에서는 동일한 파드(Pod)에서 실행 중인 두 개의 컨테이너 간에 통신할 때에, 어떻게 볼륨(Volume)을 이용하는지
+이 페이지에서는 동일한 파드에서 실행 중인 두 개의 컨테이너 간에 통신할 때에, 어떻게 볼륨을 이용하는지
 살펴본다. 컨테이너 간에 [프로세스 네임스페이스 공유하기](/docs/tasks/configure-pod-container/share-process-namespace/)를 통해 통신할 수 있는 방법을 참고하자.
 
 

content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md

@@ -26,7 +26,12 @@ card:
 ## {{% heading "prerequisites" %}}
 
 
-{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+{{< include "task-tutorial-prereqs.md" >}}
+
+{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}이 설치되었는지 확인하려면,
+`kubectl version --client`을 실행한다. kubectl 버전은 클러스터의 API 서버 버전과
+[마이너 버전 하나 차이 이내](/ko/docs/setup/release/version-skew-policy/#kubectl)여야
+한다.
 
 
 

content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md

@@ -61,7 +61,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
 
 ## 컨테이너화 된 애플리케이션 배포
 
-대시보드를 이용하여 컨테이너화 된 애플리케이션을 디플로이먼트와 간단한 마법사를 통한 선택적인 서비스(Service) 로 생성하고 배포할 수 있다. 애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML, JSON 파일을 업로드 할 수 있다.
+대시보드를 이용하여 컨테이너화 된 애플리케이션을 디플로이먼트와 간단한 마법사를 통한 선택적인 서비스로 생성하고 배포할 수 있다. 애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML, JSON 파일을 업로드 할 수 있다.
 
 시작하는 페이지의 상위 오른쪽 코너에 있는 **CREATE** 버튼을 클릭한다.
 
@@ -69,7 +69,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
 
 배포 마법사는 다음 정보를 제공한다.
 
-- **앱 이름** (필수): 애플리케이션 이름. [레이블](/ko/docs/concepts/overview/working-with-objects/labels/) 이름은 배포할 모든 디플로이먼트와 서비스(Service)에 추가되어야 한다.
+- **앱 이름** (필수): 애플리케이션 이름. [레이블](/ko/docs/concepts/overview/working-with-objects/labels/) 이름은 배포할 모든 디플로이먼트와 서비스에 추가되어야 한다.
 
   애플리케이션 이름은 선택된 쿠버네티스 [네임스페이스](/docs/tasks/administer-cluster/namespaces/) 안에서 유일해야 한다. 소문자로 시작해야하며, 소문자 또는 숫자로 끝나고, 소문자, 숫자 및 대쉬(-)만을 포함해야한다. 24 문자만을 제한한다. 처음과 끝의 스페이스는 무시된다.
 
@@ -79,17 +79,21 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
 
   클러스터에 의도한 파드의 수를 유지하기 위해서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)가 생성될 것이다.
 
-- **서비스(Service)** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스(Service)](/ko/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다. 외부 서비스들을 위해, 한개 또는 여러 개의 포트들을 열어 둘 필요가 있다. [이 곳](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/) 내용을 참고한다.
+- **서비스** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스](/ko/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다.
 
-  클러스터 내부에서만 보고 싶은 어떤 서비스(Serivce)들이 있을 것인다. 이를 내부 서비스라고 한다.
+  {{< note >}}
+  외부 서비스들을 위해, 한 개 또는 여러 개의 포트를 열어 둘 필요가 있다.
+  {{< /note >}}
 
-  서비스(Service) 타입과는 무관하게, 서비스(Service) 생성을 선택해서 컨테이너의 (들어오는 패킷의) 포트를 리슨한다면, 두 개의 포트를 정의해야 한다. 서비스(Service)는 컨테이너가 바라보는 타겟 포트와 (들어오는 패킷의) 맵핑하는 포트가 만들어져야 할 것이다. 서비스(Service)는 배포된 파드에 라우팅 될 것이다. 지원하는 프로토콜은 TCP와 UDP이다. 서비스(Service)가 이용하는 내부 DNS 이름은 애플리케이션 이름으로 지정한 값이 될 것이다.
+  클러스터 내부에서만 보고 싶은 어떤 서비스들이 있을 것이다. 이를 내부 서비스라고 한다.
+
+  서비스 타입과는 무관하게, 서비스 생성을 선택해서 컨테이너의 (들어오는 패킷의) 포트를 리슨한다면, 두 개의 포트를 정의해야 한다. 서비스는 컨테이너가 바라보는 타겟 포트와 (들어오는 패킷의) 맵핑하는 포트가 만들어져야 할 것이다. 서비스는 배포된 파드에 라우팅 될 것이다. 지원하는 프로토콜은 TCP와 UDP이다. 서비스가 이용하는 내부 DNS 이름은 애플리케이션 이름으로 지정한 값이 될 것이다.
 
 만약 필요하다면, 더 많은 세팅을 지정할 수 있는 **자세한 옵션 보기** 섹션에서 확장할 수 있다.
 
 - **설명**: 입력하는 텍스트값은 디플로이먼트에 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/) 으로 추가될 것이고, 애플리케이션의 세부사항에 표시될 것이다.
 
-- **레이블**: 애플리케이션에 사용되는 기본적인 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)은 애플리케이션 이름과 버전이다. 릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스(Service), 그리고 파드를 생성할 때 추가적으로 정의할 수 있다.
+- **레이블**: 애플리케이션에 사용되는 기본적인 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)은 애플리케이션 이름과 버전이다. 릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스, 그리고 파드를 생성할 때 추가적으로 정의할 수 있다.
 
   예를 들면:
 
@@ -119,7 +123,7 @@ track=stable
 
 - **특권을 가진(privileged) 상태로 실행**: 다음 세팅은 호스트에서 루트 권한을 가진 프로세스들이 [특권을 가진 컨테이너](/docs/user-guide/pods/#privileged-mode-for-pod-containers)의 프로세스들과 동등한 지 아닌지 정의한다. 특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다.
 
-- **환경 변수**: 쿠버네티스 서비스(Service)를 [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다. 환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다. 애플리케이션들이 서비스(Service)를 찾는데 사용된다. 값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다.
+- **환경 변수**: 쿠버네티스 서비스를 [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다. 환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다. 애플리케이션들이 서비스를 찾는데 사용된다. 값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다.
 
 ### YAML 또는 JSON 파일 업로드
 
@@ -140,12 +144,12 @@ track=stable
 클러스터와 네임스페이스 관리자에게 대시보드는 노드, 네임스페이스 그리고 퍼시스턴트 볼륨과 세부사항들이 보여진다. 노드는 모든 노드를 통틀어 CPU와 메모리 사용량을 보여준다. 세부사항은 각 노드들에 대한 사용량, 사양, 상태, 할당된 리소스, 이벤트 그리고 노드에서 돌아가는 파드를 보여준다.
 
 #### 워크로드
-선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. 애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카 셋, 스테이트풀 셋 등)를 보여주고 각각의 워크로드 종류는 따로 보여진다. 리스트는 예를 들어 레플리카 셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 워크로드에 대한 실용적인 정보를 요약한다.
+선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. 애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카 셋, 스테이트풀셋(StatefulSet) 등)를 보여주고 각각의 워크로드 종류는 따로 보여진다. 리스트는 예를 들어 레플리카 셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 워크로드에 대한 실용적인 정보를 요약한다.
 
 워크로드에 대한 세부적인 것들은 상태와 사양 정보, 오프젝트들 간의 관계를 보여준다. 예를 들어, 레플리카 셋으로 관리하는 파드들 또는 새로운 레플리카 셋과 디플로이먼트를 위한 Horizontal Pod Autoscalers 이다.
 
-#### 서비스(Service)
+#### 서비스
-외부로 노출되는 서비스들과 클러스터 내에 발견되는 서비스들을 허용하는 쿠버네티스 리소스들을 보여준다. 이러한 이유로 서비스(Service)와 인그레스는 클러스터간의 연결을 위한 내부 엔드포인트들과 외부 사용자를 위한 외부 엔드포인트들에 의해 타게팅된 파드들을 보여준다.
+외부로 노출되는 서비스들과 클러스터 내에 발견되는 서비스들을 허용하는 쿠버네티스 리소스들을 보여준다. 이러한 이유로 서비스와 인그레스는 클러스터간의 연결을 위한 내부 엔드포인트들과 외부 사용자를 위한 외부 엔드포인트들에 의해 타게팅된 파드들을 보여준다.
 
 #### 스토리지
 스토리지는 애플리케이션이 데이터를 저장하기 위해 사용하는 퍼시턴트 볼륨 클레임 리소스들을 보여준다.

content/ko/docs/tasks/administer-cluster/change-default-storage-class.md

@@ -0,0 +1,101 @@
+---
+title: 기본 스토리지클래스(StorageClass) 변경하기
+content_type: task
+---
+
+<!-- overview -->
+이 페이지는 특별한 요구사항이 없는 퍼시스턴트볼륨클레임(PersistentVolumeClaim)의 볼륨을 프로비저닝 
+하는데 사용되는 기본 스토리지 클래스를 변경하는 방법을 보여준다.
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+<!-- steps -->
+
+## 왜 기본 스토리지 클래스를 변경하는가?
+
+설치 방법에 따라, 사용자의 쿠버네티스 클러스터는 기본으로 표시된 기존 
+스토리지클래스와 함께 배포될 수 있다. 이 기본 스토리지클래스는 특정 
+스토리지 클래스가 필요하지 않은 퍼시스턴트볼륨클레임에 대해 스토리지를 
+동적으로 프로비저닝 하기 위해 사용된다.
+더 자세한 내용은 [퍼시스턴트볼륨클레임 문서](/ko/docs/concepts/storage/persistent-volumes/#class-1)를
+보자.
+
+미리 설치된 기본 스토리지클래스가 사용자의 예상되는 워크로드에 적합하지 
+않을수도 있다. 예를 들어, 너무 가격이 높은 스토리지를 프로비저닝 해야할 
+수도 있다. 이런 경우에, 기본 스토리지 클래스를 변경하거나 완전히 비활성화 
+하여 스토리지의 동적 프로비저닝을 방지할 수 있다.
+
+단순하게 기본 스토리지클래스를 삭제하는 경우, 사용자의 클러스터에서 구동중인 
+애드온 매니저에 의해 자동으로 다시 생성될 수 있으므로 정상적으로 삭제가 되지 않을 수도 있다. 애드온 관리자 
+및 개별 애드온을 비활성화 하는 방법에 대한 자세한 내용은 설치 문서를 참조하자. 
+
+## 기본 스토리지클래스 변경하기
+
+1. 사용자의 클러스터에 있는 스토리지클래스 목록을 조회한다.
+
+    ```bash
+    kubectl get storageclass
+    ```
+
+	결과는 아래와 유사하다.
+
+    ```bash
+    NAME                 PROVISIONER               AGE
+    standard (default)   kubernetes.io/gce-pd      1d
+    gold                 kubernetes.io/gce-pd      1d
+    ```
+
+	기본 스토리지클래스는 `(default)` 로 표시되어 있다.
+
+1. 기본 스토리지클래스를 기본값이 아닌 것으로 표시한다.
+
+      기본 스토리지클래스에는 
+      `storageclass.kubernetes.io/is-default-class` 의 값이 `true` 로 설정되어 있다.
+      다른 값이거나 어노테이션이 없을 경우 `false` 로 처리된다.
+
+      스토리지클래스를 기본값이 아닌 것으로 표시하려면, 그 값을 `false` 로 변경해야 한다.
+
+      ```bash
+      kubectl patch storageclass standard -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
+      ```
+
+      여기서 `standard` 는 사용자가 선택한 스토리지클래스의 이름이다.
+
+1. 스토리지클래스를 기본값으로 표시한다.
+
+      이전 과정과 유사하게, 어노테이션을 추가/설정 해야 한다.
+      `storageclass.kubernetes.io/is-default-class=true`.
+
+      ```bash
+      kubectl patch storageclass gold -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
+      ```
+
+      최대 1개의 스토리지클래스를 기본값으로 표시할 수 있다는 것을 알아두자. 만약
+	  2개 이상이 기본값으로 표시되면, 명시적으로 `storageClassName` 가 지정되지 않은 `PersistentVolumeClaim` 은 생성될 수 없다.
+
+1. 사용자가 선택한 스토리지클래스가 기본값으로 되어있는지 확인한다.
+
+      ```bash
+      kubectl get storageclass
+      ```
+
+	  결과는 아래와 유사하다.
+
+      ```bash
+      NAME             PROVISIONER               AGE
+      standard         kubernetes.io/gce-pd      1d
+      gold (default)   kubernetes.io/gce-pd      1d
+      ```
+
+
+
+## {{% heading "whatsnext" %}}
+
+* [퍼시스턴트볼륨(PersistentVolume)](/ko/docs/concepts/storage/persistent-volumes/)에 대해 더 보기.

content/ko/docs/tasks/administer-cluster/coredns.md

@@ -0,0 +1,98 @@
+---
+title: 서비스 디스커버리를 위해 CoreDNS 사용하기
+min-kubernetes-server-version: v1.9
+content_type: task
+---
+
+<!-- overview -->
+이 페이지는 CoreDNS 업그레이드 프로세스와 kube-dns 대신 CoreDNS를 설치하는 방법을 보여준다.
+
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+<!-- steps -->
+
+## CoreDNS 소개
+
+[CoreDNS](https://coredns.io)는 쿠버네티스 클러스터의 DNS 역할을 수행할 수 있는, 유연하고 확장 가능한 DNS 서버이다.
+쿠버네티스와 동일하게, CoreDNS 프로젝트도 {{< glossary_tooltip text="CNCF" term_id="cncf" >}}가 관리한다.
+
+사용자는 기존 디플로이먼트인 kube-dns를 교체하거나, 클러스터를 배포하고 업그레이드하는 
+kubeadm과 같은 툴을 사용하여 클러스터 안의 kube-dns 대신 CoreDNS를 사용할 수 있다.
+
+## CoreDNS 설치
+
+Kube-dns의 배포나 교체에 관한 매뉴얼은 [CoreDNS GitHub 프로젝트](https://github.com/coredns/deployment/tree/master/kubernetes)에
+있는 문서를 확인하자.
+
+## CoreDNS로 이관하기
+
+### Kubeadm을 사용해 기존 클러스터 업그레이드하기
+
+쿠버네티스 버전 1.10 이상에서, `kube-dns` 를 사용하는 클러스터를 업그레이드하기 위하여
+`kubeadm` 을 사용할 때 CoreDNS로 이동할 수도 있다. 이 경우, `kubeadm` 은
+`kube-dns` 컨피그맵(ConfigMap)을 기반으로 패더레이션, 스텁 도메인(stub domain), 업스트림 네임 서버의
+설정을 유지하며 CoreDNS 설정("Corefile")을 생성한다.
+
+만약 kube-dns에서 CoreDNS로 이동하는 경우, 업그레이드 과정에서 기능 게이트의 `CoreDNS` 값을 `true` 로 설정해야 한다.
+예를 들어, `v1.11.0` 로 업그레이드 하는 경우는 다음과 같다.
+```
+kubeadm upgrade apply v1.11.0 --feature-gates=CoreDNS=true
+```
+
+쿠버네티스 1.13 이상에서 기능 게이트의 `CoreDNS` 항목은 제거되었으며, CoreDNS가 기본적으로 사용된다.
+업그레이드된 클러스터에서 kube-dns를 사용하려는 경우, [여기](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)에 
+설명된 지침 가이드를 참고하자.
+
+1.11 미만 버전일 경우 업그레이드 과정에서 만들어진 파일이 Corefile을 **덮어쓴다**.
+**만약 컨피그맵을 사용자 정의한 경우, 기존의 컨피그맵을 저장해야 한다.** 새 컨피그맵이
+시작된 후에 변경 사항을 다시 적용해야 할 수도 있다.
+
+만약 쿠버네티스 1.11 이상 버전에서 CoreDNS를 사용하는 경우, 업그레이드 과정에서,
+기존의 Corefile이 유지된다.
+
+
+### Kubeadm을 사용해 CoreDNS가 아닌 kube-dns 설치하기
+
+{{< note >}}
+쿠버네티스 1.11 버전에서, CoreDNS는 GA(General Availability) 되었으며,
+기본적으로 설치된다.
+{{< /note >}}
+
+{{< warning >}}
+쿠버네티스 1.18 버전에서, kubeadm을 통한 kube-dns는 사용 중단되었으며, 향후 버전에서 제거될 예정이다.
+{{< /warning >}}
+
+1.13 보다 이전 버전에서 kube-dns를 설치하는경우, 기능 게이트의 `CoreDNS` 
+값을 `false` 로 변경해야 한다.
+
+```
+kubeadm init --feature-gates=CoreDNS=false
+```
+
+1.13 이후 버전에서는, [여기](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)에 설명된 지침 가이드를 참고하자.
+
+## CoreDNS 업그레이드하기
+
+CoreDNS는 쿠버네티스 1.9 버전부터 사용할 수 있다.
+쿠버네티스와 함께 제공되는 CoreDNS의 버전과 CoreDNS의 변경 사항은 [여기](https://github.com/coredns/deployment/blob/master/kubernetes/CoreDNS-k8s_version.md)에서 확인할 수 있다.
+
+CoreDNS는 사용자 정의 이미지를 사용하거나 CoreDNS만 업그레이드 하려는 경우에 수동으로 업그레이드할 수 있다.
+업그레이드를 원활하게 수행하는 데 유용한 [가이드라인 및 연습](https://github.com/coredns/deployment/blob/master/kubernetes/Upgrading_CoreDNS.md)을 참고하자.
+
+## CoreDNS 튜닝하기
+
+리소스 활용이 중요한 경우, CoreDNS 구성을 조정하는 것이 유용할 수 있다. 
+더 자세한 내용은 [CoreDNS 스케일링에 대한 설명서](https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md)를 확인하자.
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+`Corefile` 을 수정하여 kube-dns 보다 더 많은 유스케이스를 지원하도록 
+[CoreDNS](https://coredns.io)를 구성할 수 있다.
+더 자세한 내용은 [CoreDNS 웹사이트](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/)을 확인하자.

content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md

@@ -241,4 +241,8 @@ CSR에는 인증서 이름, 도메인 및 IP가 포함되지만, 용도를 지
 [cert-cas]: /ko/docs/setup/best-practices/certificates/#단일-루트-ca
 [cert-table]: /ko/docs/setup/best-practices/certificates/#모든-인증서
 
+## 인증 기관(CA) 순환(rotation) {#certificate-authority-rotation}
 
+Kubeadm은 CA 인증서의 순환이나 교체 기능을 기본적으로 지원하지 않는다.
+
+CA의 수동 순환이나 교체에 대한 보다 상세한 정보는 [CA 인증서 수동 순환](/docs/tasks/tls/manual-rotation-of-ca-certificates/) 문서를 참조한다.

content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md

@@ -294,6 +294,7 @@ sudo kubeadm upgrade apply
 kubelet을 다시 시작한다.
 
 ```shell
+sudo systemctl daemon-reload
 sudo systemctl restart kubelet
 ```
 
@@ -372,6 +373,7 @@ sudo systemctl restart kubelet
 -  kubelet을 다시 시작한다.
 
     ```shell
+    sudo systemctl daemon-reload
     sudo systemctl restart kubelet
     ```
 

content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md

@@ -199,3 +199,5 @@ kubectl delete namespace default-mem-example
 * [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/)
 
 
+
+

content/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md

@@ -136,3 +136,8 @@ kubectl delete namespace quota-pod-example
 * [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/)
 
 
+
+
+
+
+

content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md

@@ -1,5 +1,4 @@
 ---
-reviewers:
 title: 네트워크 폴리시로 캘리코(Calico) 사용하기
 content_type: task
 weight: 10
@@ -52,4 +51,3 @@ Kubeadm을 이용해서 15분 이내에 지역 단일 호스트 캘리코 클러
 클러스터가 동작하면, 쿠버네티스 네트워크 폴리시(NetworkPolicy)를 시도하기 위해
 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
 
-

content/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md

@@ -1,10 +1,11 @@
 ---
-reviewers:
 title: 네트워크 폴리시로 큐브 라우터(Kube-router) 사용하기
 content_type: task
 weight: 30
 ---
 
+
+
 <!-- overview -->
 이 페이지는 네트워크 폴리시(NetworkPolicy)로 [큐브 라우터(Kube-router)](https://github.com/cloudnativelabs/kube-router)를 사용하는 방법을 살펴본다.
 

content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md

@@ -1,10 +1,11 @@
 ---
-reviewers:
 title: 네트워크 폴리시로 로마나(Romana)
 content_type: task
 weight: 40
 ---
 
+
+
 <!-- overview -->
 
 이 페이지는 네트워크 폴리시(NetworkPolicy)로 로마나(Romana)를 사용하는 방법을 살펴본다.

content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md

@@ -1,5 +1,4 @@
 ---
-reviewers:
 title: 네트워크 폴리시로 위브넷(Weave Net) 사용하기
 content_type: task
 weight: 50

content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md

@@ -25,7 +25,8 @@ weight: 10
 서비스 실행이 필요하다. 이미 실행중인 metrics-server가 있다면
 다음 단계를 건너뛸 수 있다.
 
-Minikube를 사용 중이라면, 다음 명령어를 실행해 metric-server를 활성화 할 수 있다.
+Minikube를 사용 중이라면, 다음 명령어를 실행해 metric-server를 
+활성화할 수 있다.
 
 ```shell
 minikube addons enable metrics-server
@@ -52,7 +53,8 @@ v1beta1.metrics.k8s.io
 
 ## 네임스페이스 생성
 
-이 예제에서 생성할 자원과 클러스터 내 나머지를 분리하기 위해 네임스페이스를 생성한다.
+이 예제에서 생성할 자원과 클러스터 내 나머지를 분리하기 위해 
+네임스페이스를 생성한다.
 
 ```shell
 kubectl create namespace mem-example
@@ -111,7 +113,8 @@ kubectl top pod memory-demo --namespace=mem-example
 ```
 
 출력은 파드가 약 150 MiB 해당하는 약 162,900,000 바이트 메모리를 사용하는 것을 보여준다.
-이는 파드의 100 MiB 요청 보다 많으나 파드의 200 MiB 상한보다는 적다.
+이는 파드의 100 MiB 요청 보다 많으나 
+파드의 200 MiB 상한보다는 적다.
 
 ```
 NAME                        CPU(cores)   MEMORY(bytes)
@@ -138,7 +141,7 @@ kubectl delete pod memory-demo --namespace=mem-example
 
 {{< codenew file="pods/resource/memory-request-limit-2.yaml" >}}
 
-구성 파일의 'args' 섹션에서 컨테이너가
+구성 파일의 `args` 섹션에서 컨테이너가
 100 MiB 상한을 훨씬 초과하는 250 MiB의 메모리를 할당하려는 것을 볼 수 있다.
 
 파드 생성:
@@ -242,7 +245,8 @@ kubectl delete pod memory-demo-2 --namespace=mem-example
 
 이 예제에서는 메모리 요청량이 너무 커 클러스터 내 모든 노드의 용량을 초과하는 파드를 생성한다.
 다음은 클러스터 내 모든 노드의 용량을 초과할 수 있는 1000 GiB 메모리 요청을 포함하는
-컨테이너를 갖는 파드의 구성 파일이다.
+컨테이너를 갖는 
+파드의 구성 파일이다.
 
 {{< codenew file="pods/resource/memory-request-limit-3.yaml" >}}
 
@@ -302,8 +306,7 @@ kubectl delete pod memory-demo-3 --namespace=mem-example
 컨테이너에 메모리 상한을 지정하지 않으면 다음 중 하나가 적용된다.
 
 * 컨테이너가 사용할 수 있는 메모리 상한은 없다. 컨테이너가
-실행 중인 노드에서 사용 가능한 모든 메모리를 사용하여 OOM Killer가 실행 될 수 있다. 또한 메모리 부족으로 인한 종료 시 메모리 상한이
+실행 중인 노드에서 사용 가능한 모든 메모리를 사용하여 OOM Killer가 실행될 수 있다. 또한 메모리 부족으로 인한 종료 시 메모리 상한이 없는 컨테이너가 종료될 가능성이 크다.
-없는 컨테이너가 종료될 가능성이 크다.
 
 * 기본 메모리 상한을 갖는 네임스페이스 내에서 실행중인 컨테이너는
 자동으로 기본 메모리 상한이 할당된다. 클러스터 관리자들은
@@ -356,3 +359,6 @@ kubectl delete namespace mem-example
 * [API 오브젝트에 할당량 구성 ](/docs/tasks/administer-cluster/quota-api-object/)
 
 
+
+
+