Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Esecuzione di carichi di lavoro eterogenei
Kubernetes supporta cluster eterogenei in cui è possibile avere una combinazione di nodi Linux e Windows nello stesso cluster. All'interno di quel cluster, puoi avere una combinazione di Pod che funzionano su Linux e Pod che funzionano su Windows. Puoi persino eseguire più versioni di Windows nello stesso cluster. Tuttavia, ci sono diversi fattori (come indicato di seguito) che dovranno essere presi in considerazione quando si prende questa decisione.
## Assegnazione PODs ai nodi: best practice
Per mantenere i carichi di lavoro Linux e Windows sui rispettivi nodi specifici del sistema operativo, è necessario utilizzare una combinazione di selettori di nodi e contaminazioni/tolleranze. L'obiettivo principale della pianificazione dei carichi di lavoro in un ambiente eterogeneo è evitare di compromettere la compatibilità per i carichi di lavoro Linux esistenti.
## Garantire che i carichi di lavoro specifici del sistema operativo arrivino sull'host container appropriato
Gli utenti possono garantire che i contenitori Windows possano essere pianificati sull'host appropriato utilizzando NodeSelectors. Oggi tutti i nodi Kubernetes hanno le seguenti etichette predefinite:
```
kubernetes.io/os = [windows|linux]
kubernetes.io/arch = [amd64|arm64|...]
```
Se una specifica Pod non include un NodeSelector come`"kubernetes.io/os": windows`, il Pod può essere pianificato su qualsiasi host, Windows o Linux. Questo può essere problematico poiché un contenitore Windows può essere eseguito solo su Windows e un contenitore Linux può essere eseguito solo su Linux.
Negli ambienti aziendali, non è raro disporre di un gran numero di implementazioni preesistenti per contenitori Linux, nonché di un ecosistema di off-the-shelf configurazioni, come Helm charts. In queste situazioni, potresti essere restio ad apportare modifiche ai NodeSelectors di una distribuzione. **L'alternativa è usare Taints**.
Ad esempio: `--register-with-taints='os=windows:NoSchedule'`
Se stai usando EKS, eksctl offre modi per applicare i taint tramite ClusterConfig:
```
NodeGroups:
- name: windows-ng
amiFamily: WindowsServer2022FullContainer
...
labels:
nodeclass: windows2022
taints:
os: "windows:NoSchedule"
```
Aggiungendo una macchia a tutti i nodi di Windows, lo scheduler non pianificherà i pod su quei nodi a meno che non tollerino la contaminazione. Esempio di manifesto Pod:
```
nodeSelector:
kubernetes.io/os: windows
tolerations:
- key: "os"
operator: "Equal"
value: "windows"
effect: "NoSchedule"
```
## Gestione di più build di Windows nello stesso cluster
L'immagine di base del contenitore Windows utilizzata da ogni pod deve corrispondere alla stessa versione di build del kernel del nodo. **Se desideri utilizzare più build di Windows Server nello stesso cluster, devi impostare etichette di nodo aggiuntive, NodeSelectors o utilizzare un'etichetta chiamata windows-build.**
Kubernetes 1.17 aggiunge automaticamente una nuova etichetta **node.kubernetes.io/windows-build** per semplificare la gestione di più build di Windows nello stesso cluster. Se utilizzi una versione precedente, ti consigliamo di aggiungere questa etichetta manualmente ai nodi Windows.
Questa etichetta riflette il numero principale, secondario e di build di Windows che devono corrispondere per motivi di compatibilità. Di seguito sono riportati i valori utilizzati oggi per ogni versione di Windows Server.
È importante notare che Windows Server sta passando al Long-Term Servicing Channel (LTSC) come canale di rilascio principale. Il Windows Server Semi-Annual Channel (SAC) è stato ritirato il 9 agosto 2022. Non ci saranno future versioni SAC di Windows Server.
| Nome prodotto | Numeri di build |
| --- | --- |
| Server completo 2022 LTSC | 10.0.20348 |
| Server core 2019 LTSC | 10.0.17763 |
È possibile verificare la versione di build del sistema operativo tramite il seguente comando:
```
kubectl get nodes -o wide
```
L'output KERNEL-VERSION corrisponde alla versione build del sistema operativo Windows.
```
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
```
L'esempio seguente applica un NodeSelector aggiuntivo al manifesto del pod in modo che corrisponda alla versione Windows-build corretta quando si eseguono diverse versioni del sistema operativo di gruppi di nodi Windows.
```
nodeSelector:
kubernetes.io/os: windows
node.kubernetes.io/windows-build: '10.0.20348'
tolerations:
- key: "os"
operator: "Equal"
value: "windows"
effect: "NoSchedule"
```
## Semplificazione e tolleranza nei manifesti Pod utilizzando NodeSelector RuntimeClass
Puoi anche utilizzarlo per RuntimeClass semplificare il processo di utilizzo delle macchie e delle tolleranze. Ciò può essere ottenuto creando un RuntimeClass oggetto che viene utilizzato per incapsulare queste macchie e tolleranze.
Crea un RuntimeClass eseguendo il seguente manifesto:
```
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"
```
Una volta creata la classe Runtime, assegnala utilizzando come Spec nel manifesto del Pod:
```
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
```
## Managed Node Group Support
Per aiutare i clienti a eseguire le proprie applicazioni Windows in modo più semplificato, AWS ha lanciato il supporto per il [supporto Amazon EKS Managed Node Group (MNG) per i container Windows](https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-eks-automated-provisioning-lifecycle-management-windows-containers/) il 15 dicembre 2022. [Per aiutare ad allineare i team operativi, [Windows](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) è abilitato a utilizzare MNGs gli stessi flussi di lavoro e gli stessi strumenti di Linux. MNGs](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) Sono supportate le versioni complete e principali della famiglia AMI (Amazon Machine Image) di Windows Server 2019 e 2022.
Le seguenti famiglie AMI sono supportate per i Managed Node Groups (MNG).
| Famiglia AMI |
| --- |
| Windows\$1Core\$12019\$1x86\$164 |
| Windows\$1Full\$12019\$1x86\$164 |
| Windows\$1Core\$12022\$1x86\$164 |
| Windows\$1Full\$12022\$1x86\$164 |
## Documentazione aggiuntiva
Documentazione ufficiale AWS: https://docs.aws.amazon.com/eks/ latest/userguide/windows -support.html
Per capire meglio come funziona Pod Networking (CNI), controlla il seguente link: -networking.html https://docs.aws.amazon.com/eks/ latest/userguide/pod
Blog AWS sulla distribuzione di gruppi di nodi gestiti per Windows su EKS: https://aws.amazon.com/blogs/ contenitori/ -/deploying-amazon-eks-windowsmanaged-node-groups