Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Gestion des AMI Windows optimisée pour Amazon EKS
Les AMI optimisées pour Windows Amazon EKS sont basées sur Windows Server 2019 et Windows Server 2022. Elles sont configurées pour servir d'image de base pour les nœuds Amazon EKS. Par défaut, les AMI incluent les composants suivants :
Vous pouvez récupérer par programmation l'ID Amazon Machine Image (AMI) pour les AMI optimisées pour Amazon EKS en interrogeant l'API AWS Systems Manager Parameter Store. Ce paramètre vous évite de devoir rechercher manuellement les ID d'AMI optimisées pour Amazon EKS. Pour plus d'informations sur l'API Systems Manager Parameter Store, consultez GetParameter. Votre compte utilisateur doit disposer de l'autorisation ssm : GetParameter IAM pour récupérer les métadonnées AMI optimisées pour Amazon EKS.
L'exemple suivant récupère l'ID d'AMI de la dernière AMI optimisée pour Amazon EKS pour Windows Server 2019 LTSC Core. Le numéro de version indiqué dans le nom de l'AMI se rapporte à la version de Kubernetes correspondante pour laquelle elle est préparée.
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
Exemple de sortie :
ami-09770b3eec4552d4e
Gestion de votre propre AMI Windows optimisée pour Amazon EKS
Une étape essentielle vers les environnements de production consiste à maintenir la même version d'AMI Windows optimisée pour Amazon EKS et de kubelet sur l'ensemble du cluster Amazon EKS.
L'utilisation de la même version sur l'ensemble du cluster Amazon EKS réduit la durée du dépannage et améliore la cohérence du cluster. Amazon EC2 Image Builder
Utilisez Amazon EC2 Image Builder pour sélectionner entre les versions de Windows Server, les dates de sortie de l'AMI AWS Windows Server et la version de compilation du système d' and/or exploitation. L'étape de génération des composants vous permet de choisir entre les artefacts Windows optimisés EKS existants ainsi que les versions de kubelet. Pour plus d'informations : https://docs.aws.amazon.com/eks/latest/userguide/eks-custom-ami-windows.html
REMARQUE : Avant de sélectionner une image de base, consultez la section Version et licence de Windows Server pour obtenir des informations importantes concernant les mises à jour des chaînes de publication.
Configuration d'un lancement plus rapide pour les AMI personnalisées optimisées pour EKS
Lorsque vous utilisez une AMI personnalisée optimisée pour Windows Amazon EKS, les nœuds de travail Windows peuvent être lancés jusqu'à 65 % plus rapidement en activant la fonctionnalité de lancement rapide. Cette fonctionnalité permet de conserver un ensemble de snapshots préprovisionnés qui comprennent la spécialisation Sysprep, les étapes OOBE (Windows Out of Box Experience) et les redémarrages requis déjà effectués. Ces instantanés sont ensuite utilisés lors des lancements suivants, ce qui réduit le temps nécessaire à la mise à l'échelle ou au remplacement des nœuds. Le lancement rapide ne peut être activé que pour les AMI que vous possédez via la console EC2 ou dans l'AWS CLI et le nombre de snapshots conservés est configurable.
REMARQUE : Fast Launch n'est pas compatible avec l'AMI optimisée par défaut pour Amazon-provided EKS. Créez une AMI personnalisée comme ci-dessus avant d'essayer de l'activer.
Pour plus d'informations : AMI Windows AWS - Configurez votre AMI pour un lancement plus rapide
Mise en cache des couches de base Windows sur des AMI personnalisées
Les images de conteneurs Windows sont plus grandes que leurs homologues Linux. Si vous exécutez une Framework-based application .NET conteneurisée, la taille moyenne de l'image est d'environ 8,24 Go. Lors de la planification du pod, l'image du conteneur doit être entièrement extraite et extraite sur le disque avant que le pod n'atteigne l'état En cours d'exécution.
Au cours de ce processus, le moteur d'exécution du conteneur (containerd) extrait l'intégralité de l'image du conteneur sur le disque. L'opération d'extraction est un processus parallèle, ce qui signifie que le moteur d'exécution du conteneur extrait les couches d'image du conteneur en parallèle. En revanche, l'opération d'extraction se déroule selon un processus séquentiel et elle est I/O intensive. De ce fait, l'extraction complète de l'image du conteneur peut prendre plus de 8 minutes et être prête à être utilisée par le moteur d'exécution du conteneur (containerd). Par conséquent, le démarrage du pod peut prendre plusieurs minutes.
Comme indiqué dans la rubrique Patching Windows Server and Container, il existe une option permettant de créer une AMI personnalisée avec EKS. Pendant la préparation de l'AMI, vous pouvez ajouter un composant EC2 Image builder supplémentaire pour extraire toutes les images de conteneurs Windows nécessaires localement, puis générer l'AMI. Cette stratégie permettra de réduire considérablement le temps pendant lequel un pod atteint le statut Running.
Sur Amazon EC2 Image Builder, créez un composant pour télécharger les images nécessaires et joignez-le à la recette Image. L'exemple suivant extrait une image spécifique d'un référentiel 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
Pour vous assurer que le composant suivant fonctionne comme prévu, vérifiez si le rôle IAM utilisé par EC2 Image builder (EC2InstanceProfileForImageBuilder) possède les politiques associées :
Billet de blog
Dans l'article de blog suivant, vous trouverez étape par étape comment implémenter une stratégie de mise en cache pour les AMI Windows Amazon EKS personnalisées :
