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.

Ausführung heterogener Workloads

Kubernetes unterstützt heterogene Cluster, in denen Sie eine Mischung aus Linux- und Windows-Knoten im selben Cluster haben können. Innerhalb dieses Clusters können Sie eine Mischung aus Pods haben, die unter Linux laufen, und Pods, die unter Windows laufen. Sie können sogar mehrere Versionen von Windows im selben Cluster ausführen. Es gibt jedoch mehrere Faktoren (wie unten erwähnt), die bei dieser Entscheidung berücksichtigt werden müssen.

Bewährte Methoden beim Zuweisen von PODs zu Knoten

Um die Linux- und Windows-Workloads auf ihren jeweiligen OS-specific Knoten zu belassen, müssen Sie eine Kombination aus Knotenselektoren und verwenden. taints/tolerations Das Hauptziel der Planung von Workloads in einer heterogenen Umgebung besteht darin, zu verhindern, dass die Kompatibilität vorhandener Linux-Workloads beeinträchtigt wird.

Sicherstellen, dass OS-specific Workloads auf dem entsprechenden Container-Host landen

Benutzer können mithilfe von NodeSelectors sicherstellen, dass Windows-Container auf dem entsprechenden Host geplant werden können. Alle Kubernetes-Knoten haben heute die folgenden Standardbezeichnungen:

kubernetes.io/os = [windows|linux]
kubernetes.io/arch = [amd64|arm64|...]

Wenn eine Pod-Spezifikation keinen NodeSelector wie zum Beispiel enthält"kubernetes.io/os": windows, kann der Pod auf einem beliebigen Host, Windows oder Linux, geplant werden. Dies kann problematisch sein, da ein Windows-Container nur unter Windows und ein Linux-Container nur unter Linux ausgeführt werden kann.

In Unternehmensumgebungen ist es nicht ungewöhnlich, eine große Anzahl bereits vorhandener Bereitstellungen für Linux-Container sowie ein Ökosystem von Standardkonfigurationen wie Helm-Charts zu haben. In diesen Situationen zögern Sie möglicherweise, Änderungen an den NodeSelectors einer Bereitstellung vorzunehmen. Die Alternative besteht darin, Taints zu verwenden.

Beispiel: --register-with-taints='os=windows:NoSchedule'

Wenn Sie EKS verwenden, bietet eksctl Möglichkeiten, Taints über ClusterConfig anzuwenden:

NodeGroups:
  - name: windows-ng
    amiFamily: WindowsServer2022FullContainer
    ...
    labels:
      nodeclass: windows2022
    taints:
      os: "windows:NoSchedule"

Wenn Sie allen Windows-Knoten eine Verunreinigung hinzufügen, plant der Scheduler keine Pods auf diesen Knoten, es sei denn, sie tolerieren die Verunreinigung. Beispiel für ein Pod-Manifest:

nodeSelector:
    kubernetes.io/os: windows
tolerations:
    - key: "os"
      operator: "Equal"
      value: "windows"
      effect: "NoSchedule"

Umgang mit mehreren Windows-Builds im selben Cluster

Das Windows-Container-Basisimage, das von jedem Pod verwendet wird, muss derselben Kernel-Build-Version wie der Knoten entsprechen. Wenn Sie mehrere Windows Server-Builds im selben Cluster verwenden möchten, sollten Sie zusätzliche Node-Labels, NodeSelectors, einrichten oder ein Label namens Windows-Build verwenden.

Kubernetes 1.17 fügt automatisch ein neues Label node.kubernetes hinzu. io/windows-build, um die Verwaltung mehrerer Windows-Builds im selben Cluster zu vereinfachen. Wenn Sie eine ältere Version verwenden, wird empfohlen, dieses Label manuell zu den Windows-Knoten hinzuzufügen.

Dieses Label gibt die Hauptnummer, Nebennummer und Build-Nummer von Windows wieder, die aus Kompatibilitätsgründen übereinstimmen müssen. Im Folgenden sind die Werte aufgeführt, die heute für jede Windows Server-Version verwendet werden.

Es ist wichtig zu beachten, dass Windows Server auf den Long-Term Servicing Channel (LTSC) als primären Versionskanal umgestellt wird. Der Windows Server Semi-Annual Channel (SAC) wurde am 9. August 2022 eingestellt. Es wird keine zukünftigen SAC-Versionen von Windows Server geben.

