Ninth Korean l10n work for release 1.18

- Fix error in k8s.io/ko/docs/concepts/workloads/pods/pod-lifecycle/ (#22681) - Translate docs/reference/setup-tools/kubeadm/kubeadm.md in Korean (#22684) - Update outdated files in dev-1.18-ko.9 branch (#22686) - Fix issues of ko-doc links in translated docs (#22718) - Translate concepts/cluster-administration/monitoring.md into Korean (#22808) - Translate tasks/access-application-cluster/service-access-application-cluster in Korean (#22800) - Translate concepts/storage/storage-limits.md into Korean (#22795) Co-authored-by: Jihoon Seo <jihoon.seo@etri.re.kr> Co-authored-by: Reung37 <reung37@naver.com> Co-authored-by: Seokho Son <shsongist@gmail.com> Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: coolguyhong <podolsmith@naver.com>
2020-07-24 11:09:21 +09:00
parent cac85d2bb2
commit e2ea8ff0f3
75 changed files with 795 additions and 337 deletions
@@ -324,7 +324,7 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
 {{< feature-state state="alpha" for_k8s_version="v1.16" >}}

 `TopologyManager`
-[기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)를
+[기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
 활성화 시켜두면, kubelet이 리소스 할당 결정을 할 때 토폴로지 힌트를 사용할 수 있다.
 자세한 내용은
 [노드의 컨트롤 토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)을 본다.
@@ -78,7 +78,8 @@ kubectl logs counter
 전자의 접근 방식은 다른 환경에서 사용된다. 두 경우 모두,
 기본적으로 로그 파일이 10MB를 초과하면 로테이션이 되도록 구성된다.

-예를 들어, `kube-up.sh` 가 해당 [스크립트][cosConfigureHelper]에서
+예를 들어, `kube-up.sh` 가 해당
+[스크립트](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)에서
 GCP의 COS 이미지 로깅을 설정하는 방법에 대한 자세한 정보를 찾을 수 있다.

 기본 로깅 예제에서와 같이 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs)를
@@ -93,8 +94,6 @@ GCP의 COS 이미지 로깅을 설정하는 방법에 대한 자세한 정보를
 그 후 `kubectl logs` 는 빈 응답을 반환한다.
 {{< /note >}}

-[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh
-
 ### 시스템 컴포넌트 로그

 시스템 컴포넌트에는 컨테이너에서 실행되는 것과 컨테이너에서 실행되지 않는 두 가지 유형이 있다.
@@ -106,7 +105,7 @@ GCP의 COS 이미지 로깅을 설정하는 방법에 대한 자세한 정보를
 systemd를 사용하는 시스템에서, kubelet과 컨테이너 런타임은 journald에 작성한다.
 systemd를 사용하지 않으면, `/var/log` 디렉터리의 `.log` 파일에 작성한다.
 컨테이너 내부의 시스템 컴포넌트는 기본 로깅 메커니즘을 무시하고,
-항상 `/var/log` 디렉터리에 기록한다. 그것은 [klog][klog]
+항상 `/var/log` 디렉터리에 기록한다. 그것은 [klog](https://github.com/kubernetes/klog)
 로깅 라이브러리를 사용한다. [로깅에 대한 개발 문서](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)에서
 해당 컴포넌트의 로깅 심각도(severity)에 대한 규칙을 찾을 수 있다.

@@ -115,8 +114,6 @@ systemd를 사용하지 않으면, `/var/log` 디렉터리의 `.log` 파일에
 로그는 매일 또는 크기가 100MB를 초과하면
 `logrotate` 도구에 의해 로테이트가 되도록 구성된다.

-[klog]: https://github.com/kubernetes/klog
-
 ## 클러스터 레벨 로깅 아키텍처

 쿠버네티스는 클러스터-레벨 로깅을 위한 네이티브 솔루션을 제공하지 않지만, 고려해야 할 몇 가지 일반적인 접근 방법을 고려할 수 있다. 여기 몇 가지 옵션이 있다.
@@ -0,0 +1,129 @@
+---
+title: 쿠버네티스 컨트롤 플레인에 대한 메트릭
+content_type: concept
+weight: 60
+aliases:
+- controller-metrics.md
+---
+
+<!-- overview -->
+
+시스템 컴포넌트 메트릭으로 내부에서 발생하는 상황을 더 잘 파악할 수 있다. 메트릭은 대시보드와 경고를 만드는 데 특히 유용하다.
+
+쿠버네티스 컨트롤 플레인의 메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)으로 출력되며 사람이 읽기 쉽다.
+
+
+
+<!-- body -->
+
+## 쿠버네티스의 메트릭
+
+대부분의 경우 메트릭은 HTTP 서버의 `/metrics` 엔드포인트에서 사용할 수 있다. 기본적으로 엔드포인트를 노출하지 않는 컴포넌트의 경우 `--bind-address` 플래그를 사용하여 활성화할 수 있다.
+
+해당 컴포넌트의 예는 다음과 같다.
+
+* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}
+* {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}
+* {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}
+* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}}
+* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}
+
+프로덕션 환경에서는 이러한 메트릭을 주기적으로 수집하고 시계열 데이터베이스에서 사용할 수 있도록
+[프로메테우스 서버](https://prometheus.io/) 또는 다른 메트릭 수집기(scraper)를 구성할 수 있다.
+
+참고로 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}도 `/metrics/cadvisor`, `/metrics/resource` 그리고 `/metrics/probes` 엔드포인트에서 메트릭을 노출한다. 이러한 메트릭은 동일한 라이프사이클을 가지지 않는다.
+
+클러스터가 {{< glossary_tooltip term_id="rbac" text="RBAC" >}}을 사용하는 경우, 메트릭을 읽으려면 `/metrics` 에 접근을 허용하는 클러스터롤(ClusterRole)을 가지는 사용자, 그룹 또는 서비스어카운트(ServiceAccount)를 통한 권한이 필요하다.
+예를 들면, 다음과 같다.
+```
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: prometheus
+rules:
+  - nonResourceURLs:
+      - "/metrics"
+    verbs:
+      - get
+```
+
+## 메트릭 라이프사이클
+
+알파 메트릭 → 안정적인 메트릭 → 사용 중단된 메트릭 → 히든(hidden) 메트릭 → 삭제
+
+알파 메트릭은 안정성을 보장하지 않는다. 따라서 언제든지 수정되거나 삭제될 수 있다.
+
+안정적인 메트릭은 변경되지 않는다는 보장을 할 수 있다. 특히 안정성은 다음을 의미한다.
+
+* 메트릭 자체는 삭제되거나 이름이 변경되지 않는다
+* 메트릭 유형은 수정되지 않는다
+
+사용 중단된 메트릭은 메트릭이 결국 삭제된다는 것을 나타낸다. 어떤 버전을 찾으려면, 해당 메트릭이 어떤 쿠버네티스 버전에서부터 사용 중단될 것인지를 고려하는 내용을 포함하는 어노테이션을 확인해야 한다.
+
+사용 중단되기 전에는 아래와 같다.
+
+```
+# HELP some_counter this counts things
+# TYPE some_counter counter
+some_counter 0
+```
+
+사용 중단된 이후에는 아래와 같다.
+
+```
+# HELP some_counter (Deprecated since 1.15.0) this counts things
+# TYPE some_counter counter
+some_counter 0
+```
+
+메트릭이 일단 숨겨지면 기본적으로 메트릭은 수집용으로 게시되지 않는다. 히든 메트릭을 사용하려면, 관련 클러스터 컴포넌트의 구성을 오버라이드(override)해야 한다.
+
+메트릭이 삭제되면, 메트릭이 게시되지 않는다. 오버라이드해서 이를 변경할 수 없다.
+
+
+## 히든 메트릭 표시
+
+위에서 설명한 것처럼, 관리자는 특정 바이너리의 커맨드 라인 플래그를 통해 히든 메트릭을 활성화할 수 있다. 관리자가 지난 릴리스에서 사용 중단된 메트릭의 마이그레이션을 놓친 경우 관리자를 위한 임시방편으로 사용된다.
+
+`show-hidden-metrics-for-version` 플래그는 해당 릴리스에서 사용 중단된 메트릭을 보여주려는 버전을 사용한다. 버전은 xy로 표시되며, 여기서 x는 메이저(major) 버전이고, y는 마이너(minor) 버전이다. 패치 릴리스에서 메트릭이 사용 중단될 수 있지만, 패치 버전은 필요하지 않다. 그 이유는 메트릭 사용 중단 정책이 마이너 릴리스에 대해 실행되기 때문이다.
+
+플래그는 그 값으로 이전의 마이너 버전만 사용할 수 있다. 관리자가 이전 버전을 `show-hidden-metrics-for-version` 에 설정하면 이전 버전의 모든 히든 메트릭이 생성된다. 사용 중단 메트릭 정책을 위반하기 때문에 너무 오래된 버전은 허용되지 않는다.
+
+1.n 버전에서 사용 중단되었다고 가정한 메트릭 `A` 를 예로 들어보겠다. 메트릭 사용 중단 정책에 따르면, 다음과 같은 결론에 도달할 수 있다.
+
+* `1.n` 릴리스에서는 메트릭이 사용 중단되었으며, 기본적으로 생성될 수 있다.
+* `1.n+1` 릴리스에서는 기본적으로 메트릭이 숨겨져 있으며, `show-hidden-metrics-for-version=1.n` 커맨드 라인에 의해서 생성될 수 있다.
+* `1.n+2` 릴리스에서는 코드베이스에서 메트릭이 제거되어야 한다. 더이상 임시방편은 존재하지 않는다.
+
+릴리스 `1.12` 에서 `1.13` 으로 업그레이드 중이지만, `1.12` 에서 사용 중단된 메트릭 `A` 를 사용하고 있다면, 커맨드 라인에서 `--show-hidden-metrics=1.12` 플래그로 히든 메트릭을 설정해야 하고, `1.14` 로 업그레이드하기 전에 이 메트릭을 사용하지 않도록 의존성을 제거하는 것을 기억해야 한다.
+
+## 컴포넌트 메트릭
+
+### kube-controller-manager 메트릭
+
+컨트롤러 관리자 메트릭은 컨트롤러 관리자의 성능과 상태에 대한 중요한 인사이트를 제공한다.
+이러한 메트릭에는 go_routine 수와 같은 일반적인 Go 언어 런타임 메트릭과
+etcd 요청 대기 시간 또는 Cloudprovider(AWS, GCE, OpenStack) API 대기 시간과 같은 컨트롤러 특정 메트릭이 포함되어
+클러스터의 상태를 측정하는 데 사용할 수 있다.
+
+쿠버네티스 1.7부터 GCE, AWS, Vsphere 및 OpenStack의 스토리지 운영에 대한 상세한 Cloudprovider 메트릭을 사용할 수 있다.
+이 메트릭은 퍼시스턴트 볼륨 동작의 상태를 모니터링하는 데 사용할 수 있다.
+
+예를 들어, GCE의 경우 이러한 메트릭을 다음과 같이 호출한다.
+
+```
+cloudprovider_gce_api_request_duration_seconds { request = "instance_list"}
+cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"}
+cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"}
+cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"}
+cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
+cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
+```
+
+
+
+## {{% heading "whatsnext" %}}
+
+* 메트릭에 대한 [프로메테우스 텍스트 형식](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format)에 대해 읽어본다
+* [안정적인 쿠버네티스 메트릭](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml) 목록을 참고한다
+* [쿠버네티스 사용 중단 정책](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)에 대해 읽어본다
@@ -225,7 +225,7 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최
 - immutable로 표시된 컨피그맵에 대한 감시를 중단하여, kube-apiserver의 부하를 크게 줄임으로써 클러스터의 성능을 향상시킴

 이 기능을 사용하려면 `ImmutableEmphemeralVolumes`
