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.

Patchen von Windows-Servern und Containern

Das Patchen von Windows Server ist eine Standardverwaltungsaufgabe für Windows-Administratoren. Dies kann mit verschiedenen Tools wie Amazon System Manager — Patch Manager, WSUS, System Center Configuration Manager und vielen anderen erreicht werden. Windows-Knoten in einem Amazon EKS-Cluster sollten jedoch nicht wie normale Windows-Server behandelt werden. Sie sollten als unveränderlicher Server behandelt werden. Einfach ausgedrückt, vermeiden Sie es, einen vorhandenen Knoten zu aktualisieren, sondern starten Sie einfach einen neuen Knoten, der auf einem neuen aktualisierten AMI basiert.

Mit EC2 Image Builder können Sie die Erstellung von AMIs automatisieren, indem Sie Rezepte erstellen und Komponenten hinzufügen.

Das folgende Beispiel zeigt Komponenten, bei denen es sich sowohl um bereits vorhandene Komponenten handeln kann, die von AWS (Amazon-managed) erstellt wurden, als auch um die Komponenten, die Sie erstellen (im Besitz von mir). Achten Sie genau auf die Amazon-managed Komponente namens update-windows. Dadurch wird Windows Server aktualisiert, bevor das AMI über die EC2 Image Builder-Pipeline generiert wird.

Mit EC2 Image Builder können Sie AMIs auf der Grundlage von Amazon Managed Public AMIs erstellen und sie an Ihre Geschäftsanforderungen anpassen. Anschließend können Sie diese AMIs mit Launch Templates verknüpfen, sodass Sie ein neues AMI mit der Auto Scaling Group verknüpfen können, die von der EKS-Nodegroup erstellt wurde. Sobald dieser Vorgang abgeschlossen ist, können Sie mit dem Beenden der vorhandenen Windows-Knoten beginnen. Neue Knoten werden auf der Grundlage des neuen aktualisierten AMI gestartet.

Windows-Images verschieben und abrufen

Amazon veröffentlicht EKS-optimierte AMIs, die zwei zwischengespeicherte Windows-Container-Images enthalten.

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

Zwischengespeicherte Images werden im Anschluss an die Aktualisierungen auf dem Hauptbetriebssystem aktualisiert. Wenn Microsoft ein neues Windows-Update veröffentlicht, das sich direkt auf das Windows-Container-Basisimage auswirkt, wird das Update als normales Windows Update auf dem Hauptbetriebssystem gestartet. Wenn Sie die Umgebung auf dem neuesten Stand halten, wird die Umgebung auf Knoten- und Containerebene sicherer.

Die Größe eines Windows-Container-Images beeinflusst den push/pull Betrieb, was zu langsamen Container-Startzeiten führen kann. Durch das Zwischenspeichern von Windows-Container-Images können die teuren I/O Operationen (Dateiextraktion) bereits bei der Erstellung des AMI-Builds statt beim Start des Containers ausgeführt werden. Dadurch werden alle erforderlichen Image-Ebenen auf dem AMI extrahiert und sind sofort einsatzbereit. Dadurch wird die Zeit verkürzt, in der ein Windows-Container gestartet wird und mit der Aufnahme von Datenverkehr beginnen kann. Während eines Push-Vorgangs werden nur die Ebenen, aus denen Ihr Image besteht, in das Repository hochgeladen.

Das folgende Beispiel zeigt, dass die fluentd-windows-sac2004-Images auf dem Amazon ECR nur 390,18 MB groß sind. Dies ist die Menge an Uploads, die während des Push-Vorgangs stattgefunden hat.

Das folgende Beispiel zeigt ein flüssiges Windows ltsc-Image, das in ein Amazon ECR-Repository übertragen wurde. Die Größe der in ECR gespeicherten Ebene beträgt 533,05 MB.

Die folgende Ausgabe vondocker image ls, die Größe von Fluentd v1.14-windows-ltsc2019-1 beträgt 6,96 GB auf der Festplatte, aber das bedeutet nicht, dass diese Datenmenge heruntergeladen und extrahiert wurde.

In der Praxis werden während des Pull-Vorgangs nur die komprimierten 533,05 MB heruntergeladen und extrahiert.

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

Die Größenspalte zeigt die Gesamtgröße des Bildes, 6,96 GB. Aufschlüsselung:

Das Basisimage ist bereits auf der lokalen Festplatte vorhanden, was dazu führt, dass die Gesamtmenge auf der Festplatte zusätzlich 1,2 GB beträgt. Wenn Sie das nächste Mal die Anzahl der GB in der Größenspalte sehen, machen Sie sich keine allzu großen Sorgen. Wahrscheinlich befinden sich bereits mehr als 70% als zwischengespeichertes Container-Image auf der Festplatte.

Referenz

Verkürzen Sie die Startzeiten von Windows-Containern mit dem EC2 Image Builder und der Image-Cache-Strategie