Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Menjalankan beban kerja heterogen
Kubernetes memiliki dukungan untuk cluster heterogen di mana Anda dapat memiliki campuran node Linux dan Windows dalam cluster yang sama. Di dalam cluster itu, Anda dapat memiliki campuran Pod yang berjalan di Linux dan Pod yang berjalan di Windows. Anda bahkan dapat menjalankan beberapa versi Windows di cluster yang sama. Namun, ada beberapa faktor (seperti yang disebutkan di bawah) yang perlu diperhitungkan saat membuat keputusan ini.
## Menetapkan POD ke Node Praktik terbaik
Untuk menjaga beban kerja Linux dan Windows pada OS-specific node masing-masing, Anda perlu menggunakan beberapa kombinasi pemilih node dan. taints/tolerations Tujuan utama penjadwalan beban kerja dalam lingkungan yang heterogen adalah untuk menghindari pemutusan kompatibilitas untuk beban kerja Linux yang ada.
## Memas OS-specific tikan beban kerja mendarat di host kontainer yang sesuai
Pengguna dapat memastikan wadah Windows dapat dijadwalkan pada host yang sesuai menggunakan NodeSelectors. Semua node Kubernetes saat ini memiliki label default berikut:
```
kubernetes.io/os = [windows|linux]
kubernetes.io/arch = [amd64|arm64|...]
```
Jika spesifikasi Pod tidak menyertakan NodeSelector seperti`"kubernetes.io/os": windows`, Pod dapat dijadwalkan pada host apa pun, Windows atau Linux. Ini bisa menjadi masalah karena wadah Windows hanya dapat berjalan di Windows dan wadah Linux hanya dapat berjalan di Linux.
Di lingkungan Perusahaan, tidak jarang memiliki sejumlah besar penerapan yang sudah ada sebelumnya untuk wadah Linux, serta ekosistem konfigurasi siap pakai, seperti bagan Helm. Dalam situasi ini, Anda mungkin ragu untuk membuat perubahan pada NodeSelectors penerapan. **Alternatifnya adalah menggunakan Taints**.
Misalnya: `--register-with-taints='os=windows:NoSchedule'`
Jika Anda menggunakan EKS, eksctl menawarkan cara untuk menerapkan noda melalui ClusterConfig:
```
NodeGroups:
- name: windows-ng
amiFamily: WindowsServer2022FullContainer
...
labels:
nodeclass: windows2022
taints:
os: "windows:NoSchedule"
```
Menambahkan noda ke semua node Windows, penjadwal tidak akan menjadwalkan pod pada node tersebut kecuali mereka mentolerir noda tersebut. Contoh manifes pod:
```
nodeSelector:
kubernetes.io/os: windows
tolerations:
- key: "os"
operator: "Equal"
value: "windows"
effect: "NoSchedule"
```
## Menangani beberapa build Windows di cluster yang sama
Gambar dasar wadah Windows yang digunakan oleh setiap pod harus cocok dengan versi build kernel yang sama dengan node. Jika Anda ingin menggunakan beberapa build Windows Server di cluster yang sama, maka Anda harus mengatur label node tambahan, NodeSelectors atau memanfaatkan label yang disebut windows-build. ** **
Kubernetes 1.17 secara otomatis menambahkan label baru node.kubernetes. ** io/windows-build ** untuk menyederhanakan pengelolaan beberapa Windows build di cluster yang sama. Jika Anda menjalankan versi yang lebih lama, maka disarankan untuk menambahkan label ini secara manual ke node Windows.
Label ini mencerminkan nomor mayor, minor, dan build Windows yang perlu dicocokkan untuk kompatibilitas. Di bawah ini adalah nilai yang digunakan hari ini untuk setiap versi Windows Server.
Penting untuk dicatat bahwa Windows Server pindah ke Serv Long-Term icing Channel (LTSC) sebagai saluran rilis utama. Windows Server Semi-Annual Channel (SAC) pensiun pada 9 Agustus 2022. Tidak akan ada rilis SAC Windows Server di masa mendatang.
| Nama Produk | Nomor Bangun |
| --- | --- |
| Server penuh 2022 LTSC | 10.020348 |
| Inti server 2019 LTSC | 10.0.17763 |
Dimungkinkan untuk memeriksa versi build OS melalui perintah berikut:
```
kubectl get nodes -o wide
```
KERNEL-VERSION Outputnya cocok dengan versi build OS 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
```
Contoh di bawah ini menerapkan NodeSelector tambahan ke manifes pod untuk mencocokkan Windows-build versi yang benar saat menjalankan versi OS grup node Windows yang berbeda.
```
nodeSelector:
kubernetes.io/os: windows
node.kubernetes.io/windows-build: '10.0.20348'
tolerations:
- key: "os"
operator: "Equal"
value: "windows"
effect: "NoSchedule"
```
## Penyederhanaan NodeSelector dan Toleransi dalam manifestasi Pod menggunakan RuntimeClass
Anda juga dapat memanfaatkan RuntimeClass untuk menyederhanakan proses penggunaan noda dan toleransi. Hal ini dapat dicapai dengan membuat RuntimeClass objek yang digunakan untuk merangkum noda dan toleransi ini.
Buat RuntimeClass dengan menjalankan manifes berikut:
```
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"
```
Setelah Runtimeclass dibuat, tetapkan menggunakan sebagai Spec pada manifes 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
```
## Dukungan Grup Node Terkelola
Untuk membantu pelanggan menjalankan aplikasi Windows mereka dengan cara yang lebih efisien, AWS meluncurkan dukungan untuk dukungan Amazon [ EKS Managed Node Group (MNG) untuk wadah Windows ](https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-eks-automated-provisioning-lifecycle-management-windows-containers/) pada 15 Desember 2022. Untuk membantu menyelaraskan tim operasi, MNG [ Windows ](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) diaktifkan menggunakan alur kerja dan alat yang sama seperti MNG Linux. [https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) Versi keluarga AMI penuh dan inti (Amazon Machine Image) Windows Server 2019 dan 2022 didukung.
Keluarga AMI berikut didukung untuk Grup Node Terkelola (MNG).
| Keluarga AMI |
| --- |
| Windows\_Core\_2019\_x86\_64 |
| Windows\_full\_2019\_x86\_64 |
| Windows\_Core\_2022\_x86\_64 |
| Windows\_full\_2022\_x86\_64 |
## Dokumentasi tambahan
Dokumentasi Resmi AWS: https://docs.aws.amazon.com/eks/latest/userguide/windows-support.html
Untuk lebih memahami cara kerja Pod Networking (CNI), periksa tautan berikut: https://docs.aws.amazon.com/eks/latest/userguide/pod-networking.html
Blog AWS tentang Menyebarkan Grup Node Terkelola untuk Windows di EKS: https://aws.amazon.com/blogs/containers/deploying-amazon-eks-windows-managed-node-groups/