기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Windows Server 및 컨테이너 패치 적용
Windows Server 패치는 Windows 관리자의 표준 관리 작업입니다. 이는 Amazon System Manager - Patch Manager, WSUS, System Center Configuration Manager 등과 같은 다양한 도구를 사용하여 수행할 수 있습니다. 그러나 Amazon EKS 클러스터의 Windows 노드는 일반 Windows 서버로 취급해서는 안 됩니다. 변경 불가능한 서버로 취급해야 합니다. 간단히 말해서 기존 노드를 업데이트하지 말고 새로 업데이트된 AMI를 기반으로 새 노드를 시작하면 됩니다.
[EC2 Image Builder](https://aws.amazon.com/image-builder/)를 사용하면 레시피를 생성하고 구성 요소를 추가하여 AMIs 빌드를 자동화할 수 있습니다.
다음 예제에서는 AWS에서 구축한 기존 **구성 요소**(Amazon 관리형)와 사용자가 생성한 구성 요소(내 소유)일 수 있는 구성 요소를 보여줍니다. **update-windows**라는 Amazon 관리형 구성 요소에 주의하세요. 그러면 EC2 Image Builder 파이프라인을 통해 AMI를 생성하기 전에 Windows Server가 업데이트됩니다.
![\[연결된 구성 요소\]](http://docs.aws.amazon.com/ko_kr/eks/latest/best-practices/images/windows/associated-components.png)
EC2 Image Builder를 사용하면 Amazon Managed Public AMI를 기반으로 AMIs 빌드하고 비즈니스 요구 사항에 맞게 사용자 지정할 수 있습니다. 그런 다음 이러한 AMIs 시작 템플릿과 연결하여 새 AMI를 EKS 노드 그룹에서 생성한 Auto Scaling 그룹에 연결할 수 있습니다. 완료되면 기존 Windows 노드 종료를 시작할 수 있으며 업데이트된 새 AMI를 기반으로 새 노드가 시작됩니다.
## Windows 이미지 푸시 및 가져오기
Amazon은 캐시된 두 개의 Windows 컨테이너 이미지가 포함된 EKS 최적화 AMIs를 게시합니다.
```
mcr.microsoft.com/windows/servercore
mcr.microsoft.com/windows/nanoserver
```
![\[이미지\]](http://docs.aws.amazon.com/ko_kr/eks/latest/best-practices/images/windows/images.png)
캐시된 이미지는 기본 OS의 업데이트에 따라 업데이트됩니다. Microsoft가 Windows 컨테이너 기본 이미지에 직접 영향을 미치는 새 Windows 업데이트를 릴리스하면 기본 OS에서 일반 Windows 업데이트로 업데이트가 시작됩니다. 환경을 up-to-date 상태로 유지하면 노드 및 컨테이너 수준에서 보다 안전한 환경이 제공됩니다.
Windows 컨테이너 이미지의 크기는 푸시/풀 작업에 영향을 미치므로 컨테이너 시작 시간이 느려질 수 있습니다. [Windows 컨테이너 이미지를 캐싱](https://aws.amazon.com/blogs/containers/speeding-up-windows-container-launch-times-with-ec2-image-builder-and-image-cache-strategy/)하면 컨테이너 시작 대신 AMI 빌드 생성 시 비용이 많이 드는 I/O 작업(파일 추출)이 발생할 수 있습니다. 따라서 필요한 모든 이미지 계층이 AMI에서 추출되고 사용할 준비가 되어 Windows 컨테이너가 시작되고 트래픽 수락을 시작할 수 있는 시간이 단축됩니다. 푸시 작업 중에는 이미지를 구성하는 계층만 리포지토리에 업로드됩니다.
다음 예제는 Amazon ECR에서 **fluentd-windows-sac2004** 이미지의 크기가 **390.18MB**에 불과함을 보여줍니다. 푸시 작업 중에 발생한 업로드 양입니다.
다음 예제는 Amazon ECR [리포지토리로 푸시된 유창한 Windows ltsc](https://github.com/fluent/fluentd-docker-image/blob/master/v1.14/windows-ltsc2019/Dockerfile) 이미지를 보여줍니다. ECR에 저장된 계층의 크기는 **533.05MB**입니다.
![\[ecr 이미지\]](http://docs.aws.amazon.com/ko_kr/eks/latest/best-practices/images/windows/ecr-image.png)
아래 `docker image ls`의 출력인 fluentd v1.14-windows-ltsc2019-1의 크기는 디스크에서 **6.96GB**이지만 해당 양의 데이터를 다운로드하고 추출했음을 의미하지는 않습니다.
실제로 풀 작업 중에는 **압축된 533.05MB**만 다운로드되고 추출됩니다.
```
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
```
크기 열에는 이미지의 전체 크기인 6.96GB가 표시됩니다. 분류:
+ Windows Server Core 2019 LTSC 기본 이미지 = 5.74GB
+ Fluentd 비압축 기본 이미지 = 6.96GB
+ 디스크 차이 = 1.2GB
+ Fluentd [압축된 최종 이미지 ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-info.html) = 533.05MB
기본 이미지가 이미 로컬 디스크에 있으므로 디스크의 총량은 1.2GB가 추가됩니다. 다음에 크기 열에 GBs의 양이 표시되면 너무 많이 걱정하지 마세요. 70% 이상이 이미 캐시된 컨테이너 이미지로 디스크에 있을 가능성이 높습니다.
## 레퍼런스
[EC2 이미지 빌더 및 이미지 캐시 전략을 사용하여 Windows 컨테이너 시작 시간 단축](https://aws.amazon.com/blogs/containers/speeding-up-windows-container-launch-times-with-ec2-image-builder-and-image-cache-strategy/)