[ko] Reorg 'Windows in K8s' docs (#35423)

* [ko] Split 'Windows resource mgmt' into new page * [ko] Split 'Windows security' into new page * [ko] Split 'Windows storage' into new page * [ko] Split 'Windows networking' into new page * [ko] Split 'Windows troubleshooting' into new page * [ko] Update 'Windows containers user guide' * [ko] Move 'Intro-Windows-in-K8s' * [ko] Update links for reorg-ed Windows pages * [ko] Reflect review suggestions * [ko] Reflect review suggestions (2)

Author: jihoon-seo

content/ko/docs/concepts/configuration/windows-resource-management.md

@@ -0,0 +1,79 @@
+---
+# reviewers:
+# - jayunit100
+# - jsturtevant
+# - marosset
+# - perithompson
+title: 윈도우 노드의 자원 관리
+content_type: concept
+weight: 75
+---
+
+<!-- overview -->
+
+이 페이지는 리눅스와 윈도우 간에 리소스를 관리하는 방법의 차이점을 간략하게 설명한다.
+
+<!-- body -->
+
+리눅스 노드에서, {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}이 
+리소스 제어를 위한 파드 경계로서 사용된다. 
+컨테이너는 네트워크, 프로세스 및 파일시스템 격리를 위해 해당 경계 내에 생성된다. 
+cpu/io/memory 통계를 수집하기 위해 cgroup API를 사용할 수 있다.
+
+반대로, 윈도우는 시스템 네임스페이스 필터와 함께 
+컨테이너별로 [잡(job) 오브젝트](https://docs.microsoft.com/windows/win32/procthread/job-objects)를 사용하여 
+모든 프로세스를 컨테이너 안에 포함시키고 호스트와의 논리적 격리를 제공한다.
+(잡 오브젝트는 윈도우의 프로세스 격리 메커니즘이며 
+쿠버네티스의 {{< glossary_tooltip term_id="job" text="잡(Job)" >}}과는 다른 것이다.)
+
+네임스페이스 필터링 없이 윈도우 컨테이너를 실행할 수 있는 방법은 없다. 
+이는 곧 시스템 권한은 호스트 입장에서 주장할(assert) 수 없고, 
+이로 인해 특권을 가진(privileged) 컨테이너는 윈도우에서 사용할 수 없음을 의미한다. 
+또한 보안 계정 매니저(Security Account Manager, SAM)가 분리되어 있으므로 
+컨테이너는 호스트의 ID를 가정(assume)할 수 없다.
+
+## 메모리 관리 {#resource-management-memory}
+
+윈도우에는 리눅스에는 있는 메모리 부족 프로세스 킬러가 없다. 
+윈도우는 모든 사용자 모드 메모리 할당을 항상 가상 메모리처럼 처리하며, 페이지파일(pagefile)이 필수이다.
+
+윈도우 노드는 프로세스를 위해 메모리를 오버커밋(overcommit)하지 않는다. 
+이로 인해 윈도우는 메모리 컨디션에 도달하는 방식이 리눅스와 다르며, 
+프로세스는 메모리 부족(OOM, out of memory) 종료를 겪는 대신 디스크에 페이징을 수행한다. 
+메모리가 오버프로비저닝(over-provision)되고 전체 물리 메모리가 고갈되면, 
+페이징으로 인해 성능이 저하될 수 있다.
+
+## CPU 관리 {#resource-management-cpu}
+
+윈도우는 각 프로세스에 할당되는 CPU 시간의 양을 제한할 수는 있지만, 
+CPU 시간의 최소량을 보장하지는 않는다.
+
+윈도우에서, kubelet은 kubelet 프로세스의 
+[스케줄링 우선 순위](https://docs.microsoft.com/windows/win32/procthread/scheduling-priorities)를 설정하기 위한 명령줄 플래그인 
+`--windows-priorityclass`를 지원한다. 
+이 플래그를 사용하면 윈도우 호스트에서 실행되는 kubelet 프로세스가 다른 프로세스보다 더 많은 CPU 시간 슬라이스를 할당받는다. 
+할당 가능한 값 및 각각의 의미에 대한 자세한 정보는 
+[윈도우 프라이어리티 클래스](https://docs.microsoft.com/en-us/windows/win32/procthread/scheduling-priorities#priority-class)에서 확인할 수 있다. 
+실행 중인 파드가 kubelet의 CPU 사이클을 빼앗지 않도록 하려면, 이 플래그를 `ABOVE_NORMAL_PRIORITY_CLASS` 이상으로 설정한다.
+
+## 리소스 예약 {#resource-reservation}
+
+운영 체제, 컨테이너 런타임, 그리고 kubelet과 같은 쿠버네티스 호스트 프로세스가 사용하는 메모리 및 CPU를 고려하기 위해, 
+kubelet 플래그 `--kube-reserved` 및 `--system-reserved`를 사용하여 
+메모리 및 CPU 리소스의 예약이 가능하다 (그리고 필요하다). 
+윈도우에서 이들 값은 노드의 
+[할당 가능(allocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) 리소스의 계산에만 사용된다.
+
+{{< caution >}}
+워크로드를 배포할 때, 컨테이너에 메모리 및 CPU 리소스 제한을 걸자. 
+이 또한 NodeAllocatable에서 차감되며, 클러스터 수준 스케줄러가 각 파드를 어떤 노드에 할당할지 결정하는 데 도움을 준다.
+
+제한을 설정하지 않은 파드를 스케줄링하면 윈도우 노드가 오버프로비전될 수 있으며, 
+극단적인 경우 노드가 비정상 상태(unhealthy)로 될 수도 있다.
+{{< /caution >}}
+
+윈도우에서는, 메모리를 최소 2GB 이상 예약하는 것이 좋다.
+
+얼마나 많은 양의 CPU를 예약할지 결정하기 위해, 
+각 노드의 최대 파드 수를 확인하고 해당 노드의 시스템 서비스의 CPU 사용량을 모니터링한 뒤, 
+워크로드 요구사항을 충족하는 값을 선택한다.

content/ko/docs/concepts/security/windows-security.md

@@ -0,0 +1,55 @@
+---
+# reviewers:
+# - jayunit100
+# - jsturtevant
+# - marosset
+# - perithompson
+title: 윈도우 노드에서의 보안
+content_type: concept
+weight: 40
+---
+
+<!-- overview -->
+
+이 페이지에서는 윈도우 운영 체제에서의 보안 고려 사항 및 추천 사례에 대해 기술한다.
+
+<!-- body -->
+
+## 노드의 시크릿 데이터 보호
+
+윈도우에서, 시크릿에 있던 데이터는 노드의 로컬 스토리지에 
+평문으로 기록된다(리눅스는 tmpfs 또는 인메모리 파일시스템에 기록). 
+클러스터 운영자로서, 다음 2 가지의 추가 사항을 고려해야 한다.
+
+1. 파일 ACL을 사용하여 시크릿의 파일 위치를 보호한다.
+1. [BitLocker](https://docs.microsoft.com/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server)를 사용하여 볼륨 수준의 암호화를 적용한다.
+
+## 컨테이너 사용자
+
+윈도우 파드 또는 컨테이너에 
+[RunAsUsername](/ko/docs/tasks/configure-pod-container/configure-runasusername/)을 설정하여 
+해당 컨테이너 프로세스를 실행할 사용자를 지정할 수 있다. 
+이는 [RunAsUser](/ko/docs/concepts/security/pod-security-policy/#사용자-및-그룹)와 대략적으로 동등하다.
+
+윈도우 컨테이너는 ContainerUser와 ContainerAdministrator의 2 개의 기본 사용자 계정을 제공한다. 
+이 두 사용자 계정이 어떻게 다른지는 마이크로소프트의 _안전한 윈도우 컨테이너_ 문서 내의 
+[언제 ContainerAdmin 및 ContainerUser 사용자 계정을 사용해야 하는가](https://docs.microsoft.com/virtualization/windowscontainers/manage-containers/container-security#when-to-use-containeradmin-and-containeruser-user-accounts)를 참고한다.
+
+컨테이너 빌드 과정에서 컨테이너 이미지에 로컬 사용자를 추가할 수 있다.
+
+{{< note >}}
+
+* [Nano Server](https://hub.docker.com/_/microsoft-windows-nanoserver) 기반 이미지는 기본적으로 `ContainerUser`로 실행된다
+* [Server Core](https://hub.docker.com/_/microsoft-windows-servercore) 기반 이미지는 기본적으로 `ContainerAdministrator`로 실행된다
+
+{{< /note >}}
+
+[그룹 관리 서비스 어카운트](/ko/docs/tasks/configure-pod-container/configure-gmsa/)를 활용하여 윈도우 컨테이너를 Active Directory 사용자로 실행할 수도 있다.
+
+## 파드-수준 보안 격리
+
+리눅스 특유의 파드 보안 컨텍스트 메커니즘(예: SELinux, AppArmor, Seccomp, 
+또는 커스텀 POSIX 기능)은 윈도우 노드에서 지원되지 않는다.
+
+특권을 가진(Privileged) 컨테이너는 윈도우에서 [지원되지 않는다](/ko/docs/concepts/windows/intro/#compatibility-v1-pod-spec-containers-securitycontext). 
+대신, 리눅스에서 권한 있는 컨테이너가 할 수 있는 작업 중 많은 부분을 윈도우에서 수행하기 위해 [HostProcess 컨테이너](/docs/tasks/configure-pod-container/create-hostprocess-pod)를 사용할 수 있다.