As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Gerenciamento otimizado de AMI do Windows para Amazon EKS
As AMIs do Windows otimizadas para o Amazon EKS são desenvolvidas com base no Windows Server 2019 e 2022. Elas são configuradas para servirem como imagem base para nós do Amazon EKS. As AMIs incluem por padrão os seguintes componentes:
+ [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)
+ [kube-proxy](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/)
+ [AWS IAM Authenticator para Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator)
+ [csi-proxy](https://github.com/kubernetes-csi/csi-proxy)
+ [containerd](https://containerd.io/)
Você pode recuperar programaticamente o ID da Amazon Machine Image (AMI) para AMIs otimizadas do Amazon EKS consultando a API AWS Systems Manager Parameter Store. Esse parâmetro elimina a necessidade de pesquisar manualmente IDs de AMIs otimizadas para o Amazon EKS. Para obter mais informações sobre a API Systems Manager Parameter Store, consulte [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html). Sua conta de usuário deve ter a permissão ssm: GetParameter IAM para recuperar os metadados otimizados da AMI do Amazon EKS.
O exemplo a seguir recupera o ID da AMI da AMI otimizada mais recente do Amazon EKS para Windows Server 2019 LTSC Core. O número da versão listado no nome da AMI está relacionado à compilação correspondente do Kubernetes para a qual ela está preparada.
```
aws ssm get-parameter --name /aws/service/ami-windows-latest/Windows_Server-2019-English-Core-EKS_Optimized-1.21/image_id --region us-east-1 --query "Parameter.Value" --output text
```
Resultado do exemplo:
```
ami-09770b3eec4552d4e
```
## Gerenciando sua própria AMI Windows otimizada para Amazon EKS
Uma etapa essencial em direção aos ambientes de produção é manter a mesma AMI do Windows otimizada para Amazon EKS e a mesma versão kubelet em todo o cluster do Amazon EKS.
Usar a mesma versão em todo o cluster Amazon EKS reduz o tempo durante a solução de problemas e aumenta a consistência do cluster. [O Amazon EC2 Image Builder](https://aws.amazon.com/image-builder/) ajuda a criar e manter AMIs personalizadas do Windows otimizadas para Amazon EKS para serem usadas em um cluster do Amazon EKS.
Use o Amazon EC2 Image Builder para selecionar entre as versões do Windows Server, as datas de lançamento da AMI do AWS Windows Server e a versão de compilação do and/or sistema operacional. A etapa de criação de componentes permite que você selecione entre os artefatos do Windows otimizados para EKS existentes e as versões do kubelet. Para obter mais informações: https://docs.aws.amazon.com/eks/latest/userguide/eks-custom-ami-windows.html
**OBSERVAÇÃO:** Antes de selecionar uma imagem base, consulte a seção [Versão e Licença do Windows Server](windows-licensing.md) para obter detalhes importantes sobre as atualizações do canal de lançamento.
## Configurando o lançamento mais rápido para AMIs personalizadas otimizadas para EKS
Ao usar uma AMI personalizada otimizada para Windows Amazon EKS, os nós de trabalho do Windows podem ser iniciados até 65% mais rápido ao ativar o recurso Fast Launch. Esse recurso mantém um conjunto de instantâneos pré-provisionados que têm a *especialização Sysprep*, as etapas do *Windows Out of Box Experience (OOBE) e as reinicializações necessárias já concluídas*. Esses instantâneos são então usados em lançamentos subsequentes, reduzindo o tempo de expansão ou substituição de nós. O Fast Launch só pode ser habilitado para AMIs *que você possui* por meio do console do EC2 ou na AWS CLI, e o número de snapshots mantidos é configurável.
**OBSERVAÇÃO:** O Fast Launch não é compatível com a AMI otimizada para Amazon-provided EKS padrão. Crie uma AMI personalizada conforme descrito acima antes de tentar ativá-la.
Para obter mais informações: [AWS Windows AMIs — Configure sua AMI para um lançamento mais rápido](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/windows-ami-version-history.html#win-ami-config-fast-launch)
## Armazenamento em cache das camadas base do Windows em AMIs personalizadas
As imagens de contêiner do Windows são maiores do que as do Linux. Se você estiver executando qualquer Framework-based aplicativo.NET em contêineres, o tamanho médio da imagem é de cerca de 8,24 GB. Durante o agendamento do pod, a imagem do contêiner deve ser totalmente extraída e extraída no disco antes que o pod alcance o status Running.
Durante esse processo, o tempo de execução do contêiner (containerd) extrai e extrai toda a imagem do contêiner no disco. A operação de extração é um processo paralelo, o que significa que o tempo de execução do contêiner puxa as camadas da imagem do contêiner em paralelo. Por outro lado, a operação de extração ocorre em um processo sequencial e é I/O intensiva. Por esse motivo, a imagem do contêiner pode levar mais de 8 minutos para ser totalmente extraída e pronta para ser usada pelo tempo de execução do contêiner (containerd) e, como resultado, o tempo de inicialização do pod pode levar vários minutos.
Conforme mencionado no tópico **Patching Windows Server and Container**, há uma opção para criar uma AMI personalizada com o EKS. Durante a preparação da AMI, você pode adicionar um componente adicional do EC2 Image Builder para extrair localmente todas as imagens de contêiner do Windows necessárias e, em seguida, gerar a AMI. Essa estratégia reduzirá drasticamente o tempo em que um pod atinge o status **Executando**.
No Amazon EC2 Image Builder, crie um [componente](https://docs.aws.amazon.com/imagebuilder/latest/userguide/manage-components.html) para baixar as imagens necessárias e anexá-las à receita da imagem. O exemplo a seguir extrai uma imagem específica de um repositório ECR.
```
name: ContainerdPull
description: This component pulls the necessary containers images for a cache strategy.
schemaVersion: 1.0
phases:
- name: build
steps:
- name: containerdpull
action: ExecutePowerShell
inputs:
commands:
- Set-ExecutionPolicy Unrestricted -Force
- (Get-ECRLoginCommand).Password | docker login --username AWS --password-stdin 111000111000.dkr.ecr.us-east-1.amazonaws.com
- ctr image pull mcr.microsoft.com/dotnet/framework/aspnet:latest
- ctr image pull 111000111000.dkr.ecr.us-east-1.amazonaws.com/myappcontainerimage:latest
```
Para garantir que o componente a seguir funcione conforme o esperado, verifique se a função do IAM usada pelo EC2 Image builder (EC2InstanceProfileForImageBuilder) tem as políticas anexadas:
## Publicação no blog
Na postagem do blog a seguir, você encontrará um passo a passo sobre como implementar a estratégia de armazenamento em cache para AMIs personalizadas do Amazon EKS para Windows:
[Acelerando os tempos de lançamento de contêineres do Windows com o EC2 Image Builder e a estratégia de cache de imagens](https://aws.amazon.com/blogs/containers/speeding-up-windows-container-launch-times-with-ec2-image-builder-and-image-cache-strategy/)