Merge pull request #29998 from kubernetes/dev-1.22-ko.1

[ko] 1st Korean localization work for v1.22
2021-10-09 06:54:36 -07:00
parent 1cd35c2a42 14e5fe697f
commit 38be851062
105 changed files with 3053 additions and 648 deletions
@@ -121,3 +121,6 @@ _A_ 영역에 있는 컨트롤 플레인 호스트로만 전달한다. 단일
 [클러스터 오토스케일러](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)는
 여러 클라우드 프로바이더와 통합되어 클러스터의 리소스 요구 수준에 맞는
 노드 수를 실행할 수 있도록 도와준다.
+
+[addon resizer](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer#readme)는 
+클러스터 스케일이 변경될 때 자동으로 애드온 크기를 조정할 수 있도록 도와준다.
@@ -26,7 +26,7 @@ weight: 20
 다른 운영 체제의 경우, 해당 플랫폼과 관련된 문서를 찾아보자.
 {{< /note >}}

-## Cgroup 드라이버
+## cgroup 드라이버

 Control group은 프로세스에 할당된 리소스를 제한하는데 사용된다.

@@ -57,6 +57,38 @@ kubelet을 재시작하는 것은 에러를 해결할 수 없을 것이다.
 교체하거나, 자동화를 사용하여 다시 설치한다.
 {{< /caution >}}

+## cgroup v2
+
+cgroup v2는 cgroup Linux API의 다음 버전이다. 
+cgroup v1과는 다르게 각 컨트롤러마다 다른 계층 대신 단일 계층이 있다.
+
+새 버전은 cgroup v1에 비해 몇 가지 향상된 기능을 제공하며, 개선 사항 중 일부는 다음과 같다.
+
+- API를 더 쉽고 깔끔하게 사용할 수 있음
+- 컨테이너로의 안전한 하위 트리 위임
+- 압력 중지 정보와 같은 새로운 기능
+
+일부 컨트롤러는 cgroup v1에 의해 관리되고 다른 컨트롤러는 cgroup v2에 의해 관리되는 하이브리드 구성을 지원하더라도, 
+쿠버네티스는 모든 컨트롤러를 관리하기 위해 
+동일한 cgroup 버전만 지원한다.
+
+systemd가 기본적으로 cgroup v2를 사용하지 않는 경우, 커널 명령줄에 `systemd.unified_cgroup_hierarchy=1`을 
+추가하여 cgroup v2를 사용하도록 시스템을 구성할 수 있다.
+
+```shell
+# dnf install -y grubby && \
+  sudo grubby \
+  --update-kernel=ALL \
+  --args=”systemd.unified_cgroup_hierarchy=1"
+```
+
+구성을 적용하려면 노드를 재부팅해야 한다.
+
+cgroup v2로 전환할 때 사용자가 노드 또는 컨테이너 내에서 
+cgroup 파일 시스템에 직접 접근하지 않는 한 사용자 경험에 현저한 차이가 없어야 한다.
+
+cgroup v2를 사용하려면 CRI 런타임에서도 cgroup v2를 지원해야 한다.
+
 ### kubeadm으로 생성한 클러스터의 드라이버를 `systemd`로 변경하기

 kubeadm으로 생성한 클러스터의 cgroup 드라이버를 `systemd`로 변경하려면
@@ -1,78 +1,108 @@
 ---
-reviewers:
-title: kubeadm으로 컨트롤 플레인 사용자 정의하기
+
+
+title: kubeadm API로 컴포넌트 사용자 정의하기
 content_type: concept
 weight: 40
 ---

 <!-- overview -->

+이 페이지는 kubeadm이 배포하는 컴포넌트(component)들을 사용자 정의하는 방법을 다룬다. 컨트롤 플레인 컴포넌트에
+대해서는 `ClusterConfiguration` 구조에서 플래그를 사용하거나 노드당 패치를 사용할 수 있다. kubelet과
+kube-proxy의 경우, `KubeletConfiguration`과 `KubeProxyConfiguration`을 각각 사용할 수 있다.
+
+이 모든 옵션이 kubeadm 구성 API를 통해 가용하다.
+구성의 각 필드 상세 사항은
+[API 참조 페이지](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3)에서 찾아볼 수 있다.
+
+{{< note >}}
+kubeadm의 CoreDNS 디플로이먼트 사용자 정의는 현재 제공되지 않는다.
+`kube-system/coredns` {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}을 수동으로
+패치하고, 그 이후에 CoreDNS {{< glossary_tooltip text="파드" term_id="pod" >}}를 다시 생성해야 한다. 또는,
+기본 CoreDNS 디플로이먼트를 생략하고 자체 변형(variant)을 배포할 수 있다.
+더 자세한 사항은 [kubeadm에서 초기화 단계 사용하기](/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-phases)을 참고한다.
+{{< /note >}}
+
+<!-- body -->
+
 {{< feature-state for_k8s_version="v1.12" state="stable" >}}

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

 - `apiServer`
 - `controllerManager`
 - `scheduler`
+- `etcd`

-`extraArgs` 필드는 `key: value` 쌍으로 구성되어 있다. 컨트롤 플레인 구성요소를 위한 플래그를 대체하려면 다음을 수행한다.
+이 구조체들은 공통 필드인 `extraArgs`를 포함하며, 이 필드는 `키: 값` 쌍으로 구성된다.
+컨트롤 플레인 컴포넌트를 위한 플래그를 덮어쓰려면 다음을 수행한다.

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

-각 필드의 구성에서 자세한 정보를 보려면,
-[API 참고 문서](/docs/reference/config-api/kubeadm-config.v1beta2/)에서 확인해 볼 수 있다.
-
 {{< note >}}
-`kubeadm config print init-defaults`를 실행하고 원하는 파일에 출력을 저장하여 기본값인 `ClusterConfiguration` 오브젝트를 생성할 수 있다.
+`kubeadm config print init-defaults`를 실행하고 원하는 파일에 출력을
+저장하여 기본값들로 구성된 `ClusterConfiguration` 오브젝트를 생성할 수 있다.
 {{< /note >}}

+{{< note >}}
+`ClusterConfiguration` 오브젝트는 현재 kubeadm 클러스터에서 전역(global)으로 사용된다. 즉, 사용자가 추가하는 모든 플래그는
+다른 노드에 있는 동일한 컴포넌트에도 모두 적용될 것이다. 다른 노드에서
+컴포넌트별로 개별 구성을 적용하려면 [패치](#patches)를 사용하면 된다.
+{{< /note >}}

+{{< note >}}
+플래그(키)를 복제하거나 동일한 플래그 `--foo`를 여러 번 전달하는 것은 현재 지원하지 않는다.
+이 문제를 해결하려면 [패치](#patches)를 사용해야 한다.
+{{< /note >}}

-<!-- body -->
-
-## APIServer 플래그
+### APIServer 플래그

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

-예시:
+사용 예시:
+
 ```yaml
-apiVersion: kubeadm.k8s.io/v1beta2
+apiVersion: kubeadm.k8s.io/v1beta3
 kind: ClusterConfiguration
 kubernetesVersion: v1.16.0
 apiServer:
  extraArgs:
-    advertise-address: 192.168.0.103
    anonymous-auth: "false"
    enable-admission-plugins: AlwaysPullImages,DefaultStorageClass
    audit-log-path: /home/johndoe/audit.log
 ```

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

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

-예시:
+사용 예시:
+
 ```yaml
-apiVersion: kubeadm.k8s.io/v1beta2
+apiVersion: kubeadm.k8s.io/v1beta3
 kind: ClusterConfiguration
 kubernetesVersion: v1.16.0
 controllerManager:
  extraArgs:
    cluster-signing-key-file: /home/johndoe/keys/ca.key
-    bind-address: 0.0.0.0
    deployment-controller-sync-period: "50"
 ```

-## 스케줄러 플래그
+### 스케줄러 플래그

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

-예시:
+사용 예시:
+
 ```yaml
-apiVersion: kubeadm.k8s.io/v1beta2
+apiVersion: kubeadm.k8s.io/v1beta3
 kind: ClusterConfiguration
 kubernetesVersion: v1.16.0
 scheduler:
@@ -85,3 +115,96 @@ scheduler:
      readOnly: true
      pathType: "File"
 ```
+
+### Etcd 플래그
+
+자세한 사항은 [etcd 서버 문서](https://etcd.io/docs/)를 확인한다.
+
+사용 예시:
+
+```yaml
+apiVersion: kubeadm.k8s.io/v1beta3
+kind: ClusterConfiguration
+etcd:
+  local:
+    extraArgs:
+      election-timeout: 1000
+```
+
+## 패치를 통해 컨트롤 플레인 사용자 정의하기 {#patches}
+
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
+
+Kubeadm을 사용하면 패치 파일이 있는 디렉토리를 개별 노드에 대한 `InitConfiguration`과 `JoinConfiguration`에
+전달할 수 있다. 이 패치는 컨트롤 플레인 컴포넌트 메니패스트가 디스크에 기록되기 전에
+최종 사용자 정의 단계로 사용될 수 있다.
+
+`--config <YOUR CONFIG YAML>`을 사용하여 이 파일을 `kubeadm init`에 전달할 수 있다.
+
+```yaml
+apiVersion: kubeadm.k8s.io/v1beta3
+kind: InitConfiguration
+nodeRegistration:
+  patches:
+    directory: /home/user/somedir
+```
+
+{{< note >}}
+`kubeadm init`의 경우, `---`로 구분된 `ClusterConfiguration`과 `InitConfiguration`을 모두
+포함하는 파일을 전달할 수 있다.
+{{< /note >}}
+
+`--config <YOUR CONFIG YAML>`을 사용하여 이 파일을 `kubeadm join`에 전달할 수 있다.
+
+```yaml
+apiVersion: kubeadm.k8s.io/v1beta3
+kind: JoinConfiguration
+nodeRegistration:
+  patches:
+    directory: /home/user/somedir
+```
+
+디렉토리는 `target[suffix][+patchtype].extension` 형태의 파일을 포함해야 한다.
+예를 들면, `kube-apiserver0+merge.yaml` 또는 단순히 `etcd.json`의 형태이다.
+
+- `target`은 `kube-apiserver`, `kube-controller-manager`, `kube-scheduler` 그리고 `etcd` 중 하나가 될 수 있다.
+- `patchtype`은 `strategic`, `merge` 그리고 `json` 중 하나가 될 수 있으며
+[kubectl에서 지원하는](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch) 패치 형식을 준수해야 한다.
+`patchtype`의 기본값은 `strategic`이다.
+- `extension`은 `json` 또는 `yaml` 중 하나여야 한다.
+- `suffix`는 어떤 패치가 먼저 적용되는지를 결정하는 데 사용할 수 있는 영숫자 형태의
+선택적 문자열이다.
+
+{{< note >}}
+`kubeadm upgrade`를 사용하여 kubeadm 노드를 업그레이드하는 경우, 업그레이드 이후에도
+사용자 정의를 유지하려면 동일한 패치를 다시 제공해야 한다. 이는 동일한 디렉토리로 지정된 `--patches`
+플래그를 사용하여 처리할 수 있다. `kubeadm upgrade`는 동일 목적으로 재사용할 수 있는 구성
+API 구조를 현재는 지원하지 않는다.
+{{< /note >}}
+
+## kubelet 사용자 정의하기
+
+kubelet을 사용자 정의하려면, `KubeletConfiguration`을 동일한 구성 파일 내에서 `---`로 구분된 `ClusterConfiguration`이나 `InitConfiguration` 다음에 추가하면
+된다. 그런 다음 `kubeadm init`에 해당 파일을 전달한다.
+
+{{< note >}}
+kubeadm은 클러스터의 모든 노드에 동일한 `KubeletConfiguration`을 적용한다. 노드별 설정을
+적용하려면 kubelet 플래그를 덮어쓰기(overrides)로 사용하여, `InitConfiguration` 및
+`JoinConfiguration` 모두에서 지원되는 `nodeRegistration.kubeletExtraArgs`에 전달할 수 있다.
+일부 kubelet 플래그는 더 이상 사용되지 않는다(deprecated). 따라서 사용하기 전에 [kubelet 참조 문서](/docs/reference/command-line-tools-reference/kubelet)를 통해
+상태를 확인해야 한다.
+{{< /note >}}
+
+자세한 사항은 [kubeadm을 통해 클러스터의 각 kubelet 구성하기](/docs/setup/production-environment/tools/kubeadm/kubelet-integration)에서 살펴본다.
+
+## kube-proxy 사용자 정의하기
+
+kube-proxy를 사용자 정의하려면, `KubeProxyConfiguration`을 `---`로 구분된 `ClusterConfiguration`이나 `InitConfiguration`
+다음에 두고 `kubeadm init`에 전달하면 된다.
+
+자세한 사항은 [API 참조 페이지](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3)에서 살펴볼 수 있다.
+
+{{< note >}}
+kubeadm은 kube-proxy를 {{< glossary_tooltip text="데몬셋" term_id="daemonset" >}}으로 배포한다. 이것은
+`KubeProxyConfiguration`이 클러스터의 모든 kube-proxy 인스턴스에 적용된다는 것을 의미한다.
+{{< /note >}}
@@ -239,8 +239,9 @@ CNI 플러그인 설치(대부분의 파드 네트워크에 필요)

 ```bash
 CNI_VERSION="v0.8.2"
+ARCH="amd64"
 sudo mkdir -p /opt/cni/bin
-curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-amd64-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz
+curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-${ARCH}-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz
 ```

 명령어 파일을 다운로드할 디렉터리 정의
@@ -259,15 +260,17 @@ crictl 설치(kubeadm / Kubelet 컨테이너 런타임 인터페이스(CRI)에

 ```bash
 CRICTL_VERSION="v1.17.0"
-curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz
+ARCH="amd64"
+curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz
 ```

 `kubeadm`, `kubelet`, `kubectl` 설치 및 `kubelet` systemd 서비스 추가

 ```bash
 RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)"
+ARCH="amd64"
 cd $DOWNLOAD_DIR
-sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl}
+sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet,kubectl}
 sudo chmod +x {kubeadm,kubelet,kubectl}

 RELEASE_VERSION="v0.4.0"
@@ -67,10 +67,9 @@ weight: 65

 | 쿠버네티스 버전 | 윈도우 서버 LTSC 릴리스 | 윈도우 서버 SAC 릴리스 |
 | --- | --- | --- | --- |
-| *Kubernetes v1.19* | Windows Server 2019 | Windows Server ver 1909, Windows Server ver 2004 |
 | *Kubernetes v1.20* | Windows Server 2019 | Windows Server ver 1909, Windows Server ver 2004 |
 | *Kubernetes v1.21* | Windows Server 2019 | Windows Server ver 2004, Windows Server ver 20H2 |
-
+| *Kubernetes v1.22* | Windows Server 2019 | Windows Server ver 2004, Windows Server ver 20H2 |

 지원 모델을 포함한 다양한 윈도우 서버
 서비스 채널에 대한 정보는
@@ -98,12 +97,16 @@ weight: 65
 일단 쿠버네티스에서 Hyper-V 격리가 포함된 윈도우 컨테이너를 지원하면,
 제한 및 호환성 규칙이 변경될 것이다.

-#### 퍼즈(Pause) 이미지
+#### 퍼즈(Pause) 이미지 {#pause-image}

-Microsoft는 `mcr.microsoft.com/oss/kubernetes/pause:3.4.1`에서
-윈도우 퍼즈 인프라 컨테이너를 유지한다.
-이외에도 `k8s.gcr.io/pause:3.5`를 통해 쿠버네티스에서 관리하는 다중 아키텍처 이미지를
-사용할 수도 있는데, 이 이미지는 리눅스와 윈도우를 모두 지원한다.
+쿠버네티스는 윈도우 지원을 포함하는 다중 아키텍처 이미지를 유지보수한다.
+쿠버네티스 v1.22의 경우 권장 퍼즈 이미지는 `k8s.gcr.io/pause:3.5`이다.
+[소스 코드](https://github.com/kubernetes/kubernetes/tree/master/build/pause)는 
+GitHub에서 찾을 수 있다.
+
+Microsoft는 리눅스, 윈도우 amd64를 지원하는 다중 아키텍처 이미지를 `mcr.microsoft.com/oss/kubernetes/pause:3.5`에서 유지보수하고 있다.
+이 이미지는 쿠버네티스가 유지 관리하는 이미지와 동일한 소스코드에서 생성되었지만, 모든 윈도우 바이너리는 Microsoft에 의해 서명된 [인증 코드](https://docs.microsoft.com/en-us/windows-hardware/drivers/install/authenticode)이다.
+프로덕션 환경에서 서명된 바이너리가 필요한 경우, Microsoft가 유지 관리하는 이미지를 사용하는 것을 권장한다.

 #### 컴퓨트

@@ -237,7 +240,7 @@ powershell 스크립트로 배포된 다음의 FlexVolume

 ##### CSI 플러그인

-{{< feature-state for_k8s_version="v1.19" state="beta" >}}
+{{< feature-state for_k8s_version="v1.22" state="stable" >}}

 {{< glossary_tooltip text="CSI" term_id="csi" >}} 플러그인과
 관련된 코드는 일반적으로 컨테이너 이미지로 배포되고 데몬셋(DaemonSets)
@@ -246,9 +249,7 @@ powershell 스크립트로 배포된 다음의 FlexVolume
 바이너리로 제공된다. CSI 플러그인은 쿠버네티스에서 볼륨 프로비저닝/디-프로비저닝, 볼륨
 크기 조정, 쿠버네티스 노드에 볼륨 연결/분리, 파드의 개별 컨테이너에 볼륨
 마운트/분리, 스냅샷 및 복제를 사용하여 퍼시스턴트 데이터 백업/복원과 같은
-다양한 볼륨 관리 작업을 처리한다. CSI 플러그인은
-일반적으로 (각 노드에서 데몬셋으로 실행되는) 노드 플러그인과 컨트롤러
-플러그인으로 구성된다.
+다양한 볼륨 관리 작업을 처리한다.

 CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템으로 노출된
 퍼시스턴트 볼륨과 관련된 플러그인)은 디스크 장치 스캔, 파일 시스템 마운트 등과 같은
@@ -262,6 +263,13 @@ CSI 노드 플러그인에 대한 특권이 필요한 작업은 커뮤니티에
 내용은 배포하려는 CSI 플러그인의 배포 가이드를
 참조한다.

+윈도우 노드에서 CSI 노드 플러그인은 일반적으로 로컬 스토리지 작업을 처리하는 
+커뮤니티에서 관리하는 [csi-proxy](https://github.com/kubernetes-csi/csi-proxy)에 의해 노출된 API를 호출한다.
+
+설치에 대한 자세한 내용은 윈도우 CSI 플러그인을 
+배포할 환경의 배포 가이드를 참고한다.
+또한 다음 [설치 단계](https://github.com/kubernetes-csi/csi-proxy#installation)를 참고할 수도 있다.
+
 #### 네트워킹

 윈도우 컨테이너용 네트워킹은
@@ -1068,9 +1076,8 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를
    kubelet.exe를 등록한다.

    ```powershell
-    # Microsoft는 mcr.microsoft.com/oss/kubernetes/pause:1.4.1에서 pause 인프라 컨테이너를 릴리스했다.
    nssm install kubelet C:\k\kubelet.exe
-    nssm set kubelet AppParameters --hostname-override=<hostname> --v=6 --pod-infra-container-image=mcr.microsoft.com/oss/kubernetes/pause:1.4.1 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns=<DNS-service-IP> --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false  --log-dir=<log directory> --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config
+    nssm set kubelet AppParameters --hostname-override=<hostname> --v=6 --pod-infra-container-image=k8s.gcr.io/pause:3.5 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns=<DNS-service-IP> --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false  --log-dir=<log directory> --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config
    nssm set kubelet AppDirectory C:\k
    nssm start kubelet
    ```
@@ -1224,13 +1231,13 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를

 * 내 파드가 "Container Creating"에서 멈췄거나 계속해서 다시 시작된다.

-  pause 이미지가 OS 버전과 호환되는지 확인한다.
+  퍼즈 이미지가 OS 버전과 호환되는지 확인한다.
  [지침](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources)에서는
  OS와 컨테이너가 모두 버전 1803이라고 가정한다. 이후 버전의
  윈도우가 있는 경우, Insider 빌드와 같이 그에 따라 이미지를
  조정해야 한다. 이미지는 Microsoft의
  [도커 리포지터리](https://hub.docker.com/u/microsoft/)를 참조한다.
-  그럼에도 불구하고, pause 이미지 Dockerfile과 샘플 서비스는 이미지가
+  그럼에도 불구하고, 퍼즈 이미지 Dockerfile과 샘플 서비스는 이미지가
  :latest로 태그될 것으로 예상한다.

 * DNS 확인(resolution)이 제대로 작동하지 않는다.
@@ -1239,12 +1246,18 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를

 * `kubectl port-forward`가 "unable to do port forwarding: wincat not found"로 실패한다.

-  이는 쿠버네티스 1.15 및 pause 인프라 컨테이너
+  이는 쿠버네티스 1.15 및 퍼즈 인프라 컨테이너
  `mcr.microsoft.com/oss/kubernetes/pause:1.4.1`에서 구현되었다.
-  해당 버전 또는 최신 버전을 사용해야 한다. 자체 pause
+  해당 버전 또는 최신 버전을 사용해야 한다. 자체 퍼즈
  인프라 컨테이너를 빌드하려면
  [wincat](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)을 포함해야 한다.

+  윈도우에서 포트 포워딩을 지원하려면 [퍼즈 인프라 컨테이너](#pause-image)를 이용하기 위해서 
+  wincat.exe가 필요하다. 
+  윈도우 OS 버전과 호환되는 지원되는 이미지를 사용하고 있는지 확인해야 한다.
+  자신만의 퍼즈 인프라 컨테이너를 구축하려면 
+  [wincat](https://github.com/kubernetes/kubernetes/tree/master/build/pause/windows/wincat)을 포함해야 한다.
+
 * 내 윈도우 서버 노드가 프록시 뒤에 있기 때문에 내 쿠버네티스
  설치가 실패한다.

@@ -1256,20 +1269,18 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를
  [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine)
  ```

-* `pause` 컨테이너란 무엇인가?
+* 퍼즈(`pause`) 컨테이너란 무엇인가?

  쿠버네티스 파드에서는 컨테이너 엔드포인트를 호스팅하기 위해
-  먼저 인프라 또는 "pause" 컨테이너가 생성된다. 인프라 및 워커 컨테이너를 포함하여
+  먼저 인프라 또는 "퍼즈" 컨테이너가 생성된다. 인프라 및 워커 컨테이너를 포함하여
  동일한 파드에 속하는 컨테이너는 공통 네트워크 네임스페이스 및
  엔드포인트(동일한 IP 및 포트 공간)를 공유한다. 네트워크 구성을 잃지 않고
-  워커 컨테이너가 충돌하거나 다시 시작되도록 하려면 pause 컨테이너가
+  워커 컨테이너가 충돌하거나 다시 시작되도록 하려면 퍼즈 컨테이너가
  필요하다.

-  "pause" (인프라) 이미지는 Microsoft Container Registry(MCR)에서
-  호스팅된다. `mcr.microsoft.com/oss/kubernetes/pause:1.4.1`을 사용하여 접근할 수 있다.
-  자세한 내용은
-  [DOCKERFILE](https://github.com/kubernetes-sigs/windows-testing/blob/master/images/pause/Dockerfile)을 참고한다.
-
+  퍼즈 이미지 추천 버전을 찾기 위해서는 
+  [퍼즈 이미지](#pause-image)를 참고한다.
+  
 ### 추가 조사

 이러한 단계로 문제가 해결되지 않으면, 다음을 통해 쿠버네티스의 윈도우 노드에서
@@ -20,8 +20,8 @@ weight: 75

 ## 시작하기 전에

-* [윈도우 서버에서 운영하는 마스터와 워커 노드](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)를
-포함한 쿠버네티스 클러스터를 생성한다.
+* 컨트롤 플레인과 [윈도우 서버로 운영되는 워커 노드](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)를
+포함하는 쿠버네티스 클러스터를 생성한다.
 * 쿠버네티스에서 서비스와 워크로드를 생성하고 배포하는 것은 리눅스나 윈도우 컨테이너
 모두 비슷한 방식이라는 것이 중요하다.
 [Kubectl 커맨드](/ko/docs/reference/kubectl/overview/)로 클러스터에 접속하는 것은 동일하다.
@@ -100,15 +100,15 @@ spec:
 1. 이 디플로이먼트가 성공적인지 확인한다. 다음을 검토하자.

    * 윈도우 노드에 파드당 두 컨테이너가 존재하는지 확인하려면, `docker ps`를 사용한다.
-    * 리눅스 마스터에서 나열된 두 파드가 존재하는지 확인하려면, `kubectl get pods`를 사용한다.
-    * 네트워크를 통한 노드에서 파드로의 통신이 되는지 확인하려면, 리눅스 마스터에서 `curl`을
+    * 리눅스 컨트롤 플레인 노드에서 나열된 두 파드가 존재하는지 확인하려면, `kubectl get pods`를 사용한다.
+    * 네트워크를 통한 노드에서 파드로의 통신이 되는지 확인하려면, 리눅스 컨트롤 플레인 노드에서 `curl`을
      파드 IP 주소의 80 포트로 실행하여 웹 서버 응답을 확인한다.
    * 파드 간 통신이 되는지 확인하려면, `docker exec` 나 `kubectl exec`를 이용해 파드 간에
      핑(ping)한다(윈도우 노드가 2대 이상이라면, 서로 다른 노드에 있는 파드 간 통신도 확인할 수 있다).
-    * 서비스에서 파드로의 통신이 되는지 확인하려면, 리눅스 마스터와 독립 파드에서 `curl`을 가상 서비스
+    * 서비스에서 파드로의 통신이 되는지 확인하려면, 리눅스 컨트롤 플레인 노드와 독립 파드에서 `curl`을 가상 서비스
      IP 주소(`kubectl get services`로 볼 수 있는)로 실행한다.
    * 서비스 검색(discovery)이 되는지 확인하려면, 쿠버네티스 [기본 DNS 접미사](/ko/docs/concepts/services-networking/dns-pod-service/#서비스)와 서비스 이름으로 `curl`을 실행한다.
-    * 인바운드 연결이 되는지 확인하려면, 클러스터 외부 장비나 리눅스 마스터에서 NodePort로 `curl`을 실행한다.
+    * 인바운드 연결이 되는지 확인하려면, 클러스터 외부 장비나 리눅스 컨트롤 플레인 노드에서 NodePort로 `curl`을 실행한다.
    * 아웃바운드 연결이 되는지 확인하려면, `kubectl exec`를 이용해서 파드에서 외부 IP 주소로 `curl`을 실행한다.

 {{< note >}}
@@ -178,8 +178,8 @@ GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동
 예를 들면,  `--register-with-taints='os=windows:NoSchedule'`

 모든 윈도우 노드에 테인트를 추가하여 아무 것도 거기에 스케줄링하지 않게 될 것이다(존재하는 리눅스 파드를 포함하여).
-윈도우 파드가 윈도우 노드에 스케줄링되려면,
-윈도우를 선택하기 위한 노드 셀렉터 및 적합하게 일치하는 톨러레이션이 모두 필요하다.
+윈도우 파드가 윈도우 노드에 스케줄링되도록 하려면,
+윈도우 노드가 선택되도록 하기 위한 노드 셀렉터 및 적합하게 일치하는 톨러레이션이 모두 필요하다.

 ```yaml
 nodeSelector: