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)을 본다.
-
-