Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Jaringan Windows

Ikhtisar Jaringan Kontainer Windows

Wadah Windows pada dasarnya berbeda dari wadah Linux. Kontainer Linux menggunakan konstruksi Linux seperti ruang nama, sistem file serikat, dan cgroups. Pada Windows, konstruksi tersebut diabstraksikan dari containerd oleh Host Compute Service (HCS). HCS bertindak sebagai lapisan API yang berada di atas implementasi container pada Windows. Windows container juga memanfaatkan Host Network Service (HNS) yang mendefinisikan topologi jaringan pada sebuah node.

Dari perspektif jaringan, HCS dan HNS membuat wadah Windows berfungsi seperti mesin virtual. Misalnya, setiap wadah memiliki adaptor jaringan virtual (vNIC) yang terhubung ke sakelar Hyper-V virtual (vSwitch) seperti yang ditunjukkan pada diagram di atas.

Manajemen Alamat IP

Sebuah node di Amazon EKS menggunakan Elastic Network Interface (ENI) untuk terhubung ke jaringan AWS VPC. Saat ini, hanya satu ENI per node pekerja Windows yang didukung. Manajemen alamat IP untuk node Windows dilakukan oleh VPC Resource Controller yang berjalan di bidang kontrol. Rincian lebih lanjut tentang alur kerja untuk manajemen alamat IP node Windows dapat ditemukan di sini.

Jumlah pod yang dapat didukung oleh node pekerja Windows ditentukan oleh ukuran node dan jumlah alamat IPv4 yang tersedia. Anda dapat menghitung alamat IPv4 yang tersedia pada node seperti di bawah ini:

Dengan menggunakan rumus di atas, kita dapat menghitung pod maks untuk pekerja Windows yang diangguhkan berdasarkan instance m5.large seperti di bawah ini:

Untuk informasi selengkapnya tentang berapa banyak alamat IP yang dapat didukung oleh jenis instans, lihat Alamat IP per antarmuka jaringan per jenis instans.

Pertimbangan utama lainnya adalah aliran lalu lintas jaringan. Dengan Windows ada risiko kelelahan port pada node dengan lebih dari 100 layanan. Ketika kondisi ini muncul, node akan mulai melemparkan kesalahan dengan pesan berikut:

“Pembuatan kebijakan gagal: hcn CreateLoadBalancer gagal di Win32: Port yang ditentukan sudah ada.”

Untuk mengatasi masalah ini, kami memanfaatkan Direct Server Return (DSR). DSR adalah implementasi distribusi beban jaringan asimetris. Dengan kata lain, lalu lintas permintaan dan respons menggunakan jalur jaringan yang berbeda. Fitur ini mempercepat komunikasi antar pod dan mengurangi risiko kelelahan port. Oleh karena itu kami merekomendasikan mengaktifkan DSR pada node Windows.

DSR diaktifkan secara default di AMI yang dioptimalkan Windows Server SAC EKS. Untuk AMI yang Dioptimalkan untuk Windows Server 2019 LTSC EKS, Anda harus mengaktifkannya selama penyediaan instance menggunakan skrip di bawah ini dan dengan menggunakan Windows Server 2019 Full atau Core sebagai AmiFamily di NodeGroup. eksctl Lihat eksctl custom AMI untuk informasi tambahan.

nodeGroups:
- name: windows-ng
  instanceType: c5.xlarge
  minSize: 1
  volumeSize: 50
  amiFamily: WindowsServer2019CoreContainer
  ssh:
    allow: false

Untuk menggunakan DSR di Windows Server 2019 dan yang lebih tinggi, Anda harus menentukan flag kube-proxy berikut selama startup instance. Anda dapat melakukan ini dengan menyesuaikan skrip data pengguna yang terkait dengan grup node yang dikelola sendiri Launch Template.

<powershell>
[string]$EKSBinDir = "$env:ProgramFiles\Amazon\EKS"
[string]$EKSBootstrapScriptName = 'Start-EKSBootstrap.ps1'
[string]$EKSBootstrapScriptFile = "$EKSBinDir\$EKSBootstrapScriptName"
(Get-Content $EKSBootstrapScriptFile).replace('"--proxy-mode=kernelspace",', '"--proxy-mode=kernelspace", "--feature-gates WinDSR=true", "--enable-dsr",') | Set-Content $EKSBootstrapScriptFile
& $EKSBootstrapScriptFile -EKSClusterName "eks-windows" -APIServerEndpoint "https://<REPLACE-EKS-CLUSTER-CONFIG-API-SERVER>" -Base64ClusterCA "<REPLACE-EKSCLUSTER-CONFIG-DETAILS-CA>" -DNSClusterIP "172.20.0.10" -KubeletExtraArgs "--node-labels=alpha.eksctl.io/cluster-name=eks-windows,alpha.eksctl.io/nodegroup-name=windows-ng-ltsc2019 --register-with-taints=" 3>&1 4>&1 5>&1 6>&1
</powershell>

