[ko] Update outdated files in dev-1.23-ko.1 M62-70

2021-12-20 16:02:29 +09:00
parent 0a2da8cb46
commit fdde76a4ce
7 changed files with 38 additions and 117 deletions
@@ -79,7 +79,7 @@ systemd가 기본적으로 cgroup v2를 사용하지 않는 경우, 커널 명
 # dnf install -y grubby && \
  sudo grubby \
  --update-kernel=ALL \
-  --args=”systemd.unified_cgroup_hierarchy=1"
+  --args="systemd.unified_cgroup_hierarchy=1"
 ```

 구성을 적용하려면 노드를 재부팅해야 한다.
@@ -243,7 +243,7 @@ sudo mkdir -p $DOWNLOAD_DIR
 crictl 설치(kubeadm / Kubelet 컨테이너 런타임 인터페이스(CRI)에 필요)

 ```bash
-CRICTL_VERSION="v1.17.0"
+CRICTL_VERSION="v1.22.0"
 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
 ```
@@ -38,8 +38,8 @@ Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](h
 * 타겟 서버들은 docker 이미지를 풀(pull) 하기 위해 반드시 인터넷에 접속할 수 있어야 한다. 아니라면, 추가적인 설정을 해야 한다 ([오프라인 환경 확인하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md))
 * 타겟 서버들의 **IPv4 포워딩**이 활성화되어야 한다
 * **SSH 키**가 인벤토리의 모든 서버들에 복사되어야 한다
-* **방화벽은 관리되지 않는다**. 사용자가 예전 방식대로 고유한 규칙을 구현해야 한다. 디플로이먼트 과정에서의 문제를 방지하려면 방화벽을 비활성화해야 한다
-* 만약 kubespray가 루트가 아닌 사용자 계정에서 실행되었다면, 타겟 서버에서 알맞은 권한 확대 방법이 설정되어야 한다. 그 뒤 `ansible_become` 플래그나 커맨드 파라미터들, `--become` 또는 `-b` 가 명시되어야 한다
+* **방화벽은 kubespray에 의해 관리되지 않는다**. 사용자는 필요에 따라 적절한 규칙을 구현해야 한다. 디플로이먼트 과정에서의 문제를 방지하려면 방화벽을 비활성화해야 한다
+* 만약 kubespray가 루트가 아닌 사용자 계정에서 실행되었다면, 타겟 서버에서 알맞은 권한 확대 방법이 설정되어야 하며, `ansible_become` 플래그나 커맨드 파라미터들, `--become` 또는 `-b` 가 명시되어야 한다

 Kubespray는 환경에 맞는 프로비저닝을 돕기 위해 아래와 같은 서비스를 제공한다:

@@ -1,4 +1,9 @@
 ---
+
+
+
+
+
 title: 쿠버네티스에서 윈도우 컨테이너 스케줄링을 위한 가이드
 content_type: concept
 weight: 75
@@ -155,7 +160,21 @@ GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동
 노드셀렉터(nodeSelector)의 조합을 이용해야 한다.
 이것은 윈도우 사용자에게만 부담을 줄 것으로 보인다. 아래는 권장되는 방식의 개요인데,
 이것의 주요 목표 중에 하나는 이 방식이 기존 리눅스 워크로드와 호환되어야 한다는 것이다.
+ {{< note >}}
+`IdentifyPodOS` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있으면, 
+파드의 컨테이너가 어떤 운영 체제용인지를 파드의 `.spec.os.name`에 설정할 수 있다(그리고 설정해야 한다). 
+리눅스 컨테이너를 실행하는 파드에는 `.spec.os.name`을 `linux`로 설정한다. 
+윈도우 컨테이너를 실행하는 파드에는 `.spec.os.name`을 
+`windows`로 설정한다.

+스케줄러는 파드를 노드에 할당할 때 `.spec.os.name` 필드의 값을 사용하지 않는다. 
+컨트롤 플레인이 파드를 적절한 운영 체제가 실행되고 있는 노드에 배치하도록 하려면, 
+[파드를 노드에 할당](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)하는 
+일반적인 쿠버네티스 메카니즘을 사용해야 한다. 
+`.spec.os.name` 필드는 윈도우 파드의 스케줄링에는 영향을 미치지 않기 때문에, 
+윈도우 파드가 적절한 윈도우 노드에 할당되도록 하려면 테인트, 
+톨러레이션 및 노드 셀렉터가 여전히 필요하다.
+ {{< /note >}}
 ### 특정 OS 워크로드를 적절한 컨테이너 호스트에서 처리하도록 보장하기

 사용자는 테인트와 톨러레이션을 이용하여 윈도우 컨테이너가 적절한 호스트에서 스케줄링되기를 보장할 수 있다.