Merge pull request #27553 from jihoon-seo/210414_Update_outdated_files_of_dev-1.20-ko.7_p3

[ko] Update outdated files in dev-1.21-ko.1 (p3)

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

@@ -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,6 +384,9 @@ kubectl api-resources --api-group=extensions # "extensions" API 그룹의 모든
 # 클러스터에서 실행 중인 모든 이미지
 kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'
 
+# `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'
 

content/ko/docs/reference/scheduling/config.md

@@ -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를 구성할 수 있다.
 
 최소 구성은 다음과 같다.
 
@@ -149,7 +147,12 @@ profiles:
   익스텐션 포인트: `Score`.
 - `VolumeBinding`: 노드에 요청된 {{< glossary_tooltip text="볼륨" term_id="volume" >}}이 있는지
   또는 바인딩할 수 있는지 확인한다.
-  익스텐션 포인트: `PreFilter`, `Filter`, `Reserve`, `PreBind`.
+  익스텐션 포인트: `PreFilter`, `Filter`, `Reserve`, `PreBind`, `Score`.
+  {{< note >}}
+  `Score` 익스텐션 포인트는 `VolumeCapacityPriority` 기능이 
+  활성화되어 있어야 활성화되며, 
+  요청된 볼륨 사이즈를 만족하는 가장 작은 PV들을 우선순위 매긴다.
+  {{< /note >}}
 - `VolumeRestrictions`: 노드에 마운트된 볼륨이 볼륨 제공자에 특정한
   제한 사항을 충족하는지 확인한다.
   익스텐션 포인트: `Filter`.
@@ -249,3 +252,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/) 레퍼런스 읽어보기

content/ko/docs/reference/scheduling/policies.md

@@ -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/) 읽어보기

content/ko/docs/reference/setup-tools/kubeadm/_index.md

@@ -26,5 +26,7 @@ kubeadm을 설치하려면, [설치 가이드](/ko/docs/setup/production-environ
 * [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config/): kubeadm v1.7.x 이하의 버전을 사용하여 클러스터를 초기화한 경우, `kubeadm upgrade` 를 위해 사용자의 클러스터를 구성한다.
 * [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token/): `kubeadm join` 을 위한 토큰을 관리한다.
 * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/): `kubeadm init` 또는 `kubeadm join` 에 의한 호스트의 모든 변경 사항을 되돌린다.
+* [kubeadm certs](/docs/reference/setup-tools/kubeadm/kubeadm-certs): 쿠버네티스 인증서를 관리한다.
+* [kubeadm kubeconfig](/docs/reference/setup-tools/kubeadm/kubeadm-kubeconfig): kubeconfig 파일을 관리한다.
 * [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version/): kubeadm 버전을 출력한다.
 * [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/): 커뮤니티에서 피드백을 수집하기 위해서 기능 미리 보기를 제공한다.

content/ko/docs/setup/best-practices/cluster-large.md

@@ -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 및 메모리 제한을 설정할 수 있다.
 

content/ko/docs/setup/production-environment/container-runtimes.md

@@ -48,7 +48,7 @@ Systemd는 cgroup과의 긴밀한 통합을 통해 프로세스당 cgroup을 할
 시스템이 안정화된다. 도커에 대해 구성하려면, `native.cgroupdriver=systemd`를 설정한다.
 
 {{< caution >}}
-클러스터에 결합되어 있는 노드의 cgroup 관리자를 변경하는 것은 강력하게 권장하지 *않는다*.
+클러스터에 결합되어 있는 노드의 cgroup 관리자를 변경하는 것은 신중하게 수행해야 한다.
 하나의 cgroup 드라이버의 의미를 사용하여 kubelet이 파드를 생성해왔다면,
 컨테이너 런타임을 다른 cgroup 드라이버로 변경하는 것은 존재하는 기존 파드에 대해 파드 샌드박스 재생성을 시도할 때, 에러가 발생할 수 있다.
 kubelet을 재시작하는 것은 에러를 해결할 수 없을 것이다.
@@ -57,6 +57,11 @@ kubelet을 재시작하는 것은 에러를 해결할 수 없을 것이다.
 교체하거나, 자동화를 사용하여 다시 설치한다.
 {{< /caution >}}
 
+### kubeadm으로 생성한 클러스터의 드라이버를 `systemd`로 변경하기
+
+kubeadm으로 생성한 클러스터의 cgroup 드라이버를 `systemd`로 변경하려면
+[변경 가이드](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)를 참고한다.
+
 ## 컨테이너 런타임
 
 {{% thirdparty-content %}}

content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md

@@ -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          | 자체                      |
@@ -294,33 +294,17 @@ Flatcar Container Linux 배포판은 `/usr` 디렉터리를 읽기 전용 파일
 kubelet은 이제 kubeadm이 수행할 작업을 알려 줄 때까지 크래시루프(crashloop) 상태로
 기다려야 하므로 몇 초마다 다시 시작된다.
 
-## 컨트롤 플레인 노드에서 kubelet이 사용하는 cgroup 드라이버 구성
+## cgroup 드라이버 구성
 
