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, bei 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 ausgeführt werden, und Pods, die unter Windows ausgeführt werden. 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 PODs für die Zuweisung zu Knoten
Um Linux- und Windows-Workloads auf ihren jeweiligen betriebssystemspezifischen Knoten zu belassen, müssen Sie eine Kombination aus Knotenselektoren und Fehler/Toleranzen verwenden. 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 betriebssystemspezifische 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-Like enthält, kann der Pod auf einem beliebigen Host`"kubernetes.io/os": windows`, 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 Implementierungen für Linux-Container sowie ein Ökosystem von off-the-shelf Konfigurationen 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 allen Windows-Knoten ein Taint hinzugefügt wird, plant der Scheduler keine Pods auf diesen Knoten, es sei denn, sie tolerieren den Taint. 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 von jedem Pod verwendete Windows-Container-Basis-Image 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 Knotenbezeichnungen oder NodeSelectors einrichten oder eine Bezeichnung namens Windows-Build nutzen.**
Kubernetes 1.17 fügt automatisch ein neues Label **node.kubernetes.io/windows-build** hinzu, um die Verwaltung mehrerer Windows-Builds im selben Cluster zu vereinfachen. Wenn Sie eine ältere Version ausführen, wird empfohlen, dieses Label manuell zu Windows-Knoten hinzuzufügen.
Diese Bezeichnung gibt die Haupt-, Minor- und Buildnummer 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 Release-Channel umsteigt. Der Windows Server Semi-Annual Channel (SAC) wurde am 9. August 2022 eingestellt. Es wird keine future SAC-Versionen von Windows Server geben.
| Product Name (Produktname) | Buildnummer (n) |
| --- | --- |
| Voller Server 2022 LTSC | 10.0.20348 |
| Serverkern 2019 LTSC | 10.0.17763 |
Es ist möglich, die Build-Version des Betriebssystems mit dem folgenden Befehl zu überprüfen:
```
kubectl get nodes -o wide
```
Die Ausgabe von KERNEL-VERSION 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 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 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 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 der richtigen Windows-Build-Version zu entsprechen, wenn verschiedene Betriebssystemversionen für 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 und Tolerierung NodeSelector in Pod-Manifesten mit RuntimeClass
Sie können Taints and Tolerations auch verwenden RuntimeClass , um den Prozess der Verwendung von Taints and Tolerations zu vereinfachen. Dies kann erreicht werden, indem ein RuntimeClass Objekt erstellt wird, das zur Verkapselung dieser Fehler und Toleranzen verwendet wird.
Erstellen Sie ein, 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 ist, 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
```
## Support für verwaltete Knotengruppen
Um Kunden dabei zu helfen, ihre Windows-Anwendungen effizienter auszuführen, hat AWS am 15. Dezember 2022 den Support für Amazon [EKS Managed Node Group (MNG) für Windows-Container](https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-eks-automated-provisioning-lifecycle-management-windows-containers/) eingeführt. [Um die Abstimmung der Betriebsteams zu erleichtern, MNGs werden [Windows](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) mit denselben Workflows und Tools wie Linux aktiviert. MNGs](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) Die Voll- 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.
| AMI-Familie |
| --- |
| Windows\$1Core\$12019\$1x86\$164 |
| Windows\$1Full\$12019\$1x86\$164 |
| Windows\$1Core\$12022\$1x86\$164 |
| Windows\$1FULL\$12022\$1x86\$164 |
## 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, schauen Sie sich den folgenden Link an: -networking.html https://docs.aws.amazon.com/eks/ latest/userguide/pod
AWS-Blog zur Bereitstellung von Managed Node Group für Windows auf EKS: https://aws.amazon.com/blogs/ containers/ -/deploying-amazon-eks-windowsmanaged-node-groups