View a markdown version of this page

Amazon EKS hat die Windows AMI-Verwaltung optimiert - Amazon EKS

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Amazon EKS hat die Windows AMI-Verwaltung optimiert

Amazon-EKS-optimierte Windows-AMIs bauen auf Windows Server 2019 und Windows Server 2022 auf. Sie sind so konfiguriert, dass sie als Basis-Image für Amazon-EKS-Knoten dienen. Standardmäßig enthalten die AMIs die folgenden Komponenten:

Sie können die Amazon Machine Image (AMI) -ID für Amazon EKS-optimierte AMIs programmgesteuert abrufen, indem Sie die AWS Systems Manager Parameter Store API abfragen. Mit diesem Parameter müssen Sie Amazon-EKS-optimierte AMI-IDs nicht manuell abrufen. Weitere Informationen zur Systems Manager Parameter Store API finden Sie unter. GetParameter Ihr Benutzerkonto muss über die ssm: GetParameter IAM-Berechtigung verfügen, um die für Amazon EKS optimierten AMI-Metadaten abzurufen.

Im folgenden Beispiel wird die AMI-ID für das neueste Amazon EKS-optimierte AMI für Windows Server 2019 LTSC Core abgerufen. Die im AMI-Namen angegebene Versionsnummer bezieht sich auf den entsprechenden Kubernetes-Build, für den sie vorbereitet wurde.

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

Beispielausgabe:

ami-09770b3eec4552d4e

Verwaltung Ihres eigenen für Amazon EKS optimierten Windows-AMI

Ein wichtiger Schritt in Richtung Produktionsumgebungen ist die Aufrechterhaltung derselben Amazon EKS-optimierten Windows-AMI- und Kubelet-Version im gesamten Amazon EKS-Cluster.

Die Verwendung derselben Version im gesamten Amazon EKS-Cluster reduziert den Zeitaufwand bei der Fehlerbehebung und erhöht die Cluster-Konsistenz. Amazon EC2 Image Builder hilft bei der Erstellung und Verwaltung benutzerdefinierter Amazon EKS-optimierter Windows-AMIs, die in einem Amazon EKS-Cluster verwendet werden können.

Verwenden Sie Amazon EC2 Image Builder, um zwischen Windows Server-Versionen, AWS Windows Server-AMI-Veröffentlichungsdaten und and/or Betriebssystem-Build-Versionen zu wählen. Im Schritt zum Erstellen der Komponenten können Sie zwischen vorhandenen EKS-optimierten Windows-Artefakten und den Kubelet-Versionen wählen. Für weitere Informationen: https://docs.aws.amazon.com/eks/latest/userguide/eks-custom-ami-windows.html

Komponenten bauen

HINWEIS: Bevor Sie ein Basisimage auswählen, lesen Sie im Abschnitt Version und Lizenz von Windows Server nach, um wichtige Informationen zu Release-Channel-Updates zu erhalten.

Konfiguration eines schnelleren Starts für benutzerdefinierte EKS-optimierte AMIs

Wenn Sie ein benutzerdefiniertes, für Windows Amazon EKS optimiertes AMI verwenden, können Windows-Worker-Knoten bis zu 65% schneller gestartet werden, indem die Schnellstartfunktion aktiviert wird. Diese Funktion verwaltet eine Reihe von vorab bereitgestellten Snapshots, für die die Sysprep-Spezialisierung, die Windows Out of Box Experience (OOBE) -Schritte (Windows Out of Box Experience) und die erforderlichen Neustarts bereits abgeschlossen sind. Diese Snapshots werden dann bei nachfolgenden Starts verwendet, wodurch die Zeit für das Scale-Out oder den Austausch von Knoten reduziert wird. Fast Launch kann über die EC2-Konsole oder in der AWS-CLI nur für AMIs aktiviert werden, die Sie besitzen. Die Anzahl der verwalteten Snapshots ist konfigurierbar.

HINWEIS: Fast Launch ist nicht mit dem für Amazon-provided EKS optimierten Standard-AMI kompatibel. Erstellen Sie wie oben beschrieben ein benutzerdefiniertes AMI, bevor Sie versuchen, es zu aktivieren.

Weitere Informationen finden Sie unter AWS Windows AMIs — Konfigurieren Sie Ihr AMI für einen schnelleren Start

Zwischenspeichern von Windows-Basisschichten auf benutzerdefinierten AMIs

Windows-Container-Images sind größer als ihre Linux-Gegenstücke. Wenn Sie eine Framework-based containerisierte.NET-Anwendung ausführen, liegt die durchschnittliche Image-Größe bei etwa 8,24 GB. Während der Pod-Planung muss das Container-Image vollständig abgerufen und auf die Festplatte extrahiert werden, bevor der Pod den Status Running erreicht.

Während dieses Vorgangs ruft die Container-Runtime (containerd) das gesamte Container-Image auf der Festplatte ab und extrahiert es. Die Pull-Operation ist ein paralleler Prozess, was bedeutet, dass die Container-Runtime die Container-Image-Ebenen parallel abruft. Im Gegensatz dazu erfolgt der Extraktionsvorgang in einem sequentiellen Prozess und ist I/O intensiv. Aus diesem Grund kann es länger als 8 Minuten dauern, bis das Container-Image vollständig extrahiert ist und von der Container-Runtime (containerd) verwendet werden kann. Infolgedessen kann die Startzeit des Pods mehrere Minuten dauern.

Wie im Thema Patchen von Windows Server und Containern erwähnt, gibt es eine Option zum Erstellen eines benutzerdefinierten AMI mit EKS. Während der AMI-Vorbereitung können Sie eine zusätzliche EC2 Image Builder-Komponente hinzufügen, um alle erforderlichen Windows-Container-Images lokal abzurufen und dann das AMI zu generieren. Mit dieser Strategie wird die Zeit, in der ein Pod den Status Wird ausgeführt erreicht, drastisch reduziert.

Erstellen Sie in Amazon EC2 Image Builder eine Komponente, um die erforderlichen Bilder herunterzuladen und sie an das Image-Rezept anzuhängen. Das folgende Beispiel ruft ein bestimmtes Bild aus einem ECR-Repository ab.

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

Um sicherzustellen, dass die folgende Komponente erwartungsgemäß funktioniert, überprüfen Sie, ob die von EC2 Image Builder (EC2InstanceProfileForImageBuilder) verwendete IAM-Rolle über die angehängten Richtlinien verfügt:

Richtlinien für Berechtigungen

Blogbeitrag

Im folgenden Blogbeitrag erfahren Sie Schritt für Schritt, wie Sie die Caching-Strategie für benutzerdefinierte Amazon EKS-Windows-AMIs implementieren:

Verkürzung der Startzeiten von Windows-Containern mit EC2 Image Builder und Image-Cache-Strategie