Merge pull request #436 from Simyung/master

Windows kr docs added

content/windows/docs/networking.ko.md

@@ -0,0 +1,83 @@
+# 윈도우 네트워크
+
+## 윈도우 컨테이너 네트워크 개요
+윈도우 컨테이너는 리눅스 컨테이너와 근본적으로 다릅니다. 리눅스 컨테이너는 네임스페이스, 유니온 파일 시스템 그리고 cgroup 등의 구성 요소로 이루어져 있습니다. 윈도우에서는 이런 구성 요소를 [Host Compute Service (HCS)](https://github.com/microsoft/hcsshim)에 의해 도코에서 추상화 됩니다. HCS는 윈도우에서 컨테이너 구현을 위한 API 레이어 역할을 합니다. 또한 윈도우 컨테이너는 노드에서 네트워크 토폴로지를 정의하는데 Host Network Service(HNS)를 활용합니다.
+
+![](./images/windows-networking.png)
+
+네트워킹 관점에서 보면 HCS와 HNS는 윈도우 컨테이너가 가상 머신처럼 작동하게 만듭니다. 예를 들어, 위 다이어그램에 표시된 것 처럼 각 컨테이너에는 Hyper-V virtual switch(vSwitch)에 연결된 가상 네트워크 어댑터(vNIC)가 있습니다.
+
+## IP 주소 관리
+Amazon EKS의 노드는 Elastic Network Interface(ENI)를 사용하여 AWS VPC 네트워크에 연결합니다. 현재, **윈도우 워커 노드당 단일 ENI만 지원 됩니다**. 윈도우 노드의 IP 주소 관리는 컨트롤 플레인에서 실행되는 [VPC Resource Controller](https://github.com/aws/amazon-vpc-resource-controller-k8s)에서 수행됩니다. 윈도우 노드의 IP 주소 관리 워크플로에 대한 자세한 내용은 [여기](https://github.com/aws/amazon-vpc-resource-controller-k8s#windows-ipv4-address-management)에서 확인할 수 있습니다.
+
+윈도우 워커 노드가 지원할 수 있는 파드 수는 노드의 크기와 사용 가능한 IPv4 개수에 따라 달라집니다. 노드에서 사용 가능한 IPv4 개수는 아래와 같이 계산할 수 있습니다:
+- 기본적으로 ENI에는 보조(Secondary) IPv4 주소만 할당 됩니다. 다음과 같은 경우 -
+  ```
+  파드에 사용 가능한 총 IPv4 개수 = 인터페이스당 지원되는 IPv4 개수 - 1
+  ```
+  하나의 IPv4 주소가 ENI의 primary 주소로 사용되므로 파드에 할당할 수 없으므로 총 개수에서 1을 뺍니다.
+- 만약 [prefix delegation feature](../../networking/prefix-mode/index_windows.md)을 활성화하여 파드의 밀집도를 높이도록 구성된 경우에는 -
+  ```
+  파드에 사용 가능한 총 IPv4 개수 = (인터페이스당 지원되는 IPv4 개수 - 1) * 16
+  ```
+  VPC Resource Controller는 보조 IPv4 주소를 할당하는 대신 `/28 prefixes`를 할당하므로 사용 가능한 전체 IPv4 개수가 16배 증가합니다.
+
+위 공식을 사용하면 아래와 같이 m5.large 인스턴스의 최대 파드 수를 계산할 수 있습니다-
+- 기본적으로 보조 IP 모드에서 실행하는 경우 -
+  ```
+  인터페이스당 10개 보조 IPv4 개수 - 1 = 9개 사용 가능한 IPv4 개수
+  ```
+- `prefix delegation`를 사용하는 경우 -
+  ```
+  (인터페이스당 10개 보조 IPv4 개수 - 1) * 16 = 144개 사용 가능한 IPv4 개수
+  ```
+
+인스턴스 유형에 따른 사용 가능한 IP 개수에 대한 자세한 내용은 [IP addresses per network interface per instance type](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI)를 참조 바랍니다.
+
+---
+
+또 다른 주요 고려 사항은 네트워크 트래픽의 흐름입니다. 윈도우를 사용하면 100개가 넘는 서비스가 있는 노드에서 포트가 고갈 될 위험이 있습니다. 이 상태가 발생하면 노드에서 다음 메시지와 함께 오류가 발생하기 시작합니다:
+
+**"Policy creation failed: hcnCreateLoadBalancer failed in Win32: The specified port already exists."**
+
+이 문제를 해결하기 위해 Direct Server Return(DSR)을 활용합니다. DSR은 비대칭 네트워크 부하 분산을 구현한 것입니다. 즉, 요청 트래픽과 응답 트래픽은 서로 다른 네트워크 경로를 사용합니다. 이 기능은 Pod 간의 통신 속도를 높이고 포트 고갈 위험을 줄입니다. 따라서 윈도우 노드에서 DSR을 활성화 하는 것이 좋습니다.
+
+ DSR은 Windows Server SAC EKS Optimized AMIs에서 기본적으로 활성화 됩니다. Windows Server 2019 LTSC EKS Optimized AMI의 경우, 아래 스크립트를 사용하고 `eksctl` 노드그룹의 amiFamily로 Windows Server 2019 Full 또는 Core를 사용하여 인스턴스 프로비저닝 중에 이를 활성화해야 합니다. 자세한 내용은 [eksctl custom AMI](https://eksctl.io/usage/custom-ami-support/)를 참조 바랍니다.
+
+```yaml
+nodeGroups:
+- name: windows-ng
+  instanceType: c5.xlarge
+  minSize: 1
+  volumeSize: 50
+  amiFamily: WindowsServer2019CoreContainer
+  ssh:
+    allow: false
+```
+윈도우 서버 2019 이상에서 DSR을 활용하려면 인스턴스 시작 시 다음과 같은 [**kube-proxy**](https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#load-balancing-and-services) 플래그를 지정해야 합니다. [자체 관리형 노드 그룹 시작 템플릿](https://docs.aws.amazon.com/eks/latest/userguide/launch-windows-workers.html)과 관련된 사용자 데이터 스크립트를 조정하여 이 작업을 수행할 수 있습니다.
+
+```powershell
+<powershell>
+[string]$EKSBinDir = "$env:ProgramFiles\Amazon\EKS"
+[string]$EKSBootstrapScriptName = 'Start-EKSBootstrap.ps1'
+[string]$EKSBootstrapScriptFile = "$EKSBinDir\$EKSBootstrapScriptName"
+(Get-Content $EKSBootstrapScriptFile).replace('"--proxy-mode=kernelspace",', '"--proxy-mode=kernelspace", "--feature-gates WinDSR=true", "--enable-dsr",') | Set-Content $EKSBootstrapScriptFile 
+& $EKSBootstrapScriptFile -EKSClusterName "eks-windows" -APIServerEndpoint "https://<REPLACE-EKS-CLUSTER-CONFIG-API-SERVER>" -Base64ClusterCA "<REPLACE-EKSCLUSTER-CONFIG-DETAILS-CA>" -DNSClusterIP "172.20.0.10" -KubeletExtraArgs "--node-labels=alpha.eksctl.io/cluster-name=eks-windows,alpha.eksctl.io/nodegroup-name=windows-ng-ltsc2019 --register-with-taints=" 3>&1 4>&1 5>&1 6>&1
+</powershell>
+```
+
+DSR 활성화 절차에 대한 자세한 내용은 [Microsoft 네트워크 블로그](https://techcommunity.microsoft.com/t5/networking-blog/direct-server-return-dsr-in-a-nutshell/ba-p/693710) 및 [AWS 윈도우 컨테이너 워크샵](https://catalog.us-east-1.prod.workshops.aws/workshops/1de8014a-d598-4cb5-a119-801576492564/en-US/module1-eks/lab3-handling-mixed-clusters)에서 확인할 수 있습니다.
+
+![](./images/dsr.png)
+
+이전 버전의 윈도우를 사용하면 DSR을 지원하지 않으므로 포트가 고갈될 위험이 높아집니다.
+
+## Container Network Interface (CNI) 옵션
+AWS VPC CNI는 윈도우 및 리눅스 워커 노드를 위한 사실상 표준(de facto)의 CNI 플러그인입니다. AWS VPC CNI는 많은 고객의 요구를 충족하지만, IP 주소 고갈을 방지하기 위해 오버레이 네트워크와 같은 대안을 고려해야 하는 경우가 있을 수 있습니다. 이런 경우 AWS VPC CNI 대신 Calico CNI를 사용할 수 있습니다. [Project Calico](https://www.projectcalico.org/)는 [Tigera](https://www.tigera.io/)에서 개발한 오픈 소스 소프트웨어로, EKS와 함께 작동하는 CNI를 포함하고 있습니다. EKS에 Calico CNI를 설치하는 방법은 [Project Calico EKS 설치](https://docs.projectcalico.org/getting-started/kubernetes/managed-public-cloud/eks) 페이지에서 확인 할 수 있습니다.
+
+## 네트워크 정책 
+Kubernetes 클러스터의 파드 간 개방형 통신의 기본 모드에서 네트워크 정책을 기반으로 액세스를 제한하는 것으로 변경하는 것이 모범 사례로 간주됩니다. 오픈소스 [Project Calico](https://www.tigera.io/tigera-products/calico/)는 Linux와 Windows 노드 모두에서 작동하는 네트워크 정책을 강력하게 지원합니다. 이 기능은 별개이며 Calico CNI 사용에 의존하지 않습니다. 따라서 Calico를 설치하여 네트워크 정책 관리에 사용하는 것이 좋습니다.
+
+EKS에 Calico를 설치하는 방법에 대한 내용은 [Amazon EKS Calico 설치](https://docs.aws.amazon.com/eks/latest/userguide/calico.html)에서 확인할 수 있습니다.
+
+또한, [보안 모범 사례 - 네트워크 섹션](https://aws.github.io/aws-eks-best-practices/security/docs/network/)의 내용은 Windows 워커 노드가 있는 EKS 클러스터에도 동일하게 적용되지만, "파드용 보안 그룹"과 같은 일부 기능은 현재 Windows에서 지원되지 않습니다.

content/windows/docs/oom.ko.md

@@ -0,0 +1,42 @@
+# OOM(Out of Memory) 에러 방지
+
+윈도우에는 Linux처럼 OOM 프로세스 킬러가 없습니다. 윈도우는 항상 모든 사용자 모드(user-mode) 메모리 할당을 가상으로 취급하며 pagefiles 가 필수입니다. 결과적으로 윈도우는 Linux와 같은 방식으로 OOM 상태에 도달하지 않습니다. 프로세스는 OOM로 종료되는 대신 디스크로 페이징됩니다. 메모리가 과도하게 프로비저닝되고 물리적 메모리가 모두 소진되면 페이징으로 인해 성능이 저하될 수 있습니다.
+
+## 시스템 및 kubelet 메모리 예약
+`--kubelet-reserve` 는 kubelet, 컨테이너 런타임 등과 같은 쿠버네티스 시스템 데몬에 대한 리소스 예약을 **캡처**하고 `--system-reserve` 는 sshd, udev 등과 같은 OS 시스템 데몬에 대한 리소스 예약을 **캡처**하고 설정하는 리눅스와는 다릅니다. **윈도우**에서 이런 플래그는 **kubelet** 또는 노드에서 실행되는 **프로세스**에 대한 메모리 제한을 **캡처**하거나 **설정**하지 않습니다.
+
+하지만 이런 플래그를 조합하여 **NodeAllocatable**을 관리하여 파드 매니페스트에 **메모리 리소스 한도(memory resource limit)**가 있는 노드의 용량을 줄여 파드별로 메모리 할당을 제어할 수 있습니다. 이 전략을 사용하면 메모리 할당을 더 잘 제어할 수 있을 뿐만 아니라 윈도우 노드의 OOM을 최소화하는 메커니즘도 확보할 수 있습니다.
+
+윈도우 노드에서는 OS 및 프로세스에 사용할 최소 2GB의 메모리를 예약하는 것이 가장 좋습니다. `--kubelet-reserve` 또는 `--system-reserve`  파라미터를 활용하여 NodeAllocatable을 줄일 수 있습니다.
+
+[Amazon EKS 자체 관리형 윈도우 노드](https://docs.aws.amazon.com/eks/latest/userguide/launch-windows-workers.html) 설명에 따라 CloudFormation 템플릿을 사용하여 kubelet 구성을 커스터마이제이션 하여 새 윈도우 노드 그룹으로 시작할 수 있습니다. CloudFormation에는 `BootstraArguments`라는 요소가 있는데, 이는 `KubeletExtraArgs`와 동일합니다. 다음 플래그 및 값과 함께 사용할 수 있습니다.
+
+```bash 
+--kube-reserved memory=0.5Gi,ephemeral-storage=1Gi --system-reserved memory=1.5Gi,ephemeral-storage=1Gi --eviction-hard memory.available<200Mi,nodefs.available<10%"
+```
+
+eksctl을 배포 도구로 사용하는 경우, 다음 https://eksctl.io/usage/customizing-the-kubelet/ 문서를 참조하여 kublet을 커스터마이즈 할 수 있습니다.
+
+## 윈도우 컨테이너 메모리 요구 사항
+[Microsoft 문서](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/system-requirements)에 따르면 NANO용 Windows Server 베이스 이미지에는 최소 30MB가 필요한 반면 윈도우 Server Core 이미지에는 45MB가 필요합니다. 이 수치는 .NET 프레임워크, IIS 웹 서비스 및 응용 프로그램과 같은 윈도우 구성 요소를 추가함에 따라 증가합니다.
+
+윈도우 컨테이너 이미지(예: 기본 이미지와 해당 응용 프로그램 계층)에 필요한 최소 메모리 양을 알고 파드 스펙에 컨테이너의 리소스 requests를 설정하는 것이 중요합니다. 또한 애플리케이션 문제 발생 시 파드가 가용 노드 메모리를 모두 사용하지 않도록 limit을 설정해야 합니다.
+
+아래 예제에서, 쿠버네티스 스케줄러가 노드에 파드를 배치하려고 할 때, 파드의 requests을 통해 충분한 리소스가 있는 노드를 결정하는데 사용합니다.
+
+```yaml 
+ spec:
+  - name: iis
+    image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
+    resources:
+      limits:
+        cpu: 1
+        memory: 800Mi
+      requests:
+        cpu: .1
+        memory: 128Mi
+```
+## 결론
+
+위와 같은 접근 방식을 사용해도 메모리 고갈 위험이 최소화되지만 발생 자체를 방지할 수는 없습니다. Amazon CloudWatch 메트릭 지표를 사용하면 메모리 소진이 발생할 경우 알림 및 해결 방법을 설정할 수 있습니다.
+

content/windows/docs/patching.ko.md

@@ -0,0 +1,55 @@
+# 윈도우 서버 및 컨테이너 패치
+
+윈도우 서버 패치 작업은 윈도우 관리자를 위한 표준 관리 작업입니다. Amazon System Manager - Patch Manager, WSUS, System Center Configuration Manager 등과 같은 다양한 도구를 사용하여 이 작업을 수행할 수 있습니다. 하지만 Amazon EKS 클러스터의 윈도우 노드를 일반 윈도우 서버로 취급해서는 안 됩니다. 이들은 변경할 수 없는 서버로 취급되어야 합니다. 간단히 말해, 기존 노드를 업데이트하지 말고 시작 템플릿에 새로 업데이트된 AMI를 기반으로 새 노드를 시작하기만 하면 됩니다.
+
+[EC2 Image Builder](https://aws.amazon.com/image-builder/)를 사용하여 레시피를 생성하고 구성 요소를 추가하여 AMI 빌드를 자동화할 수 있습니다.
+
+다음 예제는 **구성 요소**를 보여줍니다. 구성 요소는 AWS에서 구축한 기존 구성 요소(Amazon-managed)일 수도 있고 사용자가 생성한 구성 요소(Owned by me)일 수도 있습니다. Amazon에서 관리하는 **update-windows**라는 구성 요소에 주목하십시오. 이렇게 하면 EC2 Image Builder 파이프라인을 통해 AMI를 생성하기 전에 윈도우 서버가 업데이트됩니다.
+
+![](./images/associated-components.png)
+
+EC2 Image Builder를 사용하면 Amazon 제공 퍼블릭 AMI를 기반으로 AMI를 구축하고 비즈니스 요구 사항에 맞게 커스터마이징할 수 있습니다. 그런 다음 해당 AMI를 EKS 노드 그룹에서 생성한 Auto Scaling 그룹의 시작 템플릿(Launch Template)에 연결 할 수 있습니다. 이 작업이 완료되면 기존 윈도우 노드를 종료할 수 있으며 새로 업데이트된 AMI를 기반으로 새 윈도우 노드가 시작됩니다.
+
+## 윈도우 이미지 푸싱(Pushing)와 풀링(Pulling)
+Amazon은 2개의 캐시된 윈도우 컨테이너 이미지를 포함하는 EKS 최적화 AMI를 제공합니다.
+
+    mcr.microsoft.com/windows/servercore
+    mcr.microsoft.com/windows/nanoserver
+
+![](./images/images.png)
+
+캐시된 이미지는 main OS 업데이트에 따라 업데이트 됩니다. Microsoft가 윈도우 컨테이너 베이스 이미지에 직접적인 영향을 미치는 새로운 윈도우 업데이트를 출시하면 해당 업데이트는 main OS에서 일반적인 윈도우 업데이트(ordinary Windows Update)로 시작 됩니다. 환경을 최신 상태로 유지하면 노드 및 컨테이너 수준에서 보다 안전한 환경이 제공됩니다.
+
+윈도우 컨테이너 이미지의 크기는 푸시/풀 수행에 영향을 미치므로 컨테이너 시작 시간(conatiner startup time)이 느려질 수 있습니다. [윈도우 컨테이너 이미지 캐싱](https://aws.amazon.com/blogs/containers/speeding-up-windows-container-launch-times-with-ec2-image-builder-and-image-cache-strategy/)에 방식으로 컨테이너 이미지를 캐싱하면 컨테이너 시작 대신 AMI 빌드 생성시 비용이 많이 드는 I/O 작업(파일 추출)이 발생할 수 있습니다. 따라서 필요한 모든 이미지 레이어가 AMI에서 추출되어 바로 사용할 수 있게 되므로 윈도우 컨테이너가 시작되고 트래픽 수신을 시작할 수 있는 시간이 단축됩니다. 푸시 작업 중에는 이미지를 구성하는 레이어만 저장소에 업로드됩니다.
+
+다음 예제에서는 Amazon ECR에서 **fluentd-windows-sac2004** 이미지의 크기가 **390.18MB**에 불과하다는 것을 보여줍니다. 푸시 작업 중에 발생한 업로드 양입니다.
+
+다음 예제에서는 Amazon ECR 리포지토리에 푸시된 [fluentd Windows ltsc](https://github.com/fluent/fluentd-docker-image/blob/master/v1.14/windows-ltsc2019/Dockerfile) 이미지를 보여줍니다. ECR에 저장되는 레이어의 크기는 **533.05MB**입니다.
+
+![](./images/ecr-image.png)
+
+ 아래 `docker image ls` 출력에서는 fluentd v1.14-windows-ltsc2019-1의 크기가 디스크에서 **6.96GB**이지만, 해당 양의 데이터를 다운로드하고 추출했다는 의미는 아닙니다.
+
+실제로 풀 수행시에는 **compressed 533.05MB**만 다운로드되어 추출됩니다.
+
+```bash
+REPOSITORY                                                              TAG                        IMAGE ID       CREATED         SIZE
+111122223333.dkr.ecr.us-east-1.amazonaws.com/fluentd-windows-coreltsc   latest                     721afca2c725   7 weeks ago     6.96GB
+fluent/fluentd                                                          v1.14-windows-ltsc2019-1   721afca2c725   7 weeks ago     6.96GB
+amazonaws.com/eks/pause-windows                                         latest                     6392f69ae6e7   10 months ago   255MB
+```
+
+size 컬럼에 이미지의 전체 크기로 6.96GB가 표시됩니다. 이에 대한 상세한 내역입니다:
+
+* Windows Server Core 2019 LTSC Base image = 5.74GB
+* Fluentd Uncompressed Base Image = 6.96GB
+* Difference on disk = 1.2GB
+* Fluentd [compressed final image ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-info.html) = 533.05MB
+
+기본 이미지가 로컬 디스크에 이미 있으므로 디스크의 총 용량은 1.2GB가 추가됩니다. 다음에 size 컬럼에 GB 용량이 표시되더라도 너무 걱정할 필요 없습니다. 이미 70% 이상이 캐시된 컨테이너 이미지로 디스크에 저장되어 있을 것입니다.
+
+## 참고 자료
+[EC2 Image builder 및 이미지 캐시 전략으로 윈도우 컨테이너 시작 시간 단축](https://aws.amazon.com/blogs/containers/speeding-up-windows-container-launch-times-with-ec2-image-builder-and-image-cache-strategy/)
+
+
+