Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Gestione delle AMI Windows ottimizzate per Amazon EKS
Le AMI Windows ottimizzate per Amazon EKS sono state sviluppate sulla base di Windows Server 2019 e Windows Server 2022. Sono configurate per fungere da immagine di base per i nodi Amazon EKS. Per impostazione predefinita, le AMI includono i componenti seguenti:
+ [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 per Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator)
+ [csi-proxy](https://github.com/kubernetes-csi/csi-proxy)
+ [containerd](https://containerd.io/)
Puoi recuperare a livello di codice l'ID Amazon Machine Image (AMI) per le AMI ottimizzate per Amazon EKS interrogando l'API AWS Systems Manager Parameter Store. Questo parametro consente di evitare la ricerca manuale degli ID AMI ottimizzata per Amazon EKS. Per ulteriori informazioni sull'API Systems Manager Parameter Store, vedere [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html). Il tuo account utente deve disporre dell'autorizzazione ssm: GetParameter IAM per recuperare i metadati AMI ottimizzati per Amazon EKS.
L'esempio seguente recupera l'ID AMI per l'ultima AMI ottimizzata Amazon EKS per Windows Server 2019 LTSC Core. Il numero di versione riportato nel nome dell'AMI si riferisce alla build Kubernetes corrispondente per cui è stato preparato.
```
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
```
Output di esempio:
```
ami-09770b3eec4552d4e
```
## Gestione della propria AMI Windows ottimizzata per Amazon EKS
Un passo essenziale verso gli ambienti di produzione è mantenere la stessa AMI Windows ottimizzata per Amazon EKS e la stessa versione kubelet nel cluster Amazon EKS.
L'utilizzo della stessa versione in tutto il cluster Amazon EKS riduce i tempi di risoluzione dei problemi e aumenta la coerenza del cluster. [Amazon EC2 Image Builder](https://aws.amazon.com/image-builder/) aiuta a creare e gestire AMI Windows ottimizzate per Amazon EKS personalizzate da utilizzare in un cluster Amazon EKS.
Usa Amazon EC2 Image Builder per scegliere tra le versioni di Windows Server, le date and/or di rilascio dell'AMI AWS Windows Server e la versione di build del sistema operativo. La fase di compilazione dei componenti consente di scegliere tra gli artefatti Windows ottimizzati per EKS esistenti e le versioni kubelet. Per ulteriori informazioni: https://docs.aws.amazon.com/eks/latest/userguide/eks-custom-ami-windows.html
**NOTA:** prima di selezionare un'immagine di base, consulta la sezione [Versione e licenza di Windows Server](windows-licensing.md) per dettagli importanti relativi agli aggiornamenti del canale di rilascio.
## Configurazione di un avvio più rapido per AMI ottimizzate per EKS personalizzate
Quando si utilizza un'AMI personalizzata ottimizzata per Windows Amazon EKS, i nodi di lavoro Windows possono essere avviati fino al 65% più velocemente abilitando la funzionalità Fast Launch. Questa funzionalità mantiene una serie di istantanee preconfigurate che prevedono la *specializzazione in Sysprep, i passaggi* *Windows Out of Box Experience (OOBE) e i riavvii richiesti già completati*. Queste istantanee vengono quindi utilizzate negli avvii successivi, riducendo i tempi di scalabilità o sostituzione dei nodi. Fast Launch può essere abilitato solo per le AMI di *tua proprietà* tramite la console EC2 o nella CLI AWS e il numero di istantanee gestite è configurabile.
**NOTA:** Fast Launch non è compatibile con l'AMI ottimizzata Amazon-provided EKS predefinita, crea un'AMI personalizzata come sopra prima di tentare di abilitarla.
Per ulteriori informazioni: AMI [AWS Windows: configura la tua AMI per un avvio più rapido](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/windows-ami-version-history.html#win-ami-config-fast-launch)
## Memorizzazione nella cache dei livelli base di Windows su AMI personalizzate
Le immagini dei contenitori Windows sono più grandi delle loro controparti Linux. Se si esegue Framework-based un'applicazione.NET containerizzata, la dimensione media dell'immagine è di circa 8,24 GB. Durante la pianificazione del pod, l'immagine del contenitore deve essere completamente estratta ed estratta dal disco prima che il pod raggiunga lo stato In esecuzione.
Durante questo processo, il runtime del contenitore (containerd) recupera ed estrae l'intera immagine del contenitore nel disco. L'operazione pull è un processo parallelo, il che significa che il runtime del contenitore attira i livelli dell'immagine del contenitore in parallelo. Al contrario, l'operazione di estrazione avviene in un processo sequenziale ed è I/O intensivo. Per questo motivo, l'immagine del contenitore può impiegare più di 8 minuti per essere completamente estratta e pronta per essere utilizzata dal runtime del contenitore (containerd) e, di conseguenza, l'avvio del pod può richiedere diversi minuti.
Come indicato nell'argomento Applicazione di **patch a Windows Server and Container**, esiste un'opzione per creare un'AMI personalizzata con EKS. Durante la preparazione dell'AMI, puoi aggiungere un componente aggiuntivo EC2 Image Builder per estrarre localmente tutte le immagini dei container Windows necessarie e quindi generare l'AMI. **Questa strategia ridurrà drasticamente il tempo in cui un pod raggiunge lo stato In esecuzione.**
Su Amazon EC2 Image Builder, crea [un](https://docs.aws.amazon.com/imagebuilder/latest/userguide/manage-components.html) componente per scaricare le immagini necessarie e allegalo alla ricetta Image. L'esempio seguente estrae un'immagine specifica da un repository 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
```
Per assicurarti che il seguente componente funzioni come previsto, controlla se il ruolo IAM utilizzato da EC2 Image builder (EC2InstanceProfileForImageBuilder) ha le policy allegate:
## Post del blog
Nel seguente post del blog, troverai istruzioni dettagliate su come implementare la strategia di caching per le AMI Windows Amazon EKS personalizzate:
[Accelerazione dei tempi di avvio dei container Windows con EC2 Image Builder e la strategia Image Cache](https://aws.amazon.com/blogs/containers/speeding-up-windows-container-launch-times-with-ec2-image-builder-and-image-cache-strategy/)