Merge pull request #27901 from jihoon-seo/210507_Update_outdated_files_in_dev-1.20-ko.8_p3

[ko] Update outdated files in dev-1.20-ko.8 (p3)
2021-05-11 03:53:36 -07:00 · 2021-05-10 10:11:33 +09:00 · 2021-05-06 06:05:17 -07:00 · 2021-05-06 06:03:16 -07:00 · 2021-05-04 09:24:19 +09:00 · 2021-05-04 09:22:05 +09:00
64 changed files with 393 additions and 363 deletions
@@ -138,13 +138,13 @@ time_format_default = "January 02, 2006 at 3:04 PM PST"
 description = "Production-Grade Container Orchestration"
 showedit = true

-latest = "v1.20"
+latest = "v1.21"

-fullversion = "v1.20.0"
+fullversion = "v1.20.5"
 version = "v1.20"
-githubbranch = "master"
-docsbranch = "master"
-deprecated = false
+githubbranch = "v1.20.5"
+docsbranch = "release-1.20"
+deprecated = true
 currentUrl = "https://kubernetes.io/docs/home/"
 nextUrl = "https://kubernetes-io-vnext-staging.netlify.com/"

@@ -178,40 +178,40 @@ js = [
 ]

 [[params.versions]]
-fullversion = "v1.20.0"
-version = "v1.20"
-githubbranch = "v1.20.0"
+fullversion = "v1.21.0"
+version = "v1.21"
+githubbranch = "v1.21.0"
 docsbranch = "master"
 url = "https://kubernetes.io"

 [[params.versions]]
-fullversion = "v1.19.4"
+fullversion = "v1.20.5"
+version = "v1.20"
+githubbranch = "v1.20.5"
+docsbranch = "release-1.20"
+url = "https://v1-20.docs.kubernetes.io"
+
+[[params.versions]]
+fullversion = "v1.19.9"
 version = "v1.19"
-githubbranch = "v1.19.4"
+githubbranch = "v1.19.9"
 docsbranch = "release-1.19"
 url = "https://v1-19.docs.kubernetes.io"

 [[params.versions]]
-fullversion = "v1.18.12"
+fullversion = "v1.18.17"
 version = "v1.18"
-githubbranch = "v1.18.12"
+githubbranch = "v1.18.17"
 docsbranch = "release-1.18"
 url = "https://v1-18.docs.kubernetes.io"

 [[params.versions]]
-fullversion = "v1.17.14"
+fullversion = "v1.17.17"
 version = "v1.17"
-githubbranch = "v1.17.14"
+githubbranch = "v1.17.17"
 docsbranch = "release-1.17"
 url = "https://v1-17.docs.kubernetes.io"

-[[params.versions]]
-fullversion = "v1.16.15"
-version = "v1.16"
-githubbranch = "v1.16.15"
-docsbranch = "release-1.16"
-url = "https://v1-16.docs.kubernetes.io"
-

 # User interface configuration
 [params.ui]
@@ -8,14 +8,14 @@ aliases:

 <!-- overview -->

-이 문서는 컨트롤 플레인(실제로는 API 서버)과 쿠버네티스 클러스터 사이에 대한 통신 경로의 목록을 작성한다. 이는 사용자가 신뢰할 수 없는 네트워크(또는 클라우드 공급자의 완전한 퍼블릭 IP)에서 클러스터를 실행할 수 있도록 네트워크 구성을 강화하기 위한 맞춤 설치를 할 수 있도록 한다.
+이 문서는 컨트롤 플레인(API 서버)과 쿠버네티스 클러스터 사이에 대한 통신 경로의 목록을 작성한다. 이는 사용자가 신뢰할 수 없는 네트워크(또는 클라우드 공급자의 완전한 퍼블릭 IP)에서 클러스터를 실행할 수 있도록 네트워크 구성을 강화하기 위한 맞춤 설치를 할 수 있도록 한다.



 <!-- body -->

 ## 노드에서 컨트롤 플레인으로의 통신
