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.

Vermeiden von OOM-Fehlern

Windows verfügt nicht wie Linux über einen Prozesskiller bei unzureichendem Arbeitsspeicher. Windows behandelt alle Speicherzuweisungen im Benutzermodus immer als virtuell, und Auslagerungsdateien sind obligatorisch. Der Nettoeffekt ist, dass Windows Probleme mit Speicherüberschreitungen nicht auf die gleiche Weise löst wie Linux. Prozesse werden per Page auf die Festplatte weitergeleitet, anstatt bei unzureichendem Arbeitsspeicher (OOM) beendet zu werden. Wenn zu viel Arbeitsspeicher zur Verfügung steht und der gesamte physische Speicher erschöpft ist, kann das Auslagern die Leistung beeinträchtigen.

Reservieren von System- und Kubelet-Speicher

Anders als unter Linux, wo --kubelet-reserve die Ressourcenreservierung für Kubernetes-Systemdämonen wie Kubelet, Container Runtime usw. --system-reserve erfasst und die Ressourcenreservierung für Betriebssystem-Daemons wie sshd, udev usw. erfasst wird. Unter Windows erfassen und setzen diese Flags keine Speicherbeschränkungen für Kubelet oder Prozesse, die auf dem Knoten ausgeführt werden.

Sie können diese Flags jedoch kombinieren, um die Kapazität auf dem Knoten mit der Speicherressourcenbegrenzung des Pod-Manifests zu reduzieren, um die Speicherzuweisung pro Pod zu steuern. NodeAllocatable Mit dieser Strategie haben Sie eine bessere Kontrolle über die Speicherzuweisung und verfügen über einen Mechanismus zur Minimierung von Speichermangel (OOM) auf Windows-Knoten.

Auf Windows-Knoten empfiehlt es sich, mindestens 2 GB Arbeitsspeicher für das Betriebssystem und den Prozess zu reservieren. Zum --kubelet-reserve and/or --system-reserve NodeAllocatable Reduzieren verwenden.

Verwenden Sie die CloudFormation Vorlage gemäß der Amazon EKS-Dokumentation für Self-managed Windows-Knoten, um eine neue Windows-Knotengruppe mit Anpassungen an der Kubelet-Konfiguration zu starten. Das CloudFormation hat ein Element namensBootstrapArguments, das dasselbe ist wie. KubeletExtraArgs Verwenden Sie es mit den folgenden Flags und Werten:

--kube-reserved memory=0.5Gi,ephemeral-storage=1Gi --system-reserved memory=1.5Gi,ephemeral-storage=1Gi --eviction-hard memory.available<200Mi,nodefs.available<10%"

Wenn eksctl das Bereitstellungstool ist, lesen Sie in der folgenden Dokumentation nach, um die Kubelet-Konfiguration anzupassen https://eksctl.io/usage/customizing-the-kubelet/

Speicheranforderungen für den Windows-Container

Gemäß der Microsoft-Dokumentation benötigt ein Windows Server-Basisimage für NANO mindestens 30 MB, wohingegen Server Core 45 MB benötigt. Diese Zahlen steigen, wenn Sie Windows-Komponenten wie das.NET Framework, Webdienste wie IIS und Anwendungen hinzufügen.

Es ist wichtig, dass Sie wissen, wie viel Speicher Ihr Windows-Container-Image mindestens benötigt, d. h. das Basis-Image plus seine Anwendungsebenen, und es als Container resources/requests in der Pod-Spezifikation festlegen. Sie sollten auch ein Limit festlegen, um zu verhindern, dass Pods im Falle eines Anwendungsproblems den gesamten verfügbaren Knotenspeicher verbrauchen.

Wenn im folgenden Beispiel der Kubernetes-Scheduler versucht, einen Pod auf einem Knoten zu platzieren, werden die Anforderungen des Pods verwendet, um zu ermitteln, welcher Knoten über ausreichende Ressourcen für das Scheduling verfügt.

 spec:
  - name: iis
    image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
    resources:
      limits:
        cpu: 1
        memory: 800Mi
      requests:
        cpu: .1
        memory: 128Mi

Schlussfolgerung

Die Verwendung dieses Ansatzes minimiert das Risiko einer Speichererschöpfung, verhindert jedoch nicht, dass dies geschieht. Mithilfe von Amazon CloudWatch Metrics können Sie Warnmeldungen und Abhilfemaßnahmen für den Fall einrichten, dass der Speicherplatz knapp wird.