-[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하고
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하고
 시크릿 또는 컨피그맵의 `immutable` 필드를 `true` 로 한다. 다음은 예시이다.
 ```yaml
 apiVersion: v1
@@ -292,7 +292,7 @@ kubelet은 사용 중인 로컬 스토리지 양을 측정할 수 있다. 이것
 제공한다.

 - `LocalStorageCapacityIsolation`
-  [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)(이
+  [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)(이
  기능이 기본적으로 설정되어 있음)를 활성화하고,
 - 로컬 임시 스토리지에 대한 지원되는 구성 중 하나를
  사용하여 노드를 설정한다.
@@ -441,7 +441,7 @@ kubelet은 각 `emptyDir` 볼륨, 컨테이너 로그 디렉터리 및 쓰기
 프로젝트 쿼터를 사용하려면, 다음을 수행해야 한다.

 * kubelet 구성에서 `LocalStorageCapacityIsolationFSQuotaMonitoring=true`
-  [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를
+  [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
  활성화한다.

 * 루트 파일시스템(또는 선택적인 런타임 파일시스템)에
@@ -32,7 +32,7 @@ _파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파
 ## 파드 오버헤드 활성화하기 {#set-up}

 기능 활성화를 위해 클러스터에서
-`PodOverhead` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 가 활성화 되어 있고 (1.18 버전에서는 기본적으로 활성화),
+`PodOverhead` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있고(1.18 버전에서는 기본적으로 활성화),
 `overhead` 필드를 정의하는 `RuntimeClass` 가 사용되고 있는지 확인해야 한다.

 ## 사용 예제
@@ -160,7 +160,7 @@ description: "이 프라이어리티 클래스는 XYZ 서비스 파드에만 사
 해당 프라이어리티클래스의 파드는 비-선점될 것이다.

 `PreemptionPolicy` 필드를 사용하려면 `NonPreemptingPriority`
-[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)가
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가
 활성화되어야 한다.

 예제 유스케이스는 데이터 과학 관련 워크로드이다.
@@ -408,4 +408,3 @@ kubelet 리소스 부족 축출은 사용량이 요청을 초과하지 않는
 ## {{% heading "whatsnext" %}}

 * 프라이어리티클래스와 관련하여 리소스쿼터 사용에 대해 [기본적으로 프라이어리티 클래스 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을 읽어보자.
-
@@ -33,7 +33,7 @@ weight: 20
 ## 셋업

 런타임클래스 기능 게이트가 활성화(기본값)된 것을 확인한다.
-기능 게이트 활성화에 대한 설명은 [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를
+기능 게이트 활성화에 대한 설명은 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
 참고한다. `RuntimeClass` 기능 게이트는 apiservers _및_ kubelets에서 활성화되어야 한다.

 1. CRI 구현(implementation)을 노드에 설정(런타임에 따라서)
@@ -135,9 +135,7 @@ https://github.com/containerd/cri/blob/master/docs/config.md
  runtime_path = "${PATH_TO_BINARY}"
 ```

-더 자세한 것은 CRI-O의 [설정 문서][100]를 본다.
-
-[100]: https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md
+더 자세한 것은 CRI-O의 [설정 문서](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md)를 본다.

 ## 스케줄

@@ -146,7 +144,8 @@ https://github.com/containerd/cri/blob/master/docs/config.md
 쿠버네티스 v1.16 부터, 런타임 클래스는 `scheduling` 필드를 통해 이종의 클러스터
 지원을 포함한다. 이 필드를 사용하면, 이 런타임 클래스를 갖는 파드가 이를 지원하는
 노드로 스케줄된다는 것을 보장할 수 있다. 이 스케줄링 기능을 사용하려면,
-[런타임 클래스 어드미션(admission) 컨트롤러][]를 활성화(1.16 부터 기본값)해야 한다.
+[런타임 클래스 어드미션(admission) 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#runtimeclass)를
+활성화(1.16 부터 기본값)해야 한다.

 파드가 지정된 런타임클래스를 지원하는 노드에 안착한다는 것을 보장하려면,
 해당 노드들은 `runtimeClass.scheduling.nodeSelector` 필드에서 선택되는 공통 레이블을 가져야한다.
@@ -162,15 +161,13 @@ https://github.com/containerd/cri/blob/master/docs/config.md
 노드 셀렉터와 톨러레이션 설정에 대해 더 배우려면
 [노드에 파드 할당](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)을 참고한다.

-[런타임클래스 어드미션 컨트롤러]: /docs/reference/access-authn-authz/admission-controllers/#runtimeclass
-
 ### 파드 오버헤드

 {{< feature-state for_k8s_version="v1.18" state="beta" >}}

 파드 실행과 연관되는 _오버헤드_ 리소스를 지정할 수 있다. 오버헤드를 선언하면
 클러스터(스케줄러 포함)가 파드와 리소스에 대한 결정을 내릴 때 처리를 할 수 있다.
-PodOverhead를 사용하려면, PodOverhead [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)
+PodOverhead를 사용하려면, PodOverhead [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
 를 활성화 시켜야 한다. (기본으로 활성화 되어 있다.)

 파드 오버헤드는 런타임 클래스에서 `overhead` 필드를 통해 정의된다. 이 필드를 사용하면,
@@ -27,7 +27,7 @@ Extension-apiserver는 kube-apiserver로 오가는 연결의 레이턴시가 낮
 kube-apiserver로 부터의 디스커버리 요청은 왕복 레이턴시가 5초 이내여야 한다.

 extention API server가 레이턴시 요구 사항을 달성할 수 없는 경우 이를 충족할 수 있도록 변경하는 것을 고려한다.
-`EnableAggregatedDiscoveryTimeout=false` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 설정해서 타임아웃
+`EnableAggregatedDiscoveryTimeout=false` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 설정해서 타임아웃
 제한을 비활성화 할 수 있다. 이 사용 중단(deprecated)된 기능 게이트는 향후 릴리스에서 제거될 예정이다.


@@ -39,4 +39,3 @@ extention API server가 레이턴시 요구 사항을 달성할 수 없는 경
 * 다음에, [확장 API 서버를 구성해서](/docs/tasks/extend-kubernetes/setup-extension-api-server/) 애그리게이션 레이어와 연계한다.
 * 또한, 어떻게 [쿠버네티스 API를 커스텀 리소스 데피니션으로 확장하는지](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)를 배워본다.
 * [API 서비스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)의 사양을 읽어본다.
-
@@ -181,7 +181,7 @@ gRPC 서비스는 `/var/lib/kubelet/pod-resources/kubelet.sock` 의 유닉스
 `/var/lib/kubelet/pod-resources` 를
 {{< glossary_tooltip text="볼륨" term_id="volume" >}}으로 마운트해야 한다.

-"PodResources 서비스"를 지원하려면 `KubeletPodResources` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. 쿠버네티스 1.15부터 기본적으로 활성화되어 있다.
+"PodResources 서비스"를 지원하려면 `KubeletPodResources` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. 쿠버네티스 1.15부터 기본적으로 활성화되어 있다.

 ## 토폴로지 관리자와 장치 플러그인 통합

@@ -229,6 +229,6 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.


 * 장치 플러그인을 사용한 [GPU 리소스 스케줄링](/ko/docs/tasks/manage-gpus/scheduling-gpus/)에 대해 알아보기
-* 노드에서의 [확장 리소스 알리기](/docs/tasks/administer-cluster/extended-resource-node/)에 대해 배우기
+* 노드에서의 [확장 리소스 알리기](/ko/docs/tasks/administer-cluster/extended-resource-node/)에 대해 배우기
 * 쿠버네티스에서 [TLS 수신에 하드웨어 가속](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) 사용에 대해 읽기
 * [토폴로지 관리자](/docs/tasks/adminster-cluster/topology-manager/)에 대해 알아보기
@@ -35,7 +35,7 @@ kubectl과 대시보드와 같은 많은 도구들로 쿠버네티스 오브젝
 | Key                                 | Description           | Example  | Type |
 | ----------------------------------- | --------------------- | -------- | ---- |
 | `app.kubernetes.io/name`            | 애플리케이션 이름 | `mysql` | 문자열 |
-| `app.kubernetes.io/instance`        | 애플리케이션의 인스턴스를 식별하는 고유한 이름 | `wordpress-abcxzy` | 문자열 |
+| `app.kubernetes.io/instance`        | 애플리케이션의 인스턴스를 식별하는 고유한 이름 | `mysql-abcxzy` | 문자열 |
 | `app.kubernetes.io/version`         | 애플리케이션의 현재 버전 (예: a semantic version, revision hash 등.) | `5.7.21` | 문자열 |
 | `app.kubernetes.io/component`       | 아키텍처 내 구성요소 | `database` | 문자열 |
 | `app.kubernetes.io/part-of`         | 이 애플리케이션의 전체 이름 | `wordpress` | 문자열 |
@@ -49,7 +49,7 @@ kind: StatefulSet
 metadata:
  labels:
    app.kubernetes.io/name: mysql
-    app.kubernetes.io/instance: wordpress-abcxzy
+    app.kubernetes.io/instance: mysql-abcxzy
    app.kubernetes.io/version: "5.7.21"
    app.kubernetes.io/component: database
    app.kubernetes.io/part-of: wordpress
@@ -299,7 +299,7 @@ kubectl-user delete pod pause
 약간 다르게 다시 시도해보자.

 ```shell
-kubectl-user run pause --image=k8s.gcr.io/pause
+kubectl-user create deployment pause --image=k8s.gcr.io/pause
 deployment "pause" created

 kubectl-user get pods
@@ -162,13 +162,13 @@ DNS 정책은 파드별로 설정할 수 있다.

 - "`Default`": 파드는 파드가 실행되고 있는 노드로부터 네임 해석 설정(the name resolution configuration)을 상속받는다.
  자세한 내용은
-  [관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node)에서
+  [관련 논의](/ko/docs/tasks/administer-cluster/dns-custom-nameservers/)에서
  확인할 수 있다.
 - "`ClusterFirst`": "`www.kubernetes.io`"와 같이 클러스터 도메인 suffix 구성과
  일치하지 않는 DNS 쿼리는 노드에서 상속된 업스트림 네임서버로 전달된다.
  클러스터 관리자는 추가 스텁-도메인(stub-domain)과 업스트림 DNS 서버를 구축할 수 있다.
  그러한 경우 DNS 쿼리를 어떻게 처리하는지에 대한 자세한 내용은
-  [관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#effects-on-pods)에서
+  [관련 논의](/ko/docs/tasks/administer-cluster/dns-custom-nameservers/)에서
  확인할 수 있다.
 - "`ClusterFirstWithHostNet`": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인
  "`ClusterFirstWithHostNet`"을 명시적으로 설정해야 한다.
@@ -272,4 +272,4 @@ options ndots:5


 DNS 구성 관리에 대한 지침은
-[DNS 서비스 구성](/docs/tasks/administer-cluster/dns-custom-nameservers/)에서 확인할 수 있다.
+[DNS 서비스 구성](/ko/docs/tasks/administer-cluster/dns-custom-nameservers/)에서 확인할 수 있다.
@@ -39,7 +39,7 @@ IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음

 ## IPv4/IPv6 이중 스택 활성화

-IPv4/IPv6 이중 스택을 활성화 하려면, 클러스터의 관련 구성요소에 대해 `IPv6DualStack` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 를 활성화 하고, 이중 스택 클러스터 네트워크 할당을 설정한다.
+IPv4/IPv6 이중 스택을 활성화 하려면, 클러스터의 관련 구성요소에 대해 `IPv6DualStack` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 를 활성화 하고, 이중 스택 클러스터 네트워크 할당을 설정한다.

   * kube-apiserver:
      * `--feature-gates="IPv6DualStack=true"`
@@ -105,5 +105,3 @@ IPv6가 활성화된 외부 로드 밸런서를 지원하는 클라우드 공급


 * [IPv4/IPv6 이중 스택 확인](/docs/tasks/network/validate-dual-stack) 네트워킹
-
-
@@ -99,7 +99,7 @@ __egress__: 각 네트워크폴리시에는 화이트리스트 `egress` 규칙
   * 172.17.0.0–172.17.0.255 와 172.17.2.0–172.17.255.255 의 범위를 가지는 IP 주소(예: 172.17.0.0/16 전체에서 172.17.1.0/24 를 제외)
 3. (이그레스 규칙)은 "role=db" 레이블이 있는 "default" 네임스페이스의 모든 파드에서 TCP 포트 5978의 CIDR 10.0.0.0/24 로의 연결을 허용한다.

-자세한 설명과 추가 예시는 [네트워크 정책 선언](/docs/tasks/administer-cluster/declare-network-policy/)을 본다.
+자세한 설명과 추가 예시는 [네트워크 정책 선언](/ko/docs/tasks/administer-cluster/declare-network-policy/)을 본다.

 ## `to` 및 `from` 셀럭터의 동작

@@ -203,7 +203,7 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C

 {{< feature-state for_k8s_version="v1.12" state="alpha" >}}

-이 기능을 사용하려면 사용자(또는 클러스터 관리자가) API 서버에 `--feature-gates=SCTPSupport=true,…` 를 사용해서 `SCTPSupport` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다.
+이 기능을 사용하려면 사용자(또는 클러스터 관리자가) API 서버에 `--feature-gates=SCTPSupport=true,…` 를 사용해서 `SCTPSupport` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다.
 기능 게이트가 활셩화 되면, 네트워크폴리시의 `protocol` 필드를 `SCTP` 로 설정할 수 있다.

 {{< note >}}
@@ -217,5 +217,5 @@ SCTP 프로토콜 네트워크폴리시를 지원하는 {{< glossary_tooltip tex


 - 자세한 설명과 추가 예시는
-  [네트워크 정책 선언](/docs/tasks/administer-cluster/declare-network-policy/)을 본다.
+  [네트워크 정책 선언](/ko/docs/tasks/administer-cluster/declare-network-policy/)을 본다.
 - 네트워크폴리시 리소스에서 사용되는 일반적인 시나리오는 [레시피](https://github.com/ahmetb/kubernetes-network-policy-recipes)를 본다.
@@ -208,7 +208,7 @@ AppProtocol 필드는 각 서비스 포트에 사용될 애플리케이션 프
 지정하는 방법을 제공한다.

 알파 기능으로 이 필드는 기본적으로 활성화되어 있지 않다. 이 필드를 사용하려면,
-[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)에서
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에서
 `ServiceAppProtocol` 을 활성화해야 한다.

 ## 가상 IP와 서비스 프록시
@@ -132,7 +132,7 @@ Events:            <none>

 #### Delete(삭제)

-`Delete` 반환 정책을 지원하는 볼륨 플러그인의 경우, 삭제는 쿠버네티스에서 퍼시스턴트볼륨 오브젝트와 외부 인프라(예: AWS EBS, GCE PD, Azure Disk 또는 Cinder 볼륨)의 관련 스토리지 자산을 모두 삭제한다. 동적으로 프로비저닝된 볼륨은 [스토리지클래스의 반환 정책](#반환-정책)을 상속하며 기본값은 `Delete`이다. 관리자는 사용자의 기대에 따라 스토리지클래스를 구성해야 한다. 그렇지 않으면 PV를 생성한 후 PV를 수정하거나 패치해야 한다. [퍼시스턴트볼륨의 반환 정책 변경](/docs/tasks/administer-cluster/change-pv-reclaim-policy/)을 참고하길 바란다.
+`Delete` 반환 정책을 지원하는 볼륨 플러그인의 경우, 삭제는 쿠버네티스에서 퍼시스턴트볼륨 오브젝트와 외부 인프라(예: AWS EBS, GCE PD, Azure Disk 또는 Cinder 볼륨)의 관련 스토리지 자산을 모두 삭제한다. 동적으로 프로비저닝된 볼륨은 [스토리지클래스의 반환 정책](#반환-정책)을 상속하며 기본값은 `Delete`이다. 관리자는 사용자의 기대에 따라 스토리지클래스를 구성해야 한다. 그렇지 않으면 PV를 생성한 후 PV를 수정하거나 패치해야 한다. [퍼시스턴트볼륨의 반환 정책 변경](/ko/docs/tasks/administer-cluster/change-pv-reclaim-policy/)을 참고하길 바란다.

 #### Recycle(재활용)

@@ -228,7 +228,7 @@ FlexVolume은 파드 재시작 시 크기를 조정할 수 있다.
 {{< feature-state for_k8s_version="v1.15" state="beta" >}}

 {{< note >}}
-사용 중인 PVC 확장은 쿠버네티스 1.15 이후 버전에서는 베타로, 1.11 이후 버전에서는 알파로 제공된다. `ExpandInUsePersistentVolumes` 기능을 사용하도록 설정해야 한다. 베타 기능의 경우 여러 클러스터에서 자동으로 적용된다. 자세한 내용은 [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 문서를 참고한다.
+사용 중인 PVC 확장은 쿠버네티스 1.15 이후 버전에서는 베타로, 1.11 이후 버전에서는 알파로 제공된다. `ExpandInUsePersistentVolumes` 기능을 사용하도록 설정해야 한다. 베타 기능의 경우 여러 클러스터에서 자동으로 적용된다. 자세한 내용은 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 문서를 참고한다.
 {{< /note >}}

 이 경우 기존 PVC를 사용하는 파드 또는 디플로이먼트를 삭제하고 다시 만들 필요가 없다.
@@ -0,0 +1,75 @@
+---
+title: 노드 별 볼륨 한도
+content_type: concept
+---
+
+<!-- overview -->
+
+이 페이지는 다양한 클라우드 공급자들이 제공하는 노드에 연결할 수 있는
+최대 볼륨 수를 설명한다.
+
+Google, Amazon 그리고 Microsoft와 같은 클라우드 공급자는 일반적으로 노드에
+연결할 수 있는 볼륨 수에 제한이 있다. 쿠버네티스가 이러한 제한을
+준수하는 것은 중요하다. 그렇지 않으면, 노드에서 예약된 파드가 볼륨이
+연결될 때까지 멈추고 기다릴 수 있다.
+
+
+
+<!-- body -->
+
+## 쿠버네티스 기본 한도
+
+쿠버네티스 스케줄러에는 노드에 연결될 수 있는 볼륨 수에 대한
+기본 한도가 있다.
+
+<table>
+  <tr><th>클라우드 서비스</th><th>노드 당 최대 볼륨</th></tr>
+  <tr><td><a href="https://aws.amazon.com/ebs/">Amazon Elastic Block Store (EBS)</a></td><td>39</td></tr>
+  <tr><td><a href="https://cloud.google.com/persistent-disk/">Google Persistent Disk</a></td><td>16</td></tr>
+  <tr><td><a href="https://azure.microsoft.com/ko-kr/services/storage/main-disks/">Microsoft Azure Disk Storage</a></td><td>16</td></tr>
+</table>
+
+## 사용자 정의 한도
+
+`KUBE_MAX_PD_VOLS` 환경 변수의 값을 설정한 후,
+스케줄러를 시작하여 이러한 한도를 변경할 수 있다.
+CSI 드라이버는 절차가 다를 수 있으므로, 한도를 사용자 정의하는
+방법에 대한 문서를 참고한다.
+
+기본 한도보다 높은 한도를 설정한 경우 주의한다. 클라우드
+공급자의 문서를 참조하여 노드가 실제로 사용자가 설정한 한도를
+지원할 수 있는지 확인한다.
+
+한도는 전체 클러스터에 적용되므로, 모든 노드에 영향을 준다.
+
+## 동적 볼륨 한도
+
+{{< feature-state state="stable" for_k8s_version="v1.17" >}}
+
+다음 볼륨 유형에 대해 동적 볼륨 한도가 지원된다.
+
+- Amazon EBS
+- Google Persistent Disk
+- Azure Disk
+- CSI
+
+인-트리(in-tree) 볼륨 플러그인으로 관리되는 볼륨의 경우, 쿠버네티스는 자동으로 노드 유형을
+결정하고 노드에 적절한 최대 볼륨 수를 적용한다. 예를 들면, 다음과 같다.
+
+* <a href="https://cloud.google.com/compute/">Google Compute Engine</a>에서는,
+[노드 유형에 따라](https://cloud.google.com/compute/docs/disks/#pdnumberlimits)
+최대 127개의 볼륨까지
+노드에 연결할 수 있다.
+
+* M5, C5, R5, T3와 Z1D 인스턴스 유형의 Amazon EBS 디스크의 경우, 쿠버네티스는 25개의 볼륨만 노드에 
+연결할 수 있도록 허용한다.
+<a href="https://aws.amazon.com/ec2/">Amazon Elastic Compute Cloud (EC2)</a>의
+다른 인스턴스 유형의 경우, 쿠버네티스는 노드에 39개의 볼륨을 연결할 수 있도록 허용한다.
+
+* Azure에서는, 노드 유형에 따라 최대 64개의 디스크를 노드에 연결할 수 있다. 더 자세한 내용은 [Azure의 가상 머신 크기](https://docs.microsoft.com/ko-kr/azure/virtual-machines/windows/sizes)를 참고한다.
+
+* CSI 스토리지 드라이버가 `NodeGetInfo` 를 사용해서 노드에 대한 최대 볼륨 수를 알린다면, {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}는 그 한도를 따른다.
+
+자세한 내용은 [CSI 명세](https://github.com/container-storage-interface/spec/blob/master/spec.md#nodegetinfo)를 참고한다.
+
+* CSI 드라이버로 마이그레이션된 인-트리 플러그인으로 관리되는 볼륨의 경우, 최대 볼륨 수는 CSI 드라이버가 보고한 개수이다.
@@ -779,7 +779,7 @@ iSCSI 볼륨와 같은)를 "클레임" 할 수 있는 방법이다.
 서비스 어카운트 토큰의 프로젝션은 쿠버네티스 1.11에 기능이
 도입되었고 1.12에서 베타로 승격되었다.
 1.11에서 이 기능을 활성화 하려면 `TokenRequestProjection`
-[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
 True로 명시적인 설정이 필요하다.

 #### 시크릿, downward API 그리고 configmap이 있는 파드 예시.
@@ -1197,7 +1197,7 @@ spec:


 `subPathExpr` 필드를 사용해서 Downward API 환경 변수로부터 `subPath` 디렉터리 이름을 구성한다.
-이 기능을 사용하려면 `VolumeSubpathEnvExpansion` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다. 쿠버네티스 1.15에서는 시작 시 기본적으로 활성화되어 있다.
+이 기능을 사용하려면 `VolumeSubpathEnvExpansion` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다. 쿠버네티스 1.15에서는 시작 시 기본적으로 활성화되어 있다.
 `subPath` 와 `subPathExpr` 속성은 상호 배타적이다.

 이 예제는 파드가 `subPathExpr` 을 사용해서 Downward API로부터 파드 이름을 사용해서 hostPath 볼륨 `/var/log/pods` 내에 `pod1` 디렉터리를 생성한다.  호스트 디렉터리 `/var/log/pods/pod1` 은 컨테이너의 `/logs` 에 마운트 된다.
@@ -211,9 +211,9 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
 이렇게 하려면 `.spec.backoffLimit` 에 잡을 실패로 간주하기 이전에
 재시도할 횟수를 설정한다. 백오프 제한은 기본적으로 6으로 설정되어 있다. 잡과
 관련한 실패한 파드는 최대 6분안에서 기하급수적으로 증가하는 백-오프 지연 (10초, 20초, 40초 ...)
-한도가 되어 잡 컨트롤러에 의해 재생성 된다. 잡의 다음 상태
-확인 이전에 새로 실패한 파드가 표시되지 않으면 백 오프
-카운트가 재설정 된다.
+한도가 되어 잡 컨트롤러에 의해 재생성된다. 잡의 파드가 삭제되거나 
+해당 시간 동안 잡에 대한 다른 파드가 실패 없이 성공했을 때 백 오프
+카운트가 재설정된다.

 {{< note >}}
 1.12 이전 버전의 쿠버네티스 버전에 대해 여전히 [#54870](https://github.com/kubernetes/kubernetes/issues/54870) 이슈가 있다.
@@ -346,7 +346,7 @@ kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50

 ### 잡

-스스로 종료되는 것이 예상되는 파드의 경우에는 레플리카셋 대신 [`잡`](/docs/concepts/jobs/run-to-completion-finite-workloads/)을 이용한다
+스스로 종료되는 것이 예상되는 파드의 경우에는 레플리카셋 대신 [`잡`](/ko/docs/concepts/workloads/controllers/job/)을 이용한다
 (즉, 배치 잡).

 ### 데몬셋
@@ -269,7 +269,7 @@ API 오브젝트에 대한 더 자세한 것은
 ### 잡

 자체적으로 제거될 것으로 예상되는 파드 (즉, 배치 잡)의 경우
-레플리케이션 컨트롤러 대신 [`잡`](/docs/concepts/jobs/run-to-completion-finite-workloads/)을 사용하라.
+레플리케이션 컨트롤러 대신 [`잡`](/ko/docs/concepts/workloads/controllers/job/)을 사용하라.

 ### 데몬셋

@@ -134,6 +134,18 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
 일치되는 DNS 서브도메인을 가지며, 여기서 거버닝 서비스(governing service)는
 스테이트풀셋의 `serviceName` 필드에 의해 정의된다.

+클러스터에서 DNS가 구성된 방식에 따라, 새로 실행된 파드의 DNS 이름을
+즉시 찾지 못할 수 있다. 이 동작은 클러스터의 다른 클라이언트가
+파드가 생성되기 전에 파드의 호스트 이름에 대한 쿼리를 이미 보낸 경우에 발생할 수 있다.
+네거티브 캐싱(DNS에서 일반적)은 이전에 실패한 조회 결과가
+파드가 실행된 후에도 적어도 몇 초 동안 기억되고 재사용됨을 의미한다.
+
+파드를 생성한 후 즉시 파드를 검색해야 하는 경우, 몇 가지 옵션이 있다.
+
+- DNS 조회에 의존하지 않고 쿠버네티스 API를 직접(예를 들어 watch 사용) 쿼리한다.
+- 쿠버네티스 DNS 공급자의 캐싱 시간(일반적으로 CoreDNS의 컨피그맵을 편집하는 것을 의미하며, 현재 30초 동안 캐시함)을 줄인다.
+
+
 [제한사항](#제한사항) 섹션에서 언급한 것처럼 사용자는
 파드의 네트워크 신원을 책임지는
 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 생성할 책임이 있다.
@@ -16,7 +16,7 @@ TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을

 알파(Alpha) 고지 사항: 이 기능은 현재 알파이고,
 kube-apiserver와 kube-controller-manager와 함께
-[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)로 `TTLAfterFinished` 를 활성화할 수 있다.
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)로 `TTLAfterFinished` 를 활성화할 수 있다.



@@ -8,9 +8,9 @@ weight: 80

 {{< feature-state state="alpha" for_k8s_version="v1.16" >}}

-이 페이지는 임시 컨테이너에 대한 개요를 제공한다: 이 특별한 유형의 컨테이너는 
-트러블 슈팅과 같은 사용자가 시작한 작업을 완료하기위해 기존 {{< glossary_tooltip text="파드" term_id="pod" >}} 에서 
-임시적으로 실행된다. 사용자는 애플리케이션 빌드보다는 서비스를 점검할 때 임시 
+이 페이지는 임시 컨테이너에 대한 개요를 제공한다: 이 특별한 유형의 컨테이너는
+트러블 슈팅과 같은 사용자가 시작한 작업을 완료하기위해 기존 {{< glossary_tooltip text="파드" term_id="pod" >}} 에서
+임시적으로 실행된다. 사용자는 애플리케이션 빌드보다는 서비스를 점검할 때 임시
 컨테이너를 사용한다.

 {{< warning >}}
@@ -82,7 +82,7 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지

 {{< note >}}
 이 섹션의 예시는 `EphemeralContainers` [기능
-게이트](/docs/reference/command-line-tools-reference/feature-gates/)의
+게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)의
 활성화를 필요로 하고, 쿠버네티스 클라이언트와 서버는 v1.16 또는 이후의 버전이어야 한다.
 {{< /note >}}

@@ -322,4 +322,4 @@ myapp-pod   1/1       Running   0          9m


 * [초기화 컨테이너를 가진 파드 생성하기](/ko/docs/tasks/configure-pod-container/configure-pod-initialization/#초기화-컨테이너를-갖는-파드-생성)
-* [초기화 컨테이너 디버깅](/docs/tasks/debug-application-cluster/debug-init-containers/) 알아보기
+* [초기화 컨테이너 디버깅](/ko/docs/tasks/debug-application-cluster/debug-init-containers/) 알아보기
@@ -90,7 +90,7 @@ kubelet은 컨테이너에 의해서 구현된

 * [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core)
  은 지정한 포트 및 경로에서 컨테이너의 IP주소에
-  대한 HTTP Get 요청을 수행한다. 응답의 상태 코드가 200보다 크고 400보다 작으면
+  대한 HTTP Get 요청을 수행한다. 응답의 상태 코드가 200 이상 400 미만이면
  진단이 성공한 것으로 간주한다.

 각 probe는 다음 세 가지 결과 중 하나를 가진다.
@@ -20,7 +20,7 @@ weight: 50

 를 참조한다. {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} **와**
 {{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}에 대해
-`EvenPodsSpread` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)가
+`EvenPodsSpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가
 활성화되어야 한다.

 ### 노드 레이블
@@ -244,5 +244,3 @@ profiles:

 - 디플로이먼트를 스케일링 다운하면 그 결과로 파드의 분포가 불균형이 될 수 있다.
 - 파드와 일치하는 테인트(taint)가 된 노드가 존중된다. [이슈 80921](https://github.com/kubernetes/kubernetes/issues/80921)을 본다.
-
-
@@ -28,41 +28,62 @@ card:

 ## 시작하기

-누구든지 문서에 대한 이슈를 오픈 또는 풀 리퀘스트(PR)를 사용해서 [`kubernetes/website` GitHub 리포지터리](https://github.com/kubernetes/website)에 변경하는 기여를 할 수 있습니다. 당신이 쿠버네티스 커뮤니티에 효과적으로 기여하려면 [git](https://git-scm.com/)과 [GitHub](https://lab.github.com/)에 익숙해야 합니다.
+누구든지 문서에 대한 이슈를 오픈 또는 풀 리퀘스트(PR)를 사용해서
+[`kubernetes/website` GitHub 리포지터리](https://github.com/kubernetes/website)에
+변경하는 기여를 할 수 있습니다.
+쿠버네티스 커뮤니티에 효과적으로 기여하려면
+[git](https://git-scm.com/)과
+[GitHub](https://lab.github.com/)에
+익숙해야 합니다.

 문서에 참여하려면

 1. CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md)에 서명합니다.
-2. [문서 리포지터리](https://github.com/kubernetes/website) 와 웹사이트의 [정적 사이트 생성기](https://gohugo.io)를 숙지합니다.
-3. [풀 리퀘스트 열기](/ko/docs/contribute/new-content/new-content/)와 [변경 검토](/ko/docs/contribute/review/reviewing-prs/)의 기본 프로세스를 이해하도록 합니다.
+1. [문서 리포지터리](https://github.com/kubernetes/website)와 웹사이트의
+   [정적 사이트 생성기](https://gohugo.io)를 숙지합니다.
+1. [풀 리퀘스트 열기](/ko/docs/contribute/new-content/new-content/)와
+   [변경 검토](/ko/docs/contribute/review/reviewing-prs/)의
+   기본 프로세스를 이해하도록 합니다.

 일부 작업에는 쿠버네티스 조직에서 더 많은 신뢰와 더 많은 접근이 필요할 수 있습니다.
 역할과 권한에 대한 자세한 내용은
-[SIG Docs 참여](/ko/docs/contribute/participating/)를 봅니다.
+[SIG Docs 참여](/ko/docs/contribute/participate/)를 봅니다.

 ## 첫 번째 기여

- [기여 개요](/ko/docs/contribute/new-content/overview/)를 읽고 기여할 수 있는 다양한 방법에 대해 알아봅니다.
- [kubernetes/website에 기여하기](https://github.com/kubernetes/website/contribute)를 참조하여 좋은 진입점이 되는 이슈를 찾을 수 있습니다.
- 기존 문서에 대해 [GitHub을 사용해서 풀 리퀘스트 열거나](/ko/docs/contribute/new-content/new-content/#github을-사용하여-변경하기) GitHub에서의 이슈 제기에 대해 자세히 알아봅니다.
- 정확성과 언어에 대해 다른 쿠버네티스 커뮤니티 맴버의 [풀 리퀘스트 검토](/ko/docs/contribute/review/reviewing-prs/)를 합니다.
- 쿠버네티스 [콘텐츠](/docs/contribute/style/content-guide/)와 [스타일 가이드](/docs/contribute/style/style-guide/)를 읽고 정보에 대한 코멘트를 남길 수 있습니다.
- [페이지 템플릿 사용](/docs/contribute/style/page-content-types/)과 [휴고(Hugo) 단축코드(shortcodes)](/docs/contribute/style/hugo-shortcodes/)를 사용해서 큰 변경을 하는 방법에 대해 배워봅니다.
+- [기여 개요](/ko/docs/contribute/new-content/overview/)를 읽고
+  기여할 수 있는 다양한 방법에 대해 알아봅니다.
+- [kubernetes/website에 기여하기](https://github.com/kubernetes/website/contribute)를
+  참조하여 좋은 진입점이 되는 이슈를 찾을 수 있습니다.
+- 기존 문서에 대해 [GitHub을 사용해서 풀 리퀘스트 열거나](/ko/docs/contribute/new-content/new-content/#github을-사용하여-변경하기)
+  GitHub에서의 이슈 제기에 대해 자세히 알아봅니다.
+- 정확성과 언어에 대해 다른 쿠버네티스 커뮤니티 맴버의
+  [풀 리퀘스트 검토](/ko/docs/contribute/review/reviewing-prs/)를 합니다.
+- 쿠버네티스 [콘텐츠](/docs/contribute/style/content-guide/)와
+  [스타일 가이드](/docs/contribute/style/style-guide/)를 읽고 정보에 대한 코멘트를 남길 수 있습니다.
+- [페이지 콘텐츠 유형](/docs/contribute/style/page-content-types/)과
+  [휴고(Hugo) 단축코드(shortcodes)](/docs/contribute/style/hugo-shortcodes/)에 대해 배워봅니다.

 ## 다음 단계

- 리포지터리의 [로컬 복제본에서 작업](/ko/docs/contribute/new-content/new-content/#fork-the-repo)하는 방법을 배워봅니다.
+- 리포지터리의 [로컬 복제본에서 작업](/ko/docs/contribute/new-content/new-content/#fork-the-repo)하는
+  방법을 배워봅니다.
 - [릴리스된 기능](/docs/contribute/new-content/new-features/)을 문서화 합니다.
- [SIG Docs](/ko/docs/contribute/participating/)에 참여하고, [멤버 또는 검토자](/ko/docs/contribute/participating/#역할과-책임)가 되어봅니다.
+- [SIG Docs](/ko/docs/contribute/participate/)에 참여하고,
+  [멤버 또는 검토자](/ko/docs/contribute/participate/roles-and-responsibilities/)가 되어봅니다.
+
 - [현지화](/ko/docs/contribute/localization_ko/)를 시작하거나 도와줍니다.

 ## SIG Docs에 참여

-[SIG Docs](/ko/docs/contribute/participating/)는 쿠버네티스 문서와 웹 사이트를 게시하고 관리하는 기여자 그룹입니다. SIG Docs에 참여하는 것은 쿠버네티스 기여자(기능 개발 및 다른 여러가지)가 쿠버네티스 프로젝트에 가장 큰 영향을 미칠 수 있는 좋은 방법입니다.
+[SIG Docs](/ko/docs/contribute/participate/)는 쿠버네티스 문서와 웹 사이트를 게시하고
+관리하는 기여자 그룹입니다. SIG Docs에 참여하는 것은
+쿠버네티스 기여자(기능 개발 및 다른 여러가지)가 쿠버네티스 프로젝트에 가장 큰 영향을
+미칠 수 있는 좋은 방법입니다.

 SIG Docs는 여러가지 방법으로 의견을 나누고 있습니다.

- [쿠버네티스 슬랙 인스턴스에서 `#sig-docs` 에 가입](http://slack.k8s.io/)을 하고,
+- [쿠버네티스 슬랙 인스턴스에서 `#sig-docs` 에 가입](https://slack.k8s.io/)하고,
  자신을 소개하세요!
 - 더 광범위한 토론이 이루어지고 공식적인 결정이 기록이 되는
  [`kubernetes-sig-docs` 메일링 리스트에 가입](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) 하세요.
@@ -19,7 +19,8 @@ weight: 98

 ## 개선 제안

-SIG Docs [멤버](/ko/docs/contribute/participating/#멤버)는 개선을 제안할 수 있다.
+SIG Docs [멤버](/ko/docs/contribute/participate/roles-and-responsibilities/#멤버)는
+개선을 제안할 수 있다.

 한 동안 쿠버네티스 문서에 기여한 후에,
 [스타일 가이드](/docs/contribute/style/style-guide/),
@@ -42,12 +43,12 @@ website 스타일, 풀 리퀘스트 리뷰와 병합

 ## 쿠버네티스 릴리스를 위한 문서 조정

-SIG Docs [승인자](/ko/docs/contribute/participating/#승인자)는 쿠버네티스
-릴리스에 대한 문서를 조정할 수 있다.
+SIG Docs [승인자](/ko/docs/contribute/participate/roles-and-responsibilities/#승인자)는
+쿠버네티스 릴리스에 대한 문서를 조정할 수 있다.

 각 쿠버네티스 릴리스는 sig-release SIG(Special Interest Group)에 참여하는
 사람들의 팀에 의해 조정된다. 특정 릴리스에 대한 릴리스 팀의 다른 구성원에는
-전체 릴리스 리드와 sig-pm, sig-testing 및 기타 담당자가
+전체 릴리스 리드와 sig-testing 및 기타 담당자가
 포함된다. 쿠버네티스 릴리스 프로세스에 대한 자세한 내용은
 [https://github.com/kubernetes/sig-release](https://github.com/kubernetes/sig-release)를
 참고한다.
@@ -73,8 +74,8 @@ SIG Docs [승인자](/ko/docs/contribute/participating/#승인자)는 쿠버네

 ## 새로운 기여자 홍보대사로 봉사

-SIG Docs [승인자](/ko/docs/contribute/participating/#승인자)는 새로운 기여자
-홍보대사로 활동할 수 있다.
+SIG Docs [승인자](/ko/docs/contribute/participate/roles-and-responsibilities/#승인자)는
+새로운 기여자 홍보대사로 활동할 수 있다.

 새로운 기여자 홍보대사는 SIG-Docs에 기여한 새 기여자를 환영하고,
 새 기여자에게 PR을 제안하고, 첫 몇 번의 PR 제출을 통해
@@ -92,12 +93,12 @@ SIG Docs [승인자](/ko/docs/contribute/participating/#승인자)는 새로운

 ## 새로운 기여자 후원

-SIG Docs [리뷰어](/ko/docs/contribute/participating/#리뷰어)는 새로운 기여자를
-후원할 수 있다.
+SIG Docs [리뷰어](/ko/docs/contribute/participate/roles-and-responsibilities/#리뷰어)는
+새로운 기여자를 후원할 수 있다.

 새로운 기여자가 하나 이상의 쿠버네티스 리포지터리에 5개의
 실질적인 풀 리퀘스트를 성공적으로 제출한 후에는
-쿠버네티스 조직의 [멤버십](/ko/docs/contribute/participating#멤버)을
+쿠버네티스 조직의 [멤버십](/ko/docs/contribute/participate/roles-and-responsibilities/#멤버)을
 신청할 수 있다. 기여자의 멤버십은 이미 리뷰어인 두 명의 스폰서가
 후원해야 한다.

@@ -111,7 +112,8 @@ SIG Docs [리뷰어](/ko/docs/contribute/participating/#리뷰어)는 새로운

 ## SIG 공동 의장으로 봉사

-SIG Docs [승인자](/ko/docs/contribute/participating/#승인자)는 SIG Docs의 공동 의장 역할을 할 수 있다.
+SIG Docs [승인자](/ko/docs/contribute/participate/roles-and-responsibilities/#승인자)는
+SIG Docs의 공동 의장 역할을 할 수 있다.

 ### 전제 조건

@@ -120,7 +122,12 @@ SIG Docs [승인자](/ko/docs/contribute/participating/#승인자)는 SIG Docs
 - 6개월 이상 SIG Docs 승인자로 활동한다.
 - [쿠버네티스 문서 릴리스 주도](/ko/docs/contribute/advanced/#쿠버네티스-릴리스를-위한-문서-조정) 또는 두 개의 릴리스에서 섀도잉을 수행한다.
 - SIG Docs 워크플로와 툴링을 이해한다(git, Hugo, 현지화, 블로그 하위 프로젝트).
- [k/org의 팀](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), [k/community의 프로세스](https://github.com/kubernetes/community/tree/master/sig-docs), [k/test-infra](https://github.com/kubernetes/test-infra/)의 플러그인 및 [SIG 아키텍처](https://github.com/kubernetes/community/tree/master/sig-architecture)의 역할을 포함하여 다른 쿠버네티스 SIG와 리포지터리가 SIG Docs 워크플로에 미치는 영향을 이해한다.
+- [k/org의 팀](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml),
+  [k/community의 프로세스](https://github.com/kubernetes/community/tree/master/sig-docs),
+  [k/test-infra](https://github.com/kubernetes/test-infra/)의 플러그인 및
+  [SIG 아키텍처](https://github.com/kubernetes/community/tree/master/sig-architecture)의
+  역할을 포함하여 다른 쿠버네티스 SIG와 리포지터리가 SIG Docs 워크플로에 미치는
+  영향을 이해한다.
 - 최소 6개월 동안 일주일에 5시간 이상(대부분 더)을 역할에 책임진다.

 ### 책임
@@ -187,7 +187,7 @@ API 오브젝트의 필드 이름, 파일 이름, 경로와 같은 내용은 독

 ### 기능 게이트(feature gate) 한글화 방침

-쿠버네티스의 [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를
+쿠버네티스의 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
 의미하는 용어는 한글화하지 않고 원문 형태를 유지한다.

 기능 게이트의 예시는 다음과 같다.
@@ -198,7 +198,7 @@ API 오브젝트의 필드 이름, 파일 이름, 경로와 같은 내용은 독
 - ...

 전체 기능 게이트 목록은
-[여기](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates)를 참고한다.
+[여기](/ko/docs/reference/command-line-tools-reference/feature-gates/#feature-gates)를 참고한다.

 {{% note %}}
 단, 해당 원칙에는 예외가 있을 수 있으며, 이 경우에는 가능한
@@ -1,6 +1,5 @@
 ---
 title: 풀 리퀘스트 열기
-slug: new-content
 content_type: concept
 weight: 10
 card:
@@ -20,8 +20,12 @@ weight: 5
 - 마크다운(Markdown)으로 쿠버네티스 문서를 작성하고 [Hugo](https://gohugo.io/)를 사용하여 쿠버네티스 사이트를 구축한다.
 - 소스는 [GitHub](https://github.com/kubernetes/website)에 있다. 쿠버네티스 문서는 `/content/ko/docs/` 에서 찾을 수 있다. 일부 참조 문서는 `update-imported-docs/` 디렉터리의 스크립트에서 자동으로 생성된다.
 - [페이지 템플릿](/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/` 에 저장된다.
+- 표준 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/)를 참고한다.

 ## 시작하기 전에 {#before-you-begin}
@@ -20,7 +20,9 @@ SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다.
 누구나 풀 리퀘스트(PR)를 요청할 수 있고,
 누구나 콘텐츠에 대해 이슈를 등록하거나 진행 중인 풀 리퀘스트에 코멘트를 등록할 수 있다.

-[멤버](/ko/docs/contribute/participating/roles-and-responsibilities/#멤버), [리뷰어](/ko/docs/contribute/participating/roles-and-responsibilities/#리뷰어), 또는 [승인자](/ko/docs/contribute/participating/roles-and-responsibilities/#승인자)가 될 수 있다.
+[멤버](/ko/docs/contribute/participate/roles-and-responsibilities/#멤버),
+[리뷰어](/ko/docs/contribute/participate/roles-and-responsibilities/#리뷰어), 또는
+[승인자](/ko/docs/contribute/participate/roles-and-responsibilities/#승인자)가 될 수 있다.
 이런 역할은 변경을 승인하고 커밋할 수 있도록 보다 많은 접근 권한과 이에 상응하는 책임이 수반된다.
 쿠버네티스 커뮤니티 내에서 멤버십이 운영되는 방식에 대한 보다 많은 정보를 확인하려면
 [커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md)
@@ -30,8 +32,6 @@ SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다.
 문서를 관리하는 책임을 가지는 SIG Docs에서,
 이런 체계가 작동하는 특유의 방식에 대한 윤곽을 잡아보겠다.

-
-
 <!-- body -->

 ## SIG Docs 의장
@@ -58,7 +58,8 @@ GitHub의 SIG Docs [팀]에는 두 분류가 있다.
 그룹의 전원과 의사소통하기 위해서
 각각 GitHub 코멘트에서 그룹의 `@name`으로 참조할 수 있다.

-가끔은 Prow와 GitHub 팀은 정확히 일치하지 않고 중복된다. 이슈, 풀 리퀘스트를 할당하고, PR 승인을 지원하기 위해서
+가끔은 Prow와 GitHub 팀은 정확히 일치하지 않고 중복된다.
+이슈, 풀 리퀘스트를 할당하고, PR 승인을 지원하기 위해서
 자동화 시스템이 `OWNERS` 파일의 정보를 활용한다.

 ### OWNERS 파일과 전문(front-matter)
@@ -6,7 +6,8 @@ weight: 10

 <!-- overview -->

-누구나 쿠버네티스에 기여할 수 있다. SIG Docs에 대한 기여가 커짐에 따라, 커뮤니티의 다양한 멤버십을 신청할 수 있다.
+누구나 쿠버네티스에 기여할 수 있다. SIG Docs에 대한 기여가 커짐에 따라,
+커뮤니티의 다양한 멤버십을 신청할 수 있다.
 이러한 역할을 통해 커뮤니티 내에서 더 많은 책임을 질 수 있다.
 각 역할마다 많은 시간과 노력이 필요하다. 역할은 다음과 같다.

@@ -23,10 +24,13 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D

 모든 사람은 다음의 작업을 할 수 있다.

- [`kubernetes/website`](https://github.com/kubernetes/website)를 포함한 모든 [쿠버네티스] 리포지터리에서 이슈를 올린다.
+- [`kubernetes/website`](https://github.com/kubernetes/website)를 포함한 모든
+  [쿠버네티스](https://github.com/kubernetes/) 리포지터리에서
+  이슈를 올린다.
 - 풀 리퀘스트에 대해 구속력 없는 피드백을 제공한다.
 - 현지화에 기여한다.
- [슬랙](http://slack.k8s.io/) 또는 [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선을 제안한다.
+- [슬랙](http://slack.k8s.io/) 또는
+  [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선을 제안한다.

 [CLA에 서명](/ko/docs/contribute/new-content/overview/#sign-the-cla) 후에 누구나 다음을 할 수 있다.

@@ -37,16 +41,19 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D

 ## 멤버

-멤버는 `kubernetes/website` 에 여러 개의 풀 리퀘스트를 제출한 사람이다. 멤버는 [쿠버네티스 GitHub 조직](https://github.com/kubernetes)의 회원이다.
+멤버는 `kubernetes/website` 에 여러 개의 풀 리퀘스트를 제출한
+사람이다. 멤버는
+[쿠버네티스 GitHub 조직](https://github.com/kubernetes)의 회원이다.

 멤버는 다음의 작업을 할 수 있다.

 - [모든 사람](#모든-사람)에 나열된 모든 것을 한다.
 - 풀 리퀘스트에 `/lgtm` 코멘트를 사용하여 LGTM(looks good to me) 레이블을 추가한다.

-    {{< note >}}
-    `/lgtm` 사용은 자동화를 트리거한다. 만약 구속력 없는 승인을 제공하려면, 단순히 "LGTM" 코멘트를 남기는 것도 좋다!
-    {{< /note >}}
+  {{< note >}}
+  `/lgtm` 사용은 자동화를 트리거한다. 만약 구속력 없는 승인을 제공하려면, 단순히 "LGTM" 코멘트를 남기는 것도 좋다!
+  {{< /note >}}
+
 - `/hold` 코멘트를 사용하여 풀 리퀘스트에 대한 병합을 차단한다.
 - `/assign` 코멘트를 사용하여 풀 리퀘스트에 리뷰어를 지정한다.
 - 풀 리퀘스트에 구속력 없는 리뷰를 제공한다.
@@ -55,46 +62,56 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D

 ### 멤버 되기

-최소 5개의 실질적인 풀 리퀘스트를 제출하고 다른 [요구 사항](https://github.com/kubernetes/community/blob/master/community-membership.md#member)을 충족시킨 후, 다음의 단계를 따른다.
+최소 5개의 실질적인 풀 리퀘스트를 제출하고 다른
+[요구 사항](https://github.com/kubernetes/community/blob/master/community-membership.md#member)을 충족시킨 후, 다음의 단계를 따른다.

-1.  멤버십을 [후원](/docs/contribute/advanced#sponsor-a-new-contributor)해 줄 두 명의 [리뷰어](#리뷰어) 또는 [승인자](#승인자)를 찾는다.
+1. 멤버십을 [후원](/docs/contribute/advanced#sponsor-a-new-contributor)해줄 두 명의
+   [리뷰어](#리뷰어) 또는 [승인자](#승인자)를
+   찾는다.

-    [슬랙의 #sig-docs 채널](https://kubernetes.slack.com) 또는
-    [SIG Docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에서 후원을 요청한다.
+   [슬랙의 #sig-docs 채널](https://kubernetes.slack.com) 또는
+   [SIG Docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에서 후원을 요청한다.

-    {{< note >}}
-    SIG Docs 멤버 개인에게 직접 email을 보내거나
-    슬랙 다이렉트 메시지를 보내지 않는다. 반드시 지원서를 제출하기 전에 후원을 요청해야 한다.
-    {{< /note >}}
+   {{< note >}}
+   SIG Docs 멤버 개인에게 직접 email을 보내거나
+   슬랙 다이렉트 메시지를 보내지 않는다. 반드시 지원서를 제출하기 전에 후원을 요청해야 한다.
+   {{< /note >}}

-2.  [`kubernetes/org`](https://github.com/kubernetes/org/) 리포지터리에 GitHub 이슈를 등록한다. **Organization Membership Request** 이슈 템플릿을 사용한다.
+1. [`kubernetes/org`](https://github.com/kubernetes/org/) 리포지터리에
+   GitHub 이슈를 등록한다.
+   **Organization Membership Request** 이슈 템플릿을 사용한다.

-3.  후원자에게 GitHub 이슈를 알린다. 다음 중 하나를 수행할 수 있다.
-  - 이슈에서 후원자의 GitHub 사용자 이름을 코멘트로 추가한다. (`@<GitHub-username>`)
-  - 슬랙 또는 이메일을 사용해 이슈 링크를 후원자에게 보낸다.
+1. 후원자에게 GitHub 이슈를 알린다. 다음 중 하나를 수행할 수 있다.
+   - 이슈에서 후원자의 GitHub 사용자 이름을 코멘트로 추가한다. (`@<GitHub-username>`)
+   - 슬랙 또는 이메일을 사용해 이슈 링크를 후원자에게 보낸다.

-    후원자는 `+1` 투표로 여러분의 요청을 승인할 것이다. 후원자가 요청을 승인하면, 쿠버네티스 GitHub 관리자가 여러분을 멤버로 추가한다. 축하한다!
+     후원자는 `+1` 투표로 여러분의 요청을 승인할 것이다. 후원자가 요청을 승인하면,
+     쿠버네티스 GitHub 관리자가 여러분을 멤버로 추가한다.
+     축하한다!

-    만약 멤버십이 수락되지 않으면 피드백을 받게 될 것이다. 피드백의 내용을 해결한 후, 다시 지원하자.
+     만약 멤버십이 수락되지 않으면 피드백을 받게 될 것이다. 피드백의 내용을 해결한 후, 다시 지원하자.

-4. 여러분의 이메일 계정으로 수신된 쿠버네티스 GitHub 조직으로의 초대를 수락한다.
+1. 여러분의 이메일 계정으로 수신된 쿠버네티스 GitHub 조직으로의 초대를 수락한다.

-    {{< note >}}
-    GitHub은 초대를 여러분 계정의 기본 이메일 주소로 보낸다.
-    {{< /note >}}
+   {{< note >}}
+   GitHub은 초대를 여러분 계정의 기본 이메일 주소로 보낸다.
+   {{< /note >}}

 ## 리뷰어

-리뷰어는 열린 풀 리퀘스트를 리뷰할 책임이 있다. 멤버 피드백과는 달리, 여러분은 리뷰어의 피드백을 반드시 해결해야 한다. 리뷰어는 [@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs) GitHub 팀의 멤버이다.
+리뷰어는 열린 풀 리퀘스트를 리뷰할 책임이 있다. 멤버 피드백과는 달리,
+여러분은 리뷰어의 피드백을 반드시 해결해야 한다. 리뷰어는
+[@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs)
+GitHub 팀의 멤버이다.

 리뷰어는 다음의 작업을 수행할 수 있다.

 - [모든 사람](#모든-사람)과 [멤버](#멤버)에 나열된 모든 것을 수행한다.
 - 풀 리퀘스트 리뷰와 구속력 있는 피드백을 제공한다.

-    {{< note >}}
-    구속력 없는 피드백을 제공하려면, 코멘트에 "선택 사항: "과 같은 문구를 접두어로 남긴다.
-    {{< /note >}}
+  {{< note >}}
+  구속력 없는 피드백을 제공하려면, 코멘트에 "선택 사항: "과 같은 문구를 접두어로 남긴다.
+  {{< /note >}}

 - 코드에서 사용자 화면 문자열 편집
 - 코드 코멘트 개선
@@ -107,37 +124,45 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D
 [@_github_handle]` 코멘트를 남겨 특정 사람에게 리뷰를 요청할 수
 있다.

-지정된 리뷰어가 PR에 코멘트를 남기지 않는다면, 다른 리뷰어가 개입할 수 있다. 필요에 따라 기술 리뷰어를 지정할 수도 있다.
+지정된 리뷰어가 PR에 코멘트를 남기지 않는다면, 다른 리뷰어가 개입할 수
+있다. 필요에 따라 기술 리뷰어를 지정할 수도 있다.

 ### `/lgtm` 사용하기

-LGTM은 "Looks good to me"의 약자이며 풀 리퀘스트가 기술적으로 정확하고 병합할 준비가 되었음을 나타낸다. 모든 PR은 리뷰어의 `/lgtm` 코멘트가 필요하고 병합을 위해 승인자의 `/approve` 코멘트가 필요하다.
+LGTM은 "Looks good to me"의 약자이며 풀 리퀘스트가 기술적으로
+정확하고 병합할 준비가 되었음을 나타낸다. 모든 PR은 리뷰어의 `/lgtm` 코멘트가
+필요하고 병합을 위해 승인자의 `/approve` 코멘트가 필요하다.

 리뷰어의 `/lgtm` 코멘트는 구속력 있고 자동화 시스템이 `lgtm` 레이블을 추가하도록 트리거한다.

 ### 리뷰어 되기

 [요건](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer)을
-충족하면, SIG Docs 리뷰어가 될 수 있다. 다른 SIG의 리뷰어는 SIG Docs의 리뷰어 자격에 반드시 별도로 지원해야 한다.
+충족하면, SIG Docs 리뷰어가 될 수 있다. 다른 SIG의 리뷰어는 SIG Docs의 리뷰어 자격에
+반드시 별도로 지원해야 한다.

 지원하려면, 다음을 수행한다.

 1. `kubernetes/website` 리포지터리 내
-[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) 파일의 섹션에
-여러분의 GitHub 사용자 이름을 추가하는 풀 리퀘스트를 연다.
+   [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) 파일의 섹션에
+   여러분의 GitHub 사용자 이름을 추가하는 풀 리퀘스트를 연다.

  {{< note >}}
  자신을 추가할 위치가 확실하지 않으면, `sig-docs-ko-reviews` 에 추가한다.
  {{< /note >}}

-2. PR을 하나 이상의 SIG-Docs 승인자(`sig-docs-{language}-owners` 에 나열된 사용자 이름)에게 지정한다.
+1. PR을 하나 이상의 SIG-Docs 승인자(`sig-docs-{language}-owners` 에
+   나열된 사용자 이름)에게 지정한다.

-승인되면, SIG Docs 리더가 적당한 GitHub 팀에 여러분을 추가한다. 일단 추가되면, [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이 새로운 풀 리퀘스트에서 리뷰어로 여러분을 할당하고 제안한다.
+승인되면, SIG Docs 리더가 적당한 GitHub 팀에 여러분을 추가한다. 일단 추가되면,
+[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이
+새로운 풀 리퀘스트에서 리뷰어로 여러분을 할당하고 제안한다.

 ## 승인자

 승인자는 병합하기 위해 풀 리퀘스트를 리뷰하고 승인한다. 승인자는
-[@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs) GitHub 팀의 멤버이다.
+[@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs)
+GitHub 팀의 멤버이다.

 승인자는 다음의 작업을 할 수 있다.

@@ -147,22 +172,27 @@ LGTM은 "Looks good to me"의 약자이며 풀 리퀘스트가 기술적으로
 - 문서 테스트 개선을 제안한다.
 - 쿠버네티스 웹사이트 또는 다른 도구 개선을 제안한다.

-PR에 이미 `/lgtm` 이 있거나, 승인자도 `/lgtm` 코멘트를 남긴다면, PR은 자동으로 병합된다. SIG Docs 승인자는 추가적인 기술 리뷰가 필요치 않는 변경에 대해서만 `/lgtm` 을 남겨야 한다.
+PR에 이미 `/lgtm` 이 있거나, 승인자도 `/lgtm` 코멘트를 남긴다면,
+PR은 자동으로 병합된다. SIG Docs 승인자는 추가적인 기술 리뷰가 필요치 않는 변경에 대해서만
+`/lgtm` 을 남겨야 한다.


 ### 풀 리퀘스트 승인

-승인자와 SIG Docs 리더는 website 리포지터리로 풀 리퀘스트를 병합할 수 있는 유일한 사람들이다. 이것은 특정한 책임이 따른다.
+승인자와 SIG Docs 리더는 website 리포지터리로 풀 리퀘스트를 병합할 수 있는
+유일한 사람들이다. 이것은 특정한 책임이 따른다.

 - 승인자는 PR들을 리포지터리에 병합하는 `/approve` 명령을 사용할 수 있다.

-    {{< warning >}}
-    부주의한 머지로 인해 사이트를 파괴할 수 있으므로, 머지할 때에 그 의미를 확인해야 한다.
-    {{< /warning >}}
+  {{< warning >}}
+  부주의한 머지로 인해 사이트를 파괴할 수 있으므로, 머지할 때에 그 의미를 확인해야 한다.
+  {{< /warning >}}

- 제안된 변경이 [컨트리뷰션 가이드 라인](/docs/contribute/style/content-guide/#contributing-content)에 적합한지 확인한다.
+- 제안된 변경이
+  [컨트리뷰션 가이드 라인](/docs/contribute/style/content-guide/#contributing-content)에 적합한지 확인한다.

-    질문이 생기거나 확실하지 않다면 자유롭게 추가 리뷰를 요청한다.
+  질문이 생기거나 확실하지 않다면 자유롭게
+  추가 리뷰를 요청한다.

 - PR을 `/approve` 하기 전에 Netlify 테스트 결과를 검토한다.

@@ -170,17 +200,24 @@ PR에 이미 `/lgtm` 이 있거나, 승인자도 `/lgtm` 코멘트를 남긴다

 - 승인 전에 PR에 대한 Netlify 프리뷰 페이지를 방문하여, 제대로 보이는지 확인한다.

- 주간 로테이션을 위해 [PR Wrangler 로테이션 스케줄](https://github.com/kubernetes/website/wiki/PR-Wranglers)에 참여한다. SIG Docs는 모든 승인자들이 이 로테이션에 참여할
-것으로 기대한다. 자세한 내용은 [PR 랭글러(PR wrangler)](/ko/docs/contribute/participating/pr-wranglers/)를
-참고한다.
+- 주간 로테이션을 위해
+  [PR Wrangler 로테이션 스케줄](https://github.com/kubernetes/website/wiki/PR-Wranglers)에
+  참여한다. SIG Docs는 모든 승인자들이 이 로테이션에 참여할 것으로 기대한다. 자세한 내용은
+  [PR 랭글러(PR wrangler)](/ko/docs/contribute/participating/pr-wranglers/)를
+  참고한다.

 ## 승인자 되기

-[요구 사항](https://github.com/kubernetes/community/blob/master/community-membership.md#approver)을 충족하면 SIG Docs 승인자가 될 수 있다. 다른 SIG의 승인자는 SIG Docs의 승인자 자격에 대해 별도로 신청해야 한다.
+[요구 사항](https://github.com/kubernetes/community/blob/master/community-membership.md#approver)을
+충족하면 SIG Docs 승인자가 될 수 있다.
+다른 SIG의 승인자는 SIG Docs의 승인자 자격에 대해
+별도로 신청해야 한다.

 지원하려면 다음을 수행한다.

-1. `kubernetes/website` 리포지터리 내 [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) 파일의 섹션에 자신을 추가하는 풀 리퀘스트를 연다.
+1. `kubernetes/website` 리포지터리 내
+   [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS)
+   파일의 섹션에 자신을 추가하는 풀 리퀘스트를 연다.

    {{< note >}}
    자신을 추가할 위치가 확실하지 않으면, `sig-docs-ko-owners` 에 추가한다.
@@ -188,7 +225,9 @@ PR에 이미 `/lgtm` 이 있거나, 승인자도 `/lgtm` 코멘트를 남긴다

 2. PR에 한 명 이상의 현재 SIG Docs 승인자를 지정한다.

-승인되면, SIG Docs 리더가 적당한 GitHub 팀에 여러분을 추가한다. 일단 추가되면, [@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이 새로운 풀 리퀘스트에서 승인자로 여러분을 할당하고 제안한다.
+승인되면, SIG Docs 리더가 적당한 GitHub 팀에 여러분을 추가한다. 일단 추가되면,
+[@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이
+새로운 풀 리퀘스트에서 승인자로 여러분을 할당하고 제안한다.

 ## {{% heading "whatsnext" %}}

@@ -8,7 +8,9 @@ weight: 20

 <!-- overview -->

-SIG Docs [리뷰어](/ko/docs/contribute/participating/#리뷰어)와 [승인자](/ko/docs/contribute/participating/#승인자)는 변경 사항을 리뷰할 때 몇 가지 추가 작업을 수행한다.
+SIG Docs [리뷰어](/ko/docs/contribute/participate/roles-and-responsibilities/#리뷰어)와
+[승인자](/ko/docs/contribute/participate/roles-and-responsibilities/#승인자)는 변경 사항을
+리뷰할 때 몇 가지 추가 작업을 수행한다.

 매주 특정 문서 승인자 역할의 지원자가
 풀 리퀘스트를 심사하고 리뷰한다. 이
@@ -19,9 +21,6 @@ SIG Docs [리뷰어](/ko/docs/contribute/participating/#리뷰어)와 [승인자
 로테이션 외에도, 봇은 영향을 받는 파일의 소유자를 기반으로
 PR에 대한 리뷰어와 승인자를 할당한다.

-
-
-
 <!-- body -->

 ## PR 리뷰
@@ -201,9 +200,9 @@ SIG Docs가 처리 방법을 문서화할 정도로 다음과 같은 유형의
 ```none
 이 이슈는 지원 요청과 비슷하지만
 문서 관련 이슈와는 관련이 없는 것 같습니다.
-[쿠버네티스 슬랙](http://slack.k8s.io/)의
+[쿠버네티스 슬랙](https://slack.k8s.io/)의
 `#kubernetes-users` 채널에서 질문을 하시기 바랍니다. 또한,
-[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)와
+[Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes)와
 같은 리소스를 검색하여 유사한 질문에 대한 답변을
 얻을 수도 있습니다.

@@ -16,10 +16,9 @@ weight: 10
 리뷰하기 전에, 다음을 수행하는 것이 좋다.

 - 적합한 코멘트를 남길 수 있도록 [콘텐츠 가이드](/docs/contribute/style/content-guide/)와
-[스타일 가이드](/docs/contribute/style/style-guide/)를 읽는다.
- 쿠버네티스 문서화 커뮤니티의 다양한 [역할과 책임](/ko/docs/contribute/participating/#역할과-책임)을 이해한다.
-
-
+  [스타일 가이드](/docs/contribute/style/style-guide/)를 읽는다.
+- 쿠버네티스 문서화 커뮤니티의 다양한
+  [역할과 책임](/ko/docs/contribute/participating/#역할과-책임)을 이해한다.

 <!-- body -->

@@ -10,7 +10,7 @@ weight: 20

 ## {{% heading "prerequisites" %}}

-[기여 시작하기](/docs/contribute/start/)에 설명된 대로 쿠버네티스
+[PR 열기](/ko/docs/contribute/new-content/open-a-pr/)에 설명된 대로 쿠버네티스
 문서 저장소의 포크(fork)를 생성하자.


@@ -13,7 +13,7 @@ weight: 20

 보안 및 주요 API 공지에 대한 이메일을 위해 [kubernetes-security-announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce)) 그룹에 가입하세요.

-[이 링크](https://groups.google.com/forum/feed/kubernetes-announce/msgs/rss_v2_0.xml?num=50)를 사용하여 RSS 피드를 구독할 수 있다.
+[이 링크](https://groups.google.com/forum/feed/kubernetes-security-announce/msgs/rss_v2_0.xml?num=50)를 사용하여 RSS 피드를 구독할 수 있다.

 ## 취약점 보고

@@ -162,6 +162,10 @@ kubectl get pv --sort-by=.spec.capacity.storage
 kubectl get pods --selector=app=cassandra -o \
  jsonpath='{.items[*].metadata.labels.version}'

+# 예를 들어 'ca.crt'와 같이 점이 있는 키값을 검색한다
+kubectl get configmap myconfig \
+  -o jsonpath='{.data.ca\.crt}'
+
 # 모든 워커 노드 조회 (셀렉터를 사용하여 'node-role.kubernetes.io/master'
 # 으로 명명된 라벨의 결과를 제외)
 kubectl get node --selector='!node-role.kubernetes.io/master'
@@ -0,0 +1,6 @@
+---
+title: 설치 도구 레퍼런스
+weight: 50
+toc-hide: true
+---
+
@@ -0,0 +1,6 @@
+---
+title: "Kubeadm"
+weight: 10
+toc-hide: true
+---
+
@@ -0,0 +1,28 @@
+---
+title: kubeadm 개요
+weight: 10
+card:
+  name: reference
+  weight: 40
+---
+<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">Kubeadm은 쿠버네티스 클러스터를 "빠른 경로"로 생성하기 위한 모범 사례인 `kubeadm init`과 `kubeadm join`을 제공하기 위해 구성된 도구이다.
+
+kubeadm은 최소 기능 클러스터(minimum viable cluster)를 시작하고 실행하는 데 필요한 작업을 수행한다. 설계상, 부트스트랩만 다루며, 머신을 프로비저닝하지는 않는다. 마찬가지로, 쿠버네티스 대시보드, 모니터링 솔루션 및 클라우드 별 애드온과 같은 다양한 기능을 갖춘 애드온을 설치하는 것은 범위에 포함되지 않는다.
+
+대신, kubeadm 위에 있는 더 높은 수준의 맞춤형 도구가 구축될 것으로 예상되며, 모든 배포의 기초로서 kubeadm을 사용하면 적합한 클러스터를 보다 쉽게 만들 수 있다.
+
+## 설치하는 방법
+
+kubeadm을 설치하려면 [설치 가이드](/docs/setup/production-environment/tools/kubeadm/install-kubeadm)를 참조한다.
+
+## 다음 내용
+
+* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init): 쿠버네티스 컨트롤 플레인 노드를 부트스트랩 함
+* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join): 쿠버네티스 워커 노드를 부트스트랩 후 클러스터에 결합시킴
+* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade): 쿠버네티스 클러스터를 최신 버전으로 업그레이드
+* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config): kubeadm v1.7.x이하의 버전을 사용하여 클러스터를 초기화한 경우, 클러스터를 설정하여 `kubeadm upgrade`하기 위해 사용
+* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token): `kubeadm join`을 위한 토큰 관리
+* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset): `kubeadm init`나 `kubeadm join`를 의한 호스트에 대해서 변경된 사항을 되돌림
+* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version): kubeadm 버전을 출력
+* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha): 커뮤니티의 피드백 수집을 위해서 기능 미리 보기를 제공
+
@@ -26,7 +26,7 @@ weight: 40
 * API 서버에서 etcd 간의 통신을 위한 클라이언트 인증서
 * 컨트롤러 매니저와 API 서버 간의 통신을 위한 클라이언트 인증서/kubeconfig
 * 스케줄러와 API 서버간 통신을 위한 클라이언트 인증서/kubeconfig
-* [front-proxy][proxy]를 위한 클라이언트와 서버 인증서
+* [front-proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)를 위한 클라이언트와 서버 인증서

 {{< note >}}
 `front-proxy` 인증서는 kube-proxy에서 [API 서버 확장](/docs/tasks/extend-kubernetes/setup-extension-api-server/)을 지원할 때만 kube-proxy에서 필요하다.
@@ -52,7 +52,7 @@ etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다.
 |------------------------|---------------------------|----------------------------------|
 | ca.crt,key             | kubernetes-ca             | 쿠버네티스 일반 CA               |
 | etcd/ca.crt,key        | etcd-ca                   | 모든 etcd 관련 기능을 위해서     |
-| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | [front-end proxy][proxy] 위해서  |
+| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | [front-end proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 위해서  |

 위의 CA외에도, 서비스 계정 관리를 위한 공개/개인 키 쌍인 `sa.key` 와 `sa.pub` 을 얻는 것이 필요하다.

@@ -72,10 +72,10 @@ etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다.
 | kube-apiserver-kubelet-client | kubernetes-ca             | system:masters | client                                 |                                             |
 | front-proxy-client            | kubernetes-front-proxy-ca |                | client                                 |                                             |

-[1]: 클러스터에 접속한 다른 IP 또는 DNS 이름([kubeadm][kubeadm] 이 사용하는 로드 밸런서 안정 IP 또는 DNS 이름, `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`,
+[1]: 클러스터에 접속한 다른 IP 또는 DNS 이름([kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) 이 사용하는 로드 밸런서 안정 IP 또는 DNS 이름, `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`,
 `kubernetes.default.svc.cluster`, `kubernetes.default.svc.cluster.local`)

-`kind`는 하나 이상의 [x509 키 사용][usage] 종류를 가진다.
+`kind`는 하나 이상의 [x509 키 사용](https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage) 종류를 가진다.

 | 종류   | 키 사용                                                                         |
 |--------|---------------------------------------------------------------------------------|
@@ -97,7 +97,7 @@ kubeadm 사용자만 해당:

 ### 인증서 파일 경로

-인증서는 권고하는 파일 경로에 존재해야 한다([kubeadm][kubeadm]에서 사용되는 것처럼). 경로는 위치에 관계없이 주어진 파라미터를 사용하여 지정되야 한다.
+인증서는 권고하는 파일 경로에 존재해야 한다([kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)에서 사용되는 것처럼). 경로는 위치에 관계없이 주어진 파라미터를 사용하여 지정되야 한다.

 | 기본 CN                      | 권고되는 키 파일 경로         | 권고하는 인증서 파일 경로   | 명령어         | 키 파라미터                  | 인증서 파라미터                           |
 |------------------------------|------------------------------|-----------------------------|----------------|------------------------------|-------------------------------------------|
@@ -158,8 +158,3 @@ KUBECONFIG=<filename> kubectl config use-context default-system
 | controller-manager.conf | kube-controller-manager | 반드시 매니페스트를 `manifests/kube-controller-manager.yaml`에 추가해야한다. |
 | scheduler.conf          | kube-scheduler          | 반드시 매니페스트를 `manifests/kube-scheduler.yaml`에 추가해야한다.          |

-[usage]: https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage
-[kubeadm]: /docs/reference/setup-tools/kubeadm/kubeadm/
-[proxy]: /docs/tasks/extend-kubernetes/configure-aggregation-layer/
-
-
@@ -62,12 +62,10 @@ card:

 ## v1.17.0 이후 체인지로그

-릴리스 노트의 전체 체인지로그는 이제 [https://relnotes.k8s.io][1]에서 사용자 정의 가능한
+릴리스 노트의 전체 체인지로그는 이제 [https://relnotes.k8s.io](https://relnotes.k8s.io/?releaseVersions=1.18.0)에서 사용자 정의 가능한
 형식으로 호스팅된다. 확인하고 의견을 보내주기
 바란다!

-[1]: https://relnotes.k8s.io/?releaseVersions=1.18.0
-
 ## 새로운 소식 (주요 테마)

 ### 쿠버네티스 토폴로지 매니저가 베타로 전환 - 정렬!
@@ -15,12 +15,12 @@ content_type: concept

 ## 처음이라면 kubectl을 사용하여 액세스

-최초로 쿠버네티스 API에 액세스할 때 우리는 
+최초로 쿠버네티스 API에 액세스할 때 우리는
 쿠버네티스 CLI인 `kubectl`을 사용하는 것을 추천한다.

-클러스터에 액세스하려면 클러스터의 위치정보를 알아야 하고 클러스터에 접속하기 위한 
-인증정보를 가져야 한다. 일반적으로 이는 당신이 
-[Getting started guide](/ko/docs/setup/)를 다 진행했을 때 자동으로 구성되거나, 
+클러스터에 액세스하려면 클러스터의 위치정보를 알아야 하고 클러스터에 접속하기 위한
+인증정보를 가져야 한다. 일반적으로 이는 당신이
+[Getting started guide](/ko/docs/setup/)를 다 진행했을 때 자동으로 구성되거나,
 다른 사람이 클러스터를 구성하고 당신에게 인증정보와 위치정보를 제공할 수도 있다.

 kubectl이 인지하는 위치정보와 인증정보는 다음 커맨드로 확인한다.
@@ -29,13 +29,13 @@ kubectl이 인지하는 위치정보와 인증정보는 다음 커맨드로 확
 kubectl config view
 ```

-많은 [예제들](/ko/docs/reference/kubectl/cheatsheet/)에서 kubectl을 사용하는 것을 소개하고 있으며 
+많은 [예제들](/ko/docs/reference/kubectl/cheatsheet/)에서 kubectl을 사용하는 것을 소개하고 있으며
 완전한 문서는 [kubectl manual](/docs/user-guide/kubectl-overview)에서 찾아볼 수 있다.

 ## REST API에 직접 액세스

-kubectl은 apiserver의 위치 파악과 인증을 처리한다. 
-만약 당신이 curl, wget 또는 웹브라우저와 같은 http 클라이언트로 
+kubectl은 apiserver의 위치 파악과 인증을 처리한다.
+만약 당신이 curl, wget 또는 웹브라우저와 같은 http 클라이언트로
 REST API에 직접 액세스하려고 한다면 위치 파악과 인증을 하는 몇 가지 방법이 존재한다.

  - kubectl을 proxy 모드로 실행.
@@ -51,8 +51,8 @@ REST API에 직접 액세스하려고 한다면 위치 파악과 인증을 하

 ### kubectl proxy 사용

-다음 커맨드는 kubectl을 reverse proxy처럼 동작하는 모드를 실행한다. 이는 
-apiserver의 위치지정과 인증을 처리한다. 
+다음 커맨드는 kubectl을 reverse proxy처럼 동작하는 모드를 실행한다. 이는
+apiserver의 위치지정과 인증을 처리한다.
 다음과 같이 실행한다.

 ```shell
@@ -61,7 +61,7 @@ kubectl proxy --port=8080

 상세 내용은 [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands/#proxy)를 참조한다

-이후에 당신은 curl, wget, 웹브라우저로 다음과 같이 API를 탐색할 수 있다. localhost는 
+이후에 당신은 curl, wget, 웹브라우저로 다음과 같이 API를 탐색할 수 있다. localhost는
 IPv6 주소 [::1]로도 대체할 수 있다.

 ```shell
@@ -142,22 +142,22 @@ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
 }
 ```

-위 예제에서는 `--insecure` flag를 사용했다. 이는 MITM 공격을 받을 수 있는 상태로 
-두는 것이다. kubectl로 클러스터에 접속할 때 저장된 root 인증서와 클라이언트 인증서들을 
+위 예제에서는 `--insecure` flag를 사용했다. 이는 MITM 공격을 받을 수 있는 상태로
+두는 것이다. kubectl로 클러스터에 접속할 때 저장된 root 인증서와 클라이언트 인증서들을
 서버 접속에 사용한다.
-(이들은 `~/.kube` 디렉터리에 설치된다.) 
-일반적으로 self-signed 인증서가 클러스터 인증서로 사용되므로 당신의 http 클라이언트가 
+(이들은 `~/.kube` 디렉터리에 설치된다.)
+일반적으로 self-signed 인증서가 클러스터 인증서로 사용되므로 당신의 http 클라이언트가
 root 인증서를 사용하려면 특수한 설정을 필요로 할 것이다.

-localhost에서 제공되거나 방화벽으로 보호되는 몇몇 클러스터들에서는 apiserver가 인증을 
-요구하지 않지만 이는 표준이 아니다. 
+localhost에서 제공되거나 방화벽으로 보호되는 몇몇 클러스터들에서는 apiserver가 인증을
+요구하지 않지만 이는 표준이 아니다.
 [Configuring Access to the API](/docs/reference/access-authn-authz/controlling-access/)
-는 클러스터 관리자가 이를 어떻게 구성할 수 있는지를 설명한다. 
+는 클러스터 관리자가 이를 어떻게 구성할 수 있는지를 설명한다.
 이 방식들은 미래의 고가용성 지원과 충돌될 수 있다.

 ## API에 프로그래밍 방식으로 액세스

-쿠버네티스는 공식적으로 [Go](#go-클라이언트)와 [Python](#python-클라이언트) 
+쿠버네티스는 공식적으로 [Go](#go-클라이언트)와 [Python](#python-클라이언트)
 클라이언트 라이브러리를 지원한다.

 ### Go 클라이언트
@@ -165,7 +165,7 @@ localhost에서 제공되거나 방화벽으로 보호되는 몇몇 클러스터
 * 라이브러리를 취득하려면 `go get k8s.io/client-go@kubernetes-<kubernetes-version-number>` 커맨드를 실행한다. [INSTALL.md](https://github.com/kubernetes/client-go/blob/master/INSTALL.md#for-the-casual-user)에서 상세한 설치 방법을 알 수 있다. [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go#compatibility-matrix)에서 어떤 버젼이 지원되는지 확인할 수 있다.
 * client-go 클라이언트 위에 애플리케이션을 작성하자. client-go는 자체적으로 API 오브젝트를 정의하므로 필요하다면 main 레포지터리보다는 client-go에서 API 정의들을 import하기를 바란다. 정확하게 `import "k8s.io/client-go/kubernetes"`로 import하는 것을 예로 들 수 있다.

-Go 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)을 사용할 수 있다. 
+Go 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)을 사용할 수 있다.
 [예제](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)를 참고한다.

 만약 애플리케이션이 클러스터 내에 파드로 배포되었다면 [다음 장](#파드에서-api-액세스)을 참조하기를 바란다.
@@ -174,7 +174,7 @@ Go 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동

 Python 클라이언트를 사용하려면 `pip install kubernetes` 커맨드를 실행한다. 설치 옵션에 대한 상세 사항은 [Python Client Library page](https://github.com/kubernetes-client/python)를 참조한다.

-Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)을 사용할 수 있다. 
+Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)을 사용할 수 있다.
 [예제](https://github.com/kubernetes-client/python/tree/master/examples)를 참조한다.

 ### 다른 언어
@@ -184,44 +184,44 @@ Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와

 ## 파드에서 API 액세스

-파드에서 API를 접속한다면 apiserver의 
+파드에서 API를 접속한다면 apiserver의
 위치지정과 인증은 다소 다르다.

-파드 내에서 apiserver의 위치를 지정하는데 추천하는 방식은 
-`kubernetes.default.svc` DNS 네임을 사용하는 것이다. 
+파드 내에서 apiserver의 위치를 지정하는데 추천하는 방식은
+`kubernetes.default.svc` DNS 네임을 사용하는 것이다.
 이 DNS 네임은 apiserver로 라우팅되는 서비스 IP로 resolve된다.

-apiserver 인증에 추천되는 방식은 
-[서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/) 
-인증정보를 사용하는 것이다. kube-system에 의해 파드는 서비스 어카운트와 연계되며 
-해당 서비스 어카운트의 인증정보(토큰)은 파드 내 각 컨테이너의 파일시스템 트리의 
+apiserver 인증에 추천되는 방식은
+[서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/)
+인증정보를 사용하는 것이다. kube-system에 의해 파드는 서비스 어카운트와 연계되며
+해당 서비스 어카운트의 인증정보(토큰)은 파드 내 각 컨테이너의 파일시스템 트리의
 `/var/run/secrets/kubernetes.io/serviceaccount/token`에 위치한다.

-사용 가능한 경우, 인증서 번들은 각 컨테이너 내 파일시스템 트리의 
-`/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`에 위치하며 
+사용 가능한 경우, 인증서 번들은 각 컨테이너 내 파일시스템 트리의
+`/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`에 위치하며
 apiserver의 인증서 제공을 검증하는데 사용되어야 한다.

-마지막으로 네임스페이스 한정의 API 조작에 사용되는 기본 네임스페이스는 각 컨테이터 내의 
+마지막으로 네임스페이스 한정의 API 조작에 사용되는 기본 네임스페이스는 각 컨테이터 내의
 `/var/run/secrets/kubernetes.io/serviceaccount/namespace` 파일로 존재한다.

 파드 내에서 API에 접근하는데 권장되는 방식은 다음과 같다.

-  - 파드의 sidecar 컨테이너 내에서 `kubectl proxy`를 실행하거나, 
-    컨테이너 내부에서 백그라운드 프로세스로 실행한다. 
-    이는 쿠버네티스 API를 파드의 localhost 인터페이스로 proxy하여 
+  - 파드의 sidecar 컨테이너 내에서 `kubectl proxy`를 실행하거나,
+    컨테이너 내부에서 백그라운드 프로세스로 실행한다.
+    이는 쿠버네티스 API를 파드의 localhost 인터페이스로 proxy하여
    해당 파드의 컨테이너 내에 다른 프로세스가 API에 접속할 수 있게 해준다.
-  - Go 클라이언트 라이브러리를 이용하여 `rest.InClusterConfig()`와 `kubernetes.NewForConfig()` 함수들을 사용하도록 클라이언트를 만든다. 
+  - Go 클라이언트 라이브러리를 이용하여 `rest.InClusterConfig()`와 `kubernetes.NewForConfig()` 함수들을 사용하도록 클라이언트를 만든다.
    이는 apiserver의 위치지정과 인증을 처리한다. [예제](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)

 각각의 사례에서 apiserver와의 보안 통신에 파드의 인증정보가 사용된다.

 ## 클러스터에서 실행되는 서비스로 액세스

-이전 장은 쿠버네티스 API server 접속에 대한 내용을 다루었다. 이번 장은 
-쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다. 쿠버네티스에서 
-[노드들](/ko/docs/concepts/architecture/nodes/), [파드들](/ko/docs/concepts/workloads/pods/pod/), [서비스들](/docs/user-guide/services)은 
-모두 자신의 IP들을 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는 
-클러스터 상의 노드 IP들, 파드 IP들, 서비스 IP들로 라우팅되지 않아서 접근을 
+이전 장은 쿠버네티스 API server 접속에 대한 내용을 다루었다. 이번 장은
+쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다. 쿠버네티스에서
+[노드들](/ko/docs/concepts/architecture/nodes/), [파드들](/ko/docs/concepts/workloads/pods/pod/), [서비스들](/docs/user-guide/services)은
+모두 자신의 IP들을 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는
+클러스터 상의 노드 IP들, 파드 IP들, 서비스 IP들로 라우팅되지 않아서 접근을
 할 수 없을 것이다.

 ### 통신을 위한 방식들
@@ -229,33 +229,33 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다.
 클러스터 외부에서 노드들, 파드들, 서비스들에 접속하는 데는 몇 가지 선택지들이 있다.

  - 공인 IP를 통해 서비스에 액세스.
-    - 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의 
-      서비스를 사용한다. [서비스](/docs/user-guide/services)와 
+    - 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의
+      서비스를 사용한다. [서비스](/docs/user-guide/services)와
      [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참조한다.
-    - 당신의 클러스터 환경에 따라 회사 네트워크에만 서비스를 노출하거나 
-      인터넷으로 노출할 수 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다. 
+    - 당신의 클러스터 환경에 따라 회사 네트워크에만 서비스를 노출하거나
+      인터넷으로 노출할 수 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다.
      해당 서비스는 자체적으로 인증을 수행하는가?
-    - 파드들은 서비스 뒤에 위치시킨다. 레플리카들의 집합에서 특정 파드 하나에 debugging 같은 목적으로 접근하려면 
+    - 파드들은 서비스 뒤에 위치시킨다. 레플리카들의 집합에서 특정 파드 하나에 debugging 같은 목적으로 접근하려면
      해당 파드에 고유의 레이블을 붙이고 셀렉터에 해당 레이블을 선택한 신규 서비스를 생성한다.
-    - 대부분의 경우에는 애플리케이션 개발자가 노드 IP를 통해 직접 노드에 
+    - 대부분의 경우에는 애플리케이션 개발자가 노드 IP를 통해 직접 노드에
      액세스할 필요는 없다.
  - Proxy Verb를 사용하여 서비스, 노드, 파드에 액세스.
-    - 원격 서비스에 액세스하기에 앞서 apiserver의 인증과 인가를 받아야 한다. 
-      서비스가 인터넷에 노출하기에 보안이 충분하지 않거나 노드 IP 상의 port에 
+    - 원격 서비스에 액세스하기에 앞서 apiserver의 인증과 인가를 받아야 한다.
+      서비스가 인터넷에 노출하기에 보안이 충분하지 않거나 노드 IP 상의 port에
      액세스를 취득하려고 하거나 debugging을 하려면 이를 사용한다.
    - 어떤 web 애플리케이션에서는 proxy가 문제를 일으킬 수 있다.
    - HTTP/HTTPS에서만 동작한다.
    - [여기](#수작업으로-apiserver-proxy-url들을-구축)에서 설명하고 있다.
  - 클러스터 내 노드 또는 파드에서 액세스.
-    - 파드를 Running시킨 다음 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 해당 파드의 셸로 접속한다. 
+    - 파드를 Running시킨 다음 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 해당 파드의 셸로 접속한다.
      해당 셸에서 다른 노드들, 파드들, 서비스들에 연결한다.
-    - 어떤 클러스터는 클러스터 내의 노드에 ssh 접속을 허용하기도 한다. 이런 클러스터에서는 
-      클러스터 서비스에 액세스도 가능하다. 이는 비표준 방식으로 특정 클러스터에서는 동작하지만 
+    - 어떤 클러스터는 클러스터 내의 노드에 ssh 접속을 허용하기도 한다. 이런 클러스터에서는
+      클러스터 서비스에 액세스도 가능하다. 이는 비표준 방식으로 특정 클러스터에서는 동작하지만
      다른 클러스터에서는 동작하지 않을 수 있다. 브라우저와 다른 도구들이 설치되지 않았거나 설치되었을 수 있다. 클러스터 DNS가 동작하지 않을 수도 있다.

 ### 빌트인 서비스들의 발견

-일반적으로 kube-system에 의해 클러스터 상에서 start되는 몇 가지 서비스들이 존재한다. 
+일반적으로 kube-system에 의해 클러스터 상에서 start되는 몇 가지 서비스들이 존재한다.
 `kubectl cluster-info` 커맨드로 이 서비스들의 리스트를 볼 수 있다.

 ```shell
@@ -273,15 +273,15 @@ grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/servic
 heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
 ```

-이는 각 서비스에 액세스하기 위한 proxy-verb URL을 보여준다. 
-예를 들어 위 클러스터는 클러스터 수준의 logging(Elasticsearch 사용)이 활성화되었으므로 적절한 인증을 통과하여 
-`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`로 액세스할 수 있다. 예를 들어 kubectl proxy로 
+이는 각 서비스에 액세스하기 위한 proxy-verb URL을 보여준다.
+예를 들어 위 클러스터는 클러스터 수준의 logging(Elasticsearch 사용)이 활성화되었으므로 적절한 인증을 통과하여
+`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`로 액세스할 수 있다. 예를 들어 kubectl proxy로
 `http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`를 통해 logging에 액세스할 수도 있다.
-(인증을 통과하는 방법이나 kubectl proxy를 사용하는 것은 [쿠버네티스 API를 사용해서 클러스터에 접근하기](/docs/tasks/administer-cluster/access-cluster-api/)을 참조한다.)
+(인증을 통과하는 방법이나 kubectl proxy를 사용하는 것은 [쿠버네티스 API를 사용해서 클러스터에 접근하기](/ko/docs/tasks/administer-cluster/access-cluster-api/)을 참조한다.)

 #### 수작업으로 apiserver proxy URL을 구축

-위에서 언급한 것처럼 서비스의 proxy URL을 검색하는데 `kubectl cluster-info` 커맨드를 사용할 수 있다. 서비스 endpoint, 접미사, 매개변수를 포함하는 proxy URL을 생성하려면 단순하게 해당 서비스에 
+위에서 언급한 것처럼 서비스의 proxy URL을 검색하는데 `kubectl cluster-info` 커맨드를 사용할 수 있다. 서비스 endpoint, 접미사, 매개변수를 포함하는 proxy URL을 생성하려면 단순하게 해당 서비스에
 `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy` 형식의 proxy URL을 덧붙인다.

 당신이 port에 이름을 지정하지 않았다면 URL에 *port_name* 을 지정할 필요는 없다.
@@ -300,7 +300,7 @@ URL의 네임 부분에 지원되는 양식은 다음과 같다.

 * Elasticsearch 서비스 endpoint `_search?q=user:kimchy`에 액세스하려면 `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`를 사용할 수 있다.
 * Elasticsearch 클러스터 상태 정보 `_cluster/health?pretty=true`에 액세스하려면 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`를 사용할 수 있다.
- 
+
 ```json
 {
  "cluster_name" : "kubernetes_logging",
@@ -320,9 +320,9 @@ URL의 네임 부분에 지원되는 양식은 다음과 같다.

 브라우저의 주소창에 apiserver proxy url을 넣을 수도 있다. 하지만

-  - 웹브라우저는 일반적으로 토큰을 전달할 수 없으므로 basic (password) auth를 사용해야 할 것이다. basic auth를 수용할 수 있도록 apiserver를 구성할 수 있지만, 
+  - 웹브라우저는 일반적으로 토큰을 전달할 수 없으므로 basic (password) auth를 사용해야 할 것이다. basic auth를 수용할 수 있도록 apiserver를 구성할 수 있지만,
    당신의 클러스터가 basic auth를 수용할 수 있도록 구성되어 있지 않을 수도 있다.
-  - 몇몇 web app은 동작하지 않을 수도 있다. 특히 proxy path prefix를 인식하지 않는 방식으로 url을 
+  - 몇몇 web app은 동작하지 않을 수도 있다. 특히 proxy path prefix를 인식하지 않는 방식으로 url을
    구성하는 client side javascript를 가진 web app은 동작하지 않을 수 있다.

 ## 요청 redirect
@@ -373,7 +373,5 @@ redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) proxy
    - UDP/TCP 만 사용한다
    - cloud provider마다 구현된 내용이 상이하다

-일반적으로 쿠버네티스 사용자들은 처음 두 타입이 아닌 다른 방식은 고려할 필요가 없지만 클러스터 관리자는 
+일반적으로 쿠버네티스 사용자들은 처음 두 타입이 아닌 다른 방식은 고려할 필요가 없지만 클러스터 관리자는
 나머지 타입을 적절하게 구성해줘야 한다.
-
-
@@ -8,6 +8,4 @@ content_type: concept
 쿠버네티스는 지원하는 모든 환경에서 기본으로 활성화된 DNS 클러스터 애드온을 제공한다. 쿠버네티스 1.11과 이후 버전에서는, CoreDNS가 권장되고 기본적으로 kubeadm과 함께 설치 된다.

 <!-- body -->
-쿠버네티스 클러스터의 CoreDNS 설정에 대한 더 많은 정보는, [DNS 서비스 사용자화 하기](/docs/tasks/administer-cluster/dns-custom-nameservers/)을 본다. kube-dns와 함께 쿠버네티스 DNS를 사용하는 방법을 보여주는 예시는 [쿠버네티스 DNS 샘플 플러그인](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)을 본다.
-
-
+쿠버네티스 클러스터의 CoreDNS 설정에 대한 더 많은 정보는, [DNS 서비스 사용자화 하기](/ko/docs/tasks/administer-cluster/dns-custom-nameservers/)을 본다. kube-dns와 함께 쿠버네티스 DNS를 사용하는 방법을 보여주는 예시는 [쿠버네티스 DNS 샘플 플러그인](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)을 본다.
@@ -0,0 +1,158 @@
+---
+title: 클러스터 내 애플리케이션에 접근하기 위해 서비스 사용하기
+content_type: tutorial
+weight: 60
+---
+
+<!-- overview -->
+
+이 문서는 외부 클라이언트가 클러스터에서 실행 중인 애플리케이션에 접근하기
+위해 사용하는 쿠버네티스 서비스 오브젝트를 생성하는 방법을 설명한다. 서비스는
+실행 중인 두 개의 인스턴스를 갖는 애플리케이션에 대한 로드 밸런싱을 제공한다.
+
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+
+## {{% heading "objectives" %}}
+
+
+* Hello World 애플리케이션 인스턴스 두 개를 실행한다.
+* 노드 포트를 노출하는 서비스 오브젝트를 생성한다.
+* 실행 중인 애플리케이션에 접근하기 위해 서비스 오브젝트를 사용한다.
+
+
+
+
+<!-- lessoncontent -->
+
+## 두 개의 파드에서 실행 중인 애플리케이션에 대한 서비스 생성하기
+
+다음은 애플리케이션 디플로이먼트(Deployment) 설정 파일이다.
+
+{{< codenew file="service/access/hello-application.yaml" >}}
+
+1. 클러스터 내 Hello World 애플리케이션을 실행하자.
+   위 파일을 사용하여 애플리케이션 디플로이먼트를 생성하자.
+   ```shell
+   kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml
+   ```
+   앞의 명령은
+   [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)
+   오브젝트와 연관된
+   [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/)
+   오브젝트를 생성한다. 레플리카셋은 두 개의
+   [파드](/ko/docs/concepts/workloads/pods/pod/)를 갖고,
+   각각은 Hello World 애플리케이션을 실행한다.
+
+1. 디플로이먼트에 대한 정보를 보여준다.
+   ```shell
+   kubectl get deployments hello-world
+   kubectl describe deployments hello-world
+   ```
+
+1. 레플리카셋 오브젝트에 대한 정보를 보여준다.
+   ```shell
+   kubectl get replicasets
+   kubectl describe replicasets
+   ```
+
+1. 디플로이먼트를 노출하는 서비스 오브젝트를 생성한다.
+   ```shell
+   kubectl expose deployment hello-world --type=NodePort --name=example-service
+   ```
+
+1. 서비스에 대한 정보를 보여준다.
+   ```shell
+   kubectl describe services example-service
+   ```
+   결과는 아래와 같다.
+   ```shell
+   Name:                   example-service
+   Namespace:              default
+   Labels:                 run=load-balancer-example
+   Annotations:            <none>
+   Selector:               run=load-balancer-example
+   Type:                   NodePort
+   IP:                     10.32.0.16
+   Port:                   <unset> 8080/TCP
+   TargetPort:             8080/TCP
+   NodePort:               <unset> 31496/TCP
+   Endpoints:              10.200.1.4:8080,10.200.2.5:8080
+   Session Affinity:       None
+   Events:                 <none>
+   ```
+   서비스의 노드포트(NodePort) 값을 메모하자. 예를 들어,
+   앞선 결과에서, 노드포트 값은 31496이다.
+
+1. Hello World 애플리케이션이 실행 중인 파드를 나열한다.
+   ```shell
+   kubectl get pods --selector="run=load-balancer-example" --output=wide
+   ```
+   결과는 아래와 같다.
+   ```shell
+   NAME                           READY   STATUS    ...  IP           NODE
+   hello-world-2895499144-bsbk5   1/1     Running   ...  10.200.1.4   worker1
+   hello-world-2895499144-m1pwt   1/1     Running   ...  10.200.2.5   worker2
+   ```
+1. Hello World 파드가 실행 중인 노드들 중 하나의 노드에 대해 공용
+   IP 주소를 얻자. 이 주소를 얻는 방법은 어떻게 클러스터를 설치했는지에
+   따라 다르다. 예를 들어, Minikube를 사용하면, `kubectl cluster-info`를
+   실행하여 노드 주소를 알 수 있다. Google Compute Engine 인스턴스를
+   사용하면, `gcloud compute instances list` 명령어를
+   사용하여 노드들의 공용 주소를 알 수
+   있다.
+
+1. 선택한 노드에서 노드 포트에 대해 TCP 통신을 허용하도록 방화벽 규칙을
+   생성하자. 예를 들어, 서비스의 노드포트 값이 31568인 경우,
+   31568 포트로 TCP 통신을 허용하도록 방화벽 규칙을 생성하자. 다른
+   클라우드 공급자는 방화벽 규칙을 설정하는 다른 방법을 제공한다.
+
+1. Hello World 애플리케이션 접근을 위해 노드 주소와 노드 포트를 사용하자.
+   ```shell
+   curl http://<public-node-ip>:<node-port>
+   ```
+   `<public-node-ip>`는 노드의 공용 IP 주소이고,
+   `<node-port>`는 서비스의 노드포트 값이다.
+   성공적인 요청에 대한 응답은 hello 메시지이다.
+   ```shell
+   Hello Kubernetes!
+   ```
+
+## 서비스 설정 파일 사용하기
+
+`kubectl expose`를 사용하는 대신,
+[서비스 설정 파일](/ko/docs/concepts/services-networking/service/)을 사용해
+서비스를 생성할 수 있다.
+
+
+
+
+## {{% heading "cleanup" %}}
+
+
+서비스를 삭제하기 위해 다음 명령어를 입력하자.
+
+    kubectl delete services example-service
+
+디플로이먼트, 레플리카셋, Hello World 애플리케이션이 실행 중인 파드를
+삭제하기 위해 다음 명령어를 입력하자.
+
+    kubectl delete deployment hello-world
+
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+[서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)에
+대해 더 알아본다.
+
@@ -258,4 +258,4 @@ kube-dns를 CoreDNS로 교체하여 적용하는 방법에 대한 상세 정보

 ## {{% heading "whatsnext" %}}

- [DNS 변환 디버깅하기](/docs/tasks/debug-application-cluster/dns-debugging-resolution/) 읽기
+- [DNS 변환 디버깅하기](/docs/tasks/administer-cluster/dns-debugging-resolution/) 읽기
@@ -10,15 +10,11 @@ weight: 10

 [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)으로 생성된 클라이언트 인증서는 1년 후에 만료된다. 이 페이지는 kubeadm으로 인증서 갱신을 관리하는 방법을 설명한다.

-
-
 ## {{% heading "prerequisites" %}}


 [쿠버네티스의 PKI 인증서와 요구 조건](/ko/docs/setup/best-practices/certificates/)에 익숙해야 한다.

-
-
 <!-- steps -->

 ## 사용자 정의 인증서 사용 {#custom-certificates}
@@ -153,33 +149,29 @@ HA 클러스터를 실행 중인 경우, 모든 컨트롤 플레인 노드에서
 ### 서명자 설정

 쿠버네티스 인증 기관(Certificate Authority)은 기본적으로 작동하지 않는다.
-[cert-manager][cert-manager-issuer] 와 같은 외부 서명자를 설정하거나, 빌트인 서명자를 사용할 수 있다.
+[cert-manager](https://docs.cert-manager.io/en/latest/tasks/issuers/setup-ca.html)와 같은 외부 서명자를 설정하거나, 빌트인 서명자를 사용할 수 있다.

-빌트인 서명자는 [`kube-controller-manager`][kcm] 의 일부이다.
+빌트인 서명자는 [`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/)의 일부이다.

 빌트인 서명자를 활성화하려면, `--cluster-signing-cert-file` 와 `--cluster-signing-key-file` 플래그를 전달해야 한다.

-새 클러스터를 생성하는 경우, kubeadm [구성 파일][config]을 사용할 수 있다.
+새 클러스터를 생성하는 경우, kubeadm [구성 파일](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)을 사용할 수 있다.

-  ```yaml
-  apiVersion: kubeadm.k8s.io/v1beta2
-  kind: ClusterConfiguration
-  controllerManager:
-    extraArgs:
-      cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt
-      cluster-signing-key-file: /etc/kubernetes/pki/ca.key
-  ```
-
-[cert-manager-issuer]: https://docs.cert-manager.io/en/latest/tasks/issuers/setup-ca.html
-[kcm]: /docs/reference/command-line-tools-reference/kube-controller-manager/
-[config]: https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2
+```yaml
+apiVersion: kubeadm.k8s.io/v1beta2
+kind: ClusterConfiguration
+controllerManager:
+  extraArgs:
+    cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt
+    cluster-signing-key-file: /etc/kubernetes/pki/ca.key
+```

 ### 인증서 서명 요청(CSR) 생성

 `kubeadm alpha certs renew --use-api` 로 쿠버네티스 인증서 API에 대한 인증서 서명 요청을 만들 수 있다.

-[cert-manager][cert-manager] 와 같은 외부 서명자를 설정하면, 인증서 서명 요청(CSR)이 자동으로 승인된다.
-그렇지 않으면, [`kubectl certificate`][certs] 명령을 사용하여 인증서를 수동으로 승인해야 한다.
+[cert-manager](https://github.com/jetstack/cert-manager)와 같은 외부 서명자를 설정하면, 인증서 서명 요청(CSR)이 자동으로 승인된다.
+그렇지 않으면, [`kubectl certificate`](/ko/docs/setup/best-practices/certificates/) 명령을 사용하여 인증서를 수동으로 승인해야 한다.
 다음의 kubeadm 명령은 승인할 인증서 이름을 출력한 다음, 승인이 발생하기를 차단하고 기다린다.

 ```shell
@@ -195,7 +187,7 @@ sudo kubeadm alpha certs renew apiserver --use-api &

 외부 서명자를 설정하면, 인증서 서명 요청(CSR)이 자동으로 승인된다.

-그렇지 않으면, [`kubectl certificate`][certs] 명령을 사용하여 인증서를 수동으로 승인해야 한다. 예를 들어 다음과 같다.
+그렇지 않으면, [`kubectl certificate`](/ko/docs/setup/best-practices/certificates/) 명령을 사용하여 인증서를 수동으로 승인해야 한다. 예를 들어 다음과 같다.

 ```shell
 kubectl certificate approve kubeadm-cert-kube-apiserver-ld526
@@ -227,20 +219,14 @@ CSR과 함께 제공되는 개인 키가 모두 출력된다.
 `kubeadm init` 과 마찬가지로 출력 디렉터리를 `--csr-dir` 플래그로 지정할 수 있다.

 CSR에는 인증서 이름, 도메인 및 IP가 포함되지만, 용도를 지정하지는 않는다.
-인증서를 발행할 때 [올바른 인증서 용도][cert-table]를 지정하는 것은 CA의 책임이다.
+인증서를 발행할 때 [올바른 인증서 용도](/ko/docs/setup/best-practices/certificates/#모든-인증서)를 지정하는 것은 CA의 책임이다.

-* `openssl` 의 경우 [`openssl ca` command][openssl-ca] 명령으로 수행한다.
-* `cfssl` 의 경우 [설정 파일에 용도][cfssl-usages]를 지정한다.
+* `openssl` 의 경우
+  [`openssl ca` 명령](https://superuser.com/questions/738612/openssl-ca-keyusage-extension)으로 수행한다.
+* `cfssl` 의 경우 [설정 파일에 용도](https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170)를 지정한다.

 선호하는 방법으로 인증서에 서명한 후, 인증서와 개인 키를 PKI 디렉터리(기본적으로 `/etc/kubernetes/pki`)에 복사해야 한다.

-[cert-manager]: https://github.com/jetstack/cert-manager
-[openssl-ca]: https://superuser.com/questions/738612/openssl-ca-keyusage-extension
-[cfssl-usages]: https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170
-[certs]: /ko/docs/setup/best-practices/certificates/
-[cert-cas]: /ko/docs/setup/best-practices/certificates/#단일-루트-ca
-[cert-table]: /ko/docs/setup/best-practices/certificates/#모든-인증서
-
 ## 인증 기관(CA) 순환(rotation) {#certificate-authority-rotation}

 Kubeadm은 CA 인증서의 순환이나 교체 기능을 기본적으로 지원하지 않는다.
@@ -49,5 +49,4 @@ Kubeadm을 이용해서 15분 이내에 지역 단일 호스트 캘리코 클러
 ## {{% heading "whatsnext" %}}

 클러스터가 동작하면, 쿠버네티스 네트워크 폴리시(NetworkPolicy)를 시도하기 위해
-[네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
-
+[네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
@@ -102,9 +102,6 @@ cilium-6rxbd    1/1     Running   0          1m

 클러스터가 동작하면,
 실리움으로 쿠버네티스 네트워크 폴리시를 시도하기 위해
-[네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
+[네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
 재미있게 즐기고, 질문이 있다면
 [실리움 슬랙 채널](https://cilium.herokuapp.com/)을 이용하여 연락한다.
-
-
-
@@ -22,7 +22,4 @@ weight: 30

 ## {{% heading "whatsnext" %}}

-큐브 라우터 애드온을 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
-
-
-
+큐브 라우터 애드온을 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
@@ -38,4 +38,4 @@ Kubeadm을 위한 [컨테이너화된 설치 안내서](https://github.com/roman
 ## {{% heading "whatsnext" %}}


-로마나를 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
+로마나를 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
@@ -52,8 +52,4 @@ weave-net-pmw8w                         2/2       Running   0          9d
 ## {{% heading "whatsnext" %}}


-위브넷 애드온을 설치하고 나서, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. 질문이 있으면 [슬랙 #weave-community 이나 Weave 유저그룹](https://github.com/weaveworks/weave#getting-help)에 연락한다.
-
-
-
-
+위브넷 애드온을 설치하고 나서, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. 질문이 있으면 [슬랙 #weave-community 이나 Weave 유저그룹](https://github.com/weaveworks/weave#getting-help)에 연락한다.
@@ -88,4 +88,4 @@ init-demo 파드 내 실행 중인 nginx 컨테이너의 셸을 실행한다.
 대해 배우기.
 * [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)에 대해 배우기.
 * [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 배우기.
-* [초기화 컨테이너 디버깅](/docs/tasks/debug-application-cluster/debug-init-containers/)에 대해 배우기.
+* [초기화 컨테이너 디버깅](/ko/docs/tasks/debug-application-cluster/debug-init-containers/)에 대해 배우기.
@@ -115,4 +115,4 @@ glossary_tooltip text="kubelet" term_id="kubelet" >}} 및 {{<
 glossary_tooltip text="kube-apiserver"
 term_id="kube-apiserver" >}} (`--feature-gates=HugePageStorageMediumSize=true`)의
 `HugePageStorageMediumSize` [기능
-게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 활성화할 수 있다.
+게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 활성화할 수 있다.
@@ -119,7 +119,7 @@ web-1     1/1       Running   0         18s
 ```

 참고로 `web-1` 파드는 `web-0` 파드가 _Running_ ([파드의 단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계-phase) 참고)
-및 _Ready_ ([파드의 조건](/docs/concepts/workloads/pods/pod-lifecycle/#파드의-조건-condition)에서 `type` 참고) 상태가 되기 전에 시작하지 않음을 주의하자.
+및 _Ready_ ([파드의 조건](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-조건-condition)에서 `type` 참고) 상태가 되기 전에 시작하지 않음을 주의하자.

 ## 스테이트풀셋 안에 파드