-도커를 사용할 때, kubeadm은 kubelet 용 cgroup 드라이버를 자동으로 감지하여
-런타임 중에 `/var/lib/kubelet/config.yaml` 파일에 설정한다.
-
-다른 CRI를 사용하는 경우, 다음과 같이 `cgroupDriver` 값을 `kubeadm init` 에 전달해야 한다.
-
-```yaml
-apiVersion: kubelet.config.k8s.io/v1beta1
-kind: KubeletConfiguration
-cgroupDriver: <value>
-```
-
-자세한 내용은 [구성 파일과 함께 kubeadm init 사용](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file)을 참고한다.
-
-`cgroupfs` 가 이미 kubelet의 기본값이기 때문에, 사용자의
-CRI cgroup 드라이버가 `cgroupfs` 가 아닌 **경우에만** 위와 같이 설정해야 한다.
-
-{{< note >}}
-`--cgroup-driver` 플래그가 kubelet에 의해 사용 중단되었으므로, `/var/lib/kubelet/kubeadm-flags.env`
-또는 `/etc/default/kubelet`(RPM에 대해서는 `/etc/sysconfig/kubelet`)에 있는 경우, 그것을 제거하고 대신 KubeletConfiguration을
-사용한다(기본적으로 `/var/lib/kubelet/config.yaml` 에 저장됨).
-{{< /note >}}
-
-CRI-O 및 containerd와 같은 다른 컨테이너 런타임에 대한 cgroup 드라이버의
-자동 감지에 대한 작업이 진행 중이다.
+컨테이너 런타임과 kubelet은 
+["cgroup 드라이버"](/ko/docs/setup/production-environment/container-runtimes/)라는 속성을 갖고 있으며, 
+cgroup 드라이버는 리눅스 머신의 cgroup 관리 측면에 있어서 중요하다.
 
+{{< warning >}}
+컨테이너 런타임과 kubelet의 cgroup 드라이버를 일치시켜야 하며, 그렇지 않으면 kubelet 프로세스에 오류가 발생한다.
+ 
+더 자세한 사항은 [cgroup 드라이버 설정하기](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)를 참고한다.
+{{< /warning >}}
 
 ## 문제 해결
 
@@ -328,5 +312,4 @@ kubeadm에 문제가 있는 경우, [문제 해결 문서](/docs/setup/productio
 
 ## {{% heading "whatsnext" %}}
 
-
 * [kubeadm을 사용하여 클러스터 생성](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)

content/ko/docs/setup/production-environment/tools/kubeadm/self-hosting.md

@@ -1,65 +0,0 @@
----
-reviewers:
-title: 컨트롤 플레인을 자체 호스팅하기 위해 쿠버네티스 클러스터 구성하기
-content_type: concept
-weight: 100
----
-
-<!-- overview -->
-
-### 쿠버네티스 컨트롤 플레인 자체 호스팅하기 {#self-hosting}
-
-kubeadm은 실험적으로 _자체 호스팅_ 된 쿠버네티스 컨트롤 플레인을 만들 수 있도록
-해준다. API 서버, 컨트롤러 매니저 및 스케줄러와 같은 주요 구성 요소가 정적(static) 파일을
-통해 kubelet에 구성된 [스태틱(static) 파드](/ko/docs/tasks/configure-pod-container/static-pod/)
-대신 쿠버네티스 API를 통해 구성된 [데몬셋(DaemonSet) 파드](/ko/docs/concepts/workloads/controllers/daemonset/)
-로 실행된다.
-
-자체 호스팅된 클러스터를 만들려면 [kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting)
-명령어를 확인한다.
-
-<!-- body -->
-
-#### 주의사항
-
-{{< caution >}}
-이 기능은 클러스터를 지원되지 않는 상태로 전환하여 더 이상 클러스터를 관리할 수 없게 만든다.
-이것은 `kubeadm upgrade`를 포함한다.
-{{< /caution >}}
-
-1. 1.8 이후 버전에서 자체 호스팅은 몇 가지 중요한 한계가 있다.
-  특히 자체 호스팅된 클러스터는 수동 조정 없이는
-  _컨트롤 플레인 노드를 재부팅하고 나서 복구할 수 없다._
-
-1. 기본적으로 자체 호스팅된 컨트롤 플레인 파드는
-  [`hostPath`](/ko/docs/concepts/storage/volumes/#hostpath) 볼륨에서 불러 온
-  자격 증명에 의존한다. 초기 생성을 제외하고, 이러한 자격 증명은 kubeadm에 의해
-  관리되지 않는다.
-
-1. 컨트롤 플레인의 자체 호스팅된 부분에는 스태틱 파드로 실행되는 etcd가
-  포함되지 않는다.
-
-#### 프로세스
-
-자체 호스팅 부트스트랩 프로세스는 [kubeadm 설계
-문서](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting)에 기록되어 있다.
-
-요약하면 `kubeadm alpha selfhosting`은 다음과 같이 작동한다.
-
-  1. 부트스트랩 스태틱 컨트롤 플레인이 실행되고 정상 상태가 될 때까지 기다린다.
-    이것은 자체 호스팅이 없는 `kubeadm init` 프로세스와 동일하다.
-
-  1. 스태틱 컨트롤 플레인 파드 매니페스트를 사용하여 자체 호스팅된 컨트롤
-    플레인을 실행할 데몬셋 매니페스트 집합을 구성한다. 또한 필요한 경우
-    해당 매니페스트를 수정한다. 예를 들어, 시크릿을 위한 새로운 볼륨을
-    추가한다.
-
-  1. `kube-system` 네임스페이스에 데몬셋을 생성하고 결과 파드가 실행될 때까지
-    대기한다.
-
-  1. 일단 자체 호스팅된 파드가 동작하면 관련 스태틱 파드가 삭제되고
-    kubeadm은 계속해서 다음 구성 요소를 설치한다.
-    이것은 kubelet이 스태틱 파드를 멈추게 한다.
-
-  1. 기존의 컨트롤 플레인이 멈추면 새롭게 자체 호스팅된 컨트롤 플레인은
-    리스닝 포트에 바인딩하여 활성화할 수 있다.

content/ko/docs/setup/production-environment/tools/kubespray.md

@@ -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의 기본 설정값을 이용해 클러스터를 배포하고 Kubernetes를 탐색하는 것이 좋다.
 
 ### (4/5) 클러스터 배포하기
 

content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md

@@ -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)의 지침을 따른다.