Enablement DSR dapat diverifikasi mengikuti petunjuk di blog Microsoft Networking dan Windows Containers di AWS Lab.

Jika menjaga alamat IPv4 yang tersedia dan meminimalkan pemborosan sangat penting untuk subnet Anda, umumnya disarankan untuk menghindari menggunakan mode delegasi awalan seperti yang disebutkan dalam Mode Awalan untuk Windows - Kapan harus menghindari. Jika penggunaan delegasi awalan masih diinginkan, Anda dapat mengambil langkah-langkah untuk mengoptimalkan pemanfaatan alamat IPv4 di subnet Anda. Lihat Meng onfigurasi Parameter untuk Delegasi Awalan untuk petunjuk terperinci tentang cara menyempurnakan permintaan alamat IPv4 dan proses alokasi. Menyesuaikan konfigurasi ini dapat membantu Anda mencapai keseimbangan antara melestarikan alamat IPv4 dan manfaat kepadatan pod dari delegasi awalan.

Saat menggunakan pengaturan default untuk menetapkan alamat IPv4 sekunder, saat ini tidak ada konfigurasi yang didukung untuk memanipulasi cara VPC Resource Controller meminta dan mengalokasikan alamat IPv4. Lebih khusus lagi, minimum-ip-target dan hanya warm-ip-target didukung untuk mode delegasi awalan. Perhatikan juga bahwa dalam mode IP sekunder, tergantung pada alamat IP yang tersedia di antarmuka, Pengontrol Sumber Daya VPC biasanya akan mengalokasikan 3 alamat IPv4 yang tidak digunakan pada node atas nama Anda untuk mempertahankan IP hangat untuk waktu startup pod yang lebih cepat. Jika Anda ingin meminimalkan pemborosan IP dari alamat IP hangat yang tidak digunakan, Anda dapat bertujuan untuk menjadwalkan lebih banyak pod pada node Windows tertentu sehingga Anda menggunakan sebanyak mungkin kapasitas alamat IP ENI. Lebih eksplisit, Anda dapat menghindari IP hangat yang tidak digunakan jika semua alamat IP di ENI sudah digunakan oleh node dan pod yang sedang berjalan. Solusi lain untuk membantu Anda mengatasi kendala dengan ketersediaan alamat IP di subnet Anda adalah dengan menjelajahi peningkatan ukuran subnet Anda atau memisahkan node Windows Anda ke subnet khusus mereka sendiri.

Selain itu, penting untuk dicatat bahwa IPv6 tidak didukung pada node Windows saat ini.

Opsi Antarmuka Jaringan Kontainer (CNI)

AWSVPC CNI adalah plugin CNI de facto untuk node pekerja Windows dan Linux. Sementara AWSVPC CNI memenuhi kebutuhan banyak pelanggan, masih ada kalanya Anda perlu mempertimbangkan alternatif seperti jaringan overlay untuk menghindari kehabisan IP. Dalam kasus ini, Calico CNI dapat digunakan sebagai pengganti AWSVPC CNI. Project Calico adalah perangkat lunak open source yang dikembangkan oleh Tig era. Perangkat lunak itu termasuk CNI yang bekerja dengan EKS. Petunjuk untuk menginstal Calico CNI di EKS dapat ditemukan di halaman instalasi Project Calico EKS.

Kebijakan Jaringan

Ini dianggap sebagai praktik terbaik untuk mengubah dari mode default komunikasi terbuka antara pod di cluster Kubernetes Anda untuk membatasi akses berdasarkan kebijakan jaringan. Open source Project Calico memiliki dukungan kuat untuk kebijakan jaringan yang bekerja dengan node Linux dan Windows. Fitur ini terpisah dan tidak tergantung pada penggunaan Calico CNI. Oleh karena itu kami merekomendasikan menginstal Calico dan menggunakannya untuk manajemen kebijakan jaringan.

Untuk petunjuk pemasangan Calico di Amazon EKS, lihat Meng instal Calico di Amazon EKS di situs web Tigera.

Selain itu, saran yang diberikan dalam Panduan Praktik Terbaik Amazon EKS untuk Keamanan - Bagian Jaringan berlaku sama untuk cluster EKS dengan node pekerja Windows, namun, beberapa fitur seperti “Grup Keamanan untuk Pod” tidak didukung oleh Windows saat ini.