Artikel ini dimaksudkan untuk dianggap sebagai ekstensi untuk arsitektur Garis Besar AKS, yang memberikan tinjauan menyeluruh tentang konfigurasi yang direkomendasikan untuk menyebarkan kluster AKS ke lingkungan produksi. Fokus artikel ini adalah memberikan panduan relatif terhadap penyebaran kontainer Windows pada AKS. Dengan demikian, artikel ini berfokus pada konfigurasi tersebut khusus untuk menyebarkan Windows di AKS dan Anda harus merujuk kembali ke dokumentasi Garis Besar AKS untuk konfigurasi yang sudah dijelaskan di sana.
Lihat proyek GitHub garis besar AKS Windows untuk meninjau implementasi referensi yang terkait dengan arsitektur referensi ini termasuk kode penyebaran sampel.
Desain jaringan
Desain jaringan yang digunakan dalam arsitektur ini didasarkan pada desain yang digunakan dalam arsitektur Garis Besar AKS dan oleh karena itu berbagi semua komponen inti dengan desain tersebut kecuali untuk perubahan berikut.
- Pengontrol domain Direktori Aktif telah ditambahkan untuk mendukung beban kerja berbasis Windows.
- Solusi masuk dalam arsitektur ini menggunakan proksi aplikasi Azure Front Door (AFD) dan Microsoft Entra daripada Azure App Gateway, yang digunakan dalam arsitektur Garis Besar AKS.
Catatan
Memigrasikan beban kerja windows ke AKS biasanya tidak termasuk upaya pemfaktoran ulang utama, dan dengan demikian beban kerja mungkin menggunakan fitur yang relatif mudah diterapkan di tempat, tetapi menimbulkan tantangan di Azure. Salah satu contohnya adalah aplikasi yang menggunakan autentikasi gMSA dan Kerberos. Ini adalah kasus penggunaan umum, dan dengan demikian, arsitektur ini mengarah dengan komponen yang memenuhi kebutuhan beban kerja tersebut. Secara khusus, menggunakan proksi aplikasi yang dihadirkan oleh AFD sebagai bagian dari jalur masuk. Jika beban kerja Anda tidak memerlukan dukungan ini, Anda dapat mengikuti panduan yang sama seperti di garis besar AKS untuk masuk.
Desain Ingress
Komponen:
- Azure Front Door dengan WAF: AFD adalah titik masuk yang menghadap publik untuk aplikasi yang dihosting di kluster AKS. AFD Premium digunakan dalam desain ini karena memungkinkan penggunaan Private Link, yang mengunci lalu lintas aplikasi internal ke jaringan privat, memberikan tingkat keamanan tertinggi. Web Application Firewall (WAF) melindungi dari eksploitasi dan kerentanan aplikasi web umum.
- Proksi aplikasi Microsoft Entra: Komponen ini berfungsi sebagai titik masuk kedua di depan load balancer internal yang dikelola oleh AKS. Ini memiliki ID Microsoft Entra yang diaktifkan untuk pra-autentikasi pengguna dan menggunakan kebijakan akses bersyariah untuk mencegah rentang IP yang tidak sah (proksi aplikasi melihat IP klien asal, yang dibandingkan dengan kebijakan akses bersyariah) dan pengguna mengakses situs. Ini adalah satu-satunya cara untuk merutekan permintaan autentikasi Kerberos saat menggunakan layanan Azure yang mendukung WAF. Untuk deskripsi terperinci tentang memberikan akses akses menyeluruh ke aplikasi yang dilindungi Proksi Aplikasi, lihat Delegasi Terbatas Kerberos untuk akses menyeluruh (SSO) ke aplikasi Anda dengan Proksi Aplikasi
- Load balancer internal: Dikelola oleh AKS. Penyeimbang beban ini mengekspos pengontrol ingress melalui alamat IP statis pribadi. Ini berfungsi sebagai satu titik kontak yang menerima permintaan HTTP masuk.
- Tidak ada pengontrol ingress dalam kluster (seperti Nginx) yang digunakan dalam arsitektur ini.
Untuk menerapkan desain ini, AFD harus dikonfigurasi untuk menggunakan URL Proksi Aplikasi yang dibuat saat aplikasi diterbitkan di layanan tersebut. Konfigurasi ini merutekan lalu lintas masuk ke proksi dan memungkinkan pra-autentikasi terjadi.
Catatan
Pelestarian IP sumber klien tidak didukung, sehingga arsitek aplikasi harus merencanakan langkah-langkah alternatif untuk eksternalisasi logika tersebut di luar kluster untuk aplikasi yang bergantung pada alamat IP sumber.
Topologi jaringan
Diagram di bawah ini menunjukkan desain jaringan hub-spoke yang digunakan dalam arsitektur ini.
Unduh file Visio arsitektur ini.
Topologi kumpulan simpul
Arsitektur ini menggunakan tiga kumpulan simpul: Kumpulan simpul sistem yang menjalankan Linux, kumpulan simpul pengguna yang menjalankan Linux, dan kumpulan simpul pengguna yang menjalankan Windows. Kumpulan simpul pengguna Windows dan Linux digunakan untuk beban kerja sementara kumpulan simpul sistem digunakan untuk semua konfigurasi tingkat sistem, seperti CoreDNS.
Arus lalu lintas ingress
- Klien mengirimkan permintaan HTTPS ke nama domain:
bicycle.contoso.com. Nama tersebut dikaitkan dengan catatan DNS A untuk alamat IP publik Azure Front Door. Lalu lintas ini dienkripsi untuk memastikan bahwa lalu lintas antara browser klien dan gateway tidak dapat diperiksa atau diubah. - Azure Front Door memiliki firewall aplikasi web terintegrasi (WAF) dan menegosiasikan jabat tangan TLS untuk
bicycle.contoso.com, yang hanya memungkinkan sandi yang aman. Azure Front Door Gateway adalah titik penghentian TLS, karena diperlukan untuk memproses aturan pemeriksaan WAF, dan menjalankan aturan perutean yang meneruskan lalu lintas ke backend yang dikonfigurasi. Sertifikat TLS disimpan di Azure Key Vault. - AFD merutekan permintaan pengguna ke Azure Proksi Aplikasi. AFD dikonfigurasi untuk hanya mengizinkan lalu lintas HTTPS. Pengguna harus mengautentikasi dengan ID Microsoft Entra jika pra-autentikasi diaktifkan.
- Proksi Aplikasi merutekan pengguna ke kontainer aplikasi backend melalui load balancer AKS.
Catatan
Anda dapat memberlakukan lalu lintas TLS end-to-end di setiap hop dalam alur, tetapi pertimbangkan untuk mengukur performa, latensi, dan dampak operasional saat membuat keputusan untuk mengamankan lalu lintas pod-ke-pod. Untuk sebagian besar kluster penyewa tunggal, dengan RBAC sarana kontrol yang tepat dan praktik Siklus Hidup Pengembangan Perangkat Lunak yang matang, cukup untuk memaksa enkripsi hingga pengontrol ingress dan melindungi backend dengan Web Application Firewall (WAF). Konfigurasi tersebut akan meminimalkan overhead dalam manajemen beban kerja dan dampak performa jaringan. Persyaratan beban kerja dan kepatuhan Anda akan menentukan di mana Anda melakukan penghentian TLS.
Arus lalu lintas keluar
Semua panduan yang ditemukan dalam artikel Garis Besar AKS berlaku di sini dengan rekomendasi tambahan untuk beban kerja Windows: Untuk memanfaatkan pembaruan Windows Server otomatis, Anda tidak boleh memblokir FQDN yang diperlukan di kumpulan aturan Azure Firewall Anda.
Catatan
Menggunakan kumpulan simpul terpisah untuk beban kerja berbasis Linux dan berbasis Windows memerlukan penggunaan pemilih simpul untuk memastikan bahwa ketika Anda menyebarkan beban kerja tertentu, itu disebarkan ke kumpulan simpul yang sesuai berdasarkan jenis beban kerja.
Perencanaan alamat IP
Tidak seperti kluster AKS dengan kumpulan simpul Linux, kluster AKS dengan kumpulan simpul Windows memerlukan Azure CNI. Menggunakan Azure CNI memungkinkan pod diberi alamat IP dari Azure Virtual Network. Pod kemudian dapat berkomunikasi melalui Azure Virtual Network sama seperti perangkat lainnya. Ini dapat terhubung ke pod lain, ke jaringan serekan atau jaringan lokal menggunakan ExpressRoute atau VPN, atau ke layanan Azure lainnya menggunakan Private Link.
Semua panduan relatif terhadap perencanaan alamat IP yang disediakan dalam artikel arsitektur Garis Besar AKS berlaku di sini, dengan satu rekomendasi tambahan: pertimbangkan untuk menyediakan subnet khusus untuk pengontrol domain Anda. Sehubungan dengan kumpulan simpul Windows, disarankan agar Anda memisahkannya dari kumpulan simpul lain secara logis melalui subnet terpisah.
Peningkatan kumpulan simpul
Proses untuk meningkatkan simpul Windows tidak berubah dari panduan yang disediakan dalam dokumentasi peningkatan gambar simpul Azure Kubernetes Service (AKS) tetapi Anda harus mempertimbangkan perbedaan jadwal berikut untuk merencanakan irama peningkatan Anda.
Microsoft menyediakan gambar Windows Server baru, termasuk patch terbaru, untuk simpul setiap bulan dan tidak melakukan patching atau pembaruan otomatis apa pun. Dengan demikian, Anda harus memperbarui simpul Anda secara manual atau terprogram sesuai dengan jadwal ini. Menggunakan GitHub Actions untuk membuat pekerjaan cron yang berjalan sesuai jadwal memungkinkan Anda menjadwalkan peningkatan bulanan secara terprogram. Panduan yang diberikan dalam dokumentasi yang ditautkan di atas mencerminkan proses simpul Linux, tetapi Anda dapat memperbarui file YAML untuk mengatur jadwal cron Anda agar berjalan setiap bulan daripada dua mingguan. Anda juga harus mengubah parameter "runs-on" dalam file YAML menjadi "windows-latest" untuk memastikan bahwa Anda meningkatkan ke gambar Windows Server terbaru.
Lihat panduan operator AKS tentang patching node pekerja dan pembaruan untuk panduan tambahan.
Catatan
Kluster harus ditingkatkan sebelum melakukan peningkatan simpul dan kumpulan simpul. Ikuti panduan Peningkatan kluster untuk melakukan peningkatan.
Menghitung pertimbangan
Ukuran gambar yang lebih besar yang terkait dengan gambar berbasis server Windows memerlukan penyebaran disk OS berukuran tepat di kumpulan simpul Anda. Menggunakan disk OS ephemeral masih disarankan untuk semua simpul, termasuk Windows, jadi pastikan Anda memahami persyaratan ukuran yang harus Anda patuhi saat merencanakan penyebaran Anda.
Pengelolaan identitas
Kontainer Windows tidak dapat bergabung dengan domain, jadi jika Anda memerlukan autentikasi dan otorisasi Direktori Aktif, Anda dapat menggunakan Akun Layanan Terkelola Grup (gMSA). Untuk menggunakan gMSA, Anda harus mengaktifkan profil gMSA pada kluster AKS yang menjalankan simpul Windows. Lihat dokumentasi gMSA AKS untuk tinjauan lengkap arsitektur dan panduan tentang mengaktifkan profil.
Penskalakan simpul dan pod
Panduan autoscaler kluster tidak berubah untuk kontainer Windows. Lihat dokumentasi Autoscaler kluster untuk panduan.
Dokumentasi kluster dasar menjelaskan pendekatan penskalaan manual dan otomatis yang tersedia untuk penskalaan pod. Kedua pendekatan tersedia untuk kluster yang menjalankan kontainer Windows dan panduan yang disediakan dalam artikel tersebut umumnya juga berlaku di sini.
Perbedaan antara kontainer Linux dan Windows sehubungan dengan operasi penskalaan pod adalah ukuran gambar dalam banyak kasus. Ukuran gambar kontainer Windows yang lebih besar kemungkinan akan meningkatkan jumlah waktu untuk menyelesaikan operasi penskalaan dan oleh karena itu beberapa pertimbangan tentang pendekatan penskalaan harus diambil. Skenario ini umum dengan aplikasi .NET warisan karena ukuran runtime .NET. Untuk mengurangi keterlambatan dalam menarik gambar ke bawah selama waktu penskalaan, Anda dapat menggunakan DaemonSet untuk menurunkan gambar dari ACR ke cache pada setiap simpul Windows, dan oleh karena itu memutar pod dengan gambar yang telah dimuat sebelumnya. Sejak saat itu, pod hanya perlu berjalan melalui proses konfigurasi aplikasi yang ditentukan untuk beban kerja Anda sebelum dibawa online.
Latihan tolok ukur harus dilakukan untuk memahami dampak waktu dari melakukan operasi penskalaan dan data ini harus ditimbang terhadap persyaratan bisnis. Jika beban kerja Anda perlu menskalakan lebih cepat dari yang mungkin melalui penskalaan otomatis, disarankan untuk mempertimbangkan solusi "hot spare" alternatif berikut:
Pertama-tama Anda harus melakukan pengujian garis besar untuk mengidentifikasi berapa banyak pod yang perlu Anda jalankan pada waktu pemuatan puncak dan waktu muat di luar puncak. Dengan garis besar yang ditetapkan ini, Anda dapat merencanakan jumlah simpul untuk memperhitungkan jumlah total simpul yang harus Anda sediakan pada waktu tertentu. Solusi ini melibatkan penggunaan penskalaan manual untuk kluster Anda dan mengatur jumlah awal simpul ke jumlah simpul di luar puncak yang diperlukan. Saat mendekati periode waktu puncak, Anda harus menskalakan ke jumlah waktu puncak beban puncak simpul secara preemtif. Seiring berjalannya waktu, Anda harus membangun kembali garis besar Anda secara teratur untuk memperhitungkan perubahan penggunaan aplikasi atau persyaratan bisnis lainnya.
Pemantauan
Kontainer yang menjalankan Windows dapat dipantau dengan Azure Monitor dan Container Insights, seperti kontainer Linux. Dengan demikian, panduan yang ditemukan dalam artikel Garis Besar AKS juga berlaku di sini untuk sebagian besar. Namun, pemantauan Container Insights untuk kluster Windows Server memiliki batasan berikut:
- Windows tidak memiliki metrik RSS Memori. Akibatnya, tidak tersedia untuk simpul dan kontainer Windows. Metrik Set Kerja tersedia
- Informasi kapasitas penyimpanan disk tidak tersedia untuk node Windows.
Anda juga dapat melengaskan Container Insights dengan menggunakan aturan pengumpulan data untuk mengumpulkan peristiwa dan penghitung kinerja dari sistem Windows Server Anda.
Catatan
Wawasan kontainer untuk sistem operasi Windows Server 2022 berada dalam pratinjau publik.
Manajemen kebijakan
Semua panduan kebijakan yang ditemukan dalam artikel garis besar AKS berlaku untuk beban kerja Windows. Kebijakan khusus Windows tambahan yang ditemukan dalam definisi bawaan Azure Policy untuk artikel referensi Azure Kubernetes Service yang perlu dipertimbangkan adalah:
- Kontainer Windows kluster Kubernetes tidak boleh mengatasi CPU dan memori
- Kontainer Windows kluster Kubernetes tidak boleh berjalan sebagai ContainerAdministrator
- Kontainer Windows kluster Kubernetes hanya boleh berjalan dengan pengguna dan grup pengguna domain yang disetujui
Klaster bootstrapping
Seperti halnya panduan bootstrapping kluster yang disediakan dalam artikel Garis Besar AKS, operator kluster harus mempertimbangkan pendekatan bootstrapping mereka untuk beban kerja berbasis Windows juga. Panduan yang sama yang disediakan dalam artikel Garis Besar AKS juga berlaku di sini.
Cost management
Semua panduan pengoptimalan biaya yang ditemukan dalam artikel Garis Besar AKS berlaku untuk beban kerja Windows. Pertimbangan biaya lain yang harus diperhitungkan adalah:
- Biaya lisensi untuk Windows Server meningkatkan biaya simpul untuk kluster AKS Anda. Rekomendasi pengoptimalan biaya untuk faktor ini termasuk pemesanan kapasitas atau menggunakan lisensi yang ada jika Anda sudah memilikinya untuk penggunaan bisnis lain.
- Lihat dokumentasi Azure Hybrid Benefit for Windows Server (AHUB) untuk mempelajari tentang diskon untuk lisensi Windows Server yang berlaku untuk Software Assurance (SA) Anda.
- Lihat FAQ kontainer Windows Server untuk instruksi tentang menerapkan manfaat ke kluster baru dan yang sudah ada.
- Ukuran gambar kontainer Windows dapat dikenakan biaya Azure Container Registry (ACR) tambahan karena jumlah penyimpanan yang diperlukan untuk beberapa gambar, jumlah simpul bersamaan yang menarik dari persyaratan ACR dan geo-replikasi.
Kontributor
Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.
Penulis utama:
- Isabelle Bersano | Arsitek Solusi Cloud
- Akshay Nimbalkar | Arsitek Solusi Cloud Utama
- Clayton Siemens | Pengembang Konten Utama
Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.
Langkah berikutnya
- Pelajari selengkapnya tentang kontainer Windows
Sumber daya terkait
- Pelajari cara menyebarkan kumpulan simpul Windows pada kluster AKS