Es ist möglich, die Build-Version des Betriebssystems mit dem folgenden Befehl zu überprüfen:

kubectl get nodes -o wide

Die KERNEL-VERSION Ausgabe entspricht der Build-Version des Windows-Betriebssystems.

NAME                          STATUS   ROLES    AGE   VERSION                INTERNAL-IP   EXTERNAL-IP     OS-IMAGE                         KERNEL-VERSION                  CONTAINER-RUNTIME
ip-10-10-2-235.ec2.internal   Ready    <none>   23m   v1.24.7-eks-fb459a0    10.10.2.235   3.236.30.157    Windows Server 2022 Datacenter   10.0.20348.1607                 containerd://1.6.6
ip-10-10-31-27.ec2.internal   Ready    <none>   23m   v1.24.7-eks-fb459a0    10.10.31.27   44.204.218.24   Windows Server 2019 Datacenter   10.0.17763.4131                 containerd://1.6.6
ip-10-10-7-54.ec2.internal    Ready    <none>   31m   v1.24.11-eks-a59e1f0   10.10.7.54    3.227.8.172     Amazon Linux 2                   5.10.173-154.642.amzn2.x86_64   containerd://1.6.19

Das folgende Beispiel wendet einen zusätzlichen NodeSelector auf das Pod-Manifest an, um die richtige Windows-build Version abzugleichen, wenn verschiedene Betriebssystemversionen von Windows-Knotengruppen ausgeführt werden.

nodeSelector:
    kubernetes.io/os: windows
    node.kubernetes.io/windows-build: '10.0.20348'
tolerations:
    - key: "os"
    operator: "Equal"
    value: "windows"
    effect: "NoSchedule"

Vereinfachung NodeSelector und Toleranz in Pod-Manifesten mit RuntimeClass

Sie können es auch verwenden, RuntimeClass um den Prozess der Verwendung von Taints und Tolerances zu vereinfachen. Dies kann erreicht werden, indem Sie ein RuntimeClass Objekt erstellen, das zur Verkapselung dieser Flecken und Toleranzen verwendet wird.

Erstellen Sie eine, RuntimeClass indem Sie das folgende Manifest ausführen:

apiVersion: node.k8s.io/v1beta1
kind: RuntimeClass
metadata:
  name: windows-2022
handler: 'docker'
scheduling:
  nodeSelector:
    kubernetes.io/os: 'windows'
    kubernetes.io/arch: 'amd64'
    node.kubernetes.io/windows-build: '10.0.20348'
  tolerations:
  - effect: NoSchedule
    key: os
    operator: Equal
    value: "windows"

Sobald die Runtime-Klasse erstellt wurde, weisen Sie sie als Spezifikation im Pod-Manifest zu:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: iis-2022
  labels:
    app: iis-2022
spec:
  replicas: 1
  template:
    metadata:
      name: iis-2022
      labels:
        app: iis-2022
    spec:
      runtimeClassName: windows-2022
      containers:
      - name: iis

Unterstützung für verwaltete Knotengruppen

Um Kunden dabei zu helfen, ihre Windows-Anwendungen effizienter auszuführen, hat AWS am 15. Dezember 2022 die Unterstützung für Amazon EKS Managed Node Group (MNG) -Unterstützung für Windows-Container eingeführt. Um die Abstimmung der Betriebsteams zu erleichtern, werden Windows-MNGs mithilfe derselben Workflows und Tools wie Linux-MNGs aktiviert. Vollständige Versionen und Kernversionen der AMI-Familie (Amazon Machine Image) von Windows Server 2019 und 2022 werden unterstützt.

Die folgenden AMI-Familien werden für Managed Node Groups (MNG) unterstützt.

Zusätzliche Dokumentationen

Offizielle AWS-Dokumentation: https://docs.aws.amazon.com/eks/latest/userguide/windows-support.html

Um besser zu verstehen, wie Pod Networking (CNI) funktioniert, klicken Sie auf den folgenden Link: https://docs.aws.amazon.com/eks/latest/userguide/pod-networking.html

AWS-Blog zur Bereitstellung einer verwalteten Knotengruppe für Windows auf EKS: https://aws.amazon.com/blogs/containers/deploying-amazon-eks-windows-managed-node-groups/