Merge pull request #28739 from kubernetes/dev-1.21-ko.5

[ko] 5th Korean localization work for v1.21
2021-07-01 18:08:12 -07:00
parent 0b3ee6bbd5 a0cab7282a
commit e87ee3e927
136 changed files with 996 additions and 498 deletions
@@ -159,11 +159,11 @@ IP 주소 관리 도구, 스토리지 서비스, 클라우드 제공자의 API
 또는 쿠버네티스 외부에서 실행할 수 있다. 가장 적합한 것은 특정 컨트롤러의 기능에
 따라 달라진다.

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

 * [쿠버네티스 컨트롤 플레인](/ko/docs/concepts/overview/components/#컨트롤-플레인-컴포넌트)에 대해 읽기
 * [쿠버네티스 오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/)의 몇 가지 기본 사항을 알아보자.
 * [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)에 대해 더 배워 보자.
-* 만약 자신만의 컨트롤러를 작성하기 원한다면, 쿠버네티스 확장하기의 [확장 패턴](/ko/docs/concepts/extend-kubernetes/extend-cluster/#익스텐션-패턴)을 본다.
+* 만약 자신만의 컨트롤러를 작성하기 원한다면, 
+  쿠버네티스 확장하기의 [확장 패턴](/ko/docs/concepts/extend-kubernetes/#익스텐션-패턴)을 
+  본다.
@@ -1,5 +1,4 @@
 ---
-
 title: kubelet 가비지(Garbage) 수집 설정하기
 content_type: concept
 weight: 70
@@ -7,12 +6,13 @@ weight: 70

 <!-- overview -->

-가비지 수집은 사용되지 않는 [이미지](/ko/docs/concepts/containers/#컨테이너-이미지)들과 [컨테이너](/ko/docs/concepts/containers/)들을 정리하는 kubelet의 유용한 기능이다. Kubelet은 1분마다 컨테이너들에 대하여 가비지 수집을 수행하며, 5분마다 이미지들에 대하여 가비지 수집을 수행한다.
-
-별도의 가비지 수집 도구들을 사용하는 것은, 이러한 도구들이 존재할 수도 있는 컨테이너들을 제거함으로써 kubelet 을 중단시킬 수도 있으므로 권장하지 않는다.
-
-
+가비지 수집은 사용되지 않는 
+[이미지](/ko/docs/concepts/containers/#컨테이너-이미지)들과 
+[컨테이너](/ko/docs/concepts/containers/)들을 정리하는 kubelet의 유용한 기능이다. Kubelet은 
+1분마다 컨테이너들에 대하여 가비지 수집을 수행하며, 5분마다 이미지들에 대하여 가비지 수집을 수행한다.

+별도의 가비지 수집 도구들을 사용하는 것은, 이러한 도구들이 존재할 수도 있는 컨테이너들을 제거함으로써 
+kubelet을 중단시킬 수도 있으므로 권장하지 않는다.

 <!-- body -->

@@ -28,10 +28,24 @@ weight: 70

 ## 컨테이너 수집

-컨테이너에 대한 가비지 수집 정책은 세 가지 사용자 정의 변수들을 고려한다: `MinAge` 는 컨테이너를 가비지 수집 할 수 있는 최소 연령이다. `MaxPerPodContainer` 는 모든 단일 파드 (UID, 컨테이너 이름) 쌍이 가질 수 있는
-최대 비활성 컨테이너의 수량이다. `MaxContainers` 죽은 컨테이너의 최대 수량이다. 이러한 변수는 `MinAge` 를 0으로 설정하고, `MaxPerPodContainer` 와 `MaxContainers` 를 각각 0 보다 작게 설정해서 비활성화 할 수 있다.
+컨테이너에 대한 가비지 수집 정책은 세 가지 사용자 정의 변수들을 고려한다. 
+`MinAge` 는 컨테이너를 가비지 수집할 수 있는 최소 연령이다. 
+`MaxPerPodContainer` 는 모든 단일 파드(UID, 컨테이너 이름) 
+쌍이 가질 수 있는 최대 비활성 컨테이너의 수량이다. 
+`MaxContainers` 는 죽은 컨테이너의 최대 수량이다. 
+이러한 변수는 `MinAge` 를 0으로 설정하고, 
+`MaxPerPodContainer` 와 `MaxContainers` 를 각각 0 보다 작게 설정해서 비활성화할 수 있다.

-Kubelet은 미확인, 삭제 또는 앞에서 언급 한 플래그가 설정 한 경계를 벗어나거나, 확인되지 않은 컨테이너에 대해 조치를 취한다. 일반적으로 가장 오래된 컨테이너가 먼저 제거된다. `MaxPerPodContainer` 와 `MaxContainer` 는 파드 당 최대 컨테이너 수 (`MaxPerPodContainer`)가 허용 가능한 범위의 전체 죽은 컨테이너의 수(`MaxContainers`)를 벗어나는 상황에서 잠재적으로 서로 충돌할 수 있습니다. 이러한 상황에서 `MaxPerPodContainer` 가 조정된다: 최악의 시나리오는 `MaxPerPodContainer` 를 1로 다운그레이드하고 가장 오래된 컨테이너를 제거하는 것이다. 추가로, 삭제된 파드가 소유 한 컨테이너는 `MinAge` 보다 오래된 컨테이너가 제거된다.
+Kubelet은 미확인, 삭제 또는 앞에서 언급한 
+플래그가 설정한 경계를 벗어나거나, 확인되지 않은 컨테이너에 대해 조치를 취한다. 
+일반적으로 가장 오래된 컨테이너가 먼저 제거된다. `MaxPerPodContainer` 와 `MaxContainer` 는 
+파드 당 최대 
+컨테이너 수(`MaxPerPodContainer`)가 허용 가능한 범위의 
+전체 죽은 컨테이너의 수(`MaxContainers`)를 벗어나는 상황에서 잠재적으로 서로 충돌할 수 있다. 
+다음의 상황에서 `MaxPerPodContainer` 가 조정된다. 
+최악의 시나리오는 `MaxPerPodContainer` 를 1로 다운그레이드하고 
+가장 오래된 컨테이너를 제거하는 것이다. 추가로, 삭제된 파드가 소유한 컨테이너는 
+`MinAge` 보다 오래되면 제거된다.

 kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대상이 아니다.

@@ -40,9 +54,9 @@ kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대
 여러분은 후술될 kubelet 플래그들을 통하여 이미지 가비지 수집을 조정하기 위하여 다음의 임계값을 조정할 수 있다.

 1. `image-gc-high-threshold`, 이미지 가비지 수집을 발생시키는 디스크 사용량의 비율로
-기본값은 85% 이다.
+ 기본값은 85% 이다.
 2. `image-gc-low-threshold`, 이미지 가비지 수집을 더 이상 시도하지 않는 디스크 사용량의 비율로
-기본값은 80% 이다.
+ 기본값은 80% 이다.

 다음의 kubelet 플래그를 통해 가비지 수집 정책을 사용자 정의할 수 있다.

@@ -77,9 +91,7 @@ kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대
 | `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | 축출이 다른 리소스에 대한 디스크 임계값을 일반화 함 |
 | `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | 축출이 다른 리소스로의 디스크 압력전환을 일반화 함 |

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

-
-자세한 내용은 [리소스 부족 처리 구성](/docs/tasks/administer-cluster/out-of-resource/)를 본다.
+자세한 내용은 [리소스 부족 처리 구성](/docs/concepts/scheduling-eviction/node-pressure-eviction/)를 
+본다.
@@ -20,7 +20,7 @@ weight: 60
 klog는 쿠버네티스의 로깅 라이브러리다. [klog](https://github.com/kubernetes/klog)
 는 쿠버네티스 시스템 컴포넌트의 로그 메시지를 생성한다.

-klog 설정에 대한 더 많은 정보는, [커맨드라인 툴](/docs/reference/command-line-tools-reference/)을 참고한다.
+klog 설정에 대한 더 많은 정보는, [커맨드라인 툴](/ko/docs/reference/command-line-tools-reference/)을 참고한다.

 klog 네이티브 형식 예 : 
 ```
@@ -61,7 +61,7 @@ I1025 00:15:15.525108       1 controller_utils.go:116] "Pod status updated" pod=

 {{<warning >}}

-JSON 출력은 많은 표준 klog 플래그를 지원하지 않는다. 지원하지 않는 klog 플래그 목록은, [커맨드라인 툴](/docs/reference/command-line-tools-reference/)을 참고한다.
+JSON 출력은 많은 표준 klog 플래그를 지원하지 않는다. 지원하지 않는 klog 플래그 목록은, [커맨드라인 툴](/ko/docs/reference/command-line-tools-reference/)을 참고한다.

 모든 로그가 JSON 형식으로 작성되는 것은 아니다(예: 프로세스 시작 중). 로그를 파싱하려는 경우
 JSON 형식이 아닌 로그 행을 처리할 수 있는지 확인해야 한다.
@@ -143,6 +143,6 @@ systemd를 사용하는 시스템에서는, kubelet과 컨테이너 런타임은

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

-* [쿠버네티스 로깅 아키텍처](/docs/concepts/cluster-administration/logging/) 알아보기
+* [쿠버네티스 로깅 아키텍처](/ko/docs/concepts/cluster-administration/logging/) 알아보기
 * [구조화된 로깅](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging) 알아보기
 * [로깅 심각도(serverity) 규칙](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) 알아보기
@@ -31,7 +31,7 @@ weight: 30
 시크릿을 안전하게 사용하려면 (최소한) 다음과 같이 하는 것이 좋다.

 1. 시크릿에 대한 [암호화 활성화](/docs/tasks/administer-cluster/encrypt-data/).
-2. 시크릿 읽기 및 쓰기를 제한하는 [RBAC 규칙 활성화 또는 구성](/docs/reference/access-authn-authz/authorization/). 파드를 만들 권한이 있는 모든 사용자는 시크릿을 암묵적으로 얻을 수 있다.
+2. 시크릿 읽기 및 쓰기를 제한하는 [RBAC 규칙 활성화 또는 구성](/ko/docs/reference/access-authn-authz/authorization/). 파드를 만들 권한이 있는 모든 사용자는 시크릿을 암묵적으로 얻을 수 있다.
 {{< /caution >}}

 <!-- body -->
@@ -48,7 +48,7 @@ weight: 30
 - 파드의 [이미지를 가져올 때 kubelet](#imagepullsecrets-사용하기)에 의해 사용.

 시크릿 오브젝트의 이름은 유효한
-[DNS 서브도메인 이름](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)이어야 한다.
+[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
 사용자는 시크릿을 위한 파일을 구성할 때 `data` 및 (또는) `stringData` 필드를
 명시할 수 있다. 해당 `data` 와 `stringData` 필드는 선택적으로 명시할 수 있다.
 `data` 필드의 모든 키(key)에 해당하는 값(value)은 base64로 인코딩된 문자열이어야 한다.
@@ -1156,10 +1156,10 @@ HTTP 요청을 처리하고, 복잡한 비즈니스 로직을 수행한 다음,

 ### 시크릿 API를 사용하는 클라이언트

-시크릿 API와 상호 작용하는 애플리케이션을 배포할 때, [RBAC](
-/docs/reference/access-authn-authz/rbac/)과 같은 [인가 정책](
-/docs/reference/access-authn-authz/authorization/)을
-사용하여 접근를 제한해야 한다.
+시크릿 API와 상호 작용하는 애플리케이션을 배포할 때, 
+[RBAC](/docs/reference/access-authn-authz/rbac/)과 같은 
+[인가 정책](/ko/docs/reference/access-authn-authz/authorization/)을
+사용하여 접근을 제한해야 한다.

 시크릿은 종종 다양한 중요도에 걸친 값을 보유하며, 이 중 많은 부분이
 쿠버네티스(예: 서비스 어카운트 토큰)와 외부 시스템으로 단계적으로
@@ -68,7 +68,7 @@ handler: myconfiguration  # 상응하는 CRI 설정의 이름임
 ```

 런타임클래스 오브젝트의 이름은 유효한
-[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)어이야 한다.
+[DNS 레이블 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-레이블-이름)어이야 한다.

 {{< note >}}
 런타임클래스 쓰기 작업(create/update/patch/delete)은
@@ -132,7 +132,7 @@ https://github.com/containerd/cri/blob/master/docs/config.md
  runtime_path = "${PATH_TO_BINARY}"
 ```

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

 ## 스케줄

@@ -175,5 +175,5 @@ PodOverhead를 사용하려면, PodOverhead [기능 게이트](/ko/docs/referenc

 - [런타임클래스 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md)
 - [런타임클래스 스케줄링 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling)
- [파드 오버헤드](/ko/docs/concepts/configuration/pod-overhead/) 개념에 대해 읽기
- [파드 오버헤드 기능 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
+- [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/) 개념에 대해 읽기
+- [파드 오버헤드 기능 설계](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead)
@@ -128,7 +128,7 @@ CRD를 사용하면 다른 API 서버를 추가하지 않고도 새로운 타입

 ## 커스텀리소스데피니션

-[커스텀리소스데피니션](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)
+[커스텀리소스데피니션](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
 API 리소스를 사용하면 커스텀 리소스를 정의할 수 있다.
 CRD 오브젝트를 정의하면 지정한 이름과 스키마를 사용하여 새 커스텀 리소스가 만들어진다.
 쿠버네티스 API는 커스텀 리소스의 스토리지를 제공하고 처리한다.
@@ -20,14 +20,14 @@ card:
 쿠버네티스 API를 사용하면 쿠버네티스의 API 오브젝트(예:
 파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의(query)하고 조작할 수 있다.

-대부분의 작업은 [kubectl](/docs/reference/kubectl/overview/)
+대부분의 작업은 [kubectl](/ko/docs/reference/kubectl/overview/)
 커맨드 라인 인터페이스 또는 API를 사용하는
 [kubeadm](/ko/docs/reference/setup-tools/kubeadm/)과
 같은 다른 커맨드 라인 도구를 통해 수행할 수 있다.
 그러나, REST 호출을 사용하여 API에 직접 접근할 수도 있다.

 쿠버네티스 API를 사용하여 애플리케이션을 작성하는 경우
-[클라이언트 라이브러리](/docs/reference/using-api/client-libraries/) 중 하나를 사용하는 것이 좋다.
+[클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/) 중 하나를 사용하는 것이 좋다.

 <!-- body -->

@@ -130,7 +130,7 @@ API 리소스는 API 그룹, 리소스 유형, 네임스페이스
 {{< /note >}}

 API 버전 수준 정의에 대한 자세한 내용은
-[API 버전 레퍼런스](/ko/docs/reference/using-api/api-overview/#api-버전-규칙)를 참조한다.
+[API 버전 레퍼런스](/ko/docs/reference/using-api/#api-버전-규칙)를 참조한다.



@@ -464,12 +464,12 @@ podsecuritypolicy "example" deleted
 예를 들면 다음과 같습니다.

 ```yaml
-allowedHostPaths:
-  # 이 정책은 "/foo", "/foo/", "/foo/bar" 등을 허용하지만,
-  # "/fool", "/etc/foo" 등은 허용하지 않는다.
-  # "/foo/../" 는 절대 유효하지 않다.
-  - pathPrefix: "/foo"
-    readOnly: true # 읽기 전용 마운트만 허용
+ allowedHostPaths:
+   # 이 정책은 "/foo", "/foo/", "/foo/bar" 등을 허용하지만,
+   # "/fool", "/etc/foo" 등은 허용하지 않는다.
+   # "/foo/../" 는 절대 유효하지 않다.
+   - pathPrefix: "/foo"
+     readOnly: true # 읽기 전용 마운트만 허용
 ```

 {{< warning >}}호스트 파일시스템에 제한없는 접근을 부여하며, 컨테이너가 특권을 에스컬레이션
@@ -58,7 +58,8 @@ weight: 20
 ## 리소스 쿼터 활성화

 많은 쿠버네티스 배포판에 기본적으로 리소스 쿼터 지원이 활성화되어 있다.
-{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} `--enable-admission-plugins=` 플래그의 인수 중 하나로
+{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} 
+`--enable-admission-plugins=` 플래그의 인수 중 하나로
 `ResourceQuota`가 있는 경우 활성화된다.

 해당 네임스페이스에 리소스쿼터가 있는 경우 특정 네임스페이스에
@@ -66,7 +67,9 @@ weight: 20

 ## 컴퓨트 리소스 쿼터

-지정된 네임스페이스에서 요청할 수 있는 총 [컴퓨트 리소스](/ko/docs/concepts/configuration/manage-resources-containers/) 합을 제한할 수 있다.
+지정된 네임스페이스에서 요청할 수 있는 총 
+[컴퓨트 리소스](/ko/docs/concepts/configuration/manage-resources-containers/) 
+합을 제한할 수 있다.

 다음과 같은 리소스 유형이 지원된다.

@@ -125,7 +128,9 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다.
 | `ephemeral-storage` | `requests.ephemeral-storage` 와 같음. |

 {{< note >}}
-CRI 컨테이너 런타임을 사용할 때, 컨테이너 로그는 임시 스토리지 쿼터에 포함된다. 이로 인해 스토리지 쿼터를 소진한 파드가 예기치 않게 축출될 수 있다. 자세한 내용은 [로깅 아키텍처](/ko/docs/concepts/cluster-administration/logging/)를 참조한다.
+CRI 컨테이너 런타임을 사용할 때, 컨테이너 로그는 임시 스토리지 쿼터에 포함된다. 
+이로 인해 스토리지 쿼터를 소진한 파드가 예기치 않게 축출될 수 있다. 
+자세한 내용은 [로깅 아키텍처](/ko/docs/concepts/cluster-administration/logging/)를 참조한다.
 {{< /note >}}

 ## 오브젝트 수 쿼터
@@ -192,7 +197,7 @@ CRI 컨테이너 런타임을 사용할 때, 컨테이너 로그는 임시 스
 | `NotTerminating` | `.spec.activeDeadlineSeconds is nil`에 일치하는 파드 |
 | `BestEffort` | 최상의 서비스 품질을 제공하는 파드 |
 | `NotBestEffort` | 서비스 품질이 나쁜 파드 |
-| `PriorityClass` | 지정된 [프라이어리티 클래스](/ko/docs/concepts/configuration/pod-priority-preemption)를 참조하여 일치하는 파드. |
+| `PriorityClass` | 지정된 [프라이어리티클래스](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)를 참조하여 일치하는 파드. |
 | `CrossNamespacePodAffinity` | 크로스-네임스페이스 파드 [(안티)어피니티 용어]가 있는 파드 |

 `BestEffort` 범위는 다음의 리소스를 추적하도록 쿼터를 제한한다.
@@ -248,13 +253,14 @@ CRI 컨테이너 런타임을 사용할 때, 컨테이너 로그는 임시 스

 {{< feature-state for_k8s_version="v1.17" state="stable" >}}

-특정 [우선 순위](/ko/docs/concepts/configuration/pod-priority-preemption/#파드-우선순위)로 파드를 생성할 수 있다.
+특정 [우선 순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#파드-우선순위)로 파드를 생성할 수 있다.
 쿼터 스펙의 `scopeSelector` 필드를 사용하여 파드의 우선 순위에 따라 파드의 시스템 리소스 사용을
 제어할 수 있다.

 쿼터 스펙의 `scopeSelector`가 파드를 선택한 경우에만 쿼터가 일치하고 사용된다.

-`scopeSelector` 필드를 사용하여 우선 순위 클래스의 쿼터 범위를 지정하면, 쿼터 오브젝트는 다음의 리소스만 추적하도록 제한된다.
+`scopeSelector` 필드를 사용하여 우선 순위 클래스의 쿼터 범위를 지정하면, 
+쿼터 오브젝트는 다음의 리소스만 추적하도록 제한된다.

 * `pods`
 * `cpu`
@@ -554,7 +560,7 @@ kubectl create -f ./object-counts.yaml --namespace=myspace
 kubectl get quota --namespace=myspace
 ```

-```
+```none
 NAME                    AGE
 compute-resources       30s
 object-counts           32s
@@ -564,7 +570,7 @@ object-counts           32s
 kubectl describe quota compute-resources --namespace=myspace
 ```

-```
+```none
 Name:                    compute-resources
 Namespace:               myspace
 Resource                 Used  Hard
@@ -580,7 +586,7 @@ requests.nvidia.com/gpu  0     4
 kubectl describe quota object-counts --namespace=myspace
 ```

-```
+```none
 Name:                   object-counts
 Namespace:              myspace
 Resource                Used    Hard
@@ -677,10 +683,10 @@ plugins:
 {{< codenew file="policy/priority-class-resourcequota.yaml" >}}

 ```shell
-$ kubectl apply -f https://k8s.io/examples/policy/priority-class-resourcequota.yaml -n kube-system
+kubectl apply -f https://k8s.io/examples/policy/priority-class-resourcequota.yaml -n kube-system
 ```

-```
+```none
 resourcequota/pods-cluster-services created
 ```

@@ -32,6 +32,6 @@ no_list: true

 {{<glossary_definition term_id="pod-disruption" length="all">}}

-* [파드 우선순위와 선점](/docs/concepts/scheduling-eviction/pod-priority-preemption/)
+* [파드 우선순위와 선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)
 * [노드-압박 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/)
-* [API를 이용한 축출](/docs/concepts/scheduling-eviction/api-eviction/)
+* [API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)
@@ -25,7 +25,7 @@ weight: 70
 관리자는 리소스쿼터를 사용하여 사용자가 우선순위가 높은 파드를 생성하지
 못하게 할 수 있다.

-자세한 내용은 [기본적으로 프라이어리티 클래스(Priority Class) 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을
+자세한 내용은 [기본적으로 프라이어리티클래스(Priority Class) 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을
 참고한다.
 {{< /warning >}}

@@ -50,7 +50,7 @@ weight: 70

 ## 프라이어리티클래스

-프라이어리티클래스는 프라이어리티 클래스 이름에서 우선순위의 정수 값으로의 매핑을
+프라이어리티클래스는 프라이어리티클래스 이름에서 우선순위의 정수 값으로의 매핑을
 정의하는 네임스페이스가 아닌(non-namespaced) 오브젝트이다. 이름은
 프라이어리티클래스 오브젝트의 메타데이터의 `name` 필드에 지정된다. 값은
 필수 `value` 필드에 지정되어 있다. 값이 클수록, 우선순위가
@@ -96,7 +96,7 @@ metadata:
  name: high-priority
 value: 1000000
 globalDefault: false
-description: "이 프라이어리티 클래스는 XYZ 서비스 파드에만 사용해야 한다."
+description: "이 프라이어리티클래스는 XYZ 서비스 파드에만 사용해야 한다."
 ```

 ## 비-선점 프라이어리티클래스 {#non-preempting-priority-class}
@@ -142,7 +142,7 @@ metadata:
 value: 1000000
 preemptionPolicy: Never
 globalDefault: false
-description: "이 프라이어리티 클래스는 다른 파드를 축출하지 않는다."
+description: "이 프라이어리티클래스는 다른 파드를 축출하지 않는다."
 ```

 ## 파드 우선순위
@@ -150,7 +150,7 @@ description: "이 프라이어리티 클래스는 다른 파드를 축출하지
 프라이어리티클래스가 하나 이상 있으면, 그것의 명세에서 이들 프라이어리티클래스 이름 중 하나를
 지정하는 파드를 생성할 수 있다. 우선순위 어드미션
 컨트롤러는 `priorityClassName` 필드를 사용하고 우선순위의 정수 값을
-채운다. 프라이어리티 클래스를 찾을 수 없으면, 파드가 거부된다.
+채운다. 프라이어리티클래스를 찾을 수 없으면, 파드가 거부된다.

 다음의 YAML은 이전 예제에서 생성된 프라이어리티클래스를
 사용하는 파드 구성의 예이다. 우선순위 어드미션 컨트롤러는
@@ -351,12 +351,12 @@ spec:
 축출 대상으로 고려한다.

 QoS와 파드 우선순위를 모두 고려하는 유일한 컴포넌트는
-[kubelet 리소스 부족 축출](/docs/tasks/administer-cluster/out-of-resource/)이다.
+[kubelet 리소스 부족 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/)이다.
 kubelet은 부족한 리소스의 사용이 요청을 초과하는지 여부에 따라, 그런 다음 우선순위에 따라,
 파드의 스케줄링 요청에 대한 부족한 컴퓨팅 리소스의 소비에 의해
 먼저 축출 대상 파드의 순위를 매긴다.
 더 자세한 내용은
-[엔드유저 파드 축출](/docs/tasks/administer-cluster/out-of-resource/#evicting-end-user-pods)을
+[엔드유저 파드 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/#evicting-end-user-pods)을
 참조한다.

 kubelet 리소스 부족 축출은 사용량이 요청을 초과하지 않는 경우
@@ -367,4 +367,4 @@ kubelet 리소스 부족 축출은 사용량이 요청을 초과하지 않는

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

-* 프라이어리티클래스와 관련하여 리소스쿼터 사용에 대해 [기본적으로 프라이어리티 클래스 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을 읽어보자.
+* 프라이어리티클래스와 관련하여 리소스쿼터 사용에 대해 [기본적으로 프라이어리티클래스 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을 읽어보자.
@@ -26,7 +26,7 @@ kube-scheduler를 미세 조정할 수 있다.
 통해 사용자는 적절한 파라미터를 사용해서 확장된 리소스를 빈 팩으로 만들 수 있어
 대규모의 클러스터에서 부족한 리소스의 활용도가 향상된다.
 `RequestedToCapacityRatioResourceAllocation` 우선 순위 기능의
-동작은 `requestedToCapacityRatioArguments`라는
+동작은 `RequestedToCapacityRatioArgs`라는
 구성 옵션으로 제어할 수 있다. 이 인수는 `shape`와 `resources`
 두 개의 파라미터로 구성된다. `shape` 파라미터는 사용자가 `utilization`과
 `score` 값을 기반으로 최소 요청 또는 최대 요청된 대로 기능을
@@ -39,27 +39,29 @@ kube-scheduler를 미세 조정할 수 있다.
 설정하는 구성의 예시이다.

 ```yaml
-apiVersion: v1
-kind: Policy
+apiVersion: kubescheduler.config.k8s.io/v1beta1
+kind: KubeSchedulerConfiguration
+profiles:
 # ...
-priorities:
-  # ...
-  - name: RequestedToCapacityRatioPriority
-    weight: 2
-    argument:
-      requestedToCapacityRatioArguments:
-        shape:
-          - utilization: 0
-            score: 0
-          - utilization: 100
-            score: 10
-        resources:
-          - name: intel.com/foo
-            weight: 3
-          - name: intel.com/bar
-            weight: 5
+  pluginConfig:
+  - name: RequestedToCapacityRatio
+    args: 
+      shape:
+      - utilization: 0
+        score: 10
+      - utilization: 100
+        score: 0
+      resources:
+      - name: intel.com/foo
+        weight: 3
+      - name: intel.com/bar
+        weight: 5
 ```

+kube-scheduler 플래그 `--config=/path/to/config/file` 을 사용하여 
+`KubeSchedulerConfiguration` 파일을 참조하면 구성이 스케줄러에
+전달된다.
+
 **이 기능은 기본적으로 비활성화되어 있다.**

 ### 우선 순위 기능 튜닝하기
@@ -281,5 +281,5 @@ tolerations:

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

-* [리소스 부족 다루기](/docs/tasks/administer-cluster/out-of-resource/)와 어떻게 구성하는지에 대해 알아보기
-* [파드 우선순위](/ko/docs/concepts/configuration/pod-priority-preemption/)에 대해 알아보기
+* [리소스 부족 다루기](/docs/concepts/scheduling-eviction/node-pressure-eviction/)와 어떻게 구성하는지에 대해 알아보기
+* [파드 우선순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)에 대해 알아보기
@@ -149,7 +149,7 @@ TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 미리
 * [파드에 대한 네트워크 정책](/ko/docs/concepts/services-networking/network-policies/)
 * [쿠버네티스 API 접근 제어하기](/ko/docs/concepts/security/controlling-access)
 * [클러스터 보안](/docs/tasks/administer-cluster/securing-a-cluster/)
-* 컨트롤 플레인을 위한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/)
+* 컨트롤 플레인을 위한 [전송 데이터 암호화](/ko/docs/tasks/tls/managing-tls-in-a-cluster/)
 * [Rest에서 데이터 암호화](/docs/tasks/administer-cluster/encrypt-data/)
 * [쿠버네티스 시크릿](/ko/docs/concepts/configuration/secret/)
 * [런타임 클래스](/ko/docs/concepts/containers/runtime-class)
@@ -7,6 +7,7 @@ content_type: concept
 weight: 20
 ---
 <!-- overview -->
+
 쿠버네티스는 파드와 서비스를 위한 DNS 레코드를 생성한다. 사용자는 IP 주소 대신에
 일관된 DNS 네임을 통해서 서비스에 접속할 수 있다.

@@ -261,6 +262,8 @@ spec:

 ### 파드의 DNS 설정 {#pod-dns-config}

+{{< feature-state for_k8s_version="v1.14" state="stable" >}}
+
 사용자들은 파드의 DNS 설정을 통해서 직접 파드의 DNS를 세팅할 수 있다.

 `dnsConfig` 필드는 선택적이고, `dnsPolicy` 세팅과 함께 동작한다.
@@ -310,18 +313,6 @@ search default.svc.cluster-domain.example svc.cluster-domain.example cluster-dom
 options ndots:5
 ```

-### 기능 지원 여부
-
-파드 DNS 구성 및 DNS 정책 "`None`"에 대한 지원 정보는 아래에서 확인 할 수 있다.
-
-| k8s 버전 | 기능 지원 |
-| :---------: |:-----------:|
-| 1.14 | 안정 |
-| 1.10 | 베타 (기본)|
-| 1.9 | 알파 |
-
-
-
 ## {{% heading "whatsnext" %}}


@@ -154,7 +154,7 @@ v1beta1 API의 `topology` 필드에 있는 `"topology.kubernetes.io/zone"`

 ### 관리

-대부분의 경우, 컨트롤 플레인(특히, 엔드포인트 슬라이스
+대부분의 경우, 컨트롤 플레인(특히, 엔드포인트슬라이스
 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}})는
 엔드포인트슬라이스 오브젝트를 생성하고 관리한다. 다른 엔티티나 컨트롤러가 추가
 엔드포인트슬라이스 집합을 관리하게 할 수 있는 서비스 메시 구현과 같이
@@ -165,13 +165,13 @@ v1beta1 API의 `topology` 필드에 있는 `"topology.kubernetes.io/zone"`
 엔티티를 나타내는 `endpointslice.kubernetes.io/managed-by`
 {{< glossary_tooltip term_id="label" text="레이블" >}}을
 정의한다.
-엔드포인트 슬라이스 컨트롤러는 관리하는 모든 엔드포인트슬라이스에 레이블의 값으로
+엔드포인트슬라이스 컨트롤러는 관리하는 모든 엔드포인트슬라이스에 레이블의 값으로
 `endpointslice-controller.k8s.io` 를 설정한다. 엔드포인트슬라이스를
 관리하는 다른 엔티티도 이 레이블에 고유한 값을 설정해야 한다.

 ### 소유권

-대부분의 유스케이스에서, 엔드포인트 슬라이스 오브젝트가 엔드포인트를
+대부분의 유스케이스에서, 엔드포인트슬라이스 오브젝트가 엔드포인트를
 추적하는 서비스가 엔드포인트슬라이스를 소유한다. 이 소유권은 각 엔드포인트슬라이스의 소유자
 참조와 서비스에 속한 모든 엔드포인트슬라이스의 간단한 조회를 가능하게 하는
 `kubernetes.io/service-name` 레이블로 표시된다.
@@ -247,5 +247,4 @@ v1beta1 API의 `topology` 필드에 있는 `"topology.kubernetes.io/zone"`

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

-* [엔드포인트슬라이스 활성화하기](/docs/tasks/administer-cluster/enabling-endpointslices)에 대해 배우기
-* [애플리케이션을 서비스와 함께 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기
+* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기
@@ -21,7 +21,7 @@ _서비스 내부 트래픽 정책_ 을 사용하면 내부 트래픽 제한이
 ## 서비스 내부 트래픽 정책 사용


-[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)에서 
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에서 
 `ServiceInternalTrafficPolicy`를 활성화한 후에 
 {{< glossary_tooltip text="서비스" term_id="service" >}}의 
 `.spec.internalTrafficPolicy`를 `Local`로 설정하여 내부 전용 트래픽 정책을 활성화 할 수 있다.
@@ -57,7 +57,7 @@ kube-proxy는 `spec.internalTrafficPolicy` 의 설정에 따라서 라우팅되
 엔드포인트를 필터링한다. 
 이것을 `Local`로 설정하면, 노드 내부 엔드포인트만 고려한다. 
 이 설정이 `Cluster`이거나 누락되었다면 모든 엔드포인트를 고려한다.
-[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)의 
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)의 
 `ServiceInternalTrafficPolicy`를 활성화한다면, `spec.internalTrafficPolicy`는 기본값 "Cluster"로 설정된다.

 ## 제약조건
@@ -215,7 +215,7 @@ API 리소스이다. 개념적으로 엔드포인트와 매우 유사하지만,
 오브젝트에 의해 미러링된다.

 이 필드는 표준 쿠버네티스 레이블 구문을 따른다. 값은
-[IANA 표준 서비스 이름](http://www.iana.org/assignments/service-names) 또는
+[IANA 표준 서비스 이름](https://www.iana.org/assignments/service-names) 또는
 `mycompany.com/my-custom-protocol`과 같은 도메인 접두사 이름 중 하나여야 한다.

 ## 가상 IP와 서비스 프록시
@@ -914,7 +914,7 @@ projected 볼륨 소스를 [`subPath`](#subpath-사용하기) 볼륨으로 마

 ### quobyte

-`quobyte` 볼륨을 사용하면 기존 [Quobyte](http://www.quobyte.com) 볼륨을
+`quobyte` 볼륨을 사용하면 기존 [Quobyte](https://www.quobyte.com) 볼륨을
 파드에 마운트할 수 있다.

 {{< note >}}
@@ -1,4 +1,10 @@
 ---
+
+
+
+
+
+
 title: 데몬셋
 content_type: concept
 weight: 40
@@ -26,7 +32,8 @@ _데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도

 ### 데몬셋 생성

-YAML 파일로 데몬셋을 설명 할 수 있다. 예를 들어 아래 `daemonset.yaml` 파일은 fluentd-elasticsearch 도커 이미지를 실행하는 데몬셋을 설명한다.
+YAML 파일에 데몬셋 명세를 작성할 수 있다. 예를 들어 아래 `daemonset.yaml` 파일은 
+fluentd-elasticsearch 도커 이미지를 실행하는 데몬셋을 설명한다.

 {{< codenew file="controllers/daemonset.yaml" >}}

@@ -40,19 +47,23 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml

 다른 모든 쿠버네티스 설정과 마찬가지로 데몬셋에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다.
 일반적인 설정파일 작업에 대한 정보는
-[스테이트리스 애플리케이션 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/),
-[컨테이너 구성하기](/ko/docs/tasks/) 그리고 [kubectl을 사용한 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다.
+[스테이트리스 애플리케이션 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/)와
+ [kubectl을 사용한 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/)를 참고한다.

 데몬셋 오브젝트의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.

-데몬셋에는 [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 섹션도 필요하다.
+데몬셋에는 
+[`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 
+섹션도 필요하다.

 ### 파드 템플릿

 `.spec.template` 는 `.spec` 의 필수 필드 중 하나이다.

-`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다. 이것은 중첩되어 있다는 점과 `apiVersion` 또는 `kind` 를 가지지 않는 것을 제외하면 {{< glossary_tooltip text="파드" term_id="pod" >}}와 정확히 같은 스키마를 가진다.
+`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다. 
+이것은 중첩되어 있다는 점과 `apiVersion` 또는 `kind` 를 가지지 않는 것을 제외하면 
+{{< glossary_tooltip text="파드" term_id="pod" >}}와 정확히 같은 스키마를 가진다.

 데몬셋의 파드 템플릿에는 파드의 필수 필드 외에도 적절한 레이블이 명시되어야
 한다([파드 셀렉터](#파드-셀렉터)를 본다).
@@ -73,19 +84,22 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml

 `.spec.selector` 는 다음 2개의 필드로 구성된 오브젝트이다.

-* `matchLabels` - [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)의 `.spec.selector` 와 동일하게 작동한다.
+* `matchLabels` - [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)의 
+`.spec.selector` 와 동일하게 작동한다.
 * `matchExpressions` - 키, 값 목록 그리고 키 및 값에 관련된 연산자를
  명시해서 보다 정교한 셀렉터를 만들 수 있다.

 2개의 필드가 명시되면 두 필드를 모두 만족하는 것(ANDed)이 결과가 된다.

-만약 `.spec.selector` 를 명시하면, 이것은 `.spec.template.metadata.labels` 와 일치해야 한다. 일치하지 않는 구성은 API에 의해 거부된다.
+만약 `.spec.selector` 를 명시하면, 이것은 `.spec.template.metadata.labels` 와 일치해야 한다. 
+일치하지 않는 구성은 API에 의해 거부된다.

 ### 오직 일부 노드에서만 파드 실행

 만약 `.spec.template.spec.nodeSelector` 를 명시하면 데몬셋 컨트롤러는
 [노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector)와
-일치하는 노드에 파드를 생성한다. 마찬가지로 `.spec.template.spec.affinity` 를 명시하면
+일치하는 노드에 파드를 생성한다. 
+마찬가지로 `.spec.template.spec.affinity` 를 명시하면
 데몬셋 컨트롤러는 [노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)와 일치하는 노드에 파드를 생성한다.
 만약 둘 중 하나를 명시하지 않으면 데몬셋 컨트롤러는 모든 노드에서 파드를 생성한다.

@@ -100,18 +114,19 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
 데몬셋 파드는 데몬셋 컨트롤러에 의해 생성되고 스케줄된다.
 이에 대한 이슈를 소개한다.

- * 파드 동작의 불일치: 스케줄 되기 위해서 대기 중인 일반 파드는 `Pending` 상태로 생성된다.
-   그러나 데몬셋 파드는 `Pending` 상태로 생성되지 않는다.
-   이것은 사용자에게 혼란을 준다.
- * [파드 선점](/ko/docs/concepts/configuration/pod-priority-preemption/)은
-   기본 스케줄러에서 처리한다. 선점이 활성화되면 데몬셋 컨트롤러는
-   파드 우선순위와 선점을 고려하지 않고 스케줄 한다.
+* 파드 동작의 불일치: 스케줄 되기 위해서 대기 중인 일반 파드는 `Pending` 상태로 생성된다.
+  그러나 데몬셋 파드는 `Pending` 상태로 생성되지 않는다.
+  이것은 사용자에게 혼란을 준다.
+* [파드 선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)은
+  기본 스케줄러에서 처리한다. 선점이 활성화되면 데몬셋 컨트롤러는
+  파드 우선순위와 선점을 고려하지 않고 스케줄 한다.

 `ScheduleDaemonSetPods` 로 데몬셋 파드에 `.spec.nodeName` 용어 대신
 `NodeAffinity` 용어를 추가해서 데몬셋 컨트롤러 대신 기본
 스케줄러를 사용해서 데몬셋을 스케줄할 수 있다. 이후에 기본
 스케줄러를 사용해서 대상 호스트에 파드를 바인딩한다. 만약 데몬셋 파드에
-이미 노드 선호도가 존재한다면 교체한다(대상 호스트를 선택하기 전에 원래 노드의 어피니티가 고려된다). 데몬셋 컨트롤러는
+이미 노드 선호도가 존재한다면 교체한다(대상 호스트를 선택하기 전에 
+원래 노드의 어피니티가 고려된다). 데몬셋 컨트롤러는
 데몬셋 파드를 만들거나 수정할 때만 이런 작업을 수행하며,
 데몬셋의 `spec.template` 은 변경되지 않는다.

@@ -152,10 +167,12 @@ nodeAffinity:

 - **푸시(Push)**: 데몬셋의 파드는 통계 데이터베이스와 같은 다른 서비스로 업데이트를 보내도록
  구성되어있다. 그들은 클라이언트들을 가지지 않는다.
- **노드IP와 알려진 포트**: 데몬셋의 파드는 `호스트 포트`를 사용할 수 있으며, 노드IP를 통해 파드에 접근할 수 있다. 클라이언트는 노드IP를 어떻게든지 알고 있으며, 관례에 따라 포트를 알고 있다.
+- **노드IP와 알려진 포트**: 데몬셋의 파드는 `호스트 포트`를 사용할 수 있으며, 
+  노드IP를 통해 파드에 접근할 수 있다. 
+  클라이언트는 노드IP를 어떻게든지 알고 있으며, 관례에 따라 포트를 알고 있다.
 - **DNS**: 동일한 파드 셀렉터로 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 만들고,
-  그 다음에 `엔드포인트` 리소스를 사용해서 데몬셋을 찾거나 DNS에서 여러 A레코드를
-  검색한다.
+  그 다음에 `엔드포인트` 리소스를 사용해서 데몬셋을 찾거나 
+  DNS에서 여러 A레코드를 검색한다.
 - **서비스**: 동일한 파드 셀렉터로 서비스를 생성하고, 서비스를 사용해서
  임의의 노드의 데몬에 도달한다(특정 노드에 도달할 방법이 없다).

@@ -304,7 +304,7 @@ spec:

 ### 완료된 잡을 위한 TTL 메커니즘

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

 완료된 잡 (`Complete` 또는 `Failed`)을 자동으로 정리하는 또 다른 방법은
 잡의 `.spec.ttlSecondsAfterFinished` 필드를 지정해서 완료된 리소스에 대해
@@ -342,11 +342,6 @@ spec:
 삭제되도록 할 수 있다. 만약 필드를 설정하지 않으면, 이 잡이 완료된
 후에 TTL 컨트롤러에 의해 정리되지 않는다.

-이 TTL 메커니즘은 기능 게이트 `TTLAfterFinished`와 함께 알파 단계이다. 더
-자세한 정보는 완료된 리소스를 위한
-[TTL 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)
-문서를 본다.
-
 ## 잡 패턴

 잡 오브젝트를 사용해서 신뢰할 수 있는 파드의 병렬 실행을 지원할 수 있다.  잡 오브젝트는 과학
@@ -31,7 +31,7 @@ weight: 60
 - 클라우드 공급자 또는 하이퍼바이저의 오류로 인한 VM 장애
 - 커널 패닉
 - 클러스터 네트워크 파티션의 발생으로 클러스터에서 노드가 사라짐
- 노드의 [리소스 부족](/docs/tasks/administer-cluster/out-of-resource/)으로 파드가 축출됨
+- 노드의 [리소스 부족](/docs/concepts/scheduling-eviction/node-pressure-eviction/)으로 파드가 축출됨

 리소스 부족을 제외한 나머지 조건은 대부분의 사용자가 익숙할 것이다.
 왜냐하면
@@ -76,7 +76,7 @@ weight: 60
 - 복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체
  ([안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티) 이용)
  또는 영역 간
-  ([다중 영역 클러스터](/docs/setup/multiple-zones)를 이용한다면)에
+  ([다중 영역 클러스터](/ko/docs/setup/best-practices/multiple-zones/)를 이용한다면)에
  애플리케이션을 분산해야 한다.

 자발적 중단의 빈도는 다양하다. 기본적인 쿠버네티스 클러스터에서는 자동화된 자발적 중단은 발생하지 않는다(사용자가 지시한 자발적 중단만 발생한다).
@@ -86,7 +86,7 @@ weight: 60
 단편화를 제거하고 노드의 효율을 높이는 과정에서 자발적 중단을 야기할 수 있다.
 클러스터 관리자 또는 호스팅 공급자는
 예측 가능한 자발적 중단 수준에 대해 문서화해야 한다.
-파드 스펙 안에 [프라이어리티클래스 사용하기](/ko/docs/concepts/configuration/pod-priority-preemption/)와 같은 특정 환경설정 옵션
+파드 스펙 안에 [프라이어리티클래스 사용하기](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)와 같은 특정 환경설정 옵션
 또한 자발적(+ 비자발적) 중단을 유발할 수 있다.


@@ -15,7 +15,7 @@ obsolete -->
 {{< note >}}
 v1.18 이전 버전의 쿠버네티스에서는 파드 토폴로지 분배 제약조건을 사용하려면
 [API 서버](/ko/docs/concepts/overview/components/#kube-apiserver)와
-[스케줄러](/docs/reference/generated/kube-scheduler/)에서
+[스케줄러](/docs/reference/command-line-tools-reference/kube-scheduler/)에서
 `EvenPodsSpread`[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
 활성화해야 한다
 {{< /note >}}
@@ -46,7 +46,7 @@ card:
 1. CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md)에 서명합니다.
 1. [문서 리포지터리](https://github.com/kubernetes/website)와 웹사이트의
   [정적 사이트 생성기](https://gohugo.io)를 숙지합니다.
-1. [풀 리퀘스트 열기](/ko/docs/contribute/new-content/new-content/)와
+1. [풀 리퀘스트 열기](/ko/docs/contribute/new-content/open-a-pr/)와
   [변경 검토](/ko/docs/contribute/review/reviewing-prs/)의
   기본 프로세스를 이해하도록 합니다.

@@ -60,7 +60,7 @@ card:
  기여할 수 있는 다양한 방법에 대해 알아봅니다.
 - [`kubernetes/website` 이슈 목록](https://github.com/kubernetes/website/issues/)을
  확인하여 좋은 진입점이 되는 이슈를 찾을 수 있습니다.
- 기존 문서에 대해 [GitHub을 사용해서 풀 리퀘스트 열거나](/ko/docs/contribute/new-content/new-content/#github을-사용하여-변경하기)
+- 기존 문서에 대해 [GitHub을 사용해서 풀 리퀘스트 열거나](/ko/docs/contribute/new-content/open-a-pr/#github을-사용하여-변경하기)
  GitHub에서의 이슈 제기에 대해 자세히 알아봅니다.
 - 정확성과 언어에 대해 다른 쿠버네티스 커뮤니티 맴버의
  [풀 리퀘스트 검토](/ko/docs/contribute/review/reviewing-prs/)를 합니다.
@@ -71,7 +71,7 @@ card:

 ## 다음 단계

- 리포지터리의 [로컬 복제본에서 작업](/ko/docs/contribute/new-content/new-content/#fork-the-repo)하는
+- 리포지터리의 [로컬 복제본에서 작업](/ko/docs/contribute/new-content/open-a-pr/#fork-the-repo)하는
  방법을 배워봅니다.
 - [릴리스된 기능](/docs/contribute/new-content/new-features/)을 문서화 합니다.
 - [SIG Docs](/ko/docs/contribute/participate/)에 참여하고,
@@ -96,6 +96,6 @@ SIG Docs는 여러가지 방법으로 의견을 나누고 있습니다.

 ## 다른 기여 방법들

- [쿠버네티스 커뮤니티 사이트](/community/)를 방문하십시오. 트위터 또는 스택 오버플로우에 참여하고, 현지 쿠버네티스 모임과 이벤트 등에 대해 알아봅니다.
+- [쿠버네티스 커뮤니티 사이트](/ko/community/)를 방문하십시오. 트위터 또는 스택 오버플로우에 참여하고, 현지 쿠버네티스 모임과 이벤트 등에 대해 알아봅니다.
 - [기여자 치트시트](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet)를 읽고 쿠버네티스 기능 개발에 참여합니다.
 - [블로그 게시물 또는 사례 연구](/docs/contribute/new-content/blogs-case-studies/)를 제출합니다.
@@ -0,0 +1,25 @@
+---
+title: 사이트 분석 보기
+content_type: concept
+weight: 100
+card:
+  name: contribute
+  weight: 100
+---
+
+<!-- overview -->
+
+이 페이지는 kubernetes.io 사이트 분석을 제공하는 대시보드에 대한 정보를 담고 있다.
+
+
+<!-- body -->
+
+[대시보드 보기](https://datastudio.google.com/reporting/fede2672-b2fd-402a-91d2-7473bdb10f04).
+
+이 대시보드는 Google Data Studio를 사용하여 구축되었으며 kubernetes.io에서 Google Analytics를 사용하여 수집한 정보를 보여준다.
+
+### 대시보드 사용
+
+기본적으로 대시보드는 지난 30일 동안 수집된 모든 데이터의 분석을 제공한다. 날짜 선택을 통해 특정 날짜 범위의 데이터를 볼 수 있다. 그 외 필터링 옵션을 사용하면, 사용자의 위치, 사이트에 접속하는데 사용된 장치, 번역된 문서 언어 등을 기준으로 데이터를 확인할 수 있다.
+
+ 이 대시보드에 문제가 있거나 개선을 요청하려면, [이슈를 오픈](https://github.com/kubernetes/website/issues/new/choose) 한다.
@@ -133,7 +133,7 @@ weight: 10
 ### API 오브젝트 용어 한글화 방침

 일반적으로 `kubectl api-resources` 결과의 `kind` 에 해당하는 API 오브젝트는
-[국립국어원 외래어 표기법](http://kornorms.korean.go.kr/regltn/regltnView.do?regltn_code=0003#a)에
+[국립국어원 외래어 표기법](https://kornorms.korean.go.kr/regltn/regltnView.do?regltn_code=0003#a)에
 따라 한글로 표기하고 영문을 병기한다. 예를 들면 다음과 같다.

 API 오브젝트(kind)      | 한글화(외래어 표기 및 영문 병기)
@@ -19,7 +19,7 @@ PR 랭글러는 일주일 간 매일 다음의 일을 해야 한다.
 - 매일 새로 올라오는 이슈를 심사하고 태그를 지정한다. SIG Docs가 메타데이터를 사용하는 방법에 대한 지침은 [이슈 심사 및 분류](/ko/docs/contribute/review/for-approvers/#이슈-심사와-분류)를 참고한다.
 - [스타일](/docs/contribute/style/style-guide/)과 [콘텐츠](/docs/contribute/style/content-guide/) 가이드를 준수하는지에 대해 [열린(open) 풀 리퀘스트](https://github.com/kubernetes/website/pulls)를 매일 리뷰한다.
  - 가장 작은 PR(`size/XS`)부터 시작하고, 가장 큰(`size/XXL`) PR까지 리뷰한다. 가능한 한 많은 PR을 리뷰한다.
- PR 기여자들이 [CLA]()에 서명했는지 확인한다.
+- PR 기여자들이 [CLA](https://github.com/kubernetes/community/blob/master/CLA.md)에 서명했는지 확인한다.
  - CLA에 서명하지 않은 기여자에게 CLA에 서명하도록 알리려면 [이](https://github.com/zparnold/k8s-docs-pr-botherer) 스크립트를 사용한다.
 - 제안된 변경 사항에 대한 피드백을 제공하고 다른 SIG의 멤버에게 기술 리뷰를 요청한다.
  - 제안된 콘텐츠 변경에 대해 PR에 인라인 제안(inline suggestion)을 제공한다.
@@ -29,7 +29,7 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D
  이슈를 올린다.
 - 풀 리퀘스트에 대해 구속력 없는 피드백을 제공한다.
 - 현지화에 기여한다.
- [슬랙](http://slack.k8s.io/) 또는
+- [슬랙](https://slack.k8s.io/) 또는
  [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선을 제안한다.

 [CLA에 서명](/ko/docs/contribute/new-content/overview/#sign-the-cla) 후에 누구나 다음을 할 수 있다.
@@ -203,7 +203,7 @@ PR은 자동으로 병합된다. SIG Docs 승인자는 추가적인 기술 리
 - 주간 로테이션을 위해
  [PR Wrangler 로테이션 스케줄](https://github.com/kubernetes/website/wiki/PR-Wranglers)에
  참여한다. SIG Docs는 모든 승인자들이 이 로테이션에 참여할 것으로 기대한다. 자세한 내용은
-  [PR 랭글러(PR wrangler)](/ko/docs/contribute/participating/pr-wranglers/)를
+  [PR 랭글러(PR wrangler)](/ko/docs/contribute/participate/pr-wranglers/)를
  참고한다.

 ## 승인자 되기
@@ -231,4 +231,4 @@ PR은 자동으로 병합된다. SIG Docs 승인자는 추가적인 기술 리

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

- 모든 승인자가 교대로 수행하는 역할인 [PR 랭글러](/ko/docs/contribute/participating/pr-wranglers)에 대해 읽어보기
+- 모든 승인자가 교대로 수행하는 역할인 [PR 랭글러](/ko/docs/contribute/participate/pr-wranglers)에 대해 읽어보기
@@ -18,7 +18,7 @@ weight: 10
 - 적합한 코멘트를 남길 수 있도록 [콘텐츠 가이드](/docs/contribute/style/content-guide/)와
  [스타일 가이드](/docs/contribute/style/style-guide/)를 읽는다.
 - 쿠버네티스 문서화 커뮤니티의 다양한
-  [역할과 책임](/ko/docs/contribute/participating/#역할과-책임)을 이해한다.
+  [역할과 책임](/ko/docs/contribute/participate/#역할과-책임)을 이해한다.

 <!-- body -->

@@ -87,7 +87,7 @@ weight: 10
 - PR이 새로운 페이지를 소개하는가? 그렇다면,
  - 페이지가 올바른 [페이지 콘텐츠 타입](/docs/contribute/style/page-content-types/)과 연관된 Hugo 단축 코드를 사용하는가?
  - 섹션의 측면 탐색에 페이지가 올바르게 나타나는가?
-  - 페이지가 [문서 홈](/ko/docs/home/) 목록에 나타나야 하는가?
+  - 페이지가 [문서 홈](/docs/home/) 목록에 나타나야 하는가?
 - 변경 사항이 Netlify 미리보기에 표시되는가? 목록, 코드 블록, 표, 메모 및 이미지에 특히 주의한다.

 ### 기타
@@ -172,4 +172,4 @@ kubectl create -f https://k8s.io/examples/pods/storage/gce-volume.yaml
 ## {{% heading "whatsnext" %}}

 * [페이지 콘텐츠 타입 사용](/docs/contribute/style/page-content-types/)에 대해 알아보기.
-* [풀 리퀘스트 작성](/ko/docs/contribute/new-content/new-content/)에 대해 알아보기.
+* [풀 리퀘스트 작성](/ko/docs/contribute/new-content/open-a-pr/)에 대해 알아보기.
@@ -10,7 +10,7 @@ card:

 <!-- overview -->

-쿠버네티스 문서에 문제가 있거나, 새로운 내용에 대한 아이디어가 있으면, 이슈를 연다. [GitHub 계정](https://github.com/join)과 웹 브라우저만 있으면 된다.
+쿠버네티스 문서의 문제를 발견하거나 새로운 내용에 대한 아이디어가 있으면, 이슈를 연다. [GitHub 계정](https://github.com/join)과 웹 브라우저만 있으면 된다.

 대부분의 경우, 쿠버네티스 문서에 대한 새로운 작업은 GitHub의 이슈로 시작된다. 그런 다음
 쿠버네티스 기여자는 필요에 따라 이슈를 리뷰, 분류하고 태그를 지정한다. 다음으로, 여러분이나
@@ -22,7 +22,7 @@ card:

 ## 이슈 열기

-기존 콘텐츠에 대한 개선을 제안하거나, 오류를 발견하면, 이슈를 연다.
+기존 콘텐츠에 대한 개선을 제안하고 싶거나 오류를 발견하면, 이슈를 연다.

 1. 오른쪽 사이드바에서 **문서에 이슈 생성** 링크를 클릭한다. 그러면 헤더가
 미리 채워진 GitHub 이슈 페이지로 리디렉션된다.
@@ -7,3 +7,6 @@ card:
  weight: 10
  title: 사용 가능한 문서 버전
 ---
+
+이 웹사이트에서는 쿠버네티스 최신 버전 및 
+이전 4개 버전에 대한 문서를 제공하고 있다.
@@ -37,7 +37,7 @@ no_list: true
 - [쿠버네티스 Python 클라이언트 라이브러리](https://github.com/kubernetes-client/python)
 - [쿠버네티스 Java 클라이언트 라이브러리](https://github.com/kubernetes-client/java)
 - [쿠버네티스 JavaScript 클라이언트 라이브러리](https://github.com/kubernetes-client/javascript)
- [쿠버네티스 Dotnet 클라이언트 라이브러리](https://github.com/kubernetes-client/csharp)
+- [쿠버네티스 C# 클라이언트 라이브러리](https://github.com/kubernetes-client/csharp)
 - [쿠버네티스 Haskell 클라이언트 라이브러리](https://github.com/kubernetes-client/haskell)

 ## CLI
@@ -55,7 +55,7 @@ no_list: true
 파드, 서비스, 레플리케이션 컨트롤러와 같은 API 오브젝트에 대한 검증과 구성을 
 수행하는 REST API.
 * [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - 쿠버네티스에 탑재된 핵심 제어 루프를 포함하는 데몬.
-* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - 간단한 
+* [kube-proxy](/ko/docs/reference/command-line-tools-reference/kube-proxy/) - 간단한 
 TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을 
 할 수 있다.
 * [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - 가용성, 성능 및 용량을 관리하는 스케줄러.
@@ -53,7 +53,7 @@ weight: 50
 1. 이전 단계는 파드에 참조되는 `ServiceAccount` 가 있도록 하고, 그렇지 않으면 이를 거부한다.
 1. 서비스어카운트 `automountServiceAccountToken` 와 파드의 `automountServiceAccountToken` 중 어느 것도 `false` 로 설정되어 있지 않다면, API 접근을 위한 토큰이 포함된 `volume` 을 파드에 추가한다.
 1. 이전 단계에서 서비스어카운트 토큰을 위한 볼륨이 만들어졌다면, `/var/run/secrets/kubernetes.io/serviceaccount` 에 마운트된 파드의 각 컨테이너에 `volumeSource` 를 추가한다.
-1. 파드에 `ImagePullSecrets` 이 없는 경우, `ServiceAccount` 의 `ImagePullSecrets` 이 파드에 추가된다.
+1. 파드에 `imagePullSecrets` 이 없는 경우, `ServiceAccount` 의 `imagePullSecrets` 이 파드에 추가된다.

 #### 바인딩된 서비스 어카운트 토큰 볼륨

@@ -86,14 +86,14 @@ weight: 50
 프로젝티드 볼륨은 세 가지로 구성된다.

 1. kube-apiserver로부터 TokenRequest API를 통해 얻은 서비스어카운트토큰(ServiceAccountToken). 서비스어카운트토큰은 기본적으로 1시간 뒤에, 또는 파드가 삭제될 때 만료된다. 서비스어카운트토큰은 파드에 연결되며 kube-apiserver를 위해 존재한다.
-1. kube-apiserver에 대한 연결을 확인하는 데 사용되는 CA 번들을 포함하는 컨피그맵(ConfigMap). 이 기능은 모든 네임스페이스에 "kube-root-ca.crt" 컨피그맵을 게시하는 기능 게이트인 `RootCAConfigMap`이 활성화되어 있어야 동작한다. `RootCAConfigMap`은 1.20에서 기본적으로 활성화되어 있으며, 1.21 이상에서는 항상 활성화된 상태이다.
+1. kube-apiserver에 대한 연결을 확인하는 데 사용되는 CA 번들을 포함하는 컨피그맵(ConfigMap). 이 기능은 모든 네임스페이스에 "kube-root-ca.crt" 컨피그맵을 게시하는 기능 게이트인 `RootCAConfigMap`에 의해 동작한다. `RootCAConfigMap` 기능 게이트는 1.21에서 GA로 전환되었으며 기본적으로 활성화되어 있다. (이 플래그는 1.22에서 `--feature-gate` 인자에서 제외될 예정이다.)
 1. 파드의 네임스페이스를 참조하는 DownwardAPI.

 상세 사항은 [프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)을 참고한다.

 `BoundServiceAccountTokenVolume` 기능 게이트가 활성화되어 있지 않은 경우, 
-위의 프로젝티드 볼륨을 파드 스펙에 추가하여 시크릿 기반 서비스 어카운트 볼륨을 프로젝티드 볼륨으로 수동으로 옮길 수 있다.
-그러나, `RootCAConfigMap`은 활성화되어 있어야 한다.
+위의 프로젝티드 볼륨을 파드 스펙에 추가하여 
+시크릿 기반 서비스 어카운트 볼륨을 프로젝티드 볼륨으로 수동으로 옮길 수 있다.

 ### 토큰 컨트롤러

@@ -611,12 +611,12 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 - `EnableEquivalenceClassCache`: 스케줄러가 파드를 스케줄링할 때 노드의
  동등성을 캐시할 수 있게 한다.
 - `EndpointSlice`: 보다 스케일링 가능하고 확장 가능한 네트워크 엔드포인트에 대한
-  엔드포인트슬라이스(EndpointSlices)를 활성화한다. [엔드포인트슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다.
+  엔드포인트슬라이스(EndpointSlices)를 활성화한다. [엔드포인트슬라이스 활성화](/ko/docs/concepts/services-networking/endpoint-slices/)를 참고한다.
 - `EndpointSliceNodeName` : 엔드포인트슬라이스 `nodeName` 필드를 활성화한다.
 - `EndpointSliceProxying`: 활성화되면, 리눅스에서 실행되는
  kube-proxy는 엔드포인트 대신 엔드포인트슬라이스를
  기본 데이터 소스로 사용하여 확장성과 성능을 향상시킨다.
-  [엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다.
+  [엔드포인트슬라이스 활성화](/ko/docs/concepts/services-networking/endpoint-slices/)를 참고한다.
 - `EndpointSliceTerminatingCondition`: 엔드포인트슬라이스 `terminating` 및 `serving`
  조건 필드를 활성화한다.
 - `EphemeralContainers`: 파드를 실행하기 위한
@@ -726,7 +726,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
  [CrossNamespacePodAffinity](/ko/docs/concepts/policy/resource-quotas/#네임스페이스-간-파드-어피니티-쿼터) 쿼터 범위 기능을 활성화한다.
 - `PodOverhead`: 파드 오버헤드를 판단하기 위해 [파드오버헤드(PodOverhead)](/ko/docs/concepts/scheduling-eviction/pod-overhead/)
  기능을 활성화한다.
- `PodPriority`: [우선 순위](/ko/docs/concepts/configuration/pod-priority-preemption/)를
+- `PodPriority`: [우선 순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)를
  기반으로 파드의 스케줄링 취소와 선점을 활성화한다.
 - `PodReadinessGates`: 파드 준비성 평가를 확장하기 위해
  `PodReadinessGate` 필드 설정을 활성화한다. 자세한 내용은 [파드의 준비성 게이트](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)를
@@ -859,12 +859,12 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 - `WindowsGMSA`: 파드에서 컨테이너 런타임으로 GMSA 자격 증명 스펙을 전달할 수 있다.
 - `WindowsRunAsUserName` : 기본 사용자가 아닌(non-default) 사용자로 윈도우 컨테이너에서
  애플리케이션을 실행할 수 있도록 지원한다. 자세한 내용은
-  [RunAsUserName 구성](/docs/tasks/configure-pod-container/configure-runasusername)을
+  [RunAsUserName 구성](/ko/docs/tasks/configure-pod-container/configure-runasusername/)을
  참고한다.
 - `WindowsEndpointSliceProxying`: 활성화되면, 윈도우에서 실행되는 kube-proxy는
  엔드포인트 대신 엔드포인트슬라이스를 기본 데이터 소스로 사용하여
  확장성과 성능을 향상시킨다.
-  [엔드포인트 슬라이스 활성화하기](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다.
+  [엔드포인트슬라이스 활성화하기](/ko/docs/concepts/services-networking/endpoint-slices/)를 참고한다.


 ## {{% heading "whatsnext" %}}
@@ -2,7 +2,7 @@
 title: 인증서(Certificate)
 id: certificate
 date: 2018-04-12
-full_link: /docs/tasks/tls/managing-tls-in-a-cluster/
+full_link: /ko/docs/tasks/tls/managing-tls-in-a-cluster/
 short_description: >
  암호화된 안전한 파일로 쿠버네티스 클러스터 접근 검증에 사용한다.

@@ -2,7 +2,7 @@
 title: 익스텐션(Extensions)
 id: Extensions
 date: 2019-02-01
-full_link: /ko/docs/concepts/extend-kubernetes/extend-cluster/#익스텐션
+full_link: /ko/docs/concepts/extend-kubernetes/#익스텐션
 short_description: >
  익스텐션은 새로운 타입의 하드웨어를 지원하기 위해 쿠버네티스를 확장하고 깊게 통합시키는 소프트웨어 컴포넌트이다.

@@ -15,4 +15,4 @@ tags:

 <!--more-->

-대부분의 클러스터 관리자는 호스트된 쿠버네티스 또는 쿠버네티스의 배포 인스턴스를 사용할 것이다. 그 결과, 대부분의 쿠버네티스 사용자는 [익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#익스텐션)의 설치가 필요할 것이며, 일부 사용자만 직접 새로운 것을 만들 것이다.
+대부분의 클러스터 관리자는 호스트된 쿠버네티스 또는 쿠버네티스의 배포 인스턴스를 사용할 것이다. 그 결과, 대부분의 쿠버네티스 사용자는 [익스텐션](/ko/docs/concepts/extend-kubernetes/#익스텐션)의 설치가 필요할 것이며, 일부 사용자만 직접 새로운 것을 만들 것이다.
@@ -2,7 +2,7 @@
 title: kube-scheduler
 id: kube-scheduler
 date: 2018-04-12
-full_link: /docs/reference/generated/kube-scheduler/
+full_link: /docs/reference/command-line-tools-reference/kube-scheduler/
 short_description: >
  노드가 배정되지 않은 새로 생성된 파드를 감지하고, 실행할 노드를 선택하는 컨트롤 플레인 컴포넌트.

@@ -2,7 +2,7 @@
 title: Minikube
 id: minikube
 date: 2018-04-12
-full_link: /ko/docs/setup/learning-environment/minikube/
+full_link: /ko/docs/tasks/tools/#minikube
 short_description: >
  로컬에서 쿠버네티스를 실행하기 위한 도구.

@@ -9,7 +9,7 @@ weight: 30

 kubectl은 쿠버네티스 클러스터 관리자를 제어한다.

- 자세한 정보는 https://kubernetes.io/docs/reference/kubectl/overview/ 에서 확인한다.
+ 자세한 정보는 [kubectl 개요](/ko/docs/reference/kubectl/overview/)를 확인한다.

 ```
 kubectl [flags]
@@ -0,0 +1,325 @@
+---
+title: 잘 알려진 레이블, 어노테이션, 테인트(Taint)
+content_type: concept
+weight: 20
+---
+
+<!-- overview -->
+
+쿠버네티스는 모든 레이블과 어노테이션을 `kubernetes.io` 네임스페이스 아래에 정의해 놓았다.
+
+이 문서는 각 값에 대한 레퍼런스를 제공하며, 값을 할당하기 위한 협력 포인트도 제공한다.
+
+
+
+<!-- body -->
+
+## kubernetes.io/arch
+
+예시: `kubernetes.io/arch=amd64`
+
+적용 대상: 노드
+
+Go에 의해 정의된 `runtime.GOARCH` 값을 kubelet이 읽어서 이 레이블의 값으로 채운다. arm 노드와 x86 노드를 혼합하여 사용하는 경우 유용할 수 있다.
+
+## kubernetes.io/os
+
+예시: `kubernetes.io/os=linux`
+
+적용 대상: 노드
+
+Go에 의해 정의된 `runtime.GOOS` 값을 kubelet이 읽어서 이 레이블의 값으로 채운다. 클러스터에서 여러 운영체제를 혼합하여 사용(예: 리눅스 및 윈도우 노드)하는 경우 유용할 수 있다.
+
+## kubernetes.io/metadata.name
+
+예시: `kubernetes.io/metadata.name=mynamespace`
+
+적용 대상: 네임스페이스
+
+`NamespaceDefaultLabelName` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 
+활성화되어 있으면, 
+쿠버네티스 API 서버가 모든 네임스페이스에 이 레이블을 적용한다. 
+레이블의 값은 네임스페이스의 이름으로 적용된다.
+
+레이블 {{< glossary_tooltip text="셀렉터" term_id="selector" >}}를 이용하여 특정 네임스페이스를 지정하고 싶다면 
+이 레이블이 유용할 수 있다.
+
+## beta.kubernetes.io/arch (사용 중단됨)
+
+이 레이블은 사용 중단되었다. 대신 `kubernetes.io/arch` 을 사용한다.
+
+## beta.kubernetes.io/os (사용 중단됨)
+
+이 레이블은 사용 중단되었다. 대신 `kubernetes.io/os` 을 사용한다.
+
+## kubernetes.io/hostname {#kubernetesiohostname}
+
+예시: `kubernetes.io/hostname=ip-172-20-114-199.ec2.internal`
+
+적용 대상: 노드
+
+kubelet이 호스트네임을 읽어서 이 레이블의 값으로 채운다. `kubelet` 에 `--hostname-override` 플래그를 전달하여 실제 호스트네임과 다른 값으로 설정할 수도 있다.
+
+이 레이블은 토폴로지 계층의 일부로도 사용된다. [`topology.kubernetes.io/zone`](#topologykubernetesiozone)에서 세부 사항을 확인한다.
+
+
+## controller.kubernetes.io/pod-deletion-cost {#pod-deletion-cost}
+
+예시: `controller.kubernetes.io/pod-deletion-cost=10`
+
+적용 대상: Pod
+
+이 어노테이션은 레플리카셋(ReplicaSet) 다운스케일 순서를 조정할 수 있는 요소인 [파드 삭제 비용](/ko/docs/concepts/workloads/controllers/replicaset/#파드-삭제-비용)을 
+설정하기 위해 사용한다. 명시된 값은 `int32` 타입으로 파싱된다.
+
+## beta.kubernetes.io/instance-type (사용 중단됨)
+
+{{< note >}} v1.17부터, [`node.kubernetes.io/instance-type`](#nodekubernetesioinstance-type)으로 대체되었다. {{< /note >}}
+
+## node.kubernetes.io/instance-type {#nodekubernetesioinstance-type}
+
+예시: `node.kubernetes.io/instance-type=m3.medium`
+
+적용 대상: 노드
+
+`클라우드 제공자`에 의해 정의된 인스턴스 타입의 값을 kubelet이 읽어서 이 레이블의 값으로 채운다. 
+`클라우드 제공자`를 사용하는 경우에만 이 레이블이 설정된다. 
+특정 워크로드를 특정 인스턴스 타입에 할당하고 싶다면 이 레이블이 유용할 수 있다. 
+하지만 일반적으로는 자원 기반 스케줄링을 수행하는 쿠버네티스 스케줄러를 이용하게 된다. 인스턴스 타입 보다는 특성을 기준으로 스케줄링을 고려해야 한다(예: `g2.2xlarge` 를 요구하기보다는, GPU가 필요하다고 요구한다).
+
+## failure-domain.beta.kubernetes.io/region (사용 중단됨) {#failure-domainbetakubernetesioregion}
+
+[`topology.kubernetes.io/region`](#topologykubernetesioregion)을 확인한다.
+
+{{< note >}} v1.17부터, [`topology.kubernetes.io/region`](#topologykubernetesioregion)으로 대체되었다. {{< /note >}}
+
+## failure-domain.beta.kubernetes.io/zone (사용 중단됨) {#failure-domainbetakubernetesiozone}
+
+[`topology.kubernetes.io/zone`](#topologykubernetesiozone)을 확인한다.
+
+{{< note >}} v1.17부터, [`topology.kubernetes.io/zone`](#topologykubernetesiozone)으로 대체되었다. {{< /note >}}
+
+## statefulset.kubernetes.io/pod-name {#statefulsetkubernetesiopod-name}
+
+예시:
+
+`statefulset.kubernetes.io/pod-name=mystatefulset-7`
+
+스테이트풀셋(StatefulSet) 컨트롤러가 파드를 위한 스테이트풀셋을 생성하면, 컨트롤 플레인이 파드에 이 레이블을 설정한다. 
+생성되는 파드의 이름을 이 레이블의 값으로 설정한다.
+
+스테이트풀셋 문서의 [파드 이름 레이블](/ko/docs/concepts/workloads/controllers/statefulset/#파드-이름-레이블)에서 
+상세 사항을 확인한다.
+
+## topology.kubernetes.io/region {#topologykubernetesioregion}
+
+예시:
+
+`topology.kubernetes.io/region=us-east-1`
+
+[`topology.kubernetes.io/zone`](#topologykubernetesiozone)을 확인한다.
+
+## topology.kubernetes.io/zone {#topologykubernetesiozone}
+
+예시:
+
+`topology.kubernetes.io/zone=us-east-1c`
+
+적용 대상: 노드, 퍼시스턴트볼륨(PersistentVolume)
+
+노드의 경우: `클라우드 제공자`가 제공하는 값을 이용하여 `kubelet` 또는 외부 `cloud-controller-manager`가 이 어노테이션의 값을 설정한다. `클라우드 제공자`를 사용하는 경우에만 이 레이블이 설정된다. 하지만, 토폴로지 내에서 의미가 있는 경우에만 이 레이블을 노드에 설정해야 한다.
+
+퍼시스턴트볼륨의 경우: 토폴로지 어웨어 볼륨 프로비저너가 자동으로 퍼시스턴트볼륨에 노드 어피니티 제약을 설정한다.
+
+영역(zone)은 논리적 고장 도메인을 나타낸다. 가용성 향상을 위해 일반적으로 쿠버네티스 클러스터는 여러 영역에 걸쳐 구성된다. 영역에 대한 정확한 정의는 사업자 별 인프라 구현에 따라 다르지만, 일반적으로 영역은 '영역 내 매우 낮은 네트워크 지연시간, 영역 내 네트워크 트래픽 비용 없음, 다른 영역의 고장에 독립적임' 등의 공통적인 특성을 갖는다. 예를 들어, 같은 영역 내의 노드는 하나의 네트워크 스위치를 공유하여 활용할 수 있으며, 반대로 다른 영역에 있는 노드는 하나의 네트워크 스위치를 공유해서는 안 된다.
+
+지역(region)은 하나 이상의 영역으로 구성된 더 큰 도메인을 나타낸다. 쿠버네티스 클러스터가 여러 지역에 걸쳐 있는 경우는 드물다. 영역이나 지역에 대한 정확한 정의는 사업자 별 인프라 구현에 따라 다르지만, 일반적으로 지역은 '지역 내 네트워크 지연시간보다 지역 간 네트워크 지연시간이 큼, 지역 간 네트워크 트래픽은 비용이 발생함, 다른 영역/지역의 고장에 독립적임' 등의 공통적인 특성을 갖는다. 예를 들어, 같은 지역 내의 노드는 전력 인프라(예: UPS 또는 발전기)를 공유하여 활용할 수 있으며, 반대로 다른 지역에 있는 노드는 일반적으로 전력 인프라를 공유하지 않는다.
+
+쿠버네티스는 영역과 지역의 구조에 대해 다음과 같이 가정한다.
+1) 지역과 영역은 계층적이다. 영역은 지역의 엄격한 부분집합(strict subset)이며, 하나의 영역이 두 개의 지역에 속할 수는 없다.
+2) 영역 이름은 모든 지역에 걸쳐서 유일하다. 예를 들어, "africa-east-1" 라는 지역은 "africa-east-1a" 와 "africa-east-1b" 라는 영역으로 구성될 수 있다.
+
+토폴로지 레이블이 변경되는 일은 없다고 가정할 수 있다. 일반적으로 레이블의 값은 변경될 수 있지만, 특정 노드가 삭제 후 재생성되지 않고서는 다른 영역으로 이동할 수 없기 때문이다.
+
+쿠버네티스는 이 정보를 다양한 방식으로 활용할 수 있다. 예를 들어, 단일 영역 클러스터에서는 스케줄러가 자동으로 레플리카셋의 파드를 여러 노드에 퍼뜨린다(노드 고장의 영향을 줄이기 위해 - [`kubernetes.io/hostname`](#kubernetesiohostname) 참고). 복수 영역 클러스터에서는, 여러 영역에 퍼뜨린다(영역 고장의 영향을 줄이기 위해). 이는 _SelectorSpreadPriority_ 를 통해 실현된다.
+
+_SelectorSpreadPriority_ 는 최선 노력(best effort) 배치 방법이다. 클러스터가 위치한 영역들의 특성이 서로 다르다면(예: 노드 숫자가 다름, 노드 타입이 다름, 파드 자원 요구사항이 다름), 파드 숫자를 영역별로 다르게 하여 배치할 수 있다. 필요하다면, 영역들의 특성(노드 숫자/타입)을 일치시켜 불균형 배치의 가능성을 줄일 수 있다.
+
+스케줄러도 (_VolumeZonePredicate_ 표시자를 이용하여) '파드가 요청하는 볼륨'이 위치하는 영역과 같은 영역에 파드를 배치한다. 여러 영역에서 볼륨에 접근할 수는 없다.
+
+`PersistentVolumeLabel`이 퍼시스턴트볼륨의 자동 레이블링을 지원하지 않는다면, 레이블을 수동으로 추가하거나 `PersistentVolumeLabel`이 동작하도록 변경할 수 있다. 
+`PersistentVolumeLabel`이 설정되어 있으면, 스케줄러는 파드가 다른 영역에 있는 볼륨에 마운트하는 것을 막는다. 만약 사용 중인 인프라에 이러한 제약이 없다면, 볼륨에 영역 레이블을 추가할 필요가 전혀 없다.
+
+## node.kubernetes.io/windows-build {#nodekubernetesiowindows-build}
+
+예시: `node.kubernetes.io/windows-build=10.0.17763`
+
+적용 대상: 노드
+
+kubelet이 Microsoft 윈도우에서 실행되고 있다면, 사용 중인 Windows Server 버전을 기록하기 위해 kubelet이 노드에 이 레이블을 추가한다.
+
+이 레이블의 값은 "MajorVersion.MinorVersion.BuildNumber"의 형태를 갖는다.
+
+## service.kubernetes.io/headless {#servicekubernetesioheadless}
+
+예시: `service.kubernetes.io/headless=""`
+
+적용 대상: 서비스
+
+서비스가 헤드리스(headless)이면, 컨트롤 플레인이 엔드포인트(Endpoints) 오브젝트에 이 레이블을 추가한다.
+
+## kubernetes.io/service-name {#kubernetesioservice-name}
+
+예시: `kubernetes.io/service-name="nginx"`
+
+적용 대상: 서비스
+
+쿠버네티스가 여러 서비스를 구분하기 위해 이 레이블을 사용한다. 현재는 `ELB`(Elastic Load Balancer) 를 위해서만 사용되고 있다.
+
+## endpointslice.kubernetes.io/managed-by {#endpointslicekubernetesiomanaged-by}
+
+예시: `endpointslice.kubernetes.io/managed-by="controller"`
+
+적용 대상: 엔드포인트슬라이스(EndpointSlices)
+
+이 레이블은 엔드포인트슬라이스(EndpointSlice)를 어떤 컨트롤러나 엔티티가 관리하는지를 나타내기 위해 사용된다. 이 레이블을 사용함으로써 한 클러스터 내에서 여러 엔드포인트슬라이스 오브젝트가 각각 다른 컨트롤러나 엔티티에 의해 관리될 수 있다.
+
+## endpointslice.kubernetes.io/skip-mirror {#endpointslicekubernetesioskip-mirror}
+
+예시: `endpointslice.kubernetes.io/skip-mirror="true"`
+
+적용 대상: 엔드포인트(Endpoints)
+
+특정 자원에 이 레이블을 `"true"` 로 설정하여, EndpointSliceMirroring 컨트롤러가 엔드포인트슬라이스를 이용하여 해당 자원을 미러링하지 않도록 지시할 수 있다.
+
+## service.kubernetes.io/service-proxy-name {#servicekubernetesioservice-proxy-name}
+
+예시: `service.kubernetes.io/service-proxy-name="foo-bar"`
+
+적용 대상: 서비스
+
+kube-proxy 에는 커스텀 프록시를 위한 이와 같은 레이블이 있으며, 이 레이블은 서비스 컨트롤을 커스텀 프록시에 위임한다.
+
+## experimental.windows.kubernetes.io/isolation-type
+
+예시: `experimental.windows.kubernetes.io/isolation-type: "hyperv"`
+
+적용 대상: 파드
+
+Hyper-V 격리(isolation)를 사용하여 윈도우 컨테이너를 실행하려면 이 어노테이션을 사용한다. Hyper-V 격리 기능을 활성화하고 Hyper-V 격리가 적용된 컨테이너를 생성하기 위해, kubelet은 기능 게이트 `HyperVContainer=true` 로 설정하여 실행되어야 하며, 파드에는 `experimental.windows.kubernetes.io/isolation-type=hyperv` 어노테이션이 설정되어 있어야 한다.
+
+{{< note >}}
+이 어노테이션은 하나의 컨테이너로 구성된 파드에만 설정할 수 있다.
+{{< /note >}}
+
+## ingressclass.kubernetes.io/is-default-class
+
+예시: `ingressclass.kubernetes.io/is-default-class: "true"`
+
+적용 대상: 인그레스클래스(IngressClass)
+
+하나의 인그레스클래스 리소스에 이 어노테이션이 `"true"`로 설정된 경우, 클래스가 명시되지 않은 새로운 인그레스(Ingress) 리소스는 해당 기본 클래스로 할당될 것이다.
+
+## kubernetes.io/ingress.class (사용 중단됨)
+
+{{< note >}}
+v1.18부터, `spec.ingressClassName`으로 대체되었다.
+{{< /note >}}
+
+## storageclass.kubernetes.io/is-default-class
+
+예시: `storageclass.kubernetes.io/is-default-class=true`
+
+적용 대상: 스토리지클래스(StorageClass)
+
+하나의 스토리지클래스(StorageClass) 리소스에 이 어노테이션이 `"true"`로 설정된 경우, 
+클래스가 명시되지 않은 새로운 퍼시스턴트볼륨클레임(PersistentVolumeClaim) 리소스는 해당 기본 클래스로 할당될 것이다.
+
+## alpha.kubernetes.io/provided-node-ip
+
+예시: `alpha.kubernetes.io/provided-node-ip: "10.0.0.1"`
+
+적용 대상: 노드
+
+kubelet이 노드에 할당된 IPv4 주소를 명시하기 위해 이 어노테이션을 사용할 수 있다.
+
+kubelet이 "외부" 클라우드 제공자에 의해 실행되었다면, 명령줄 플래그(`--node-ip`)를 통해 설정된 IP 주소를 명시하기 위해 kubelet이 이 어노테이션을 노드에 설정한다. cloud-controller-manager는 클라우드 제공자에게 이 IP 주소가 유효한지를 검증한다.
+
+## batch.kubernetes.io/job-completion-index
+
+예시: `batch.kubernetes.io/job-completion-index: "3"`
+
+적용 대상: 파드
+
+kube-controller-manager의 잡(Job) 컨트롤러는 
+`Indexed` [완료 모드](/ko/docs/concepts/workloads/controllers/job/#완료-모드)로 생성된 파드에 이 어노테이션을 추가한다.
+
+## kubectl.kubernetes.io/default-container
+
+예시: `kubectl.kubernetes.io/default-container: "front-end-app"`
+
+파드의 기본 컨테이너로 사용할 컨테이너 이름을 지정하는 어노테이션이다. 예를 들어, `kubectl logs` 또는 `kubectl exec` 명령을 사용할 때 `-c` 또는 `--container` 플래그를 지정하지 않으면, 이 어노테이션으로 명시된 기본 컨테이너를 대상으로 실행될 것이다.
+
+## endpoints.kubernetes.io/over-capacity
+
+예시: `endpoints.kubernetes.io/over-capacity:warning`
+
+적용 대상: 엔드포인트(Endpoints)
+
+v1.21 이상의 쿠버네티스 클러스터에서, 엔드포인트(Endpoints) 컨트롤러가 1000개 이상의 엔드포인트를 관리하고 있다면 각 엔드포인트 리소스에 이 어노테이션을 추가한다. 이 어노테이션은 엔드포인트 리소스가 용량 초과 되었음을 나타낸다.
+
+**이 이후로 나오는 테인트는 모두 '적용 대상: 노드' 이다.**
+
+## node.kubernetes.io/not-ready
+
+예시: `node.kubernetes.io/not-ready:NoExecute`
+
+노드 컨트롤러는 노드의 헬스를 모니터링하여 노드가 사용 가능한 상태인지를 감지하고 그에 따라 이 테인트를 추가하거나 제거한다.
+
+## node.kubernetes.io/unreachable
+
+예시: `node.kubernetes.io/unreachable:NoExecute`
+
+노드 컨트롤러는 [노드 컨디션](/ko/docs/concepts/architecture/nodes/#condition)이 `Ready`에서 `Unknown`으로 변경된 노드에 이 테인트를 추가한다.
+
+## node.kubernetes.io/unschedulable
+
+예시: `node.kubernetes.io/unschedulable:NoSchedule`
+
+경쟁 상태(race condition) 발생을 막기 위해, 생성 중인 노드에 이 테인트가 추가된다.
+
+## node.kubernetes.io/memory-pressure
+
+예시: `node.kubernetes.io/memory-pressure:NoSchedule`
+
+kubelet은 노드의 `memory.available`와 `allocatableMemory.available`을 관측하여 메모리 압박을 감지한다. 그 뒤, 관측한 값을 kubelet에 설정된 문턱값(threshold)과 비교하여 노드 컨디션과 테인트의 추가/삭제 여부를 결정한다.
+
+## node.kubernetes.io/disk-pressure
+
+예시: `node.kubernetes.io/disk-pressure:NoSchedule`
+
+kubelet은 노드의 `imagefs.available`, `imagefs.inodesFree`, `nodefs.available`, `nodefs.inodesFree`(리눅스에 대해서만)를 관측하여 디스크 압박을 감지한다. 그 뒤, 관측한 값을 kubelet에 설정된 문턱값(threshold)과 비교하여 노드 컨디션과 테인트의 추가/삭제 여부를 결정한다.
+
+## node.kubernetes.io/network-unavailable
+
+예시: `node.kubernetes.io/network-unavailable:NoSchedule`
+
+사용 중인 클라우드 공급자가 추가 네트워크 환경설정을 필요로 한다고 명시하면, kubelet이 이 테인트를 설정한다. 클라우드 상의 네트워크 경로가 올바르게 구성되어야, 클라우드 공급자가 이 테인트를 제거할 것이다.
+
+## node.kubernetes.io/pid-pressure
+
+예시: `node.kubernetes.io/pid-pressure:NoSchedule`
+
+kubelet은 '`/proc/sys/kernel/pid_max`의 크기의 D-값'과 노드에서 쿠버네티스가 사용 중인 PID를 확인하여, `pid.available` 지표라고 불리는 '사용 가능한 PID 수'를 가져온다. 그 뒤, 관측한 지표를 kubelet에 설정된 문턱값(threshold)과 비교하여 노드 컨디션과 테인트의 추가/삭제 여부를 결정한다.
+
+## node.cloudprovider.kubernetes.io/uninitialized
+
+예시: `node.cloudprovider.kubernetes.io/uninitialized:NoSchedule`
+
+kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드가 '사용 불가능'한 상태라고 표시하기 위해 이 테인트가 추가되며, 추후 cloud-controller-manager가 이 노드를 초기화하고 이 테인트를 제거한다.
+
+## node.cloudprovider.kubernetes.io/shutdown
+
+예시: `node.cloudprovider.kubernetes.io/shutdown:NoSchedule`
+
+노드의 상태가 클라우드 공급자가 정의한 'shutdown' 상태이면, 이에 따라 노드에 `node.cloudprovider.kubernetes.io/shutdown` 테인트가 `NoSchedule` 값으로 설정된다.
@@ -12,7 +12,7 @@ content_type: concept
 <!-- body -->
 ## Kubectl

-[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)은 쿠버네티스를 위한 커맨드라인 툴이며, 쿠버네티스 클러스터 매니저을 제어한다.
+[`kubectl`](/ko/docs/tasks/tools/#kubectl)은 쿠버네티스를 위한 커맨드라인 툴이며, 쿠버네티스 클러스터 매니저을 제어한다.

 ## Kubeadm

@@ -65,7 +65,6 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다.
 | PHP                  | [github.com/maclof/kubernetes-client](https://github.com/maclof/kubernetes-client) |
 | PHP                  | [github.com/travisghansen/kubernetes-client-php](https://github.com/travisghansen/kubernetes-client-php) |
 | PHP                  | [github.com/renoki-co/php-k8s](https://github.com/renoki-co/php-k8s) |
-| Python               | [github.com/eldarion-gondor/pykube](https://github.com/eldarion-gondor/pykube) |
 | Python               | [github.com/fiaas/k8s](https://github.com/fiaas/k8s) |
 | Python               | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) |
 | Python               | [github.com/tomplus/kubernetes_asyncio](https://github.com/tomplus/kubernetes_asyncio) |
@@ -1,17 +1,21 @@
 ---
-no_issue: true
+
+
+
+
 title: 시작하기
 main_menu: true
 weight: 20
 content_type: concept
+no_list: true
 card:
  name: setup
  weight: 20
  anchors:
  - anchor: "#학습-환경"
    title: 학습 환경
-  - anchor: "#운영-환경"
-    title: 운영 환경
+  - anchor: "#프로덕션-환경"
+    title: 프로덕션 환경
 ---

 <!-- overview -->
@@ -20,16 +24,40 @@ card:
 쿠버네티스를 설치할 때는 유지보수의 용이성, 보안, 제어, 사용 가능한 리소스, 그리고
 클러스터를 운영하고 관리하기 위해 필요한 전문성을 기반으로 설치 유형을 선택한다.

-쿠버네티스 클러스터를 로컬 머신에, 클라우드에, 온-프레미스 데이터센터에 배포할 수 있고, 아니면 매니지드 쿠버네티스 클러스터를 선택할 수도 있다. 광범위한 클라우드 제공 업체 또는 베어 메탈 환경에 걸쳐 사용할 수 있는 맞춤형 솔루션도 있다.
+[쿠버네티스를 다운로드](/releases/download/)하여 
+로컬 머신에, 클라우드에, 데이터센터에 쿠버네티스 클러스터를 구축할 수 있다.
+
+쿠버네티스 클러스터를 직접 관리하고 싶지 않다면, [인증된 플랫폼](/ko/docs/setup/production-environment/turnkey-solutions/)과 
+같은 매니지드 서비스를 선택할 수도 있다.
+광범위한 클라우드 또는 베어 메탈 환경에 걸쳐 사용할 수 있는 
+표준화된/맞춤형 솔루션도 있다.

 <!-- body -->

 ## 학습 환경

-쿠버네티스를 배우고 있다면, 쿠버네티스 커뮤니티에서 지원하는 도구나, 로컬 머신에서 쿠버네티스를 설치하기 위한 생태계 내의 도구를 사용하자.
+쿠버네티스를 배우고 있다면, 쿠버네티스 커뮤니티에서 지원하는 도구나, 
+로컬 머신에서 쿠버네티스를 설치하기 위한 생태계 내의 도구를 사용한다.
+[도구 설치](/ko/docs/tasks/tools/)를 살펴본다.

-## 운영 환경
+## 프로덕션 환경

-운영 환경을 위한 솔루션을 평가할 때에는, 쿠버네티스 클러스터 운영에 대한 어떤 측면(또는 _추상적인 개념_)을 스스로 관리하기를 원하는지, 제공자에게 넘기기를 원하는지 고려하자.
+[프로덕션 환경](/ko/docs/setup/production-environment/)을 위한 
+솔루션을 평가할 때에는, 쿠버네티스 클러스터(또는 _추상화된 객체_) 
+운영에 대한 어떤 측면을 스스로 관리하기를 원하는지, 
+또는 제공자에게 넘기기를 원하는지 고려한다.

-[쿠버네티스 파트너](https://kubernetes.io/partners/#conformance)에는 [공인 쿠버네티스](https://github.com/cncf/k8s-conformance/#certified-kubernetes) 공급자 목록이 포함되어 있다.
+클러스터를 직접 관리하는 경우, 공식적으로 지원되는 쿠버네티스 구축 도구는 
+[kubeadm](/ko/docs/setup/production-environment/tools/kubeadm/)이다.
+
+## {{% heading "whatsnext" %}}
+
+- [쿠버네티스를 다운로드](/releases/download/)한다.
+- `kubectl`을 포함한 [도구를 설치](/ko/docs/tasks/tools/)한다.
+- 새로운 클러스터에 사용할 [컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/)을 선택한다.
+- 클러스터 구성의 [모범 사례](/ko/docs/setup/best-practices/)를 확인한다.
+
+쿠버네티스의 {{< glossary_tooltip term_id="control-plane" text="컨트롤 플레인" >}}은 
+리눅스에서 실행되어야 한다. 클러스터 내에서는 리눅스 또는 
+다른 운영 체제(예: 윈도우)에서 애플리케이션을 실행할 수 있다.
+- [윈도우 노드를 포함하는 클러스터 구성하기](/ko/docs/setup/production-environment/windows/)를 살펴본다.
@@ -6,13 +6,13 @@ weight: 20
 클러스터는 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}에서 관리하는
 쿠버네티스 에이전트를 실행하는 {{< glossary_tooltip text="노드" term_id="node" >}}(물리
 또는 가상 머신)의 집합이다.
-쿠버네티스 {{<param "version">}}는 노드 5000개까지의 클러스터를 지원한다. 보다 정확하게는,
+쿠버네티스 {{<param "version">}}는 노드 5,000개까지의 클러스터를 지원한다. 보다 정확하게는,
 쿠버네티스는 다음 기준을 *모두* 만족하는 설정을 수용하도록 설계되었다.

-* 노드 당 파드 100 개 이하
-* 노드 5000개 이하
-* 전체 파드 150000개 이하
-* 전체 컨테이너 300000개 이하
+* 노드 당 파드 110 개 이하
+* 노드 5,000개 이하
+* 전체 파드 150,000개 이하
+* 전체 컨테이너 300,000개 이하

 노드를 추가하거나 제거하여 클러스터를 확장할 수 있다. 이를 수행하는 방법은
 클러스터 배포 방법에 따라 다르다.
@@ -53,7 +53,7 @@ no_list: true
 관리하여, 사용자 및 워크로드가 접근할 수 있는 자원에 대한 제한을 설정할 수 있다.

 쿠버네티스 프로덕션 환경을 직접 구축하기 전에, 이 작업의 일부 또는 전체를 
-[턴키 클라우드 솔루션](/docs/setup/production-environment/turnkey-solutions/) 
+[턴키 클라우드 솔루션](/ko/docs/setup/production-environment/turnkey-solutions/) 
 제공 업체 또는 기타 [쿠버네티스 파트너](/ko/partners/)에게 
 넘기는 것을 고려할 수 있다.
 다음과 같은 옵션이 있다.
@@ -151,7 +151,7 @@ etcd는 클러스터 구성 데이터를 저장하므로
 [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/), 
 [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/)를 참조한다.
 고가용성 컨트롤 플레인 예제는 
-[고가용성 토폴로지를 위한 옵션](/docs/setup/production-environment/tools/kubeadm/ha-topology/),
+[고가용성 토폴로지를 위한 옵션](/ko/docs/setup/production-environment/tools/kubeadm/ha-topology/),
 [kubeadm을 이용하여 고가용성 클러스터 생성하기](/docs/setup/production-environment/tools/kubeadm/high-availability/),
 [쿠버네티스를 위한 etcd 클러스터 운영하기](/docs/tasks/administer-cluster/configure-upgrade-etcd/)를 참조한다.
 etcd 백업 계획을 세우려면 
@@ -274,8 +274,8 @@ DNS 서비스도 확장할 준비가 되어 있어야 한다.
 ## {{% heading "whatsnext" %}}

 - 프로덕션 쿠버네티스를 직접 구축할지, 
-아니면 [턴키 클라우드 솔루션](/docs/setup/production-environment/turnkey-solutions/) 또는 
-[쿠버네티스 파트너](/partners/)가 제공하는 서비스를 이용할지 결정한다.
+아니면 [턴키 클라우드 솔루션](/ko/docs/setup/production-environment/turnkey-solutions/) 또는 
+[쿠버네티스 파트너](/ko/partners/)가 제공하는 서비스를 이용할지 결정한다.
 - 클러스터를 직접 구축한다면, 
 [인증서](/ko/docs/setup/best-practices/certificates/)를 어떻게 관리할지, 
 [etcd](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)와 
@@ -9,7 +9,8 @@ weight: 40

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

-kubeadm의 `ClusterConfiguration` 오브젝트는 API 서버, 컨트롤러매니저, 스케줄러와 같은 컨트롤 플레인 구성요소에 전달되는 기본 플래그 `extraArgs` 필드를 노출한다. 이 구성요소는 다음 필드를 사용하도록 정의되어 있다.
+kubeadm의 `ClusterConfiguration` 오브젝트는 API 서버, 컨트롤러매니저, 스케줄러와 같은 컨트롤 플레인 구성요소에 전달되는
+기본 플래그 `extraArgs` 필드를 노출한다. 이 구성요소는 다음 필드를 사용하도록 정의되어 있다.

 - `apiServer`
 - `controllerManager`
@@ -19,7 +20,7 @@ kubeadm의 `ClusterConfiguration` 오브젝트는 API 서버, 컨트롤러매니

 1.  사용자 구성에서 적절한 필드를 추가한다.
 2.  필드에 대체할 플래그를 추가한다.
-3.  `kubeadm init`에 `--config <YOUR CONFIG YAML>` 파라미터를 추가해서 실행한다.
+3.  `kubeadm init`에 `--config <CONFIG YAML 파일>` 파라미터를 추가해서 실행한다.

 각 필드의 구성에서 자세한 정보를 보려면,
 [API 참고 문서](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2#ClusterConfiguration)에서 확인해 볼 수 있다.
@@ -34,9 +35,9 @@ kubeadm의 `ClusterConfiguration` 오브젝트는 API 서버, 컨트롤러매니

 ## APIServer 플래그

-자세한 내용은 [kube-apiserver에 대한 참고 문서](/docs/reference/command-line-tools-reference/kube-apiserver/)를 확인한다.
+자세한 내용은 [kube-apiserver 레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-apiserver/)를 확인한다.

-사용 예:
+예시:
 ```yaml
 apiVersion: kubeadm.k8s.io/v1beta2
 kind: ClusterConfiguration
@@ -51,9 +52,9 @@ apiServer:

 ## 컨트롤러매니저 플래그

-자세한 내용은 [kube-controller-manager에 대한 참고 문서](/docs/reference/command-line-tools-reference/kube-controller-manager/)를 확인한다.
+자세한 내용은 [kube-controller-manager 레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-controller-manager/)를 확인한다.

-사용 예:
+예시:
 ```yaml
 apiVersion: kubeadm.k8s.io/v1beta2
 kind: ClusterConfiguration
@@ -67,9 +68,9 @@ controllerManager:

 ## 스케줄러 플래그

-자세한 내용은 [kube-scheduler에 대한 참고 문서](/docs/reference/command-line-tools-reference/kube-scheduler/)를 확인한다.
+자세한 내용은 [kube-scheduler 레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/)를 확인한다.

-사용 예:
+예시:
 ```yaml
 apiVersion: kubeadm.k8s.io/v1beta2
 kind: ClusterConfiguration
@@ -169,7 +169,7 @@ kubeadm은 `kubelet` 또는 `kubectl` 을 설치하거나 관리하지 **않으

 버전 차이에 대한 자세한 내용은 다음을 참고한다.

-* 쿠버네티스 [버전 및 버전-차이 정책](/docs/setup/release/version-skew-policy/)
+* 쿠버네티스 [버전 및 버전-차이 정책](/ko/releases/version-skew-policy/)
 * Kubeadm 관련 [버전 차이 정책](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy)

 {{< tabs name="k8s_install" >}}
@@ -84,7 +84,7 @@ weight: 65
 단계별 지침을 제공한다. 이 가이드에는 클러스터 노드와 함께 사용자 애플리케이션을
 업그레이드하기 위한 권장 업그레이드 절차가 포함된다.
 윈도우 노드는 현재 리눅스 노드와 동일한 방식으로 쿠버네티스
-[버전-스큐(skew) 정책](/ko/docs/setup/release/version-skew-policy/)(노드 대 컨트롤 플레인
+[버전-차이(skew) 정책](/ko/releases/version-skew-policy/)(노드 대 컨트롤 플레인
 버전 관리)을 준수한다.


@@ -809,7 +809,7 @@ DNS, 라우트, 메트릭과 같은 많은 구성은 리눅스에서와 같이 /
 1. [BitLocker](https://docs.microsoft.com/ko-kr/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server)를
   사용한 볼륨-레벨 암호화를 사용한다.

-[RunAsUsername](/ko/docs/tasks/configure-pod-container/configure-runasusername)은
+[RunAsUsername](/ko/docs/tasks/configure-pod-container/configure-runasusername/)은
 컨테이너 프로세스를 노드 기본 사용자로 실행하기 위해 윈도우 파드 또는
 컨테이너에 지정할 수 있다. 이것은
 [RunAsUser](/ko/docs/concepts/policy/pod-security-policy/#사용자-및-그룹)와 거의 동일하다.
@@ -139,7 +139,7 @@ LogMonitor가 로그를 STDOUT으로 푸시할 수 있도록 필요한 엔트리
 쿠버네티스 v1.16 부터, 윈도우 컨테이너는 이미지 기본 값과는 다른 username으로 엔트리포인트와 프로세스를
 실행하도록 설정할 수 있다.
 이 방식은 리눅스 컨테이너에서 지원되는 방식과는 조금 차이가 있다.
-[여기](/docs/tasks/configure-pod-container/configure-runasusername/)에서 이에 대해 추가적으로 배울 수 있다.
+[여기](/ko/docs/tasks/configure-pod-container/configure-runasusername/)에서 이에 대해 추가적으로 배울 수 있다.

 ## 그룹 매니지드 서비스 어카운트를 이용하여 워크로드 신원 관리하기

@@ -7,7 +7,6 @@ card:
  weight: 40
 ---

-
 <!-- overview -->

 이 페이지에서는 구성 파일을 사용하여 다수의 클러스터에 접근할 수 있도록
@@ -21,20 +20,15 @@ card:
 반드시 존재해야 한다는 것을 의미하는 것은 아니다.
 {{< /note >}}

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

-
 {{< include "task-tutorial-prereqs.md" >}}

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

-
-
 <!-- steps -->

 ## 클러스터, 사용자, 컨텍스트 정의
@@ -49,7 +43,7 @@ scratch 클러스터에 접근하려면 사용자네임과 패스워드로 인
 `config-exercise`라는 디렉터리를 생성한다. `config-exercise` 디렉터리에
 다음 내용을 가진 `config-demo`라는 파일을 생성한다.

-```shell
+```yaml
 apiVersion: v1
 kind: Config
 preferences: {}
@@ -114,7 +108,7 @@ kubectl config --kubeconfig=config-demo view

 두 클러스터, 두 사용자, 세 컨텍스트들이 출력 결과로 나온다.

-```shell
+```yaml
 apiVersion: v1
 clusters:
 - cluster:
@@ -186,7 +180,7 @@ kubectl config --kubeconfig=config-demo view --minify

 `dev-frontend` 컨텍스트에 관련된 구성 정보가 출력 결과로 표시될 것이다.

-```shell
+```yaml
 apiVersion: v1
 clusters:
 - cluster:
@@ -238,7 +232,6 @@ kubectl config --kubeconfig=config-demo use-context dev-storage

 현재 컨텍스트인 `dev-storage`에 관련된 설정을 보자.

-
 ```shell
 kubectl config --kubeconfig=config-demo view --minify
 ```
@@ -247,7 +240,7 @@ kubectl config --kubeconfig=config-demo view --minify

 `config-exercise` 디렉터리에서 다음 내용으로 `config-demo-2`라는 파일을 생성한다.

-```shell
+```yaml
 apiVersion: v1
 kind: Config
 preferences: {}
@@ -269,13 +262,17 @@ contexts:
 예:

 ### 리눅스
+
 ```shell
-export  KUBECONFIG_SAVED=$KUBECONFIG
+export KUBECONFIG_SAVED=$KUBECONFIG
 ```
+
 ### 윈도우 PowerShell
-```shell
+
+```powershell
 $Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG
 ```
+
 `KUBECONFIG` 환경 변수는 구성 파일들의 경로의 리스트이다. 이 리스트는
 리눅스와 Mac에서는 콜론으로 구분되며 윈도우에서는 세미콜론으로 구분된다.
 `KUBECONFIG` 환경 변수를 가지고 있다면, 리스트에 포함된 구성 파일들에
@@ -284,11 +281,14 @@ $Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG
 다음 예와 같이 임시로 `KUBECONFIG` 환경 변수에 두 개의 경로들을 덧붙여보자.

 ### 리눅스
+
 ```shell
-export  KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2
+export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2
 ```
+
 ### 윈도우 PowerShell
-```shell
+
+```powershell
 $Env:KUBECONFIG=("config-demo;config-demo-2")
 ```

@@ -303,7 +303,7 @@ kubectl config view
 컨텍스트와 `config-demo` 파일의 세 개의 컨텍스트들을
 가지고 있다는 것에 주목하길 바란다.

-```shell
+```yaml
 contexts:
 - context:
    cluster: development
@@ -347,12 +347,15 @@ kubeconfig 파일들을 어떻게 병합하는지에 대한 상세정보는
 예:

 ### 리눅스
+
 ```shell
 export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config
 ```
+
 ### 윈도우 Powershell
-```shell
- $Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config"
+
+```powershell
+$Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config"
 ```

 이제 `KUBECONFIG` 환경 변수에 리스트에 포함된 모든 파일들이 합쳐진 구성 정보를 보자.
@@ -367,19 +370,18 @@ kubectl config view
 `KUBECONFIG` 환경 변수를 원래 값으로 되돌려 놓자. 예를 들면:<br>

 ### 리눅스
+
 ```shell
 export KUBECONFIG=$KUBECONFIG_SAVED
 ```

 ### 윈도우 PowerShell
-```shell
- $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
+
+```powershell
+$Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
 ```

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

-
 * [kubeconfig 파일을 사용하여 클러스터 접근 구성하기](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
 * [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)
@@ -220,4 +220,4 @@ kubectl delete deployment frontend backend

 * [서비스](/ko/docs/concepts/services-networking/service/)에 대해 더 알아본다.
 * [컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/)에 대해 더 알아본다.
-* [서비스와 파드용 DNS](/docs/concepts/services-networking/dns-pod-service/)에 대해 더 알아본다.
+* [서비스와 파드용 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)에 대해 더 알아본다.
@@ -22,7 +22,7 @@ weight: 100
 ## 모든 네임스페이스의 모든 컨테이너 이미지 가져오기

 - `kubectl get pods --all-namespaces` 를 사용하여 모든 네임스페이스의 모든 파드 정보를 가져온다.
- 컨테이너 이미지 이름만 출력하기 위해 `-o jsonpath={..image}` 를 사용한다.
+- 컨테이너 이미지 이름만 출력하기 위해 `-o jsonpath={.items[*].spec.containers[*].image}` 를 사용한다.
  이 명령어는 결과값으로 받은 json을 반복적으로 파싱하여,
  `image` 필드만을 출력한다.
  - jsonpath를 사용하는 방법에 대해 더 많은 정보를 얻고 싶다면
@@ -33,7 +33,7 @@ weight: 100
  - `uniq` 를 사용하여 이미지 개수를 합산한다.

 ```shell
-kubectl get pods --all-namespaces -o jsonpath="{..image}" |\
+kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |\
 tr -s '[[:space:]]' '\n' |\
 sort |\
 uniq -c
@@ -80,7 +80,7 @@ sort
 명령어 결과값은 `app=nginx` 레이블에 일치하는 파드만 출력한다.

 ```shell
-kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
+kubectl get pods --all-namespaces -o=jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx
 ```

 ## 파드 네임스페이스로 필터링된 컨테이너 이미지 목록 보기
@@ -89,7 +89,7 @@ kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
 아래의 명령어 결과값은 `kube-system` 네임스페이스에 있는 파드만 출력한다.

 ```shell
-kubectl get pods --namespace kube-system -o jsonpath="{..image}"
+kubectl get pods --namespace kube-system -o jsonpath="{.items[*].spec.containers[*].image}"
 ```

 ## jsonpath 대신 Go 템플릿을 사용하여 컨테이너 이미지 목록 보기
--- a/Show More
+++ b/Show More