-쿠버네티스에는 "허브 앤 스포크(hub-and-spoke)" API 패턴을 가지고 있다. 노드(또는 노드에서 실행되는 파드들)의 모든 API 사용은 API 서버에서 종료된다(다른 컨트롤 플레인 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다). API 서버는 하나 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형식이 활성화된 보안 HTTPS 포트(일반적으로 443)에서 원격 연결을 수신하도록 구성된다.
+쿠버네티스에는 "허브 앤 스포크(hub-and-spoke)" API 패턴을 가지고 있다. 노드(또는 노드에서 실행되는 파드들)의 모든 API 사용은 API 서버에서 종료된다. 다른 컨트롤 플레인 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다. API 서버는 하나 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형식이 활성화된 보안 HTTPS 포트(일반적으로 443)에서 원격 연결을 수신하도록 구성된다.
 특히 [익명의 요청](/docs/reference/access-authn-authz/authentication/#anonymous-requests) 또는 [서비스 어카운트 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)이 허용되는 경우, 하나 이상의 [권한 부여](/ko/docs/reference/access-authn-authz/authorization/) 형식을 사용해야 한다.

 노드는 유효한 클라이언트 자격 증명과 함께 API 서버에 안전하게 연결할 수 있도록 클러스터에 대한 공개 루트 인증서로 프로비전해야 한다. 예를 들어, 기본 GKE 배포에서, kubelet에 제공되는 클라이언트 자격 증명은 클라이언트 인증서 형식이다. kubelet 클라이언트 인증서의 자동 프로비저닝은 [kubelet TLS 부트스트랩](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 참고한다.
@@ -50,20 +50,20 @@ API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다.

 ### API 서버에서 노드, 파드 및 서비스로의 통신

-API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로 일반 HTTP 연결로 연결되므로 인증되거나 암호화되지 않는다. API URL에서 노드, 파드 또는 서비스 이름을 접두어 `https:` 로 사용하여 보안 HTTPS 연결을 통해 실행될 수 있지만, HTTPS 엔드포인트가 제공한 인증서의 유효성을 검증하지 않거나 클라이언트 자격 증명을 제공하지 않으므로 연결이 암호화되는 동안 무결성을 보장하지 않는다. 이러한 연결은 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 **현재는 안전하지 않다** .
+API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로 일반 HTTP 연결로 연결되므로 인증되거나 암호화되지 않는다. API URL에서 노드, 파드 또는 서비스 이름을 접두어 `https:` 로 사용하여 보안 HTTPS 연결을 통해 실행될 수 있지만, HTTPS 엔드포인트가 제공한 인증서의 유효성을 검증하지 않거나 클라이언트 자격 증명을 제공하지 않는다. 그래서 연결이 암호화되는 동안 무결성을 보장하지 않는다. 이러한 연결은 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 **현재는 안전하지 않다** .

 ### SSH 터널

 쿠버네티스는 SSH 터널을 지원하여 컨트롤 플레인에서 노드로의 통신 경로를 보호한다. 이 구성에서, API 서버는 클러스터의 각 노드에 SSH 터널을 시작하고(포트 22에서 수신 대기하는 ssh 서버에 연결) 터널을 통해 kubelet, 노드, 파드 또는 서비스로 향하는 모든 트래픽을 전달한다.
 이 터널은 트래픽이 노드가 실행 중인 네트워크 외부에 노출되지 않도록 한다.

-SSH 터널은 현재 더 이상 사용되지 않으므로 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안된다. Konnectivity 서비스는 이 통신 채널을 대체한다.
+SSH 터널은 현재 더 이상 사용되지 않으므로, 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안된다. Konnectivity 서비스는 이 통신 채널을 대체한다.

 ### Konnectivity 서비스

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

-SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity 서비스는 컨트롤 플레인 네트워크와 노드 네트워크에서 각각 실행되는 Konnectivity 서버와 Konnectivity 에이전트의 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 네트워크 연결을 유지한다.
+SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity 서비스는 컨트롤 플레인 네트워크의 Konnectivity 서버와 노드 네트워크의 Konnectivity 에이전트, 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 네트워크 연결을 유지한다.
 Konnectivity 서비스를 활성화한 후, 모든 컨트롤 플레인에서 노드로의 트래픽은 이 연결을 통과한다.

 [Konnectivity 서비스 태스크](/docs/tasks/extend-kubernetes/setup-konnectivity/)에 따라 클러스터에서 Konnectivity 서비스를 설정한다.
@@ -63,6 +63,16 @@ kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록
 노드 오브젝트의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.

+### 노드 이름 고유성
+
+[이름](/ko/docs/concepts/overview/working-with-objects/names#names)은 노드를 식별한다. 두 노드는
+동시에 같은 이름을 가질 수 없다. 쿠버네티스는 또한 같은 이름의 리소스가
+동일한 오브젝트라고 가정한다. 노드의 경우, 동일한 이름을 사용하는 인스턴스가 동일한
+상태(예: 네트워크 설정, 루트 디스크 내용)를 갖는다고 암시적으로 가정한다. 인스턴스가
+이름을 변경하지 않고 수정된 경우 이로 인해 불일치가 발생할 수 있다. 노드를 대폭 교체하거나
+업데이트해야 하는 경우, 기존 노드 오브젝트를 먼저 API 서버에서 제거하고
+업데이트 후 다시 추가해야 한다.
+
 ### 노드에 대한 자체-등록

 kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API 서버에
@@ -233,6 +243,7 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳
 - 노드가 계속 접근 불가할 경우 나중에 노드로부터 정상적인 종료를 이용해서 모든 파드를 축출 한다.
  ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고,
  파드를 축출하기 시작하는 값은 5분이다.
+
 노드 컨트롤러는 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다.

 #### 하트비트
@@ -273,6 +284,7 @@ ConditionFalse 다.).
 - 클러스터가 작으면 (즉 `--large-cluster-size-threshold`
  노드 이하면 - 기본값 50) 축출은 중지되고, 그렇지 않으면 축출 비율은 초당
  `--secondary-node-eviction-rate`(기본값 0.01)로 감소된다.
+
 이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안
 하나의 가용성 영역이 마스터로부터 분할되어 질 수도 있기 때문이다.
 만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않으면,
@@ -16,6 +16,7 @@ content_type: concept
 ## 네트워킹과 네트워크 폴리시

 * [ACI](https://www.github.com/noironetworks/aci-containers)는 Cisco ACI로 통합 컨테이너 네트워킹 및 네트워크 보안을 제공한다.
+* [Antrea](https://antrea.io/)는 레이어 3/4에서 작동하여 쿠버네티스를 위한 네트워킹 및 보안 서비스를 제공하며, Open vSwitch를 네트워킹 데이터 플레인으로 활용한다.
 * [Calico](https://docs.projectcalico.org/latest/introduction/)는 네트워킹 및 네트워크 폴리시 제공자이다. Calico는 유연한 네트워킹 옵션을 지원하므로 BGP 유무에 관계없이 비-오버레이 및 오버레이 네트워크를 포함하여 가장 상황에 맞는 옵션을 선택할 수 있다. Calico는 동일한 엔진을 사용하여 서비스 메시 계층(service mesh layer)에서 호스트, 파드 및 (이스티오(istio)와 Envoy를 사용하는 경우) 애플리케이션에 대한 네트워크 폴리시를 적용한다.
 * [Canal](https://github.com/tigera/canal/tree/master/k8s-install)은 Flannel과 Calico를 통합하여 네트워킹 및 네트워크 폴리시를 제공한다.
 * [Cilium](https://github.com/cilium/cilium)은 L3 네트워크 및 네트워크 폴리시 플러그인으로 HTTP/API/L7 폴리시를 투명하게 시행할 수 있다. 라우팅 및 오버레이/캡슐화 모드를 모두 지원하며, 다른 CNI 플러그인 위에서 작동할 수 있다.
@@ -278,7 +278,7 @@ pod/my-nginx-2035384211-u3t6x labeled
 ```

 먼저 "app=nginx" 레이블이 있는 모든 파드를 필터링한 다음, "tier=fe" 레이블을 지정한다.
-방금 레이블을 지정한 파드를 보려면, 다음을 실행한다.
+레이블을 지정한 파드를 보려면, 다음을 실행한다.

 ```shell
 kubectl get pods -l app=nginx -L tier
@@ -30,7 +30,7 @@ weight: 90
    - API 서버 프로세스에서 실행한다.
    - 클라이언트로 프락시는 HTTPS(또는 API서버에서 HTTP로 구성된 경우는 HTTP)를 사용한다.
    - 사용 가능한 정보를 이용하여 프락시에 의해 선택한 HTTP나 HTTPS를 사용할 수 있는 대상이다.
-    - 노드, 파드, 서비스에 도달하는데 사용할 수 있다.
+    - 노드, 파드, 서비스에 도달하는 데에 사용할 수 있다.
    - 서비스에 도달할 때에는 로드 밸런싱을 수행한다.

 1.  [kube proxy](/ko/docs/concepts/services-networking/service/#ips-and-vips):
@@ -39,7 +39,7 @@ weight: 90
    - UDP, TCP, SCTP를 이용하여 프락시 한다.
    - HTTP는 이해하지 못한다.
    - 로드 밸런싱을 제공한다.
-    - 단지 서비스에 도달하는데 사용한다.
+    - 서비스에 도달하는 데에만 사용한다.

 1.  API 서버 앞단의 프락시/로드밸런서

@@ -61,7 +61,3 @@ weight: 90
 ## 요청을 리다이렉트하기

 프락시는 리다이렉트 기능을 대체했다. 리다이렉트는 더 이상 사용하지 않는다.
-
-
-
-
@@ -223,7 +223,7 @@ spec:
 현재 볼륨에서 사용된 컨피그맵이 업데이트되면, 프로젝션된 키도 마찬가지로 업데이트된다.
 kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최신 상태인지 확인한다.
 그러나, kubelet은 로컬 캐시를 사용해서 컨피그맵의 현재 값을 가져온다.
-캐시 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의
+캐시 유형은 [KubeletConfiguration 구조체](/docs/reference/config-api/kubelet-config.v1beta1/)의
 `ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용해서 구성할 수 있다.
 컨피그맵은 watch(기본값), ttl 기반 또는 API 서버로 직접
 모든 요청을 리디렉션할 수 있다.
@@ -233,6 +233,7 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최
 지연을 지켜보거나, 캐시의 ttl 또는 0에 상응함).

 환경 변수로 사용되는 컨피그맵은 자동으로 업데이트되지 않으며 파드를 다시 시작해야 한다.
+
 ## 변경할 수 없는(immutable) 컨피그맵 {#configmap-immutable}

 {{< feature-state for_k8s_version="v1.19" state="beta" >}}
@@ -21,9 +21,6 @@ feature:
 컨테이너가 사용할 수 있도록 해당 시스템 리소스의 최소 _요청_ 량을
 예약한다.

-
-
-
 <!-- body -->

 ## 요청 및 제한
@@ -72,7 +69,7 @@ Huge page는 노드 커널이 기본 페이지 크기보다 훨씬 큰 메모리
 이것은 `memory` 및 `cpu` 리소스와는 다르다.
 {{< /note >}}

-CPU와 메모리를 통칭하여 *컴퓨트 리소스* 또는 그냥 *리소스* 라고 한다. 컴퓨트
+CPU와 메모리를 통칭하여 *컴퓨트 리소스* 또는 *리소스* 라고 한다. 컴퓨트
 리소스는 요청, 할당 및 소비될 수 있는 측정 가능한
 수량이다. 이것은
 [API 리소스](/ko/docs/concepts/overview/kubernetes-api/)와는 다르다. 파드 및
@@ -441,7 +438,9 @@ kubelet은 각 `emptyDir` 볼륨, 컨테이너 로그 디렉터리 및 쓰기

 프로젝트 쿼터를 사용하려면, 다음을 수행해야 한다.

-* kubelet 구성에서 `LocalStorageCapacityIsolationFSQuotaMonitoring=true`
+* [kubelet 구성](/docs/reference/config-api/kubelet-config.v1beta1/)의
+  `featureGates` 필드 또는 `--feature-gates` 커맨드 라인 플래그를 사용하여
+  `LocalStorageCapacityIsolationFSQuotaMonitoring=true`
  [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
  활성화한다.

@@ -449,6 +448,7 @@ kubelet은 각 `emptyDir` 볼륨, 컨테이너 로그 디렉터리 및 쓰기
  프로젝트 쿼터가 활성화되어 있는지 확인한다. 모든 XFS 파일시스템은 프로젝트 쿼터를 지원한다.
  ext4 파일시스템의 경우, 파일시스템이 마운트되지 않은 상태에서 프로젝트 쿼터
  추적 기능을 활성화해야 한다.
+
  ```bash
  # ext4인 /dev/block-device가 마운트되지 않은 경우
  sudo tune2fs -O project -Q prjquota /dev/block-device
@@ -518,9 +518,8 @@ JSON-Pointer로 해석된다. 더 자세한 내용은,
 클러스터-레벨의 확장된 리소스는 노드에 연결되지 않는다. 이들은 일반적으로
 리소스 소비와 리소스 쿼터를 처리하는 스케줄러 익스텐더(extender)에 의해 관리된다.

-[스케줄러 정책 구성](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/scheduler/api/v1/types.go#L31)에서
-스케줄러 익스텐더가
-처리하는 확장된 리소스를 지정할 수 있다.
+[스케줄러 정책 구성](/docs/reference/config-api/kube-scheduler-policy-config.v1/)에서
+스케줄러 익스텐더가 처리하는 확장된 리소스를 지정할 수 있다.

 **예제:**

@@ -743,23 +742,13 @@ LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-0

 컨테이너가 `reason:OOM Killed`(`OOM` 은 메모리 부족(Out Of Memory)의 약자) 때문에 종료된 것을 알 수 있다.

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

-
 * [컨테이너와 파드에 메모리 리소스를 할당](/ko/docs/tasks/configure-pod-container/assign-memory-resource/)하는 핸즈온 경험을 해보자.
-
 * [컨테이너와 파드에 CPU 리소스를 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)하는 핸즈온 경험을 해보자.
-
 * 요청과 제한의 차이점에 대한 자세한 내용은,
  [리소스 QoS](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md)를 참조한다.
-
 * [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) API 레퍼런스 읽어보기
-
 * [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) API 레퍼런스 읽어보기
-
 * XFS의 [프로젝트 쿼터](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html)에 대해 읽어보기
+* [kube-scheduler 정책 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/)에 대해 더 읽어보기
@@ -109,7 +109,7 @@ empty-secret   Opaque   0      2m6s
 ```

 해당 `DATA` 열은 시크릿에 저장된 데이터 아이템의 수를 보여준다.
-이 경우, `0` 은 비어 있는 시크릿을 방금 하나 생성하였다는 것을 의미한다.
+이 경우, `0` 은 비어 있는 시크릿을 하나 생성하였다는 것을 의미한다.

 ###  서비스 어카운트 토큰 시크릿

@@ -667,7 +667,7 @@ cat /etc/foo/password
 볼륨에서 현재 사용되는 시크릿이 업데이트되면, 투영된 키도 결국 업데이트된다.
 kubelet은 마운트된 시크릿이 모든 주기적인 동기화에서 최신 상태인지 여부를 확인한다.
 그러나, kubelet은 시크릿의 현재 값을 가져 오기 위해 로컬 캐시를 사용한다.
-캐시의 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의
+캐시의 유형은 [KubeletConfiguration 구조체](/docs/reference/config-api/kubelet-config.v1beta1/)의
 `ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용하여 구성할 수 있다.
 시크릿은 watch(기본값), ttl 기반 또는 API 서버로 모든 요청을 직접
 리디렉션하여 전파할 수 있다.
@@ -760,8 +760,8 @@ echo $SECRET_PASSWORD
 - immutable로 표시된 시크릿에 대한 감시를 중단하여, kube-apiserver의 부하를
 크게 줄임으로써 클러스터의 성능을 향상시킴

-이 기능은 v1.19부터 기본적으로 활성화된 `ImmutableEphemeralVolumes` [기능
-게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에
+이 기능은 v1.19부터 기본적으로 활성화된 `ImmutableEphemeralVolumes`
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에
 의해 제어된다. `immutable` 필드를 `true` 로 설정하여
 변경할 수 없는 시크릿을 생성할 수 있다. 다음은 예시이다.
 ```yaml
@@ -865,6 +865,7 @@ LASTSEEN   FIRSTSEEN   COUNT     NAME            KIND      SUBOBJECT
 ### 사용 사례: 컨테이너 환경 변수로 사용하기

 시크릿 정의를 작성한다.
+
 ```yaml
 apiVersion: v1
 kind: Secret
@@ -877,6 +878,7 @@ data:
 ```

 시크릿을 생성한다.
+
 ```shell
 kubectl apply -f mysecret.yaml
 ```
@@ -1173,14 +1175,12 @@ HTTP 요청을 처리하고, 복잡한 비즈니스 로직을 수행한 다음,

 시크릿 API에 접근해야 하는 애플리케이션은 필요한 시크릿에 대한 `get` 요청을
 수행해야 한다. 이를 통해 관리자는 앱에 필요한
-[개별 인스턴스에 대한 접근을 허용 목록에 추가](
-/docs/reference/access-authn-authz/rbac/#referring-to-resources)하면서 모든 시크릿에 대한 접근을
+[개별 인스턴스에 대한 접근을 허용 목록에 추가](/docs/reference/access-authn-authz/rbac/#referring-to-resources)하면서 모든 시크릿에 대한 접근을
 제한할 수 있다.

 `get` 반복을 통한 성능 향상을 위해, 클라이언트는 시크릿을
 참조한 다음 리소스를 감시(`watch`)하고, 참조가 변경되면 시크릿을 다시 요청하는 리소스를
-설계할 수 있다. 덧붙여, 클라이언트에게 개별 리소스를 감시(`watch`)하도록 하는 ["대량 감시" API](
-https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/bulk_watch.md)도
+설계할 수 있다. 덧붙여, 클라이언트에게 개별 리소스를 감시(`watch`)하도록 하는 ["대량 감시" API](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/bulk_watch.md)도
 제안되었으며, 쿠버네티스의 후속 릴리스에서 사용할 수
 있을 것이다.

@@ -50,10 +50,11 @@ terminated 또는 completed 상태인 경우에는 `PreStop` 훅 요청이 실
 ### 훅 핸들러 구현

 컨테이너는 훅의 핸들러를 구현하고 등록함으로써 해당 훅에 접근할 수 있다.
-구현될 수 있는 컨테이너의 훅 핸들러에는 두 가지 유형이 있다.
+구현될 수 있는 컨테이너의 훅 핸들러에는 세 가지 유형이 있다.

 * Exec - 컨테이너의 cgroups와 네임스페이스 안에서, `pre-stop.sh`와 같은, 특정 커맨드를 실행.
 커맨드에 의해 소비된 리소스는 해당 컨테이너에 대해 계산된다.
+* TCP - 컨테이너의 특정 포트에 대한 TCP 연결을 연다.
 * HTTP - 컨테이너의 특정 엔드포인트에 대해서 HTTP 요청을 실행.

 ### 훅 핸들러 실행
@@ -135,7 +135,7 @@ kubelet 프로세스의 환경 변수에서 `HOME=/root` 를 명시적으로 설
 예제의 경우, 사용자의 데스크탑/랩탑에서 아래 내용을 실행한다.

   1. 사용하고 싶은 각 자격 증명 세트에 대해서 `docker login [서버]`를 실행한다. 이것은 여러분 PC의 `$HOME/.docker/config.json`를 업데이트한다.
-   1. 편집기에서 `$HOME/.docker/config.json`를 보고 사용하고 싶은 자격 증명만 포함하고 있는지 확인한다.
+   1. 편집기로 `$HOME/.docker/config.json`를 열여서 사용하고 싶은 자격 증명만 포함하고 있는지 확인한다.
   1. 노드의 리스트를 구한다. 예를 들면 다음과 같다.
      - 이름을 원하는 경우: `nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )`
      - IP를 원하는 경우: `nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )`
@@ -44,7 +44,7 @@ _선언_ 하거나 지정할 수 있게 해주며 쿠버네티스 오브젝트
 클러스터 라이프사이클과 관계없이 실행 중인 클러스터에 커스텀 컨트롤러를 배포하고
 업데이트할 수 있다. 커스텀 컨트롤러는 모든 종류의 리소스와 함께 작동할 수 있지만
 커스텀 리소스와 결합할 때 특히 효과적이다.
-[오퍼레이터 패턴](https://coreos.com/blog/introducing-operators.html)은 사용자 정의
+[오퍼레이터 패턴](/ko/docs/concepts/extend-kubernetes/operator/)은 사용자 정의
 리소스와 커스텀 컨트롤러를 결합한다. 커스텀 컨트롤러를 사용하여 특정 애플리케이션에 대한 도메인 지식을
 쿠버네티스 API의 익스텐션으로 인코딩할 수 있다.

@@ -140,9 +140,9 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치
 쿠버네티스는 몇 가지 빌트인 인증 방법과 필요에 맞지 않는 경우 [인증 웹훅](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 방법을 제공한다.


-### 승인
+### 인가

-[승인](/docs/reference/access-authn-authz/webhook/)은 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인증 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.
+[인가](/docs/reference/access-authn-authz/webhook/)은 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.


 ### 동적 어드미션 컨트롤
@@ -30,8 +30,9 @@ card:

 컨트롤 플레인 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작할 수 있다. 그러나
 간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 컨트롤 플레인 컴포넌트를 구동시키고,
-사용자 컨테이너는 해당 머신 상에 동작시키지 않는다. 다중-마스터-VM 설치 예제를 보려면
-[고가용성 클러스터 구성하기](/docs/admin/high-availability/)를 확인해본다.
+사용자 컨테이너는 해당 머신 상에 동작시키지 않는다. 여러 VM에서
+실행되는 컨트롤 플레인 설정의 예제를 보려면
+[kubeadm을 사용하여 고가용성 클러스터 만들기](/docs/setup/production-environment/tools/kubeadm/high-availability/)를 확인해본다.

 ### kube-apiserver

@@ -21,11 +21,15 @@ weight: 20

 {{< glossary_definition term_id="name" length="all" >}}

+{{< note >}}
+물리적 호스트를 나타내는 노드와 같이 오브젝트가 물리적 엔티티를 나타내는 경우, 노드를 삭제한 후 다시 생성하지 않은 채 동일한 이름으로 호스트를 다시 생성하면, 쿠버네티스는 새 호스트를 불일치로 이어질 수 있는 이전 호스트로 취급한다.
+{{< /note >}}
+
 다음은 리소스에 일반적으로 사용되는 세 가지 유형의 이름 제한 조건이다.

 ### DNS 서브도메인 이름

-대부분의 리소스 유형에는 [RFC 1123](https://tools.ietf.org/html/rfc1123)에 정의된 대로 
+대부분의 리소스 유형에는 [RFC 1123](https://tools.ietf.org/html/rfc1123)에 정의된 대로
 DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다.
 이것은 이름이 다음을 충족해야 한다는 것을 의미한다.

@@ -83,4 +87,3 @@ UUID는 ISO/IEC 9834-8 과 ITU-T X.667 로 표준화 되어 있다.

 * 쿠버네티스의 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)에 대해 읽기.
 * [쿠버네티스의 식별자와 이름](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) 디자인 문서 읽기.
-
@@ -11,18 +11,17 @@ weight: 20

 <!-- overview -->

-{{< glossary_tooltip text="파드" term_id="pod" >}}를 특정한 {{< glossary_tooltip text="노드(들)" term_id="node" >}}에서만 동작하도록 하거나,
-특정 노드들을 선호하도록 제한할 수 있다.
-이를 수행하는 방법에는 여러 가지가 있으며, 권장되는 접근 방식은 모두
-[레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를 사용하여 선택한다.
-보통 스케줄러가 자동으로 합리적인 배치(예: 노드들에 걸쳐 파드를 분배하거나,
-자원이 부족한 노드에 파드를 배치하지 않는 등)를 수행하기에 이런 제약 조건은 필요하지 않지만
-간혹 파드가 배치되는 노드에 대해 더 많은 제어를 원할 수 있는 상황이 있다.
+특정한 {{< glossary_tooltip text="노드(들)" term_id="node" >}} 집합에서만 동작하도록
+{{< glossary_tooltip text="파드" term_id="pod" >}}를 제한할 수 있다.
+이를 수행하는 방법에는 여러 가지가 있으며 권장되는 접근 방식은 모두
+[레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를 사용하여 선택을 용이하게 한다.
+보통 스케줄러가 자동으로 합리적인 배치(예: 자원이 부족한 노드에 파드를 배치하지 않도록
+노드 간에 파드를 분배하는 등)를 수행하기에 이러한 제약 조건은 필요하지 않지만
+간혹 파드가 배포할 노드를 제어해야 하는 경우가 있다.
 예를 들어 SSD가 장착된 머신에 파드가 연결되도록 하거나 또는 동일한 가용성 영역(availability zone)에서
 많은 것을 통신하는 두 개의 서로 다른 서비스의 파드를 같이 배치할 수 있다.


-
 <!-- body -->

 ## 노드 셀렉터(nodeSelector)
@@ -120,13 +119,13 @@ spec:

 여기에 현재 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 로 부르는
 두 가지 종류의 노드 어피니티가 있다. 전자는 파드가 노드에 스케줄되도록 *반드시*
-규칙을 만족해야 하는 것(`nodeSelector` 와 같으나 보다 표현적인 구문을 사용해서)을 지정하고,
+규칙을 만족해야 하는 것(`nodeSelector` 와 비슷하나 보다 표현적인 구문을 사용해서)을 지정하고,
 후자는 스케줄러가 시도하려고는 하지만, 보증하지 않는 *선호(preferences)* 를 지정한다는 점에서
 이를 각각 "엄격함(hard)" 과 "유연함(soft)" 으로 생각할 수 있다.
 이름의 "IgnoredDuringExecution" 부분은 `nodeSelector` 작동 방식과 유사하게 노드의
-레이블이 런타임 중에 변경되어 파드의 어피니티 규칙이 더 이상 충족되지 않으면 파드가 여전히 그 노드에서
+레이블이 런타임 중에 변경되어 파드의 어피니티 규칙이 더 이상 충족되지 않으면 파드가 그 노드에서
 동작한다는 의미이다. 향후에는 파드의 노드 어피니티 요구 사항을 충족하지 않는 노드에서 파드를 제거한다는
-점을 제외하고는 `preferredDuringSchedulingIgnoredDuringExecution` 와 같은 `requiredDuringSchedulingIgnoredDuringExecution` 를 제공할 계획이다.
+점을 제외하고는 `preferredDuringSchedulingIgnoredDuringExecution` 와 동일한 `requiredDuringSchedulingIgnoredDuringExecution` 를 제공할 계획이다.

 따라서 `requiredDuringSchedulingIgnoredDuringExecution` 의 예로는 "인텔 CPU가 있는 노드에서만 파드 실행"이
 될 수 있고, `preferredDuringSchedulingIgnoredDuringExecution` 의 예로는 "장애 조치 영역 XYZ에 파드 집합을 실행하려고
@@ -86,6 +86,7 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
 * [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기
 * [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽기
 * kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기
+* [kube-scheduler 구성(v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽기
 * [멀티 스케줄러 구성하기](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)에 대해 배우기
 * [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기
 * [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)에 대해 배우기
@@ -24,8 +24,6 @@ API 서버에 해당 결정을 통지한다.
 본 페이지에서는 상대적으로 큰 규모의 쿠버네티스 클러스터에 대한 성능 튜닝
 최적화에 대해 설명한다.

-
-
 <!-- body -->

 큰 규모의 클러스터에서는 스케줄러의 동작을 튜닝하여 응답 시간
@@ -44,8 +42,10 @@ kube-scheduler 의 `percentageOfNodesToScore` 설정을 통해
 `percentageOfNodesToScore` 를 100 보다 높게 설정해도 kube-scheduler는
 마치 100을 설정한 것처럼 작동한다.

-값을 변경하려면, kube-scheduler 구성 파일(이 파일은 `/etc/kubernetes/config/kube-scheduler.yaml`
-일 수 있다)을 편집한 다음 스케줄러를 재시작 한다.
+값을 변경하려면,
+[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta1/)을
+편집한 다음 스케줄러를 재시작한다.
+대부분의 경우, 구성 파일은 `/etc/kubernetes/config/kube-scheduler.yaml` 에서 찾을 수 있다.

 이를 변경한 후에 다음을 실행해서

@@ -99,7 +99,6 @@ algorithmSource:
 percentageOfNodesToScore: 50
 ```

-
 ### percentageOfNodesToScore 튜닝

 `percentageOfNodesToScore`는 1과 100 사이의 값이어야 하며
@@ -159,3 +158,7 @@ percentageOfNodesToScore: 50
 ```

 모든 노드를 검토한 후, 노드 1로 돌아간다.
+
+## {{% heading "whatsnext" %}}
+
+* [kube-scheduler 구성 레퍼런스(v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 확인
@@ -38,7 +38,7 @@ API 서버가 하나 이상의 인증기 모듈을 실행하도록 구성한다.
 인증기는 [여기](/docs/reference/access-authn-authz/authentication/)에서 더 자세히 서술한다.

 인증 단계로 들어가는 것은 온전한 HTTP 요청이지만
-일반적으로 헤더 그리고/또는 클라이언트 인증서만 검사한다.
+일반적으로 헤더 그리고/또는 클라이언트 인증서를 검사한다.

 인증 모듈은 클라이언트 인증서, 암호 및 일반 토큰, 부트스트랩 토큰,
 JWT 토큰(서비스 어카운트에 사용됨)을 포함한다.
@@ -383,7 +383,7 @@ $ curl https://<EXTERNAL-IP>:<NODE-PORT> -k
 <h1>Welcome to nginx!</h1>
 ```

-이제 클라우드 로드 밸런서를 사용하도록 서비스를 재생성하고, `my-nginx` 서비스의 `Type` 을  `NodePort` 에서 `LoadBalancer` 로 변경한다.
+이제 클라우드 로드 밸런서를 사용하도록 서비스를 재생성한다. `my-nginx` 서비스의 `Type` 을 `NodePort` 에서 `LoadBalancer` 로 변경한다.

 ```shell
 kubectl edit svc my-nginx
@@ -218,7 +218,7 @@ Events:       <none>
 {{< codenew file="service/networking/external-lb.yaml" >}}

 IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클래스에 대한
-추가 구성을 참조하는데 사용할 수 있다.
+추가 구성을 참조하는 데에 사용할 수 있다.

 ### 사용중단(Deprecated) 어노테이션

@@ -257,8 +257,8 @@ IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클

 {{< codenew file="service/networking/test-ingress.yaml" >}}

-만약 `kubectl apply -f` 를 사용해서 생성한다면 방금 추가한 인그레스의
-상태를 볼 수 있어야 한다.
+만약 `kubectl apply -f` 를 사용해서 생성했다면 생성한 인그레스의
+상태를 볼 수 있을 것이다.

 ```bash
 kubectl get ingress test-ingress
@@ -54,7 +54,7 @@ _서비스 토폴로지_ 기능은 서비스 생성자가 발신 노드와 수
 백엔드가 없는 경우, 두 번째 레이블을 그리고 더 이상의
 레이블이 남지 않을 때까지 고려한다.

-만약 일치하는 것을 못찾는 경우에는, 서비스에 대한 백엔드가 없었던 것처럼
+만약 일치하는 것을 찾지 못한 경우에는, 마치 서비스에 대한 백엔드가 없는 것처럼
 트래픽이 거부될 것이다. 즉, 엔드포인트는 사용 가능한 백엔드가 있는 첫 번째
 토폴로지 키를 기반으로 선택된다. 만약 이 필드가 지정되고 모든 항목에
 클라이언트의 토폴로지와 일치하는 백엔드가 없는 경우, 서비스에는 해당 클라이언트에
@@ -513,8 +513,12 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
 각 노드는 해당 포트 (모든 노드에서 동일한 포트 번호)를 서비스로 프록시한다.
 서비스는 할당된 포트를 `.spec.ports[*].nodePort` 필드에 나타낸다.

-포트를 프록시하기 위해 특정 IP를 지정하려면 kube-proxy의 `--nodeport-addresses` 플래그를 특정 IP 블록으로 설정할 수 있다. 이것은 쿠버네티스 v1.10부터 지원된다.
-이 플래그는 쉼표로 구분된 IP 블록 목록 (예: 10.0.0.0/8, 192.0.2.0/25)을 사용하여 kube-proxy가 로컬 노드로 고려해야 하는 IP 주소 범위를 지정한다.
+포트를 프록시하기 위해 특정 IP를 지정하려면, kube-proxy에 대한
+`--nodeport-addresses` 플래그 또는
+[kube-proxy 구성 파일](/docs/reference/config-api/kube-proxy-config.v1alpha1/)의
+동등한 `nodePortAddresses` 필드를
+특정 IP 블록으로 설정할 수 있다.
+이 플래그는 쉼표로 구분된 IP 블록 목록(예: `10.0.0.0/8`, `192.0.2.0/25`)을 사용하여 kube-proxy가 로컬 노드로 고려해야 하는 IP 주소 범위를 지정한다.

 예를 들어, `--nodeport-addresses=127.0.0.0/8` 플래그로 kube-proxy를 시작하면, kube-proxy는 NodePort 서비스에 대하여 루프백(loopback) 인터페이스만 선택한다. `--nodeport-addresses`의 기본 값은 비어있는 목록이다. 이것은 kube-proxy가 NodePort에 대해 사용 가능한 모든 네트워크 인터페이스를 고려해야 한다는 것을 의미한다. (이는 이전 쿠버네티스 릴리스와도 호환된다).

@@ -526,11 +530,13 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
 사용해야 한다.

 NodePort를 사용하면 자유롭게 자체 로드 밸런싱 솔루션을 설정하거나,
-쿠버네티스가 완벽하게 지원하지 않는 환경을 구성하거나,
+쿠버네티스가 완벽하게 지원하지 못하는 환경을 구성하거나,
 하나 이상의 노드 IP를 직접 노출시킬 수 있다.

 이 서비스는 `<NodeIP>:spec.ports[*].nodePort`와
-`.spec.clusterIP:spec.ports[*].port`로 표기된다. (kube-proxy에서 `--nodeport-addresses` 플래그가 설정되면, <NodeIP>는 NodeIP를 필터링한다.)
+`.spec.clusterIP:spec.ports[*].port`로 표기된다.
+kube-proxy에 대한 `--nodeport-addresses` 플래그 또는 kube-proxy 구성 파일의
+동등한 필드가 설정된 경우, `<NodeIP>` 는 노드 IP를 필터링한다.

 예를 들면

@@ -785,8 +791,7 @@ TCP 및 SSL은 4 계층 프록시를 선택한다. ELB는 헤더를 수정하지
 ```

 위의 예에서, 서비스에 `80`, `443`, `8443`의 3개 포트가 포함된 경우,
-`443`, `8443`은 SSL 인증서를 사용하지만, `80`은 단순히
-프록시만 하는 HTTP이다.
+`443`, `8443`은 SSL 인증서를 사용하지만, `80`은 프록시하는 HTTP이다.

 쿠버네티스 v1.9부터는 서비스에 대한 HTTPS 또는 SSL 리스너와 함께 [사전에 정의된 AWS SSL 정책](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)을 사용할 수 있다.
 사용 가능한 정책을 확인하려면, `aws` 커맨드라인 툴을 사용한다.
@@ -958,7 +963,7 @@ NLB는 특정 인스턴스 클래스에서만 작동한다. 지원되는 인스

 | 규칙 | 프로토콜 | 포트 | IP 범위 | IP 범위 설명 |
 |------|----------|---------|------------|---------------------|
-| 헬스 체크 | TCP | NodePort(s) (`.spec.healthCheckNodePort` for `.spec.externalTrafficPolicy = Local`) | VPC CIDR | kubernetes.io/rule/nlb/health=\<loadBalancerName\> |
+| 헬스 체크 | TCP | NodePort(s) (`.spec.healthCheckNodePort` for `.spec.externalTrafficPolicy = Local`) | Subnet CIDR | kubernetes.io/rule/nlb/health=\<loadBalancerName\> |
 | 클라이언트 트래픽 | TCP | NodePort(s) | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/client=\<loadBalancerName\> |
 | MTU 탐색 | ICMP | 3,4 | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/mtu=\<loadBalancerName\> |

@@ -29,7 +29,7 @@ _퍼시스턴트볼륨_ (PV)은 관리자가 프로비저닝하거나 [스토리

 _퍼시스턴트볼륨클레임_ (PVC)은 사용자의 스토리지에 대한 요청이다. 파드와 비슷하다. 파드는 노드 리소스를 사용하고 PVC는 PV 리소스를 사용한다. 파드는 특정 수준의 리소스(CPU 및 메모리)를 요청할 수 있다. 클레임은 특정 크기 및 접근 모드를 요청할 수 있다(예: ReadWriteOnce, ReadOnlyMany 또는 ReadWriteMany로 마운트 할 수 있음. [AccessModes](#접근-모드) 참고).

-퍼시스턴트볼륨클레임을 사용하면 사용자가 추상화된 스토리지 리소스를 사용할 수 있지만, 다른 문제들 때문에 성능과 같은 다양한 속성을 가진 퍼시스턴트볼륨이 필요한 경우가 일반적이다. 클러스터 관리자는 사용자에게 해당 볼륨의 구현 방법에 대한 세부 정보를 제공하지 않고 단순히 크기와 접근 모드와는 다른 방식으로 다양한 퍼시스턴트볼륨을 제공할 수 있어야 한다. 이러한 요구에는 _스토리지클래스_ 리소스가 있다.
+퍼시스턴트볼륨클레임을 사용하면 사용자가 추상화된 스토리지 리소스를 사용할 수 있지만, 다른 문제들 때문에 성능과 같은 다양한 속성을 가진 퍼시스턴트볼륨이 필요한 경우가 일반적이다. 클러스터 관리자는 사용자에게 해당 볼륨의 구현 방법에 대한 세부 정보를 제공하지 않고 크기와 접근 모드와는 다른 방식으로 다양한 퍼시스턴트볼륨을 제공할 수 있어야 한다. 이러한 요구에는 _스토리지클래스_ 리소스가 있다.

 [실습 예제와 함께 상세한 내용](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)을 참고하길 바란다.

@@ -563,8 +563,8 @@ parameters:
 * `quobyteAPIServer`: `"http(s)://api-server:7860"` 형식의
  Quobyte의 API 서버이다.
 * `registry`: 볼륨을 마운트하는 데 사용할 Quobyte 레지스트리이다. 레지스트리를
-  ``<host>:<port>`` 의 쌍으로 지정하거나 여러 레지스트리를
-  지정하려면 쉼표만 있으면 된다.
+  ``<host>:<port>`` 의 쌍으로 지정할 수 있으며, 여러 레지스트리를
+  지정하려면 각 쌍을 쉼표로 구분하면 된다.
  예: ``<host1>:<port>,<host2>:<port>,<host3>:<port>``
  호스트는 IP 주소이거나 DNS가 작동 중인 경우
  DNS 이름을 제공할 수도 있다.
@@ -34,7 +34,7 @@ weight: 10
 더 이상 존재하지 않으면, 쿠버네티스는 임시(ephemeral) 볼륨을 삭제하지만,
 퍼시스턴트(persistent) 볼륨은 삭제하지 않는다.

-기본적으로 볼륨은 디렉터리일 뿐이며, 일부 데이터가 있을 수 있으며, 파드
+기본적으로 볼륨은 디렉터리이며, 일부 데이터가 있을 수 있으며, 파드
 내 컨테이너에서 접근할 수 있다. 디렉터리의 생성 방식, 이를 지원하는
 매체와 내용은 사용된 특정 볼륨의 유형에 따라
 결정된다.
@@ -706,7 +706,7 @@ nginx-deployment-618515232    11        11        11        7m
 하나 이상의 업데이트를 트리거하기 전에 디플로이먼트를 일시 중지한 다음 다시 시작할 수 있다.
 이렇게 하면 불필요한 롤아웃을 트리거하지 않고 일시 중지와 재개 사이에 여러 수정 사항을 적용할 수 있다.

-* 예를 들어, 방금 생성된 디플로이먼트의 경우
+* 예를 들어, 생성된 디플로이먼트의 경우
  디플로이먼트 상세 정보를 가져온다.
  ```shell
  kubectl get deploy
@@ -98,8 +98,8 @@ echo $pods
 pi-5rwd7
 ```

-여기서 셀렉터는 잡의 셀렉터와 동일하다.  `--output=jsonpath` 옵션은 반환된 목록의
-각각의 파드에서 이름을 가져와서 표현하는 방식을 지정한다.
+여기서 셀렉터는 잡의 셀렉터와 동일하다.  `--output=jsonpath` 는
+반환된 목록의 각 파드 이름을 출력하도록 하는 옵션이다.

 파드 중 하나를 표준 출력으로 본다.

@@ -222,7 +222,7 @@ pod2             1/1     Running   0          36s
 ## 레플리카셋 매니페스트 작성하기

 레플리카셋은 모든 쿠버네티스 API 오브젝트와 마찬가지로 `apiVersion`, `kind`, `metadata` 필드가 필요하다.
-레플리카셋에 대한 kind 필드의 값은 항상 레플리카셋이다.
+레플리카셋에 대한 `kind` 필드의 값은 항상 레플리카셋이다.
 쿠버네티스 1.9에서의 레플리카셋의 kind에 있는 API 버전 `apps/v1`은 현재 버전이며, 기본으로 활성화 되어있다. API 버전 `apps/v1beta2`은 사용 중단(deprecated)되었다.
 API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한다.

@@ -237,7 +237,7 @@ API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한
 우리는 `frontend.yaml` 예제에서 `tier: frontend`이라는 레이블을 하나 가지고 있다.
 이 파드를 다른 컨트롤러가 취하지 않도록 다른 컨트롤러의 셀렉터와 겹치지 않도록 주의해야 한다.

-템플릿의 [재시작 정책](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책) 필드인
+템플릿의 [재시작 정책](/ko/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 필드인
 `.spec.template.spec.restartPolicy`는 기본값인 `Always`만 허용된다.

 ### 파드 셀렉터
@@ -54,7 +54,9 @@ kubectl 명령에서 숏컷으로 사용된다.
 ```shell
 kubectl apply -f https://k8s.io/examples/controllers/replication.yaml
 ```
+
 출력 결과는 다음과 같다.
+
 ```
 replicationcontroller/nginx created
 ```
@@ -64,7 +66,9 @@ replicationcontroller/nginx created
 ```shell
 kubectl describe replicationcontrollers/nginx
 ```
+
 출력 결과는 다음과 같다.
+
 ```
 Name:        nginx
 Namespace:   default
@@ -103,14 +107,16 @@ Pods Status:    3 Running / 0 Waiting / 0 Succeeded / 0 Failed
 pods=$(kubectl get pods --selector=app=nginx --output=jsonpath={.items..metadata.name})
 echo $pods
 ```
+
 출력 결과는 다음과 같다.
+
 ```
 nginx-3ntk0 nginx-4ok8v nginx-qrm3m
 ```

 여기서 셀렉터는 레플리케이션컨트롤러(`kubectl describe` 의 출력에서 보인)의 셀렉터와 같고,
-다른 형식의 파일인 `replication.yaml` 의 것과 동일하다. `--output=jsonpath` 옵션은
-반환된 목록의 각 파드에서 이름을 가져오는 표현식을 지정한다.
+다른 형식의 파일인 `replication.yaml` 의 것과 동일하다. `--output=jsonpath` 는
+반환된 목록의 각 파드 이름을 출력하도록 하는 옵션이다.


 ## 레플리케이션 컨트롤러의 Spec 작성
@@ -118,7 +124,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
 다른 모든 쿠버네티스 컨피그와 마찬가지로 레플리케이션 컨트롤러는 `apiVersion`, `kind`, `metadata` 와 같은 필드가 필요하다.
 레플리케이션 컨트롤러 오브젝트의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
-컨피그 파일의 동작에 관련된 일반적인 정보는 [쿠버네티스 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/)를 참고한다.
+환경 설정 파일의 동작에 관련된 일반적인 정보는 [쿠버네티스 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/)를 참고한다.

 레플리케이션 컨트롤러는 또한 [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다.

@@ -198,7 +204,7 @@ REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리

 ### 레플리케이션 컨트롤러에서 파드 격리

-파드는 레이블을 변경하여 레플리케이션 컨트롤러의 대상 셋에서 제거될 수 있다. 이 기술은 디버깅, 데이터 복구 등을 위해 서비스에서 파드를 제거하는데 사용될 수 있다. 이 방법으로 제거된 파드는 자동으로 교체된다 (레플리카 수가 변경되지 않는다고 가정).
+파드는 레이블을 변경하여 레플리케이션 컨트롤러의 대상 셋에서 제거될 수 있다. 이 기술은 디버깅과 데이터 복구를 위해 서비스에서 파드를 제거하는 데 사용될 수 있다. 이 방법으로 제거된 파드는 자동으로 교체된다 (레플리카 수가 변경되지 않는다고 가정).

 ## 일반적인 사용법 패턴

@@ -208,8 +214,7 @@ REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리

 ### 스케일링

-레플리케이션컨트롤러는 `replicas` 필드를 설정하여 레플리카의 수를 늘리거나 줄인다.
-레플리카를 수동으로 또는 오토 스케일링 제어 에이전트로 관리하도록 레플리케이션컨트롤러를 구성할 수 있다.
+레플리케이션컨트롤러는 `replicas` 필드를 업데이트하여, 수동으로 또는 오토 스케일링 제어 에이전트를 통해, 레플리카의 수를 늘리거나 줄일 수 있다.

 ### 롤링 업데이트

@@ -246,7 +251,6 @@ REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리

 레플리케이션 컨트롤러는 조합 가능한 빌딩-블록 프리미티브가 되도록 고안되었다. 향후 사용자의 편의를 위해 더 상위 수준의 API 및/또는 도구와 그리고 다른 보완적인 기본 요소가 그 위에 구축 될 것으로 기대한다. 현재 kubectl이 지원하는 "매크로" 작업 (실행, 스케일)은 개념 증명의 예시이다. 예를 들어 [Asgard](https://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html)와 같이 레플리케이션 컨트롤러, 오토 스케일러, 서비스, 정책 스케줄링, 카나리 등을 관리할 수 있다.

-
 ## API 오브젝트

 레플리케이션 컨트롤러는 쿠버네티스 REST API의 최상위 수준의 리소스이다.
@@ -261,8 +265,7 @@ API 오브젝트에 대한 더 자세한 것은
 이것은 주로 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다.
 사용자 지정 업데이트 조정이 필요하거나 업데이트가 필요하지 않은 경우가 아니면 레플리카셋을 직접 사용하는 대신 디플로이먼트를 사용하는 것이 좋다.

-
-### 디플로이먼트 (권장되는)
+### 디플로이먼트 (권장됨)

 [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/)는 기본 레플리카셋과 그 파드를 업데이트하는 상위 수준의 API 오브젝트이다. 선언적이며, 서버 사이드이고, 추가 기능이 있기 때문에 롤링 업데이트 기능을 원한다면 디플로이먼트를 권장한다.

@@ -313,17 +313,16 @@ myapp-pod   1/1       Running   0          9m
 파드는 다음과 같은 사유로, 초기화 컨테이너들의 재-실행을 일으키는, 재시작을 수행할 수
 있다.

-* 사용자가 초기화 컨테이너 이미지의 변경을 일으키는 파드 스펙 업데이트를 수행했다.
-  Init Container 이미지를 변경하면 파드가 다시 시작된다. 앱 컨테이너
-  이미지의 변경은 앱 컨테이너만 재시작시킨다.
-* 파드 인프라스트럭처 컨테이너가 재시작되었다. 이는 일반적인 상황이 아니며 노드에
+* 파드 인프라스트럭처 컨테이너가 재시작된 상황. 이는 일반적인 상황이 아니며 노드에
  대해서 root 접근 권한을 가진 누군가에 의해서 수행됐을 것이다.
 * 파드 내의 모든 컨테이너들이, 재시작을 강제하는 `restartPolicy` 가 항상(Always)으로 설정되어 있는,
  동안 종료되었다. 그리고 초기화 컨테이너의 완료 기록이 가비지 수집
  때문에 유실되었다.

-
-
+초기화 컨테이너 이미지가 변경되거나 초기화 컨테이너의 완료 기록이 가비지 수집 
+때문에 유실된 상태이면 파드는 재시작되지 않는다. 이는 쿠버네티스 버전 1.20 이상에 
+적용된다. 이전 버전의 쿠버네티스를 사용하는 경우 해당 쿠버네티스 버전의 문서를 
+참고한다.

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

@@ -312,8 +312,8 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지
 준비성 프로브는 활성 프로브와는 다르게 준비성에 특정된 엔드포인트를 확인한다.

 {{< note >}}
-파드가 삭제될 때 단지 요청들을 흘려 보낼(drain) 목적으로,
-준비성 프로브가 필요하지는 않다는 점을 유념해야 한다. 삭제 시에, 파드는
+파드가 삭제될 때 요청들을 흘려 보내기(drain) 위해
+준비성 프로브가 꼭 필요한 것은 아니다. 삭제 시에, 파드는
 프로브의 존재 여부와 무관하게 자동으로 스스로를 준비되지 않은 상태(unready)로 변경한다.
 파드는 파드 내의 모든 컨테이너들이 중지될 때까지 준비되지 않은 상태로
 남아 있다.
@@ -21,8 +21,6 @@ no_list: true

 * [표준 용어집](/ko/docs/reference/glossary/) -  포괄적이고, 표준화 된 쿠버네티스 용어 목록

-
-
 * [쿠버네티스 API 레퍼런스](/docs/reference/kubernetes-api/)
 * [쿠버네티스 {{< param "version" >}}용 원페이지(One-page) API 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
 * [쿠버네티스 API 사용](/ko/docs/reference/using-api/) - 쿠버네티스 API에 대한 개요
@@ -50,16 +48,35 @@ no_list: true

 ## 컴포넌트

-* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - 각 노드에서 구동되는 주요한 *노드 에이전트*. kubelet은 PodSpecs 집합을 가지며 기술된 컨테이너가 구동되고 있는지, 정상 작동하는지를 보장한다.
-* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - 파드, 서비스, 레플리케이션 컨트롤러와 같은 API 오브젝트에 대한 검증과 구성을 수행하는 REST API.
+* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - 각 
+노드에서 구동되는 주요한 에이전트. kubelet은 PodSpecs 집합을 가지며 
+기술된 컨테이너가 구동되고 있는지, 정상 작동하는지를 보장한다.
+* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - 
+파드, 서비스, 레플리케이션 컨트롤러와 같은 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/) - 간단한 TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을 할 수 있다.
+* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - 간단한 
+TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을 
+할 수 있다.
 * [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - 가용성, 성능 및 용량을 관리하는 스케줄러.

-## 스케줄링
+  * [kube-scheduler 정책](/ko/docs/reference/scheduling/policies)
+  * [kube-scheduler 프로파일](/ko/docs/reference/scheduling/config/#여러-프로파일)

-* [kube-scheduler 정책](/ko/docs/reference/scheduling/policies)
-* [kube-scheduler 프로파일](/docs/reference/scheduling/config#profiles)
+## 환경설정 API
+
+이 섹션은 쿠버네티스 구성요소 또는 도구를 환경설정하는 데에 사용되는 
+"미발표된" API를 다룬다. 이 API들은 사용자나 관리자가 클러스터를 
+사용/관리하는 데에 중요하지만, 이들 API의 대부분은 아직 API 서버가 
+제공하지 않는다.
+
+* [kubelet 환경설정 (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/)
+* [kube-scheduler 환경설정 (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/)
+* [kube-scheduler 정책 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/)
+* [kube-proxy 환경설정 (v1alpha1)](/docs/reference/config-api/kube-proxy-config.v1alpha1/)
+* [`audit.k8s.io/v1` API](/docs/reference/config-api/apiserver-audit.v1/)
+* [클라이언트 인증 API (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/)
+* [WebhookAdmission 환경설정 (v1)](/docs/reference/config-api/apiserver-webhookadmission.v1/)

 ## 설계 문서

@@ -546,7 +546,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
  생성된 리소스에서 스키마 기반 유효성 검사를 활성화한다.
 - `CustomResourceWebhookConversion`: [커스텀리소스데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에서
  생성된 리소스에 대해 웹 훅 기반의 변환을 활성화한다.
-  실행 중인 파드 문제를 해결한다.
 - `DefaultPodTopologySpread`: `PodTopologySpread` 스케줄링 플러그인을 사용하여
  [기본 분배](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/#내부-기본-제약)를 수행한다.
 - `DevicePlugins`: 노드에서 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
@@ -725,11 +724,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
  있도록 한다. 자세한 내용은
  [서비스토폴로지(ServiceTopology)](/ko/docs/concepts/services-networking/service-topology/)를
  참고한다.
- `SizeMemoryBackedVolumes`: kubelet 지원을 사용하여 메모리 백업 볼륨의 크기를 조정한다.
-  자세한 내용은 [volumes](/ko/docs/concepts/storage/volumes)를 참조한다.
 - `SetHostnameAsFQDN`: 전체 주소 도메인 이름(FQDN)을 파드의 호스트 이름으로
  설정하는 기능을 활성화한다.
-  [파드의 `setHostnameAsFQDN` 필드](/ko/docs/concepts/services-networking/dns-pod-service/#파드의-sethostnameasfqdn-필드)를 참고한다.
+  [파드의 `setHostnameAsFQDN` 필드](/ko/docs/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field)를 참고한다.
 - `StartupProbe`: kubelet에서
  [스타트업](/ko/docs/concepts/workloads/pods/pod-lifecycle/#언제-스타트업-프로브를-사용해야-하는가)
  프로브를 활성화한다.
@@ -11,10 +11,10 @@ tags:
 - architecture
 - operation
 ---
- 클라우드별 컨트롤 로직을 포함하는 쿠버네티스
+클라우드별 컨트롤 로직을 포함하는 쿠버네티스
 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}} 컴포넌트이다.
 클라우드 컨트롤러 매니저를 통해 클러스터를 클라우드 공급자의 API에 연결하고,
-해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와 상호 작용하는 컴포넌트를 분리할 수 있다.
+해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와만 상호 작용하는 컴포넌트를 구분할 수 있게 해 준다.

 <!--more-->

@@ -357,7 +357,7 @@ API 리소스를 탐색하기 위한 다른 작업:
 ```bash
 kubectl api-resources --namespaced=true      # 네임스페이스를 가지는 모든 리소스
 kubectl api-resources --namespaced=false     # 네임스페이스를 가지지 않는 모든 리소스
-kubectl api-resources -o name                # 모든 리소스의 단순한 (리소스 이름 만) 출력
+kubectl api-resources -o name                # 모든 리소스의 단순한 (리소스 이름만) 출력
 kubectl api-resources -o wide                # 모든 리소스의 확장된 ("wide"로 알려진) 출력
 kubectl api-resources --verbs=list,get       # "list"와 "get"의 요청 동사를 지원하는 모든 리소스 출력
 kubectl api-resources --api-group=extensions # "extensions" API 그룹의 모든 리소스
@@ -384,7 +384,10 @@ kubectl api-resources --api-group=extensions # "extensions" API 그룹의 모든
 # 클러스터에서 실행 중인 모든 이미지
 kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'

- # "k8s.gcr.io/coredns:1.6.2" 를 제외한 모든 이미지
+# `default` 네임스페이스의 모든 이미지를 파드별로 그룹지어 출력
+kubectl get pods --namespace default --output=custom-columns="NAME:.metadata.name,IMAGE:.spec.containers[*].image"
+
+# "k8s.gcr.io/coredns:1.6.2" 를 제외한 모든 이미지
 kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.io/coredns:1.6.2")].image'

 # 이름에 관계없이 메타데이터 아래의 모든 필드
@@ -18,12 +18,10 @@ weight: 20
 각 단계는 익스텐션 포인트(extension point)를 통해 노출된다. 플러그인은 이러한
 익스텐션 포인트 중 하나 이상을 구현하여 스케줄링 동작을 제공한다.

-컴포넌트 구성 API([`v1alpha1`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha1?tab=doc#KubeSchedulerConfiguration)
-또는 [`v1alpha2`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha2?tab=doc#KubeSchedulerConfiguration))를
-사용하고, `kube-scheduler --config <filename>`을 실행하여
+[KubeSchedulerConfiguration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 
+구조에 맞게 파일을 작성하고, 
+`kube-scheduler --config <filename>`을 실행하여
 스케줄링 프로파일을 지정할 수 있다.
-`v1alpha2` API를 사용하면 [여러 프로파일](#여러-프로파일)을
-실행하도록 kube-scheduler를 구성할 수 있다.

 최소 구성은 다음과 같다.

@@ -249,3 +247,4 @@ profiles:

 * [kube-scheduler 레퍼런스](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/) 읽어보기
 * [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 알아보기
+* [kube-scheduler configuration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽어보기
@@ -8,9 +8,7 @@ weight: 10

 스케줄링 정책을 사용하여 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}가 각각 노드를 필터링하고 스코어링(scoring)하기 위해 실행하는 *단정(predicates)* 및 *우선순위(priorities)* 를 지정할 수 있다.

-`kube-scheduler --policy-config-file <filename>` 또는 `kube-scheduler --policy-configmap <ConfigMap>`을 실행하고 [정책 유형](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1?tab=doc#Policy)을 사용하여 스케줄링 정책을 설정할 수 있다.
-
-
+`kube-scheduler --policy-config-file <filename>` 또는 `kube-scheduler --policy-configmap <ConfigMap>`을 실행하고 [정책 유형](/docs/reference/config-api/kube-scheduler-policy-config.v1/)을 사용하여 스케줄링 정책을 설정할 수 있다.

 <!-- body -->

@@ -110,9 +108,9 @@ weight: 10
 - `EvenPodsSpreadPriority`: 선호된
  [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)을 구현한다.

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

 * [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 배우기
 * [kube-scheduler 프로파일](/docs/reference/scheduling/profiles/)에 대해 배우기
+* [kube-scheduler configuration 레퍼런스 (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1) 읽어보기
+* [kube-scheduler Policy 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/) 읽어보기
@@ -67,9 +67,8 @@ _A_ 영역에 있는 컨트롤 플레인 호스트로만 전달한다. 단일

 쿠버네티스 [리소스 제한](/ko/docs/concepts/configuration/manage-resources-containers/)은
 파드와 컨테이너가 다른 컴포넌트에 영향을 줄 수 있는 메모리 누수 및 기타 방식의 영향을
-최소화하는 데 도움이 된다. 이러한 리소스 제한은 애플리케이션 워크로드에 적용되는 것과 마찬가지로
-{{< glossary_tooltip text="애드온" term_id="addons" >}}에도 적용될 수 있으며
-적용되어야 한다.
+최소화하는 데 도움이 된다. 이러한 리소스 제한은 애플리케이션 워크로드에 적용될 수 있는 것처럼 
+{{< glossary_tooltip text="애드온" term_id="addons" >}} 리소스에도 적용될 수 있다.

 예를 들어, 로깅 컴포넌트에 대한 CPU 및 메모리 제한을 설정할 수 있다.

@@ -70,7 +70,7 @@ sudo sysctl --system

 | 프로토콜   | 방향       | 포트 범위    | 목적                      | 사용자                     |
 |----------|-----------|------------|-------------------------|---------------------------|
-| TCP      | 인바운드    | 6443*      | 쿠버네티스 API 서버         | 모두                       |
+| TCP      | 인바운드    | 6443\*      | 쿠버네티스 API 서버         | 모두                       |
 | TCP      | 인바운드    | 2379-2380  | etcd 서버 클라이언트 API    | kube-apiserver, etcd      |
 | TCP      | 인바운드    | 10250      | kubelet API             | 자체, 컨트롤 플레인          |
 | TCP      | 인바운드    | 10251      | kube-scheduler          | 자체                      |
@@ -307,7 +307,8 @@ kind: KubeletConfiguration
 cgroupDriver: <value>
 ```

-자세한 내용은 [구성 파일과 함께 kubeadm init 사용](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file)을 참고한다.
+자세한 내용은 [구성 파일과 함께 kubeadm init 사용](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file)과
+[`KubeletConfiguration` 레퍼런스](/docs/reference/config-api/kubelet-config.v1beta1/)를 참고한다.

 `cgroupfs` 가 이미 kubelet의 기본값이기 때문에, 사용자의
 CRI cgroup 드라이버가 `cgroupfs` 가 아닌 **경우에만** 위와 같이 설정해야 한다.
@@ -321,12 +322,10 @@ CRI cgroup 드라이버가 `cgroupfs` 가 아닌 **경우에만** 위와 같이
 CRI-O 및 containerd와 같은 다른 컨테이너 런타임에 대한 cgroup 드라이버의
 자동 감지에 대한 작업이 진행 중이다.

-
 ## 문제 해결

 kubeadm에 문제가 있는 경우, [문제 해결 문서](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/)를 참고한다.

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

-
 * [kubeadm을 사용하여 클러스터 생성](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
@@ -68,7 +68,7 @@ Kubespray에서는 디플로이먼트의 많은 속성들을 사용자가 정의
  * {{< glossary_tooltip term_id="cri-o" >}}
 * 인증서 생성 방법

-Kubespray의 [변수 파일들](https://docs.ansible.com/ansible/playbooks_variables.html)을 사용자가 정의할 수 있다. 만약 Kubespray를 막 시작한 경우, kubespray의 기본 설정값을 이용해 클러스터를 배포하고 Kubernetes를 탐색하는 것이 좋다.
+Kubespray의 [변수 파일들](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html)을 사용자가 정의할 수 있다. 만약 Kubespray를 처음 접하는 경우, kubespray의 기본 설정값을 이용해 클러스터를 배포하고 쿠버네티스를 탐색하는 것이 좋다.

 ### (4/5) 클러스터 배포하기

@@ -33,7 +33,7 @@ weight: 65
 쿠버네티스의 윈도우 운영 체제 지원은 다음 표를 참조한다. 단일 이기종 쿠버네티스 클러스터에는 윈도우 및 리눅스 워커 노드가 모두 있을 수 있다. 윈도우 컨테이너는 윈도우 노드에서, 리눅스 컨테이너는 리눅스 노드에서 스케줄되어야 한다.

 | 쿠버네티스 버전 | 윈도우 서버 LTSC 릴리스 | 윈도우 서버 SAC 릴리스 |
-| --- | --- | --- | --- |
+| --- | --- | --- |
 | *Kubernetes v1.17* | Windows Server 2019 | Windows Server ver 1809 |
 | *Kubernetes v1.18* | Windows Server 2019 | Windows Server ver 1809, Windows Server ver 1903, Windows Server ver 1909 |
 | *Kubernetes v1.19* | Windows Server 2019 | Windows Server ver 1909, Windows Server ver 2004 |
@@ -230,23 +230,32 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템

 ### 제한

-#### 컨트롤 플레인
-
 윈도우는 쿠버네티스 아키텍처 및 컴포넌트 매트릭스에서 워커 노드로만 지원된다. 즉, 쿠버네티스 클러스터에는 항상 리눅스 마스터 노드가 반드시 포함되어야 하고, 0개 이상의 리눅스 워커 노드 및 0개 이상의 윈도우 워커 노드가 포함된다.

-#### 컴퓨트 {#컴퓨트-제한}
-
-##### 리소스 관리 및 프로세스 격리
+#### 자원 관리

 리눅스 cgroup은 리눅스에서 리소스 제어를 위한 파드 경계로 사용된다. 컨테이너는 네트워크, 프로세스 및 파일시스템 격리를 위해 해당 경계 내에 생성된다. cgroups API는 cpu/io/memory 통계를 수집하는 데 사용할 수 있다. 반대로 윈도우는 시스템 네임스페이스 필터가 있는 컨테이너별로 잡(Job) 오브젝트를 사용하여 컨테이너의 모든 프로세스를 포함하고 호스트와의 논리적 격리를 제공한다. 네임스페이스 필터링 없이 윈도우 컨테이너를 실행할 수 있는 방법은 없다. 즉, 시스템 권한은 호스트 컨텍스트에서 삽입 될(assert) 수 없으므로 권한이 있는(privileged) 컨테이너는 윈도우에서 사용할 수 없다. 보안 계정 매니져(Security Account Manager, SAM)가 분리되어 있으므로 컨테이너는 호스트의 ID를 가정할 수 없다.

-##### 운영 체제 제한
+#### 자원 예약

-윈도우에는 호스트 OS 버전이 컨테이너 베이스 이미지 OS 버전과 일치해야 하는 엄격한 호환성 규칙이 있다. 윈도우 서버 2019의 컨테이너 운영 체제가 있는 윈도우 컨테이너만 지원된다. 윈도우 컨테이너 이미지 버전의 일부 이전 버전과의 호환성을 가능하게 하는 컨테이너의 Hyper-V 격리는 향후 릴리스로 계획되어 있다.
+##### 메모리 예약
+윈도우에는 리눅스에는 있는 메모리 부족 프로세스 킬러가 없다. 윈도우는 모든 사용자-모드 메모리 할당을 항상 가상 메모리처럼 처리하며, 페이지파일이 필수이다. 결과적으로 윈도우에서는 리눅스에서 발생할 수 있는 메모리 부족 상태에 도달하지 않으며, 프로세스는 메모리 부족 (out of memory, OOM) 종료를 겪는 대신 디스크로 페이징한다. 메모리가 오버프로비저닝되고 모든 물리 메모리가 고갈되면 페이징으로 인해 성능이 저하될 수 있다.

-##### 기능 제한
+kubelet 파라미터 `--kubelet-reserve` 를 사용하여 메모리 사용량을 합리적인 범위 내로 유지할 수 있으며, `--system-reserve` 를 사용하여 노드(컨테이너 외부)의 메모리 사용량을 예약할 수 있다. 이들을 사용하면 그만큼 [노드 할당(NodeAllocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)은 줄어든다.

-* TerminationGracePeriod: CRI-containerD 필요
+{{< note >}}
+워크로드를 배포할 때, 컨테이너에 리소스 제한을 사용한다 (제한만 설정하거나, 제한이 요청과 같아야 함). 이 또한 NodeAllocatable에서 차감되며, 메모리가 꽉 찬 노드에 스케줄러가 파드를 할당하지 않도록 제한한다.
+{{< /note >}}
+
+오버프로비저닝을 방지하는 가장 좋은 방법은 윈도우, 도커, 그리고 쿠버네티스 프로세스를 위해 최소 2GB 이상의 시스템 예약 메모리로 kubelet을 설정하는 것이다.
+
+##### CPU 예약
+윈도우, 도커, 그리고 다른 쿠버네티스 호스트 프로세스가 이벤트에 잘 응답할 수 있도록, CPU의 일정 비율을 예약하는 것이 좋다. 이 값은 윈도우 노드에 있는 CPU 코어 수에 따라 조정해야 한다. 이 비율을 결정하려면, 각 노드의 최대 파드 밀도(density)를 관찰하고, 시스템 서비스의 CPU 사용량을 모니터링하여 워크로드 요구 사항을 충족하는 값을 선택해야 한다.
+
+kubelet 파라미터 `--kubelet-reserve` 를 사용하여 CPU 사용량을 합리적인 범위 내로 유지할 수 있으며, `--system-reserve` 를 사용하여 노드(컨테이너 외부)의 CPU 사용량을 예약할 수 있다. 이들을 사용하면 그만큼 [노드 할당(NodeAllocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)은 줄어든다.
+
+#### 기능 제한
+* TerminationGracePeriod: 구현되지 않음
 * 단일 파일 매핑: CRI-ContainerD로 구현 예정
 * 종료 메시지: CRI-ContainerD로 구현 예정
 * 특권을 가진(Privileged) 컨테이너: 현재 윈도우 컨테이너에서 지원되지 않음
@@ -254,15 +263,8 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템
 * 기존 노드 문제 감지기는 리눅스 전용이며 특권을 가진 컨테이너가 필요하다. 윈도우에서 특권을 가진 컨테이너를 지원하지 않기 때문에 일반적으로 윈도우에서 이 기능이 사용될 것으로 예상하지 않는다.
 * 공유 네임스페이스의 모든 기능이 지원되는 것은 아니다. (자세한 내용은 API 섹션 참조).

-##### 메모리 예약 및 처리
-
-윈도우에는 리눅스처럼 out-of-memory 프로세스 킬러가 없다. 윈도우는 항상 모든 사용자 모드 메모리 할당을 가상으로 처리하며 페이지 파일은 필수이다. 결과적으로 윈도우는 리눅스와 같은 방식으로 메모리 부족 상태에 도달하지 않고, 메모리 부족(OOM)으로 인한 종료 대신 페이지를 디스크로 처리한다. 메모리가 과도하게 프로비저닝되고 모든 실제 메모리가 고갈되면, 페이징으로 인해 성능이 저하될 수 있다.
-
-2단계 프로세스를 통해 적절한 범위 내에서 메모리 사용량을 유지할 수 있다. 먼저, kubelet 파라미터 `--kubelet-reserve` 그리고/또는 `--system-reserve`를 사용하여 노드(컨테이너 외부)의 메모리 사용량을 고려한다. 이렇게 하면 [노드 할당(NodeAllocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)이 줄어든다. 워크로드를 배포할 때 컨테이너에 리소스 제한을 사용(limits만 설정하거나 limits이 requests과 같아야 함)한다. 또한 NodeAllocatable에서 빼고 노드가 가득차면 스케줄러가 더 많은 파드를 추가하지 못하도록 한다.
-
-오버 프로비저닝을 방지하는 모범 사례는 윈도우, 도커 및 쿠버네티스 프로세스를 고려하여 최소 2GB의 시스템 예약 메모리로 kubelet을 구성하는 것이다.
-
-플래그의 동작은 아래에 설명된 대로 다르게 동작한다.
+#### 각 플래그의 리눅스와의 차이점
+윈도우 노드에서의 kubelet 플래그는 아래와 같이 다르게 동작한다.

 * `--kubelet-reserve`, `--system-reserve`, `--eviction-hard` 플래그는 Node Allocatable 업데이트
 * `--enforce-node-allocable`을 사용한 축출(Eviction)은 구현되지 않았다.
@@ -362,7 +364,7 @@ SELinux, AppArmor, Seccomp, 기능(POSIX 기능)과 같은 리눅스 특유의

 * ID - 리눅스는 정수형으로 표시되는 userID(UID) 및 groupID(GID)를 사용한다. 사용자와 그룹 이름은 정식 이름이 아니다. UID+GID에 대한 `/etc/groups` 또는 `/etc/passwd`의 별칭일 뿐이다. 윈도우는 윈도우 보안 계정 관리자(Security Account Manager, SAM) 데이터베이스에 저장된 더 큰 이진 보안 식별자(SID)를 사용한다. 이 데이터베이스는 호스트와 컨테이너 간에 또는 컨테이너들 간에 공유되지 않는다.
 * 파일 퍼미션 - 윈도우는 권한 및 UUID+GID의 비트 마스크(bitmask) 대신 SID를 기반으로 하는 접근 제어 목록을 사용한다.
-* 파일 경로 - 윈도우의 규칙은 `/` 대신 `\`를 사용하는 것이다. Go IO 라이브러리는 일반적으로 두 가지를 모두 허용하고 작동하도록 하지만, 컨테이너 내부에서 해석되는 경로 또는 커맨드 라인을 설정할 때 `\`가 필요할 수 있다.
+* 파일 경로 - 윈도우의 규칙은 `/` 대신 `\`를 사용하는 것이다. Go IO 라이브러리는 두 가지 파일 경로 분리자를 모두 허용한다. 하지만, 컨테이너 내부에서 해석되는 경로 또는 커맨드 라인을 설정할 때 `\`가 필요할 수 있다.
 * 신호(Signals) - 윈도우 대화형(interactive) 앱은 종료를 다르게 처리하며, 다음 중 하나 이상을 구현할 수 있다.
  * UI 스레드는 WM_CLOSE를 포함하여 잘 정의된(well-defined) 메시지를 처리한다.
  * 콘솔 앱은 컨트롤 핸들러(Control Handler)를 사용하여 ctrl-c 또는 ctrl-break를 처리한다.
@@ -410,6 +412,10 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를
 * V1.PodSecurityContext.SupplementalGroups - 윈도우에서는 사용할 수 없는 GID를 제공한다.
 * V1.PodSecurityContext.Sysctls - 이것들은 리눅스 sysctl 인터페이스의 일부이다. 윈도우에는 이에 상응하는 것이 없다.

+#### 운영 체제 버전 제한
+
+윈도우에는 호스트 OS 버전이 컨테이너 베이스 이미지 OS 버전과 일치해야 하는 엄격한 호환성 규칙이 있다. 윈도우 서버 2019의 컨테이너 운영 체제가 있는 윈도우 컨테이너만 지원된다. 윈도우 컨테이너 이미지 버전의 일부 이전 버전과의 호환성을 가능하게 하는 컨테이너의 Hyper-V 격리는 향후 릴리스로 계획되어 있다.
+
 ## 도움 받기 및 트러블슈팅 {#troubleshooting}

 쿠버네티스 클러스터 트러블슈팅을 위한 기본 도움말은 이 [섹션](/docs/tasks/debug-application-cluster/troubleshooting/)에서 먼저 찾아야 한다. 이 섹션에는 몇 가지 추가 윈도우 관련 트러블슈팅 도움말이 포함되어 있다. 로그는 쿠버네티스에서 트러블슈팅하는데 중요한 요소이다. 다른 기여자로부터 트러블슈팅 지원을 구할 때마다 이를 포함해야 한다. SIG-Windows [로그 수집에 대한 기여 가이드](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)의 지침을 따른다.
@@ -26,9 +26,9 @@ kubectl이 인지하는 위치정보와 인증정보는 다음 커맨드로 확
 kubectl config view
 ```

-많은 [예제들](/ko/docs/reference/kubectl/cheatsheet/)에서
-kubectl을 사용하는 것을 소개하고 있으며 완전한 문서는
-[kubectl 매뉴얼](/ko/docs/reference/kubectl/overview/)에서 찾아볼 수 있다.
+[여기](/ko/docs/reference/kubectl/cheatsheet/)에서 
+kubectl 사용 예시를 볼 수 있으며, 완전한 문서는
+[kubectl 매뉴얼](/ko/docs/reference/kubectl/overview/)에서 확인할 수 있다.

 ## REST API에 직접 접근

@@ -44,12 +44,12 @@ REST API에 직접 접근하려고 한다면 위치 파악과 인증을 하는
    - 앞으로는 클라이언트 측의 지능형 load balancing과 failover가 될 것이다.
  - 직접적으로 http 클라이언트에 위치정보와 인증정보를 제공.
    - 대안적인 접근 방식.
-    - proxy 사용과 혼동되는 몇 가지 타입의 클라이언트 code들과 같이 동작한다.
-    - MITM로부터 보호를 위해 root 인증서를 당신의 브라우저로 import해야 한다.
+    - proxy 사용과 혼동되는 몇 가지 타입의 클라이언트 코드와 같이 동작한다.
+    - MITM로부터 보호를 위해 root 인증서를 당신의 브라우저에 저장해야 한다.

 ### kubectl proxy 사용

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

@@ -205,7 +205,7 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다.

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

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

 ### 통신을 위한 방식들

-클러스터 외부에서 노드들, 파드들, 서비스들에 접속하는 데는 몇 가지 선택지들이 있다.
+클러스터 외부에서 노드, 파드 및 서비스에 접속하기 위한 몇 가지 옵션이 있다.

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

-### 빌트인 서비스들의 발견
+### 빌트인 서비스 검색

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

 ```shell
 kubectl cluster-info
@@ -278,22 +278,22 @@ heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/servi
 `http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`를 통해 logging에 접근할 수도 있다.
 (인증을 통과하는 방법이나 kubectl proxy를 사용하는 것은 [쿠버네티스 API를 사용해서 클러스터에 접근하기](/ko/docs/tasks/administer-cluster/access-cluster-api/)을 참조한다.)

-#### 수작업으로 apiserver proxy URL을 구축
+#### 수작업으로 apiserver 프록시 URL을 구축

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

-당신이 port에 이름을 지정하지 않았다면 URL에 *port_name* 을 지정할 필요는 없다.
+당신이 포트에 이름을 지정하지 않았다면 URL에 *port_name* 을 지정할 필요는 없다. 이름이 있는 포트와 이름이 없는 포트 모두에 대하여, *port_name* 이 들어갈 자리에 포트 번호를 기재할 수도 있다.

-기본적으로 API server는 http를 사용하여 서비스를 proxy한다. https를 사용하려면 다음과 같이 서비스 네임의 접두사에 `https:`를 붙인다.
+기본적으로 API server는 http를 사용하여 서비스를 프록시한다. https를 사용하려면 다음과 같이 서비스 네임의 접두사에 `https:`를 붙인다.
 `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`https:service_name:[port_name]`*`/proxy`

 URL의 네임 부분에 지원되는 양식은 다음과 같다.

-* `<service_name>` - http를 사용하여 기본값 또는 이름이 없는 port로 proxy한다
-* `<service_name>:<port_name>` - http를 사용하여 지정된 port로 proxy한다
-* `https:<service_name>:` - https를 사용하여 기본값 또는 이름이 없는 port로 proxy한다(마지막 콜론:에 주의)
-* `https:<service_name>:<port_name>` - https를 사용하여 지정된 port로 proxy한다
+* `<service_name>` - http를 사용하여 기본값 또는 이름이 없는 포트로 프록시한다.
+* `<service_name>:<port_name>` - http를 사용하여 지정된 포트 이름 또는 포트 번호로 프록시한다.
+* `https:<service_name>:` - https를 사용하여 기본값 또는 이름이 없는 포트로 프록시한다. (마지막 콜론(:)에 주의)
+* `https:<service_name>:<port_name>` - https를 사용하여 지정된 포트 이름 또는 포트 번호로 프록시한다.

 ##### 예제들

@@ -326,38 +326,38 @@ URL의 네임 부분에 지원되는 양식은 다음과 같다.

 ## 요청 redirect

-redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) proxy를 사용하기를 바란다.
+redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) 프록시를 사용하기를 바란다.

-## 다양한 Proxy들
+## 다양한 프록시들

-쿠버네티스를 사용하면서 당신이 접할 수 있는 몇 가지 다른 proxy들이 존재한다.
+쿠버네티스를 사용하면서 당신이 접할 수 있는 몇 가지 다른 프록시들이 존재한다.

 1.  [kubectl proxy](#rest-api에-직접-접근):

    - 사용자의 데스크탑이나 파드 내에서 실행한다
-    - localhost 주소에서 쿠버네티스 apiserver로 proxy한다
-    - proxy하는 클라이언트는 HTTP를 사용한다
-    - apiserver의 proxy는 HTTPS를 사용한다
+    - localhost 주소에서 쿠버네티스 apiserver로 프록시한다
+    - 프록시하는 클라이언트는 HTTP를 사용한다
+    - apiserver의 프록시는 HTTPS를 사용한다
    - apiserver를 위치지정한다
    - 인증 header들을 추가한다

-1.  [apiserver proxy](#빌트인-서비스들의-발견):
+1.  [apiserver proxy](#빌트인-서비스-검색):

    - apiserver 내의 빌트인 bastion이다
-    - 다른 방식으로는 연결할 수 없는 클러스터 외부의 사용자를 클러스터 IP들로 연결한다
+    - 다른 방식으로는 연결할 수 없는 클러스터 외부의 사용자를 클러스터 IP로 연결한다
    - apiserver process들 내에서 실행된다
-    - proxy하는 클라이언트는 HTTPS를 사용한다(또는 apiserver가 http로 구성되었다면 http)
-    - 타겟으로의 proxy는 가용정보를 사용하는 proxy에 의해서 HTTP 또는 HTTPS를 사용할 수도 있다
+    - 프록시하는 클라이언트는 HTTPS를 사용한다(또는 apiserver가 http로 구성되었다면 http)
+    - 타겟으로의 프록시는 가용정보를 사용하는 프록시에 의해서 HTTP 또는 HTTPS를 사용할 수도 있다
    - 노드, 파드, 서비스에 접근하는 데 사용될 수 있다
    - 서비스에 접근하는 데 사용되면 load balacing한다

 1.  [kube proxy](/ko/docs/concepts/services-networking/service/#ips-and-vips):

    - 각 노드 상에서 실행된다
-    - UDP와 TCP를 proxy한다
+    - UDP와 TCP를 프록시한다
    - HTTP를 인지하지 않는다
    - load balancing을 제공한다
-    - 서비스에 접근하는 데만 사용된다
+    - 서비스에 접근하는 데에만 사용된다

 1.  apiserver(s) 전면의 Proxy/Load-balancer:

@@ -8,7 +8,7 @@ min-kubernetes-server-version: v1.10
 <!-- overview -->

 이 페이지는 `kubectl port-forward` 를 사용해서 쿠버네티스 클러스터 내에서
-실행중인 Redis 서버에 연결하는 방법을 보여준다. 이 유형의 연결은 데이터베이스
+실행중인 MongoDB 서버에 연결하는 방법을 보여준다. 이 유형의 연결은 데이터베이스
 디버깅에 유용할 수 있다.


@@ -19,25 +19,25 @@ min-kubernetes-server-version: v1.10

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

-* [redis-cli](http://redis.io/topics/rediscli)를 설치한다.
+* [MongoDB Shell](https://www.mongodb.com/try/download/shell)을 설치한다.




 <!-- steps -->

-## Redis 디플로이먼트와 서비스 생성하기
+## MongoDB 디플로이먼트와 서비스 생성하기

-1. Redis를 실행하기 위해 디플로이먼트를 생성한다.
+1. MongoDB를 실행하기 위해 디플로이먼트를 생성한다.

    ```shell
-    kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml
+    kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-deployment.yaml
    ```

    성공적인 명령어의 출력은 디플로이먼트가 생성됐다는 것을 확인해준다.

    ```
-    deployment.apps/redis-master created
+    deployment.apps/mongo created
    ```

    파드 상태를 조회하여 파드가 준비되었는지 확인한다.
@@ -49,8 +49,8 @@ min-kubernetes-server-version: v1.10
    출력은 파드가 생성되었다는 것을 보여준다.

    ```
-    NAME                            READY     STATUS    RESTARTS   AGE
-    redis-master-765d459796-258hz   1/1       Running   0          50s
+    NAME                     READY   STATUS    RESTARTS   AGE
+    mongo-75f59d57f4-4nd6q   1/1     Running   0          2m4s
    ```

    디플로이먼트 상태를 조회한다.
@@ -62,64 +62,65 @@ min-kubernetes-server-version: v1.10
    출력은 디플로이먼트가 생성되었다는 것을 보여준다.

    ```
-    NAME         READY   UP-TO-DATE   AVAILABLE   AGE
-    redis-master 1/1     1            1           55s
+    NAME    READY   UP-TO-DATE   AVAILABLE   AGE
+    mongo   1/1     1            1           2m21s
    ```

+    디플로이먼트는 자동으로 레플리카셋을 관리한다.
    아래의 명령어를 사용하여 레플리카셋 상태를 조회한다.

    ```shell
-    kubectl get rs
+    kubectl get replicaset
    ```

    출력은 레플리카셋이 생성되었다는 것을 보여준다.

    ```
-    NAME                      DESIRED   CURRENT   READY     AGE
-    redis-master-765d459796   1         1         1         1m
+    NAME               DESIRED   CURRENT   READY   AGE
+    mongo-75f59d57f4   1         1         1       3m12s
    ```


-2. Redis를 네트워크에 노출시키기 위해 서비스를 생성한다.
+2. MongoDB를 네트워크에 노출시키기 위해 서비스를 생성한다.

    ```shell
-    kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml
+    kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml
    ```

    성공적인 커맨드의 출력은 서비스가 생성되었다는 것을 확인해준다.

    ```
-    service/redis-master created
+    service/mongo created
    ```

    서비스가 생성되었는지 확인한다.

    ```shell
-    kubectl get svc | grep redis
+    kubectl get service mongo
    ```

    출력은 서비스가 생성되었다는 것을 보여준다.

    ```
-    NAME           TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
-    redis-master   ClusterIP   10.0.0.213   <none>        6379/TCP   27s
+    NAME    TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)     AGE
+    mongo   ClusterIP   10.96.41.183   <none>        27017/TCP   11s
    ```

-3. Redis 서버가 파드 안에서 실행되고 있고, 6379번 포트에서 수신하고 있는지 확인한다.
+3. MongoDB 서버가 파드 안에서 실행되고 있고, 27017번 포트에서 수신하고 있는지 확인한다.

    ```shell
-    # redis-master-765d459796-258hz 를 파드 이름으로 변경한다.
-    kubectl get pod redis-master-765d459796-258hz --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
+    # mongo-75f59d57f4-4nd6q 를 사용자의 파드 이름으로 대체한다.
+    kubectl get pod mongo-75f59d57f4-4nd6q --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'

    ```

-    출력은 파드 내 Redis 포트 번호를 보여준다.
+    출력은 파드 내 MongoDB 포트 번호를 보여준다.

    ```
-    6379
+    27017
    ```

-    (이 TCP 포트는 Redis가 인터넷에 할당된 것이다).
+    (이는 인터넷 상의 MongoDB에 할당된 TCP 포트이다.)

 ## 파드의 포트를 로컬 포트로 포워딩하기

@@ -127,39 +128,39 @@ min-kubernetes-server-version: v1.10


    ```shell
-    # redis-master-765d459796-258hz 를 파드 이름으로 변경한다.
-    kubectl port-forward redis-master-765d459796-258hz 7000:6379
+    # mongo-75f59d57f4-4nd6q 를 사용자의 파드 이름으로 대체한다.
+    kubectl port-forward mongo-75f59d57f4-4nd6q 28015:27017
    ```

    이것은

    ```shell
-    kubectl port-forward pods/redis-master-765d459796-258hz 7000:6379
+    kubectl port-forward pods/mongo-75f59d57f4-4nd6q 28015:27017
    ```

    또는

    ```shell
-    kubectl port-forward deployment/redis-master 7000:6379
+    kubectl port-forward deployment/mongo 28015:27017
    ```

    또는

    ```shell
-    kubectl port-forward rs/redis-master 7000:6379
+    kubectl port-forward replicaset/mongo-75f59d57f4 28015:27017
    ```

    또는 다음과 같다.

    ```shell
-    kubectl port-forward service/redis-master 7000:redis
+    kubectl port-forward service/mongo 28015:27017
    ```

    위의 명령어들은 모두 동일하게 동작한다. 이와 유사하게 출력된다.

    ```
-    Forwarding from 127.0.0.1:7000 -> 6379
-    Forwarding from [::1]:7000 -> 6379
+    Forwarding from 127.0.0.1:28015 -> 27017
+    Forwarding from [::1]:28015 -> 27017
    ```

 {{< note >}}
@@ -168,22 +169,22 @@ min-kubernetes-server-version: v1.10

 {{< /note >}}

-2.  Redis 커맨드라인 인터페이스를 실행한다.
+2.  MongoDB 커맨드라인 인터페이스를 실행한다.

    ```shell
-    redis-cli -p 7000
+    mongosh --port 28015
    ```

-3.  Redis 커맨드라인 프롬프트에 `ping` 명령을 입력한다.
+3.  MongoDB 커맨드라인 프롬프트에 `ping` 명령을 입력한다.

    ```shell
-    ping
+    db.runCommand( { ping: 1 } )
    ```

    성공적인 핑 요청을 반환한다.

    ```
-    PONG
+    { ok: 1 }
    ```

 ### 선택적으로 _kubectl_ 이 로컬 포트를 선택하게 하기 {#let-kubectl-choose-local-port}
@@ -193,15 +194,15 @@ min-kubernetes-server-version: v1.10
 부담을 줄일 수 있다.

 ```shell
-kubectl port-forward deployment/redis-master :6379
+kubectl port-forward deployment/mongo :27017
 ```

-`kubectl` 도구는 사용 중이 아닌 로컬 포트 번호를 찾는다. (낮은 포트 번호는
-다른 애플리케이션에서 사용될 것이므로, 낮은 포트 번호를 피해서) 출력은 다음과 같을 것이다.
+`kubectl` 도구는 사용 중이 아닌 로컬 포트 번호를 찾는다 (낮은 포트 번호는
+다른 애플리케이션에서 사용될 것이므로, 낮은 포트 번호를 피해서). 출력은 다음과 같을 것이다.

 ```
-Forwarding from 127.0.0.1:62162 -> 6379
-Forwarding from [::1]:62162 -> 6379
+Forwarding from 127.0.0.1:63753 -> 27017
+Forwarding from [::1]:63753 -> 27017
 ```


@@ -209,7 +210,7 @@ Forwarding from [::1]:62162 -> 6379

 ## 토의

-로컬 7000 포트에 대한 연결은 Redis 서버가 실행중인 파드의 6379 포트로 포워딩된다.
+로컬 28015 포트에 대한 연결은 MongoDB 서버가 실행중인 파드의 27017 포트로 포워딩된다.
 이 연결로 로컬 워크스테이션에서 파드 안에서 실행 중인 데이터베이스를 디버깅하는데
 사용할 수 있다.

@@ -224,4 +225,4 @@ UDP 프로토콜에 대한 지원은

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

-[kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands/#port-forward)에 대해 더 알아본다.
+[kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands/#port-forward)에 대해 더 알아본다.
@@ -19,22 +19,22 @@ content_type: task

 쿠버네티스에서, [노드](/ko/docs/concepts/architecture/nodes/),
 [파드](/ko/docs/concepts/workloads/pods/) 및 [서비스](/ko/docs/concepts/services-networking/service/)는 모두
-고유한 IP를 가진다. 대부분의 경우, 클러스터의 노드 IP, 파드 IP 및 일부 서비스 IP는 라우팅할 수
-없으므로, 데스크톱 시스템과 같은 클러스터 외부 시스템에서
-도달할 수 없다.
+고유한 IP를 가진다. 사용자의 데스크탑 PC와 같은 클러스터 외부 장비에서는
+클러스터 상의 노드 IP, 파드 IP, 서비스 IP로 라우팅되지 않아서 
+접근할 수 없을 것이다.

 ### 연결하는 방법

-클러스터 외부에서 노드, 파드 및 서비스에 연결하기 위한 몇 가지 옵션이 있다.
+클러스터 외부에서 노드, 파드 및 서비스에 접속하기 위한 몇 가지 옵션이 있다.

  - 퍼블릭 IP를 통해 서비스에 접근한다.
-    - `NodePort` 또는 `LoadBalancer` 타입의 서비스를 사용하여 해당 서비스를 클러스터 외부에서
-      접근할 수 있게 한다. [서비스](/ko/docs/concepts/services-networking/service/)와
+    - 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의
+      서비스를 사용한다. [서비스](/ko/docs/concepts/services-networking/service/)와
      [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참고한다.
-    - 클러스터 환경에 따라, 서비스는 단지 회사 네트워크에 노출되기도 하며,
-      인터넷에 노출되는 경우도 있다. 노출되는 서비스가 안전한지 생각한다.
-      자체 인증을 수행하는가?
-    - 서비스 뒤에 파드를 배치한다. 디버깅과 같은 목적으로 레플리카 집합에서 특정 파드에 접근하려면,
+    - 클러스터 환경에 따라, 서비스는 회사 네트워크에만 노출되기도 하며,
+      인터넷에 노출되는 경우도 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다.
+      해당 서비스는 자체적으로 인증을 수행하는가?
+    - 파드는 서비스 뒤에 위치시킨다. 디버깅과 같은 목적으로 레플리카 집합에서 특정 파드에 접근하려면,
      파드에 고유한 레이블을 배치하고 이 레이블을 선택하는 새 서비스를 생성한다.
    - 대부분의 경우, 애플리케이션 개발자가 nodeIP를 통해 노드에 직접
      접근할 필요는 없다.
@@ -54,8 +54,8 @@ content_type: task

 ### 빌트인 서비스 검색

-일반적으로, kube-system에 의해 클러스터에서 시작되는 몇 가지 서비스가 있다. `kubectl cluster-info` 명령을
-사용하여 이들의 목록을 얻는다.
+일반적으로 kube-system에 의해 클러스터에 실행되는 몇 가지 서비스가 있다. 
+`kubectl cluster-info` 커맨드로 이 서비스의 리스트를 볼 수 있다.

 ```shell
 kubectl cluster-info
@@ -33,7 +33,7 @@ Kube-dns의 배포나 교체에 관한 매뉴얼은 [CoreDNS GitHub 프로젝트
 ### Kubeadm을 사용해 기존 클러스터 업그레이드하기

 쿠버네티스 버전 1.10 이상에서, `kube-dns` 를 사용하는 클러스터를 업그레이드하기 위하여
-`kubeadm` 을 사용할 때 CoreDNS로 이동할 수도 있다. 이 경우, `kubeadm` 은
+`kubeadm` 을 사용할 때 CoreDNS로 전환할 수도 있다. 이 경우, `kubeadm` 은
 `kube-dns` 컨피그맵(ConfigMap)을 기반으로 패더레이션, 스텁 도메인(stub domain), 업스트림 네임 서버의
 설정을 유지하며 CoreDNS 설정("Corefile")을 생성한다.

@@ -168,7 +168,7 @@ controllerManager:

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

-쿠버네티스 API로 CSR을 작성하려면 [CertificateSigningRequest 생성](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#create-certificatesigningrequest)을 본다.
+쿠버네티스 API로 CSR을 작성하려면 [CertificateSigningRequest 생성](/docs/reference/access-authn-authz/certificate-signing-requests/#create-certificatesigningrequest)을 본다.

 ## 외부 CA로 인증서 갱신

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

 ### 추가 정보

- kubelet 마이너 버전을 업그레이드하기 전에 [노드 드레이닝(draining)](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/)이
+- kubelet 마이너 버전을 업그레이드하기 전에 [노드 드레이닝(draining)](/docs/tasks/administer-cluster/safely-drain-node/)이
  필요하다. 컨트롤 플레인 노드의 경우 CoreNDS 파드 또는 기타 중요한 워크로드를 실행할 수 있다.
 - 컨테이너 사양 해시 값이 변경되므로, 업그레이드 후 모든 컨테이너가 다시 시작된다.

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

 **사전요구사항**: [gcloud](https://cloud.google.com/sdk/docs/quickstarts).

-1.  캘리코로 GKE 클러스터를 시작하려면, `--enable-network-policy` 플래그를 추가하면 된다.
+1.  캘리코로 GKE 클러스터를 시작하려면, `--enable-network-policy` 플래그를 추가한다.

    **문법**
    ```shell
@@ -13,7 +13,7 @@ content_template: task
 없이 특정 노드에 있는 kubelet 데몬에 의해
 직접 관리된다.
 컨트롤 플레인에 의해 관리되는 파드(예를 들어 {{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}})와는 달리,
-kubelet 이 각각의 스태틱 파드를 감시한다.
+kubelet이 각각의 스태틱 파드를 감시한다.
 (만약 실패할 경우 다시 구동한다.)

 스태틱 파드는 항상 특정 노드에 있는 하나의 {{< glossary_tooltip term_id="kubelet" >}}에 매여 있다.
@@ -31,21 +31,14 @@ API 서버에서 제어될 수는 없다.
 을 사용하는 것이 바람직하다.
 {{< /note >}}

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

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

 이 페이지는 파드를 실행하기 위해 {{< glossary_tooltip term_id="docker" >}}를 사용하며,
 노드에서 Fedora 운영 체제를 구동하고 있다고 가정한다.
 다른 배포판이나 쿠버네티스 설치 지침과는 다소 상이할 수 있다.

-
-
-
-
 <!-- steps -->

 ## 스태틱 파드 생성하기 {#static-pod-creation}
@@ -54,8 +47,10 @@ API 서버에서 제어될 수는 없다.

 ### 파일시스템이 호스팅 하는 스태틱 파드 매니페스트 {#configuration-files}

-매니페스트는 특정 디렉터리에 있는 JSON 이나 YAML 형식의 표준 파드 정의이다. [kubelet 구성 파일](/docs/tasks/administer-cluster/kubelet-config-file)의 `staticPodPath: <the directory>` 필드를 사용하자. 이 디렉터리를 정기적으로 스캔하여, 디렉터리 안의 YAML/JSON 파일이 생성되거나 삭제되었을 때 스태틱 파드를 생성하거나 삭제한다.
-Kubelet 이 특정 디렉터리를 스캔할 때 점(.)으로 시작하는 단어를 무시한다는 점을 유의하자.
+매니페스트는 특정 디렉터리에 있는 JSON 이나 YAML 형식의 표준 파드 정의이다. 
+[kubelet 구성 파일](/docs/reference/config-api/kubelet-config.v1beta1/)의 `staticPodPath: <the directory>` 필드를 사용하자. 
+명시한 디렉터리를 정기적으로 스캔하여, 디렉터리 안의 YAML/JSON 파일이 생성되거나 삭제되었을 때 스태틱 파드를 생성하거나 삭제한다.
+kubelet이 특정 디렉터리를 스캔할 때 점(.)으로 시작하는 단어를 무시한다는 점을 유의하자.

 예를 들어, 다음은 스태틱 파드로 간단한 웹 서버를 구동하는 방법을 보여준다.

@@ -68,7 +63,7 @@ Kubelet 이 특정 디렉터리를 스캔할 때 점(.)으로 시작하는 단
 2. `/etc/kubelet.d` 와 같은 디렉터리를 선택하고 웹 서버 파드의 정의를 해당 위치에, 예를 들어 `/etc/kubelet.d/static-web.yaml` 에 배치한다.  

    ```shell
-	  # kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다.
+	  # kubelet이 동작하고 있는 노드에서 이 명령을 수행한다.
    mkdir /etc/kubelet.d/
    cat <<EOF >/etc/kubelet.d/static-web.yaml
    apiVersion: v1
@@ -90,17 +85,18 @@ Kubelet 이 특정 디렉터리를 스캔할 때 점(.)으로 시작하는 단

 3. 노드에서 kubelet 실행 시에 `--pod-manifest-path=/etc/kubelet.d/` 와 같이 인자를 제공하여 해당 디렉터리를 사용하도록 구성한다. Fedora 의 경우 이 줄을 포함하기 위하여 `/etc/kubernetes/kubelet` 파일을 다음과 같이 수정한다.

-    ```
-    KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/"
-    ```
-    혹은 [kubelet 구성 파일](/docs/tasks/administer-cluster/kubelet-config-file)에 `staticPodPath: <the directory>` 필드를 추가한다.
+   ```
+   KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/"
+   ```
+   혹은 [kubelet 구성 파일](/docs/reference/config-api/kubelet-config.v1beta1/)에 
+   `staticPodPath: <the directory>` 필드를 추가한다.

 4. kubelet을 재시작한다. Fedora의 경우 아래와 같이 수행한다.

-    ```shell
-    # kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다.
-    systemctl restart kubelet
-    ```
+   ```shell
+   # kubelet이 동작하고 있는 노드에서 이 명령을 수행한다.
+   systemctl restart kubelet
+   ```

 ### 웹이 호스팅 하는 스태틱 파드 매니페스트 {#pods-created-via-http}

@@ -140,7 +136,7 @@ Kubelet은 `--manifest-url=<URL>` 의 인수로 지정된 파일을 주기적으
 3. Kubelet을 재시작한다. Fedora의 경우 아래와 같이 수행한다.

    ```shell
-    # kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다.
+    # kubelet이 동작하고 있는 노드에서 이 명령을 수행한다.
    systemctl restart kubelet
    ```

@@ -152,7 +148,7 @@ Kubelet 을 시작하면, 정의된 모든 스태틱 파드가 자동으로 시

 (노드에서) 구동되고 있는 (스태틱 파드를 포함한) 컨테이너들을 볼 수 있다.
 ```shell
-# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다.
+# kubelet이 동작하고 있는 노드에서 이 명령을 수행한다.
 docker ps
 ```

@@ -201,13 +197,13 @@ NAME                       READY     STATUS    RESTARTS   AGE
 static-web-my-node1        1/1       Running   0          12s
 ```

-kubelet 이 구동 중인 노드로 돌아가서 도커 컨테이너를 수동으로
+kubelet이 구동 중인 노드로 돌아가서 도커 컨테이너를 수동으로
 중지할 수 있다.
 일정 시간이 지나면, kubelet이 파드를 자동으로 인식하고 다시 시작하는
 것을 볼 수 있다.

 ```shell
-# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다.
+# kubelet이 동작하고 있는 노드에서 이 명령을 수행한다.
 docker stop f6d05272b57e # 예제를 수행하는 사용자의 컨테이너 ID로 변경한다.
 sleep 20
 docker ps
@@ -223,7 +219,7 @@ CONTAINER ID        IMAGE         COMMAND                CREATED       ...

 ```shell
 # 예제를 수행하는 사용자가 파일시스템이 호스팅하는 스태틱 파드 설정을 사용한다고 가정한다.
-# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다.
+# kubelet이 동작하고 있는 노드에서 이 명령을 수행한다.
 #
 mv /etc/kubelet.d/static-web.yaml /tmp
 sleep 20
@@ -57,7 +57,7 @@ kubectl describe pods ${POD_NAME}
  절대 스케줄 될 수 없다.

 	사용자는 `kubectl get nodes -o <format>` 명령으로 노드의
-	용량을 점검할 수 있다. 다음은 필요한 정보만을 추출하는 몇 가지
+	용량을 점검할 수 있다. 다음은 필요한 정보를 추출하는 몇 가지
 	명령의 예이다.

    ```shell
@@ -19,7 +19,7 @@ weight: 30
 1. **메시지 대기열 서비스를 시작한다.** 이 예에서는, RabbitMQ를 사용하지만, 다른 메시지 대기열을 이용해도
   된다. 실제로 사용할 때는, 한 번 메시지 대기열 서비스를 구축하고서 이를 여러 잡을 위해 재사용하기도 한다.
 1. **대기열을 만들고, 메시지로 채운다.** 각 메시지는 수행할 하나의 작업을 나타낸다. 
-   이 예제에서, 메시지는 긴 계산을 수행할 정수일 뿐이다.
+   이 예제에서, 메시지는 긴 계산을 수행할 정수다.
 1. **대기열에서 작업을 수행하는 잡을 시작한다.**  잡은 여러 파드를 시작한다. 각 파드는
   메시지 대기열에서 하나의 작업을 가져와서, 처리한 다음, 대기열이 비워질 때까지 반복한다.

@@ -141,13 +141,12 @@ root@temp-loe07:/#
 ```

 마지막 커맨드에서, `amqp-consume` 도구는 대기열로부터 하나의 메시지를
-받고(`-c 1`), 그 메시지를 임의의 명령 표준입력으로 전달한다. 이 경우에는, `cat` 프로그램이 표준입력으로부터
-받은 값을 바로 출력하고 있고,  echo가 캐리지 리턴을 더해주어
+받고(`-c 1`), 그 메시지를 임의의 명령 표준입력으로 전달한다. 이 경우에는, `cat` 프로그램이 표준입력으로부터 받은 값을 출력하고, echo가 캐리지 리턴을 더해주어
 출력 결과가 보여진다.

 ## 작업으로 대기열 채우기

-이제 몇 가지 "작업"으로 대기열을 채운다. 이 예제에서의 작업은 간단히 문자열을
+이제 몇 가지 "작업"으로 대기열을 채운다. 이 예제에서의 작업은 문자열을
 출력하는 것이다.

 실제로 사용할 때는, 메시지의 내용이 다음과 같을 수 있다. 
@@ -21,7 +21,7 @@ weight: 40
   않기 때문에 Redis 및 사용자 지정의 작업 대기열 클라이언트 라이브러리를 사용한다. 실제로는
   Redis와 같은 저장소를 한 번 설정하고 여러 작업과 다른 것들의 작업 대기열로 재사용한다.
 1. **대기열을 만들고, 메시지로 채운다.**  각 메시지는 수행할 하나의 작업을 나타낸다. 이
-   예에서, 메시지는 긴 계산을 수행할 정수일 뿐이다.
+   예에서, 메시지는 긴 계산을 수행할 정수다.
 1. **대기열에서 작업을 수행하는 잡을 시작한다.**  잡은 여러 파드를 시작한다. 각 파드는
   메시지 대기열에서 하나의 작업을 가져와서, 처리한 다음, 대기열이 비워질 때까지 반복한다.

@@ -111,8 +111,8 @@ kubectl edit ds/fluentd-elasticsearch -n kube-system

 ##### 컨테이너 이미지만 업데이트

-데몬셋 템플릿에서 컨테이너 이미지를 업데이트해야 하는
-경우(예: `.spec.template.spec.containers[*].image`), `kubectl set image` 를 사용한다.
+데몬셋 템플릿(예: `.spec.template.spec.containers[*].image`)에 의해 정의된 컨테이너 이미지만 업데이트하려면, 
+`kubectl set image` 를 사용한다.

 ```shell
 kubectl set image ds/fluentd-elasticsearch fluentd-elasticsearch=quay.io/fluentd_elasticsearch/fluentd:v2.6.0 -n kube-system
@@ -168,7 +168,7 @@ kubectl get pods -l name=fluentd-elasticsearch -o wide -n kube-system
 데몬셋 롤아웃이 진행되지 않는다.

 이 문제를 해결하려면, 데몬셋 템플릿을 다시 업데이트한다. 이전의 비정상 롤아웃으로 인해
-새로운 롤아웃이 차단되지 않는다.
+새로운 롤아웃이 차단되지는 않는다.

 #### 클럭 차이(skew)

@@ -13,7 +13,7 @@ description: 클러스터의 노드별로 리소스로 사용할 GPU를 구성
 쿠버네티스는 AMD 및 NVIDIA GPU(그래픽 프로세싱 유닛)를 노드들에 걸쳐 관리하기 위한 **실험적인**
 지원을 포함한다.

-이 페이지는 다른 쿠버네티스 버전 간에 걸쳐 사용자가 GPU들을 소비할 수 있는 방법과
+이 페이지는 여러 쿠버네티스 버전에서 사용자가 GPU를 활용할 수 있는 방법과
 현재의 제약 사항을 설명한다.


@@ -37,7 +37,7 @@ description: 클러스터의 노드별로 리소스로 사용할 GPU를 구성
 `nvidia.com/gpu` 를 스케줄 가능한 리소스로써 노출시킨다.

 사용자는 이 GPU들을 `cpu` 나 `memory` 를 요청하는 방식과 동일하게
-`<vendor>.com/gpu` 를 요청함으로써 컨테이너를 통해 소비할 수 있다.
+`<vendor>.com/gpu` 를 요청함으로써 컨테이너에서 활용할 수 있다.
 그러나 GPU를 사용할 때는 리소스 요구 사항을 명시하는 방식에 약간의
 제약이 있다.

@@ -37,8 +37,8 @@ kubectl delete statefulsets <statefulset-name>
 kubectl delete service <service-name>
 ```

-kubectl을 통해 스테이트풀셋을 삭제하면 0으로 스케일이 낮아지고, 스테이트풀셋에 포함된 모든 파드가 삭제된다.
-파드가 아닌 스테이트풀셋만 삭제하려면, `--cascade=false` 를 사용한다.
+kubectl을 통해 스테이트풀셋을 삭제하면, 스테이트풀셋의 크기가 0으로 설정되고 이로 인해 스테이트풀셋에 포함된 모든 파드가 삭제된다. 파드가 아닌 스테이트풀셋만 삭제하려면, `--cascade=false` 옵션을 사용한다. 
+예시는 다음과 같다.

 ```shell
 kubectl delete -f <file.yaml> --cascade=false
@@ -381,7 +381,7 @@ object:
 외부 메트릭 사용시, 먼저 모니터링 시스템에 대한 이해가 있어야 한다.
 이 설치는 사용자 정의 메트릭과 유사하다.
 외부 메트릭을 사용하면 모니터링 시스템의 사용 가능한 메트릭에 기반하여 클러스터를 오토스케일링 할 수 있다.
-위의 예제처럼 `name`과 `selector`를 갖는 `metric` 블록을 제공하고,
+위의 예제처럼 `name`과 `selector`를 갖는 `metric` 블록을 명시하고,
 `Object` 대신에 `External` 메트릭 타입을 사용한다.
 만일 여러 개의 시계열이 `metricSelector`와 일치하면, HorizontalPodAutoscaler가 값의 합을 사용한다.
 외부 메트릭들은 `Value`와 `AverageValue` 대상 타입을 모두 지원하고,
@@ -23,9 +23,7 @@ Pod Autoscaler는 크기를 조정할 수 없는 오브젝트(예: 데몬셋(Dae

 Horizontal Pod Autoscaler는 쿠버네티스 API 리소스 및 컨트롤러로 구현된다.
 리소스는 컨트롤러의 동작을 결정한다.
-컨트롤러는 관찰된 평균 CPU 사용률이 사용자가 지정한 대상과 일치하도록 레플리케이션
-컨트롤러 또는 디플로이먼트에서 레플리카 개수를 주기적으로 조정한다.
-
+컨트롤러는 평균 CPU 사용률, 평균 메모리 사용률 또는 다른 커스텀 메트릭과 같은 관찰 대상 메트릭이 사용자가 지정한 목표값과 일치하도록 레플리케이션 컨트롤러 또는 디플로이먼트에서 레플리카 개수를 주기적으로 조정한다.



@@ -355,7 +353,7 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다.

 ## 구성가능한 스케일링 동작 지원

-[v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/20190307-configurable-scale-velocity-for-hpa.md)
+[v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/853-configurable-hpa-scale-velocity/README.md)
 부터 `v2beta2` API는 HPA `behavior` 필드를 통해
 스케일링 동작을 구성할 수 있다.
 동작은 `behavior` 필드 아래의 `scaleUp` 또는 `scaleDown`
@@ -17,9 +17,9 @@ no_list: true
 `kubectl` 은 다양한 리눅스 플랫폼, macOS, 그리고 윈도우에 설치할 수 있다.
 각각에 대한 설치 가이드는 다음과 같다.

- [리눅스에 `kubectl` 설치하기](install-kubectl-linux)
- [macOS에 `kubectl` 설치하기](install-kubectl-macos)
- [윈도우에 `kubectl` 설치하기](install-kubectl-windows)
+- [리눅스에 `kubectl` 설치하기](/ko/docs/tasks/tools/install-kubectl-linux/)
+- [macOS에 `kubectl` 설치하기](/ko/docs/tasks/tools/install-kubectl-macos/)
+- [윈도우에 `kubectl` 설치하기](/ko/docs/tasks/tools/install-kubectl-windows/)

 ## kind

@@ -27,6 +27,8 @@ content_type: concept

 ## 구성

+* [예제: Java 마이크로서비스 구성하기](/ko/docs/tutorials/configuration/configure-java-microservice/)
+
 * [컨피그 맵을 사용해서 Redis 설정하기](/ko/docs/tutorials/configuration/configure-redis-using-configmap/)

 ## 상태 유지를 하지 않는(stateless) 애플리케이션
@@ -322,7 +322,7 @@ Events:
  23s          23s         1        {kubelet e2e-test-stclair-node-pool-t1f5}             Warning        AppArmor    Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded
 ```

-파드 상태는 Failed이며 오류메시지는 `Pod Cannot enforce AppArmor: profile
+파드 상태는 Pending이며, 오류 메시지는 `Pod Cannot enforce AppArmor: profile
 "k8s-apparmor-example-allow-write" is not loaded`이다. 이벤트도 동일한 메시지로 기록되었다.

 ## 관리 {#administration}
@@ -48,7 +48,7 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
    {{< kat-button >}}

 {{< note >}}
-    minikube를 로컬에 설치했다면 `minikube start`를 실행한다.
+    minikube를 로컬에 설치했다면 `minikube start`를 실행한다. `minikube dashboard` 명령을 실행하기 전에, 새 터미널을 열고, 그 터미널에서 `minikube dashboard` 명령을 실행한 후, 원래의 터미널로 돌아온다.
 {{< /note >}}

 2. 브라우저에서 쿠버네티스 대시보드를 열어보자.
@@ -154,7 +154,7 @@ minikube dashboard --url
    `k8s.gcr.io/echoserver` 이미지 내의 애플리케이션 코드는 TCP 포트 8080에서만 수신한다. `kubectl expose`를
    사용하여 다른 포트를 노출한 경우, 클라이언트는 다른 포트에 연결할 수 없다.

-2. 방금 생성한 서비스 살펴보기
+2. 생성한 서비스 살펴보기

    ```shell
    kubectl get services
@@ -229,7 +229,7 @@ minikube 툴은 활성화하거나 비활성화할 수 있고 로컬 쿠버네
    metrics-server was successfully enabled
    ```

-3. 방금 생성한 파드와 서비스를 확인한다.
+3. 생성한 파드와 서비스를 확인한다.

    ```shell
    kubectl get pod,svc -n kube-system
@@ -434,7 +434,7 @@ web-4     0/1       ContainerCreating   0         0s
 web-4     1/1       Running   0         19s
 ```

-스테이트풀셋 컨트롤러는 레플리카개수를 스케일링한다.
+스테이트풀셋 컨트롤러는 레플리카 개수를 스케일링한다.
 [스테이트풀셋 생성](#차례대로-파드-생성하기)으로 스테이트풀셋 컨트롤러는
 각 파드을 순차적으로 각 순번에 따라 생성하고 후속 파드 시작 전에
 이전 파드가 Running과 Ready 상태가 될 때까지
@@ -1067,9 +1067,10 @@ statefulset "web" deleted
 ### Parallel 파드 관리

 `Parallel` 파드 관리는 스테이트풀셋 컨트롤러가 모든 파드를
-병렬로 시작하고 종료하는 것으로 다른 파드를 시작/종료하기 전에
+병렬로 시작하고 종료하는 것으로, 다른 파드를 시작/종료하기 전에
 파드가 Running과 Ready 상태로 전환되거나 완전히 종료되기까지
 기다리지 않음을 뜻한다.
+이 옵션은 스케일링 동작에만 영향을 미치며, 업데이트 동작에는 영향을 미치지 않는다.

 {{< codenew file="application/web/web-parallel.yaml" >}}

@@ -1114,7 +1115,7 @@ web-1     1/1       Running   0         10s
 스테이트풀셋 컨트롤러는 `web-0`와  `web-1`를 둘 다 동시에 시작했다.

 두 번째 터미널을 열어 놓고 다른 터미널창에서 스테이트풀셋을
-스케일링 하자.
+스케일링하자.

 ```shell
 kubectl scale statefulset/web --replicas=4
@@ -49,13 +49,14 @@ min-kubernetes-server-version: v1.14
 1. 매니페스트 파일을 다운로드한 디렉터리에서 터미널 창을 시작한다.
 1. `mongo-deployment.yaml` 파일을 통해 MongoDB 디플로이먼트에 적용한다.

+      <!--
+      콘텐츠에 대한 로컬 테스트는 파일의 상대 경로로 한다.
+      kubectl apply -f ./content/en/examples/application/guestbook/mongo-deployment.yaml
+      -->
+
      ```shell
      kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-deployment.yaml
      ```
-<!--
-컨텐츠에 대한 로컬 테스트는 파일의 상대경로로 한다.
-kubectl apply -f ./content/en/examples/application/guestbook/mongo-deployment.yaml
-->

 1. 파드의 목록을 질의하여 MongoDB 파드가 실행 중인지 확인한다.

@@ -84,15 +85,15 @@ kubectl apply -f ./content/en/examples/application/guestbook/mongo-deployment.ya

 1. `mongo-service.yaml` 파일을 통해 MongoDB 서비스에 적용한다.

+      <!--
+      콘텐츠에 대한 로컬 테스트는 파일의 상대 경로로 한다.
+      kubectl apply -f ./content/en/examples/application/guestbook/mongo-service.yaml
+      -->
+
      ```shell
      kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml
      ```

-<!--
-컨텐츠에 대한 로컬 테스트는 파일의 상대경로로 한다.
-kubectl apply -f ./content/en/examples/application/guestbook/mongo-service.yaml
-->
-
 1. 서비스의 목록을 질의하여 MongoDB 서비스가 실행 중인지 확인한다.

      ```shell
@@ -122,15 +123,15 @@ kubectl apply -f ./content/en/examples/application/guestbook/mongo-service.yaml

 1. `frontend-deployment.yaml` 파일을 통해 프론트엔드의 디플로이먼트에 적용한다.

+      <!--
+      콘텐츠에 대한 로컬 테스트는 파일의 상대 경로로 한다.
+      kubectl apply -f ./content/en/examples/application/guestbook/frontend-deployment.yaml
+      -->
+
      ```shell
      kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml
      ```

-<!--
-컨텐츠에 대한 로컬 테스트는 파일의 상대경로로 한다.
-kubectl apply -f ./content/en/examples/application/guestbook/frontend-deployment.yaml
-->
-
 1. 파드의 목록을 질의하여 세 개의 프론트엔드 복제본이 실행되고 있는지 확인한다.

      ```shell
@@ -160,15 +161,15 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우

 1. `frontend-service.yaml` 파일을 통해 프론트엔드 서비스에 적용시킨다.

+      <!--
+      콘텐츠에 대한 로컬 테스트는 파일의 상대 경로로 한다.
+      kubectl apply -f ./content/en/examples/application/guestbook/frontend-service.yaml
+      -->
+
      ```shell
      kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-service.yaml
      ```

-<!--
-컨텐츠에 대한 로컬 테스트는 파일의 상대경로로 한다.
-kubectl apply -f ./content/en/examples/application/guestbook/frontend-service.yaml
-->
-
 1. 서비스의 목록을 질의하여 프론트엔드 서비스가 실행 중인지 확인한다.

      ```shell
@@ -179,7 +180,7 @@ kubectl apply -f ./content/en/examples/application/guestbook/frontend-service.ya

      ```
      NAME           TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
-      frontend       ClusterIP   10.0.0.112   <none>       80/TCP   6s
+      frontend       ClusterIP   10.0.0.112   <none>        80/TCP         6s
      kubernetes     ClusterIP   10.0.0.1     <none>        443/TCP        4m
      mongo          ClusterIP   10.0.0.151   <none>        6379/TCP       2m
      ```
@@ -214,8 +215,8 @@ kubectl apply -f ./content/en/examples/application/guestbook/frontend-service.ya
      결과는 아래와 같은 형태로 나타난다.

      ```
-      NAME       TYPE        CLUSTER-IP      EXTERNAL-IP        PORT(S)        AGE
-      frontend   ClusterIP   10.51.242.136   109.197.92.229     80:32372/TCP   1m
+      NAME       TYPE           CLUSTER-IP      EXTERNAL-IP        PORT(S)        AGE
+      frontend   LoadBalancer   10.51.242.136   109.197.92.229     80:32372/TCP   1m
      ```

 1. IP 주소를 복사하고, 방명록을 보기 위해 브라우저에서 페이지를 로드한다.
@@ -245,7 +246,7 @@ kubectl apply -f ./content/en/examples/application/guestbook/frontend-service.ya
      frontend-3823415956-k22zn       1/1       Running   0          54m
      frontend-3823415956-w9gbt       1/1       Running   0          54m
      frontend-3823415956-x2pld       1/1       Running   0          5s
-      mongo-1068406935-3lswp   1/1       Running   0          56m
+      mongo-1068406935-3lswp          1/1       Running   0          56m
      ```

 1. 프론트엔드 파드의 수를 축소하기 위해 아래 명령어를 실행한다.
@@ -266,7 +267,7 @@ kubectl apply -f ./content/en/examples/application/guestbook/frontend-service.ya
      NAME                            READY     STATUS    RESTARTS   AGE
      frontend-3823415956-k22zn       1/1       Running   0          1h
      frontend-3823415956-w9gbt       1/1       Running   0          1h
-      mongo-1068406935-3lswp   1/1       Running   0          1h
+      mongo-1068406935-3lswp          1/1       Running   0          1h
      ```
Author	SHA1	Message	Date
Kubernetes Prow Robot	628b9d2115	Merge pull request #27901 from jihoon-seo/210507_Update_outdated_files_in_dev-1.20-ko.8_p3 [ko] Update outdated files in dev-1.20-ko.8 (p3)	2021-05-11 03:53:36 -07:00
Jihoon Seo	d1751c8101	[ko] Update outdated files in dev-1.20-ko.8 (p3)	2021-05-10 10:11:33 +09:00
Kubernetes Prow Robot	318ae0b7fe	Merge pull request #27760 from jihoon-seo/210428_Update_outdated_files_in_dev-1.20-ko.8_p2 [ko] Update outdated files in dev-1.20-ko.8 (p2)	2021-05-06 06:05:17 -07:00
Kubernetes Prow Robot	5f1bdf56b9	Merge pull request #27728 from jihoon-seo/210426_Update_outdated_files_in_dev-1.20-ko.8_p1 [ko] Update outdated files in dev-1.20-ko.8 (p1)	2021-05-06 06:03:16 -07:00
Jihoon Seo	d38d6a4631	[ko] Update outdated files in dev-1.20-ko.8 (p2)	2021-05-04 09:24:19 +09:00
Jihoon Seo	0d17ba6f58	[ko] Update outdated files in dev-1.20-ko.8 (p1)	2021-05-04 09:22:05 +09:00
Kubernetes Prow Robot	8da84d2c2e	Merge pull request #27477 from reylejano/fix-release-1.20-config.toml Fix config.toml for release-1.20 branch	2021-04-09 01:18:47 -07:00
Rey Lejano	b7403d2140	fix config.toml for release-1.20 branch	2021-04-08 14:52:05 -07:00
Kubernetes Prow Robot	dc2ffc1833	Merge pull request #27455 from reylejano/update-release-1.20-config.toml Update 1.20 config.toml for release 1.21	2021-04-08 12:30:03 -07:00
Rey Lejano	05de8ac4d0	update release-1.20 config.toml for release 1.21	2021-04-07 16:18:32 -07:00