

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 修补 Windows 服务器和容器
<a name="windows-patching"></a>

修补 Windows 服务器是 Windows 管理员的一项标准管理任务。这可以使用不同的工具来完成，例如 Amazon System Manager-补丁管理器、WSUS、系统中心配置管理器等。但是，不应将亚马逊 EKS 集群中的 Windows 节点视为普通的 Windows 服务器。它们应该被视为不可变的服务器。简而言之，避免更新现有节点，只需基于新更新的 AMI 启动一个新节点即可。

使用 [EC2 Image Builder](https://aws.amazon.com/image-builder/)，您可以通过创建配方和添加组件来自动 AMIs 构建。

以下示例显示了**组件，这些组件**可以是由 AWS（亚马逊管理）构建的预先存在的组件，也可以是您创建的组件（归我所有）。请密切关注亚马逊管理的名为 **update-windows 的组件，它会在通过 EC2 Image Builder 管道**生成 AMI 之前更新 Windows 服务器。

![\[关联组件\]](http://docs.aws.amazon.com/zh_cn/eks/latest/best-practices/images/windows/associated-components.png)


EC2 Image Builder 允许您基于亚马逊公共托管构建 AMI， AMIs 并对其进行自定义以满足您的业务需求。然后，您可以将它们 AMIs 与启动模板相关联，这样您就可以将新的 AMI 关联到 EKS 节点组创建的 Auto Scaling 组。完成后，您可以开始终止现有的 Windows 节点，并且将基于新更新的 AMI 启动新节点。

## 推送和拉取 Windows 镜像
<a name="_pushing_and_pulling_windows_images"></a>

亚马逊发布了经过优化的 EKS AMIs ，其中包括两个缓存的 Windows 容器镜像。

```
mcr.microsoft.com/windows/servercore
mcr.microsoft.com/windows/nanoserver
```

![\[图片\]](http://docs.aws.amazon.com/zh_cn/eks/latest/best-practices/images/windows/images.png)


缓存的图像将在主操作系统更新后更新。当微软发布直接影响Windows容器基础映像的新的Windows更新时，该更新将作为普通的Windows更新在主操作系统上启动。保持环境 up-to-date可在节点和容器级别提供更安全的环境。

Windows 容器镜像的大小会影响 push/pull 操作，从而导致容器启动时间变慢。[缓存 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 年的**图片只有 **39** 0.18MB。这是推送操作期间发生的上传量。

以下示例显示了推送到亚马逊 ECR 存储库的 [fluentd Windows ltsc](https://github.com/fluent/fluentd-docker-image/blob/master/v1.14/windows-ltsc2019/Dockerfile) 镜像。存储在 ECR 中的图层大小为 **533.05** MB。

![\[ecr 图片\]](http://docs.aws.amazon.com/zh_cn/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 [压缩的最终图像 EC](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-info.html) R = 533.05MB

本地磁盘上已存在基础映像，导致磁盘上的总容量额外增加 1.2GB。下次你在大小列 GBs 中看到数量时，不用太担心，磁盘上可能已经有超过 70% 作为缓存的容器镜像。

## 参考
<a name="_reference"></a>

 [使用 EC2 映像生成器和图像缓存策略加快 Windows 容器的启动时间](https://aws.amazon.com/blogs/containers/speeding-up-windows-container-launch-times-with-ec2-image-builder-and-image-cache-strategy/) 