Arsitektur ini merinci cara menjalankan beberapa instans kluster Azure Kubernetes Service (AKS) di beberapa wilayah dalam konfigurasi aktif/aktif dan sangat tersedia.
Arsitektur ini dibangun berdasarkan arsitektur garis besar AKS, titik awal microsoft yang direkomendasikan untuk infrastruktur AKS. Garis besar AKS merinci fitur infrastructural seperti ID Beban Kerja Microsoft Entra, pembatasan masuk dan keluar, batas sumber daya, dan konfigurasi infrastruktur AKS aman lainnya. Detail infrastructural ini tidak tercakup dalam dokumen ini. Sebaiknya Anda terbiasa dengan garis besar AKS sebelum melanjutkan konten multi-wilayah.
Sistem
Unduh file Visio arsitektur ini.
Komponen
Banyak komponen dan layanan Azure digunakan dalam arsitektur AKS multi-wilayah ini. Hanya komponen dengan keunikan arsitektur multi-kluster ini yang tercantum di sini. Untuk sisanya, lihat arsitektur Garis Besar AKS.
- Kluster AKS regional: Beberapa kluster AKS disebarkan, masing-masing di wilayah Azure terpisah. Pada saat berjalan normal, lalu lintas jaringan dapat dialihkan antar wilayah. Jika satu bagian tidak tersedia, lalu lintas data dialihkan ke bagian yang paling dekat dengan pengguna yang melakukan permintaan.
- Jaringan hub-spoke regional: Pasangan jaringan hub-spoke regional disebarkan untuk setiap instans AKS regional. Kebijakan Azure Firewall Manager digunakan untuk mengelola kebijakan dalam penggunaan firewall di tiap-tiap bagian.
- Brankas kunci regional: Azure Key Vault disediakan di setiap wilayah. Brankas kunci digunakan untuk menyimpan nilai dan kunci sensitif khusus untuk kluster AKS dan layanan pendukung yang ada di wilayah tersebut.
- Beberapa ruang kerja log: Ruang kerja Analitik Log Regional digunakan untuk menyimpan metrik jaringan regional dan log diagnostik. Selain itu, Log Analytics bersama digunakan untuk menyimpan metrik dan log diagnostik semua AKS.
- Profil Azure Front Door Global: Azure Front Door digunakan untuk memuat keseimbangan dan merutekan lalu lintas ke instans Azure Application Gateway regional, yang berada di depan setiap kluster AKS. Azure Front Door memungkinkan perutean global lapisan 7, yang keduanya diperlukan untuk arsitektur ini.
- Registri kontainer global: Gambar kontainer untuk beban kerja disimpan dalam registri kontainer terkelola. Dalam arsitektur ini, satu Azure Container Registry digunakan untuk semua Kubernetes. Replikasi geografis untuk Azure Container Registry memungkinkan replikasi gambar ke Azure yang dipilih dan menyediakan akses lanjutan ke gambar meskipun bagian tersebut mengalami pemadaman.
Pola desain
Arsitektur ini menggunakan dua pola desain cloud:
- Geode (simpul geografis), di mana wilayah mana pun dapat melayani permintaan apa pun.
- Stempel Penyebaran, di mana beberapa salinan independen aplikasi atau komponen aplikasi disebarkan dari satu sumber, seperti templat penyebaran.
Pertimbangan pola geode
Saat memilih wilayah untuk menyebarkan setiap kluster AKS, pertimbangkan wilayah yang dekat dengan konsumen beban kerja atau pelanggan Anda. Selain itu, pertimbangkan untuk menggunakan replikasi lintas wilayah. Replikasi lintas wilayah secara asinkron mereplikasi aplikasi dan data yang sama di seluruh wilayah Azure lainnya untuk perlindungan pemulihan bencana. Saat kluster Anda menskalakan di luar dua wilayah, lanjutkan merencanakan replikasi lintas wilayah untuk setiap pasangan kluster AKS.
Dalam setiap wilayah, simpul di kumpulan simpul AKS tersebar di beberapa zona ketersediaan untuk membantu mencegah masalah karena kegagalan zona. Zona ketersediaan didukung oleh satu set wilayah terbatas, yang mempengaruhi penempatan klaster regional. Untuk informasi selengkapnya tentang AKS dan zona ketersediaan, termasuk daftar wilayah yang didukung, lihat Zona ketersediaan AKS.
Pertimbangan penggunaan stempel
Saat Mengelola solusi AKS multi-wilayah, Anda menyebarkan beberapa kluster AKS di beberapa wilayah. Masing-masing kluster ini dianggap sebagai stempel. Jika ada kegagalan regional, atau jika Anda perlu menambahkan lebih banyak kapasitas atau kehadiran regional untuk kluster Anda, Anda mungkin perlu membuat instans stempel baru. Saat memilih proses untuk membuat dan mengelola stempel penyebaran, penting untuk mempertimbangkan hal-hal berikut:
- Pilih teknologi yang sesuai untuk definisi stempel yang memungkinkan konfigurasi umum. Misalnya, Anda dapat menggunakan Bicep untuk menentukan infrastruktur sebagai kode.
- Berikan nilai khusus instans menggunakan mekanisme input penyebaran seperti variabel atau file parameter.
- Pilih alat penyebaran yang memungkinkan penyebaran yang fleksibel, dapat diulang, dan idempogen.
- Dalam konfigurasi stempel aktif/aktif, pertimbangkan bagaimana lalu lintas seimbang di setiap stempel. Arsitektur ini menggunakan Azure Front Door untuk penyeimbangan beban global.
- Saat stempel ditambahkan dan dihapus dari koleksi, pertimbangkan masalah kapasitas dan biaya.
- Pertimbangkan cara mendapatkan visibilitas dan memantau pengumpulan stempel sebagai satu unit.
Masing-masing item ini dirinci dengan panduan khusus di bagian berikut.
Manajemen armada
Solusi ini mewakili topologi multi-kluster dan multi-wilayah, tanpa dimasukkannya orkestrator tingkat lanjut untuk memperlakukan semua kluster sebagai bagian dari armada terpadu. Ketika jumlah kluster meningkat, pertimbangkan untuk mendaftarkan anggota di Azure Kubernetes Fleet Manager untuk manajemen skala kluster yang berpartisipasi dengan lebih baik. Arsitektur infrastruktur yang disajikan di sini pada dasarnya tidak berubah dengan pendaftaran ke Fleet Manager, tetapi operasi hari-2 dan manfaat aktivitas serupa dari sarana kontrol yang dapat menargetkan beberapa kluster secara bersamaan.
Pertimbangan
Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan yang dapat digunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.
Penyebaran klaster dan bootstrapping
Saat menyebarkan beberapa kluster Kubernetes dalam konfigurasi yang sangat tersedia dan terdistribusi secara geografis, penting untuk mempertimbangkan jumlah setiap kluster Kubernetes sebagai unit yang digabungkan. Anda mungkin ingin mengembangkan strategi berbasis kode untuk penyebaran dan konfigurasi otomatis untuk memastikan bahwa setiap instans Kubernetes seidentik mungkin. Pertimbangkan strategi untuk penskalaan keluar dan masuk, termasuk dengan menambahkan atau menghapus kluster Kubernetes lainnya. Desain Anda, serta rencana penyebaran dan konfigurasi, harus memperhitungkan pemadaman zona ketersediaan, kegagalan regional, dan skenario umum lainnya.
Definisi klaster
Banyak opsi untuk menyebarkan klaster Azure Kubernetes Service. Modul portal Azure, Azure CLI, dan Azure PowerShell adalah semua opsi yang layak untuk menyebarkan kluster AKS individual atau noncoupled. Namun, metode ini dapat menghadirkan tantangan ketika bekerja dengan banyak kluster AKS yang digabungkan dengan erat. Misalnya, menggunakan portal Azure membuka kesempatan untuk kesalahan konfigurasi karena langkah-langkah yang terlewat atau opsi konfigurasi yang tidak tersedia. Penyebaran dan konfigurasi banyak kluster menggunakan portal adalah proses yang memakan waktu yang membutuhkan fokus satu atau beberapa insinyur. Jika Anda menggunakan Azure CLI atau Azure PowerShell, Anda dapat membuat proses yang dapat diulang dan otomatis menggunakan alat baris perintah. Namun, tanggung jawab idempotensi, kontrol kegagalan penyebaran, dan pemulihan kegagalan ada pada Anda dan skrip yang Anda bangun.
Saat bekerja dengan beberapa instans AKS, sebaiknya pertimbangkan infrastruktur sebagai solusi kode, seperti Bicep, templat Azure Resource Manager, atau Terraform. Infrastruktur sebagai solusi kode menyediakan solusi penyebaran otomatis, terukur, dan idempoten. Misalnya, Anda dapat menggunakan satu file Bicep untuk layanan bersama solusi, dan satu lagi untuk kluster AKS dan layanan regional lainnya. Jika Anda menggunakan infrastruktur sebagai kode, stempel penyebaran dapat didefinisikan dengan konfigurasi umum seperti jaringan, otorisasi, dan diagnostik. File parameter penyebaran dapat disediakan dengan nilai khusus wilayah. Dengan konfigurasi ini, satu templat dapat digunakan untuk menyebarkan stempel yang identik di wilayah mana pun.
Biaya pengembangan dan pemeliharaan infrastruktur sebagai aset kode biasanya mahal. Dalam beberapa kasus, overhead mendefinisikan infrastruktur sebagai kode mungkin melebihi manfaat, seperti ketika Anda memiliki sangat kecil (misalnya, 2 atau 3) dan jumlah instans AKS yang tidak berubah. Untuk kasus ini, dapat diterima untuk menggunakan pendekatan yang lebih penting, seperti dengan alat baris perintah atau bahkan pendekatan manual dengan portal Azure.
Penyebaran klaster
Setelah stempel kluster ditentukan, Anda memiliki banyak opsi untuk menyebarkan instans stempel individual atau beberapa. Rekomendasinya adalah penggunaan teknologi integrasi berkelanjutan modern seperti GitHub Actions atau Azure Pipelines. Manfaat solusi penyebaran berbasis integrasi berkelanjutan meliputi:
- Penyebaran berbasis kode memungkinkan stempel ditambahkan dan dihapus menggunakan kode
- Kemampuan pengujian terintegrasi
- Lingkungan terintegrasi dan kemampuan pementasan
- Solusi manajemen rahasia terintegrasi
- Integrasi dengan kontrol sumber, untuk kode aplikasi dan skrip penyebaran dan templat
- Riwayat penyebaran dan pembuatan log
- Kontrol akses dan kemampuan audit, untuk mengontrol siapa yang dapat membuat perubahan dan dalam kondisi apa
Saat stempel baru ditambahkan atau dihapus dari kluster global, alur penyebaran perlu diperbarui agar tetap konsisten. Salah satu pendekatannya adalah menyebarkan sumber daya setiap wilayah sebagai langkah individual dalam alur kerja GitHub Actions. Konfigurasi ini sederhana karena setiap instans kluster didefinisikan dengan jelas dalam alur penyebaran. Konfigurasi ini mencakup beberapa overhead administratif dalam menambahkan dan menghapus kluster dari penyebaran.
Opsi lain adalah membuat logika bisnis untuk membuat kluster berdasarkan daftar lokasi yang diinginkan atau titik data lain yang menunjukkan. Misalnya, saluran penyebaran berisi daftar wilayah yang diinginkan; langkah dalam saluran kemudian dapat diputar melalui daftar ini, penyebaran klaster ke setiap wilayah yang ada dalam daftar. Kerugian dari konfigurasi ini adalah kompleksitas dalam generalisasi penyebaran dan bahwa setiap stempel kluster tidak secara eksplisit dirinci dalam alur penyebaran. Manfaat positifnya adalah menambahkan atau menghapus stempel klaster dari saluran menjadi sebuah pembaruan sederhana untuk daftar wilayah yang diinginkan.
Selain itu, menghapus stempel kluster dari alur penyebaran tidak selalu menonaktifkan sumber daya stempel. Bergantung pada solusi dan konfigurasi penyebaran, Anda mungkin memerlukan langkah tambahan untuk menonaktifkan instans AKS dan sumber daya Azure lainnya. Pertimbangkan untuk menggunakan tumpukan penyebaran untuk mengaktifkan manajemen siklus hidup penuh sumber daya Azure, termasuk pembersihan saat Anda tidak membutuhkannya lagi.
Klaster bootstrapping
Setelah setiap instans atau stempel Kubernetes disebarkan, komponen kluster seperti pengontrol ingress, solusi identitas, dan komponen beban kerja perlu disebarkan dan dikonfigurasi. Anda juga perlu mempertimbangkan untuk menerapkan kebijakan keamanan, akses, dan tata kelola di seluruh kluster.
Mirip dengan penyebaran, konfigurasi ini dapat menjadi tantangan untuk pengelolaan di beberapa Kubernetes secara manual. Sebagai gantinya, pertimbangkan opsi berikut untuk konfigurasi dan kebijakan dalam skala besar.
GitOps
Alih-alih mengonfigurasi komponen Kubernetes secara manual, disarankan untuk menggunakan metode otomatis untuk menerapkan konfigurasi ke kluster Kubernetes, karena konfigurasi ini diperiksa ke repositori sumber. Proses ini sering disebut sebagai GitOps, dan solusi GitOps populer untuk Kubernetes termasuk Flux dan Argo CD. Misalnya, ekstensi Flux untuk AKS memungkinkan bootstrapping kluster secara otomatis dan segera setelah kluster disebarkan.
GitOps dirinci secara lebih mendalam dalam arsitektur referensi garis besar AKS. Dengan menggunakan pendekatan berbasis GitOps untuk konfigurasi, Anda memastikan bahwa setiap instans Kubernetes dikonfigurasi sama tanpa upaya yang dipesan lebih dulu. Proses konfigurasi yang disederhanakan menjadi lebih penting saat ukuran armada Anda tumbuh.
Kebijakan Azure
Karena beberapa sampel Kubernetes ditambahkan, manfaat tata kelola, kepatuhan, dan konfigurasi berbasis kebijakan akan meningkat. Menggunakan kebijakan, khususnya Azure Policy, menyediakan metode terpusat dan dapat diskalakan untuk kontrol kluster. Manfaat kebijakan AKS dirinci dalam arsitektur referensi garis besar AKS.
Azure Policy harus diaktifkan saat kluster AKS dibuat. Inisiatif harus ditetapkan dalam mode Audit untuk mendapatkan visibilitas ke dalam ketidakpatuhan. Anda juga dapat mengatur lebih banyak kebijakan yang bukan bagian dari inisiatif bawaan apa pun. Kebijakan tersebut diatur dalam mode Tolak. Misalnya, ada kebijakan untuk memastikan bahwa hanya gambar kontainer yang disetujui yang dijalankan di kluster. Pertimbangkan untuk membuat inisiatif kebiasaan yang sering dilakukan Anda sendiri. Gabungkan kebijakan beban kerja Anda menjadi satu tugas.
Cakupan kebijakan mengacu pada target setiap kebijakan dan inisiatif kebijakan. Anda dapat menggunakan Bicep untuk menetapkan kebijakan ke grup sumber daya tempat setiap kluster AKS disebarkan. Seiring berkembangnya jejak kluster global, hal ini menghasilkan banyak kebijakan duplikat. Anda juga dapat mencakup kebijakan ke langganan Azure atau grup manajemen Azure. Metode ini memungkinkan Anda menerapkan satu set kebijakan ke semua kluster AKS dalam cakupan langganan, atau semua langganan yang ditemukan di bawah grup manajemen.
Saat merancang kebijakan untuk beberapa klaster AKS, pertimbangkan item berikut:
- Terapkan kebijakan yang harus berlaku secara global ke semua instans AKS ke grup manajemen atau langganan.
- Tempatkan setiap kluster regional dalam grup sumber dayanya sendiri, yang memungkinkan kebijakan khusus wilayah diterapkan ke grup sumber daya.
Lihat Organisasi sumber daya Cloud Adoption Framework untuk materi yang membantu Anda membuat strategi manajemen kebijakan.
Memantau penyebaran beban kerja
Selain konfigurasi AKS, pertimbangkan beban kerja yang diterapkan ke setiap sampel atau stempel regional. Solusi penyebaran atau alur memerlukan konfigurasi untuk mengakomodasi setiap stempel regional. Karena lebih banyak stempel ditambahkan ke kluster global, proses penyebaran perlu diperluas, atau perlu cukup fleksibel untuk mengakomodasi instans regional baru.
Pertimbangkan item berikut saat merencanakan penerapan beban kerja.
- Generalisasi penyebaran, seperti dengan bagan Helm, untuk memastikan bahwa konfigurasi penyebaran tunggal dapat digunakan di beberapa stempel klaster.
- Gunakan satu alur penyebaran yang dikonfigurasi untuk menerapkan beban kerja di semua stempel klaster.
- Berikan detail khusus stempel sebagai parameter penyebaran.
- Pertimbangkan bagaimana pencatatan diagnostik aplikasi dan pelacakan terdistribusi dikonfigurasi untuk penampakan di seluruh aplikasi.
Ketersediaan dan failover
Motivasi yang signifikan untuk memilih arsitektur Kubernetes multi-wilayah merupakan sebuah layanan. Artinya, jika komponen layanan atau layanan menjadi tidak tersedia di satu wilayah, lalu lintas harus dirutekan ke wilayah tempat instans lain layanan tersebut masih tersedia. Arsitektur multi-wilayah mencakup banyak titik kegagalan yang berbeda-beda. Pada bagian ini, masing-masing titik kegagalan potensial untuk dibahas.
Kegagalan pod aplikasi
Objek Penyebaran Kubernetes digunakan untuk membuat ReplicaSet, yang mengelola beberapa replika pod. Jika satu pod tidak tersedia, lalu lintas dirutekan di antara pod yang tersisa. ReplicaSet Kubernetes mencoba menjaga jumlah replika yang ditentukan tetap menyala dan berjalan. Jika satu instans tidak berfungsi, instans baru harus dibuat secara otomatis. Pemeriksaan keaktifan dapat digunakan untuk memeriksa status aplikasi atau proses yang berjalan di pod. Jika layanan tidak responsif, pemeriksaan keaktifan akan menghapus pod, yang memaksa ReplicaSet untuk membuat instans baru.
Untuk informasi lebih lanjut, lihat Kubernetes ReplicaSet.
Kegagalan perangkat keras pusat data
Kegagalan yang dilokalkan kadang-kadang dapat terjadi. Misalnya, daya mungkin menjadi tidak tersedia untuk satu rak server Azure. Untuk melindungi simpul AKS Anda agar tidak menjadi satu titik kegagalan, gunakan zona ketersediaan Azure. Dengan menggunakan zona ketersediaan, Anda memastikan bahwa simpul AKS dalam satu zona ketersediaan dipisahkan secara fisik dari simpul yang ditentukan di zona ketersediaan lain.
Untuk informasi selengkapnya, lihat Zona ketersediaan AKS dan Azure.
Kegagalan wilayah Azure
Ketika seluruh wilayah tidak tersedia, pod dalam klaster tidak lagi dapat melayani permintaan. Dalam hal ini, Azure Front Door merutekan semua lalu lintas ke wilayah sehat yang tersisa. Kluster dan pod Kubernetes di wilayah yang sehat terus melayani permintaan.
Berhati-hatilah dalam situasi ini untuk mengimbangi peningkatan permintaan dan lalu lintas ke kluster yang tersisa. Pertimbangkan poin-poin berikut:
- Pastikan bahwa jaringan sumber daya dan komputasi tepat untuk menyerap peningkatan lalu lintas yang tiba-tiba karena kegagalan. Misalnya, saat menggunakan Azure CNI, pastikan Anda memiliki subnet yang cukup besar untuk mendukung semua alamat IP Pod saat lalu lintas melonja.
- Gunakan Autoscaler Pod Horizontal untuk meningkatkan jumlah replika pod untuk mengimbangi peningkatan permintaan regional.
- Gunakan Autoscaler Kluster AKS untuk meningkatkan jumlah simpul instans Kubernetes untuk mengimbangi peningkatan permintaan regional.
Untuk informasi selengkapnya, lihat Horizontal Pod Autoscaler dan klaster skala otomatis AKS.
Topologi jaringan
Mirip dengan arsitektur referensi garis besar AKS, arsitektur ini menggunakan topologi jaringan hub-spoke. Selain pertimbangan yang ditentukan dalam arsitektur referensi garis besar AKS, pertimbangkan praktik terbaik berikut:
- Terapkan sekumpulan jaringan virtual hub-spoke untuk setiap instans AKS regional. Dalam setiap wilayah, rekan setiap spoke ke jaringan virtual hub.
- Rutekan semua lalu lintas keluar melalui Azure Firewall yang ditemukan di setiap jaringan hub. Kebijakan Azure Firewall Manager digunakan untuk mengelola kebijakan dalam penggunaan firewall di tiap-tiap bagian.
- Ikuti ukuran IP yang ditemukan dalam arsitektur referensi garis besar AKS, dan izinkan lebih banyak alamat IP untuk operasi skala simpul dan pod jika Anda mengalami kegagalan regional di wilayah lain dan lalu lintas ke wilayah yang tersisa meningkat secara substansial.
Manajemen lalu lintas
Dengan arsitektur referensi garis besar AKS, lalu lintas beban kerja dirutekan langsung ke instans Azure Application Gateway, lalu diteruskan ke penyeimbang beban backend dan sumber daya masuk AKS. Saat Anda bekerja dengan beberapa kluster, permintaan klien dirutekan melalui instans Azure Front Door, yang merutekan ke instans Azure Application Gateway.
Unduh file Visio dari diagram ini.
Pengguna mengirim permintaan ke nama domain (seperti
https://contoso-web-a1bc2de3fh4ij5kl.z01.azurefd.net), yang diselesaikan ke profil Azure Front Door. Permintaan ini dienkripsi dengan sertifikat kartubebas (*.azurefd.net) yang dikeluarkan untuk semua subdomain Azure Front Door. Azure Front Door memvalidasi permintaan terhadap kebijakan firewall aplikasi web, memilih asal tercepat (berdasarkan kesehatan dan latensi), dan menggunakan DNS publik untuk menyelesaikan alamat IP asal (instans Azure Application Gateway).Azure Front Door meneruskan permintaan ke instans Application Gateway yang dipilih, yang berfungsi sebagai titik masuk untuk stempel regional. Lalu lintas mengalir melalui internet. Azure Front Door memastikan lalu lintas ke asal dienkripsi.
Pertimbangkan metode untuk memastikan bahwa Azure Application Gateway hanya menerima aliran dari Pintu Depan. Salah satu pendekatannya adalah menggunakan grup keamanan jaringan pada subnet yang berisi Application Gateway. Aturan dapat memfilter aliran masuk (atau keluar) berdasarkan properti seperti Sumber, Port, Tujuan. Sumber properti memungkinkan untuk pengaturan layanan bawaan yang menunjukkan alamat IP sumber Azure. Abstraksi ini membuat lebih mudah untuk mengkonfigurasi dan memelihara aturan dan melacak alamat IP. Selain itu, pertimbangkan untuk menggunakan
X-Azure-FDIDheader, yang ditambahkan Azure Front Door ke permintaan sebelum mengirimkannya ke asal, untuk memastikan bahwa instans Application Gateway hanya menerima lalu lintas dari instans Front Door. Untuk informasi selengkapnya tentang Pintu Depan, lihat Dukungan protokol untuk HTTP di Azure Front Door.
Pertimbangan sumber daya bersama
Meskipun fokus skenario ini adalah pada memiliki beberapa instans Kubernetes yang tersebar di beberapa wilayah Azure, masuk akal untuk berbagi beberapa sumber daya di semua wilayah. Salah satu pendekatannya adalah menggunakan satu file Bicep untuk menyebarkan semua sumber daya bersama, dan kemudian yang lain untuk menyebarkan setiap stempel regional. Bagian ini merinci masing-masing sumber daya dan pertimbangan untuk menggunakannya di beberapa AKS.
Container Registry
Azure Container Registry digunakan dalam arsitektur ini untuk menyediakan layanan gambar kontainer. Kluster menarik gambar kontainer dari registri. Pertimbangkan item berikut saat bekerja dengan Azure Container Registry dalam klaster penyebaran multi-wilayah.
Ketersediaan geografis
Posisikan registri kontainer di setiap wilayah tempat kluster AKS disebarkan. Pendekatan ini memungkinkan operasi jaringan latensi rendah, memungkinkan transfer lapisan gambar yang cepat dan andal. Ini juga berarti bahwa Anda memiliki beberapa titik akhir layanan gambar untuk memberikan ketersediaan ketika layanan regional tidak tersedia. Menggunakan fungsionalitas replikasi geografis Azure Container Registry memungkinkan Anda mengelola satu registri kontainer yang secara otomatis direplikasi ke beberapa wilayah.
Pertimbangkan untuk membuat satu registri, dengan replika ke setiap wilayah Azure yang berisi kluster. Untuk informasi selengkapnya tentang replikasi Azure Container Registry, lihat Replikasi geografis di Azure Container Registry.
Gambar memperlihatkan beberapa replika Azure Container Registry dari dalam portal Azure.
Akses kluster
Setiap kluster AKS memerlukan akses ke registri kontainer sehingga dapat menarik lapisan gambar kontainer. Ada beberapa cara untuk membuat akses ke Azure Container Registry. Dalam arsitektur ini, identitas terkelola dibuat untuk setiap kluster, yang kemudian diberikan AcrPull peran pada registri kontainer. Untuk informasi selengkapnya dan rekomendasi tentang menggunakan identitas terkelola untuk akses Azure Container Registry, lihat arsitektur referensi garis besar AKS.
Konfigurasi ini didefinisikan dalam file Bicep stempel kluster, sehingga setiap kali stempel baru disebarkan, instans AKS baru diberikan akses. Karena registri kontainer adalah sumber daya bersama, pastikan penyebaran Anda menyertakan ID sumber daya registri kontainer sebagai parameter.
Azure Monitor
Fitur wawasan Kontainer Azure Monitor adalah alat yang direkomendasikan untuk memantau dan memahami performa dan kesehatan beban kerja kluster dan kontainer Anda. Wawasan kontainer menggunakan ruang kerja Analitik Log untuk menyimpan data log, dan Metrik Azure Monitor untuk menyimpan data rangkaian waktu numerik. Metrik Prometheus juga dapat dikumpulkan oleh Container Insights dan data dapat dikirim ke layanan terkelola Azure Monitor untuk Log Prometheus atau Azure Monitor. Untuk informasi selengkapnya, lihat arsitektur referensi garis besar AKS.
Anda juga dapat mengonfigurasi pengaturan diagnostik kluster AKS untuk mengumpulkan dan menganalisis log sumber daya dari komponen sarana kontrol AKS dan meneruskannya ke ruang kerja Analitik Log.
Saat Anda merancang solusi pemantauan untuk arsitektur multi-wilayah, penting untuk mempertimbangkan kopling di antara setiap stempel. Anda dapat menyebarkan satu ruang kerja Analitik Log, yang dibagikan oleh setiap kluster Kubernetes. Seperti sumber daya bersama lainnya, tentukan stempel regional Anda untuk menggunakan informasi tentang satu ruang kerja Log Analytics yang dibagikan secara global, dan sambungkan setiap kluster regional ke satu ruang kerja bersama tersebut. Saat setiap kluster regional memancarkan log diagnostik ke ruang kerja Analitik Log tunggal tersebut, Anda dapat menggunakan data, bersama dengan metrik sumber daya, untuk lebih mudah membuat laporan dan dasbor yang membantu Anda memahami bagaimana seluruh solusi multi-wilayah Anda berjalan.
Azure Front Door
Azure Front Door digunakan untuk memuat keseimbangan dan merutekan lalu lintas ke setiap kluster AKS. Azure Front Door juga memungkinkan perutean global lapisan 7. Kemampuan ini diperlukan untuk skenario ini.
Mengonfigurasi kluster
Saat setiap instans AKS regional ditambahkan, Application Gateway yang disebarkan bersama kluster Kubernetes perlu didaftarkan sebagai asal di Azure Front Door, yang membuatnya tersedia untuk perutean. Operasi ini memerlukan pembaruan infrastruktur sebagai aset kode. Atau, operasi ini dapat dipisahkan dari konfigurasi penyebaran dan dikelola dengan menggunakan alat seperti Azure CLI.
Sertifikat
Azure Front Door tidak mendukung asal menggunakan sertifikat yang ditandatangani sendiri, bahkan di lingkungan pengembangan atau pengujian. Untuk mengaktifkan lalu lintas HTTPS, Anda perlu membuat sertifikat TLS/SSL yang ditandatangani oleh otoritas sertifikat (CA). Untuk informasi tentang CA lain yang didukung Front Door, lihat Otoritas sertifikat yang diizinkan untuk mengaktifkan HTTPS kustom di Azure Front Door.
Untuk pengujian, atau untuk kluster non-produksi, Anda mungkin mempertimbangkan untuk menggunakan Certbot untuk membuat sertifikat Let's Encrypt Authority X3 untuk setiap gateway aplikasi.
Saat merencanakan klaster produksi, gunakan metode pilihan organisasi untuk mendapatkan sertifikat TLS.
Akses dan identitas klaster
Seperti yang dibahas dalam arsitektur referensi garis besar AKS, kami sarankan Anda menggunakan ID Microsoft Entra sebagai penyedia identitas untuk kluster Anda. Grup Microsoft Entra kemudian dapat digunakan untuk mengontrol akses ke sumber daya kluster.
Saat mengelola beberapa kluster, Anda perlu memutuskan skema akses. Opsi meliputi:
- Buat grup akses seluruh klaster global di mana setiap anggota dapat mengakses semua objek di setiap klaster Kubernetes. Opsi ini merupakan administrasi minimal; namun, memberikan hak istimewa yang signifikan kepada anggota kelompok mana pun.
- Buat grup akses individual untuk setiap instans Kubernetes yang digunakan untuk memberikan akses ke objek dalam instans kluster individual. Dengan opsi ini, beban administratif memang meningkat; namun, menyediakan akses klaster yang lebih detail.
- Tentukan kontrol akses terperinci untuk jenis objek dan namespace Layanan Kubernetes, dan menghubungkan hasilnya dengan struktur grup Microsoft Entra. Dengan opsi ini, overhead administratif meningkat secara signifikan; namun, ini menyediakan akses terperinci ke tidak hanya setiap kluster tetapi namespace layanan dan API Kubernetes yang ditemukan dalam setiap kluster.
Untuk akses administratif, pertimbangkan untuk membuat grup Microsoft Entra untuk setiap wilayah. Berikan setiap grup akses penuh ke stempel kluster yang sesuai di wilayah tersebut. Anggota setiap grup kemudian memiliki akses administratif ke kluster yang sesuai.
Untuk informasi selengkapnya tentang mengelola akses kluster AKS dengan MICROSOFT Entra ID, lihat Integrasi Microsoft Entra AKS.
Data, status, dan cache
Saat menggunakan sekumpulan kluster AKS yang didistribusikan secara global, pertimbangkan arsitektur aplikasi, proses, atau beban kerja lain yang mungkin berjalan di seluruh kluster. Jika beban kerja berbasis status tersebar di seluruh kluster, apakah mereka perlu mengakses penyimpanan status? Jika proses dibuat ulang di tempat lain dalam kluster karena kegagalan, apakah beban kerja atau proses terus memiliki akses ke penyimpanan status dependen atau solusi penembolokan? Status dapat disimpan dalam banyak cara, tetapi kompleks untuk dikelola bahkan dalam satu kluster Kubernetes. Kompleksitas meningkat saat menambahkan beberapa kluster Kubernetes. Karena masalah akses regional dan kompleksitas, pertimbangkan untuk merancang aplikasi Anda untuk menggunakan layanan penyimpanan status yang didistribusikan secara global.
Desain arsitektur ini tidak menyertakan konfigurasi untuk masalah status. Jika Anda menjalankan satu aplikasi logis di beberapa kluster AKS, pertimbangkan untuk merancang beban kerja Anda untuk menggunakan layanan data yang didistribusikan secara global, seperti Azure Cosmos DB. Azure Cosmos DB adalah sistem database terdistribusi secara global yang memungkinkan Anda membaca dan menulis data dari replika lokal database Anda, dan layanan Cosmos DB mengelola replikasi geografis untuk Anda. Untuk informasi selengkapnya, lihat Harga Azure Cosmos DB.
Jika beban kerja Anda menggunakan solusi penembolokan, pastikan Anda merancang layanan penembolokan sehingga tetap berfungsi bahkan selama peristiwa failover. Pastikan bahwa beban kerja itu sendiri tahan terhadap failover terkait cache, dan bahwa solusi penembolokan ada di semua instans AKS regional.
Pengoptimalan biaya
Gunakan harga Azure untuk memperkirakan biaya layanan yang digunakan dalam arsitektur. Praktik terbaik lainnya dijelaskan di bagian Pengoptimalan Biaya di Microsoft Azure Well-Architected Framework, dan opsi konfigurasi pengoptimalan biaya tertentu di artikel Optimalkan biaya .
Pertimbangkan untuk mengaktifkan analisis biaya AKS untuk alokasi biaya infrastruktur kluster terperinci oleh konstruksi khusus Kubernetes.
Langkah berikutnya
- Zona ketersediaan AKS
- Manajer Armada Azure Kubernetes
- Replikasi geografis di Azure Container Registry
- Wilayah berpasangan Azure