Arsitektur referensi ini merinci cara menjalankan beberapa contoh pada Azure Kubernetes Service (AKS) di beberapa bagian dalam konfigurasi aktif/aktif.
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. Disarankan agar Anda terbiasa dengan garis besar AKS sebelum melanjutkan konten multi-wilayah.
Arsitektur
Unduh file Visio arsitektur ini.
Implementasi referensi arsitektur ini tersedia di GitHub.
Komponen
Banyak komponen dan layanan Azure yang digunakan dalam arsitektur referensi AKS. Hanya komponen-komponen unik pada arsitektur multi-cluster yang tercantum. Sisanya, referensi dapat merujuk arsitektur AKS Baseline.
- Beberapa klaster / beberapa wilayahPenerapan beberapa klaster AKS, dilakukan di masing-masing wilayah Azure secara 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 per bagianJaringan hub-spoke regional ddipasangkan untuk setiap contoh AKS. Kebijakan Azure Firewall Manager digunakan untuk mengelola kebijakan dalam penggunaan firewall di tiap-tiap bagian.
- Penyimpanan kunci regional Azure Key Vault disediakan di setiap wilayah untuk menyimpan nilai dan kunci sensitif khusus untuk instans AKS dan layanan pendukung yang ditemukan di wilayah tersebut.
- Pintu Depan Azure Pintu depan Azure digunakan untuk keseimbangan lalu lintas dan rute ke Azure Application Gateway regional, biasanya terdapat di depan setiap AKS. Pintu Depan Azure memungkinkan routing global tujuh lapisan, keduanya diperlukan untuk arsitektur referensi.
- Analitik Log Analitik Log Regional biasanya digunakan untuk menyimpan metrik jaringan regional dan log diagnostik. Selain itu, Log Analytics bersama digunakan untuk menyimpan metrik dan log diagnostik semua AKS.
- Pendaftaran kontainer Gambar kontainer untuk kerja disimpan dalam pengelolaan pendaftaran kontainer. 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 referensi ini menggunakan dua pola desain cloud. Geographical Node (geodes), wilayah mana pun dapat melayani permintaan, dan Stempel Penyebaran di mana beberapa salinan independen aplikasi atau komponen aplikasi berasal dari satu sumber (pola penyebaran).
Pertimbangan pola Geographical Node
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 AKS multi-wilayah, beberapa contoh AKS diterapkan di beberapa bagian. Masing-masing contoh berikut dianggap sebagai stempel. Jika terjadi kegagalan regional atau kebutuhan untuk menambahkan lebih banyak kapasitas dan / 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 seperti infrastruktur sebagai kode
- Menyediakan nilai khusus menggunakan mekanisme pemasukan tersebar seperti variabel atau berkas parameter
- Pilih perkakas penyebaran yang memungkinkan yang penyebaran fleksibel, berulang, dan idempoten
- Dalam konfigurasi stempel aktif/aktif, pertimbangkan bagaimana agar lalu lintas seimbang di setiap stempel
- Jika stempel ditambahkan dan dihapus dari koleksi, pertimbangkan juga masalah kapasitas dan biaya
- Pertimbangkan cara mendapatkan visibilitas dan/atau memantau pengumpulan stempel sebagai satu unit.
Masing-masing item dirinci dengan panduan khusus di bagian arsitektur referensi berikut ini.
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. Anda harus mempertimbangkan strategi untuk memperluas skala dan masuk, dengan menambahkan atau menghapus instans Kubernetes lainnya. Anda akan menginginkan desain, serta rencana penyebaran dan konfigurasi, untuk memperhitungkan kegagalan regional atau 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 non-pasangan. Namun, metode ini dapat menghadirkan tantangan ketika bekerja dengan banyak kluster AKS yang digabungkan dengan erat. Misalnya, penggunaan portal Microsoft Azure membuka peluang untuk terjadi kesalahan konfigurasi karena langkah-langkah yang terlewatkan atau opsi konfigurasi yang tidak tersedia. Selain itu, penyebaran dan konfigurasi banyak klaster pada saat menggunakan portal merupakan proses tepat waktu yang membutuhkan seorang yang fokus dalam mengerjakannya. 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 banyak contoh AKS, sebaiknya pertimbangkan infrastruktur sebagai kode pemecahan solusi, misalnya templat Azure Resource Manager, templat Bicep, atau konfigurasi Terraform. Infrastruktur sebagai solusi kode menyediakan solusi penyebaran otomatis, terukur, dan idempoten. Arsitektur referensi ini mencakup Template ARM untuk solusi layanan bersama dan yang lainnya untuk cluster AKS + layanan regional. Jika Anda menggunakan infrastruktur sebagai kode, stempel penyebaran dapat didefinisikan dengan konfigurasi umum seperti jaringan, otorisasi, dan diagnostik. Parameter berkas penyebaran dapat diberikan nilai khusus. 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, seperti ketika jumlah statis/tetap instans AKS disebarkan, overhead infrastruktur sebagai kode mungkin melebihi manfaatnya. Untuk kasus ini, gunakan pendekatan yang lebih penting, seperti dengan alat baris perintah, atau pendekatan manual, semunya boleh dilakukan.
Penyebaran klaster
Setelah definisi stempel klaster ditentukan, Anda memiliki banyak opsi untuk menerapkan stempel tunggal atau banyak. 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 kode / kontrol sumber penyebaran
- Riwayat penyebaran dan pembuatan log
Saat stempel baru ditambahkan atau dihapus dari kluster global, alur penyebaran perlu diperbarui agar tetap konsisten. Dalam implementasi referensi, setiap wilayah disebarkan sebagai langkah individual dalam alur kerja GitHub Action (contoh). Konfigurasi ini sangat sederhana karena setiap instans klaster didefinisikan dengan jelas dalam saluran penyebaran. Konfigurasi ini mencakup beberapa overhead administratif dalam menambahkan dan menghapus kluster dari penyebaran.
Pilihan lain adalah menggunakan logika untuk membuat klaster berdasarkan daftar lokasi yang diinginkan atau titik data lainnya. 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 memastikan bahwa itu juga dinonaktifkan. Bergantung pada solusi dan konfigurasi penyebaran, Anda mungkin memerlukan langkah tambahan untuk memastikan bahwa instans AKS telah dinonaktifkan dengan tepat.
Klaster bootstrapping
Setelah setiap stempel Kubernetes digunakan, komponen klaster seperti adanya pengontrolan, solusi identitas, dan komponen beban kerja perlu diterapkan 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, pertimbangkan 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. Implementasi ini menggunakan ekstensi Flux untuk AKS untuk mengaktifkan bootstrapping kluster secara otomatis dan segera setelah kluster disebarkan.
GitOps dirinci secara lebih mendalam dalam arsitektur referensi garis besar AKS. Poin penting di sini adalah bahwa menggunakan pendekatan berbasis GitOps untuk konfigurasi membantu memastikan bahwa setiap instans Kubernetes dikonfigurasi secara serupa tanpa upaya yang dipesan lebih dulu. Ini menjadi lebih penting ketika ukuran armada Anda tumbuh.
Kebijakan Azure
Karena beberapa sampel Kubernetes ditambahkan, manfaat tata kelola, kepatuhan, dan konfigurasi berbasis kebijakan akan meningkat. Menggunakan kebijakan, Azure Policy secara khusus, menyediakan metode terpusat dan dapat diskalakan untuk kontrol kluster. Manfaat kebijakan AKS dirinci dalam arsitektur referensi garis besar AKS.
Azure Policy diaktifkan dalam implementasi referensi ini saat klaster AKS dibuat dan penetaan inisiatif pembatasan dalam mode Audit untuk mendapatkan visibilitas menjadi tidak sejalan. Implementasi ini juga menetapkan 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 saja yang disetujui yang dijalankan di klaster. Pertimbangkan untuk membuat inisiatif kebiasaan yang sering dilakukan Anda sendiri. Gabungkan kebijakan beban kerja Anda menjadi satu tugas.
Ruang lingkup Azure Policy mengacu pada target inisiatif kebijakan dan kebijakan. Implementasi referensi yang terkait dengan arsitektur ini menggunakan templat ARM untuk menetapkan kebijakan ke grup sumber daya tempat klaster AKS digunakan. 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, dan/atau semua langganan yang ditemukan di bawah grup manajemen.
Saat merancang kebijakan untuk beberapa klaster AKS, pertimbangkan item berikut:
- Kebijakan yang diterapkan secara global untuk semua instans AKS dapat diterapkan ke grup manajemen atau langganan
- Menempatkan setiap klaster regional dalam kelompok sumber dayanya sendiri memungkinkan kebijakan khusus diterapkan pada grup sumber daya
Lihat Organisasi sumber daya Cloud Adoption Framework untuk materi yang akan 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 penyaluran memerlukan konfigurasi untuk mengakomodasi setiap stempel regional. Karena lebih banyak stempel ditambahkan ke kluster global, proses penyebaran perlu diperluas, atau 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 dialihkan ke wilayah di mana layanan itu tersedia. Arsitektur multi-wilayah mencakup banyak titik kegagalan yang berbeda-beda. Pada bagian ini, masing-masing titik kegagalan potensial untuk dibahas.
Pod Aplikasi (regional)
Objek penyebaran Kubernetes digunakan untuk membuat beberapa replika pod (ReplicaSet). Jika salah satu tidak tersedia, lalu lintas dialihkan ke yang tersisa. ReplicaSet Kubernetes mencoba menjaga jumlah replika yang ditentukan tetap menyala dan berjalan. Jika satu sampel turun, sampel baru harus dibuat ulang. Akhirnya, sebuah probe aktif dapat digunakan untuk memeriksa keadaan 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.
Pod Aplikasi (global)
Ketika seluruh wilayah tidak tersedia, pod dalam klaster tidak lagi dapat melayani permintaan. Dalam hal ini, sampel Azure Front Door merutekan semua lalu lintas ke wilayah yang tersisa. Klaster dan pod Kubernetes di wilayah ini akan terus melayani permintaan.
Berhati-hatilah dalam situasi ini untuk mengkompensasi peningkatan lalu lintas / permintaan ke klaster yang tersisa. Hal-hal yang perlu dipertimbangkan:
- 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 dapat mendukung semua IP Pod dengan beban lalu lintas berlebih.
- Manfaatkan Horizontal Pod Autoscaler untuk meningkatkan jumlah replika pod untuk mengimbangi peningkatan permintaan.
- Manfaatkan AKS Cluster Autoscaler untuk meningkatkan jumlah simpul sampel Kubernetes untuk mengimbangi peningkatan permintaan regional.
Untuk informasi selengkapnya, lihat Horizontal Pod Autoscaler dan klaster skala otomatis AKS.
Kumpulan simpul Kubernetes (regional)
Terkadang kegagalan setempat terjadi untuk menghitung sumber daya, misalnya, jika daya tidak tersedia untuk satu rak server Azure. Untuk melindungi simpul AKS agar tidak terjadi kegagalan pada satu titik, gunakan zona Ketersediaan Azure. Saat menggunakan zona ketersediaan AKS, model penyebaran ini memastikan simpul di zona ketersediaan tertentu dipisahkan secara fisik dari yang didefinisikan di zona ketersediaan lain.
Untuk informasi selengkapnya, lihat Zona ketersediaan AKS dan Azure.
Kumpulan simpul Kubernetes (global)
Dalam kegagalan regional yang lengkap, Azure Front Door akan merutekan lalu lintas ke wilayah yang ada dan dapat digunakan. Sekali lagi, berhati-hatilah dalam situasi ini untuk mengkompensasi peningkatan lalu lintas / permintaan ke klaster yang tersisa.
Untuk informasi selengkapnya, lihat Azure Front Door.
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 hub-spoke untuk setiap instance AKS regional, di mana jaringan virtual hub-spoke tersedia.
- 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.
Manajemen lalu lintas
Dengan arsitektur referensi garis besar AKS, lalu lintas beban kerja dirutekan langsung ke instans Azure Application Gateway, lalu diteruskan ke sumber daya penyeimbang beban backend / ingress 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.azurefd.net), yang diselesaikan ke instans Azure Front Door. Permintaan ini dienkripsi dengan kartu sertifikat (*.azurefd.net) yang digunakan untuk semua subdomain Azure Front Door. Azure Front Door memvalidasi permintaan kebijakan WAF, memilih backend tercepat (berdasarkan kesehatan dan latensi), dan menggunakan DNS publik untuk menyelesaikan alamat IP backend (Azure Application Gateway).Pintu Depan meneruskan permintaan ke Application Gateway sesuai pilihan, berfungsi sebagai titik masuk untuk stempel regional. Lalu lintas mengalir melalui internet dan dienkripsi oleh Azure Front Door. Pertimbangkan metode untuk memastikan bahwa Azure Application Gateway hanya menerima aliran dari Pintu Depan. Salah satu pendekatannya adalah dengan 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 Pintu Depan ke backend
X-Azure-FDIDpastikan bahwa Azzure Application Gateway hanya menerima lalu lintas dari Pintu Depan. Untuk informasi selengkapnya tentang Pintu Depan, lihat Dukungan protokol untuk HTTP di Azure Front Door.
Pertimbangan sumber daya bersama
Sementara fokus arsitektur referensi ini adalah memiliki beberapa Kubernetes yang tersebar di beberapa Azure, hal ini memungkinkan untuk memiliki beberapa sumber daya bersama di semua instan. Implementasi referensi multi-wilayah AKS menggunakan satu templat ARM untuk menyebarkan semua sumber daya bersama dan 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 referensi untuk menyediakan kontainer layanan gambar (tarik). Pertimbangkan item berikut saat bekerja dengan Azure Container Registry dalam klaster penyebaran multi-wilayah.
Ketersediaan geografis
Posisikan registri kontainer di setiap wilayah di mana klaster AKS digunakan operasi penutupan jaringan, yang memungkinkan transfer lapisan gambar yang cepat dan andal. Memiliki beberapa titik akhir layanan gambar untuk memberikan ketersediaan saat layanan regional tidak tersedia. Penggunaan fungsi replikasi geografis Azure Container Registries memungkinkan Anda mengelola satu Container Registry yang direplikasi ke beberapa wilayah.
Implementasi referensi multi-wilayah AKS membuat satu Container Registry dan mereplikasikannya ke setiap wilayah klaster. Untuk informasi selengkapnya tentang replikasi Azure Container Registry, lihat Replikasi geografis di Azure Container Registry.
Gambar beberapa replika ACR dari dalam portal Microsoft Azure.
Akses Kluster
Setiap AKS memerlukan akses untuk menarik gambar dari Azure Container Registry. Ada beberapa cara untuk membuat akses ke Azure Container Registry; arsitektur referensi ini menggunakan Azure Managed Identity untuk setiap klaster, yang kemudian diberi peran AcrPull pada Container Registry. Untuk informasi selengkapnya dan rekomendasi tentang menggunakan Identitas Terkelola untuk akses Container Registry, lihat arsitektur referensi garis besar AKS.
Konfigurasi ini didefinisikan dalam templat stempel klaster ARM sehingga setiap kali stempel baru diterapkan, AKS baru diberikan akses. Karena Container Registry adalah sumber daya bersama, pastikan bahwa templat stempel penyebaran dapat mengkonsumsi dan menggunakan detail yang diperlukan, dalam hal ini, ID sumber daya Container Registry.
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 mengirim data ke layanan terkelola Azure Monitor untuk Log Prometheus atau Azure Monitor.
Anda juga dapat mengonfigurasi pengaturan diagnostik kluster AKS untuk mengumpulkan dan menganalisis log sumber daya dari komponen sarana kontrol AKS dan meneruskan ke ruang kerja Analitik Log.
AKS Untuk informasi selengkapnya, lihat arsitektur referensi garis besar AKS.
Saat mempertimbangkan pemantauan untuk implementasi lintas wilayah seperti arsitektur referensi ini, penting untuk mempertimbangkan kopling antara setiap stempel. Dalam hal ini, pertimbangkan setiap stempel sebagai komponen unit (cluster regional). Implementasi referensi AKS multi-wilayah menggunakan ruang kerja Log Analytics, yang dibagikan oleh setiap klaster Kubernetes. Seperti sumber daya bersama lainnya, tentukan stempel regional Anda untuk menggunakan informasi tentang satu ruang kerja Log Analytics dan sambungkan setiap kluster ke dalamnya.
Sekarang setelah setiap kluster regional memancarkan log diagnostik ke satu ruang kerja Analitik Log, data ini, bersama dengan metrik sumber daya, dapat digunakan untuk lebih mudah membangun laporan dan dasbor yang mewakili keseluruhan kluster global.
Azure Front Door
Azure Front door digunakan untuk memuat keseimbangan dan merutekan lalu lintas ke setiap klaster AKS. Pintu Depan Azure memungkinkan routing global tujuh lapisan, keduanya diperlukan untuk arsitektur referensi.
Mengonfigurasi kluster
Saat AKS regional ditambahkan, Azzure Application Gateway yang disebarkan bersama klaster Kubernetes perlu didaftarkan sebagai backend Front Door untuk mendapatkan rute yang tepat. Operasi ini memerlukan pembaruan infrastruktur sebagai aset kode. Atau, operasi ini dapat dipisahkan dari konfigurasi penyebaran dan dikelola dengan alat seperti Azure CLI. Alur penyebaran implementasi referensi yang disertakan menggunakan langkah Azure CLI yang berbeda untuk operasi ini.
Sertifikat
Front Door tidak mendukung sertifikat yang ditandatangani sendiri bahkan di lingkungan Dev/Test. Untuk mengaktifkan lalu lintas HTTPS, Anda perlu membuat sertifikat TLS/SSL yang ditandatangani oleh otoritas sertifikat (CA). Implementasi referensi menggunakan Certbot untuk membuat sertifikat Let's Encrypt Authority X3. Saat merencanakan klaster produksi, gunakan metode pilihan organisasi untuk mendapatkan sertifikat TLS.
Untuk informasi tentang CA lain yang didukung Front Door, lihat Otoritas sertifikat yang diizinkan untuk mengaktifkan HTTPS kustom di Azure Front Door.
Akses dan identitas klaster
Seperti yang dibahas dalam arsitektur referensi garis besar AKS, disarankan untuk menggunakan ID Microsoft Entra sebagai penyedia identitas akses kluster. Grup Microsoft Entra kemudian dapat digunakan untuk mengontrol akses ke sumber daya kluster.
Saat mengelola beberapa kluster, Anda harus 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 Azure Directory. Dengan opsi ini, beban administratif meningkat secara signifikan; namun, menyediakan akses detail ke tidak hanya setiap klaster tetapi nama dan Kubernetes APIS dalam setiap klaster yang ditemukan.
Dengan implementasi referensi yang disertakan, dua grup Microsoft Entra dibuat untuk akses admin. Grup-grup ini ditentukan pada waktu penyebaran stempel klaster dengan menggunakan berkas parameter penyebaran. Anggota dari setiap grup memiliki akses penuh ke stempel klaster 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 klaster AKS yang didistribusikan secara global, pertimbangkan arsitektur aplikasi, proses, atau beban kerja lain yang mungkin berjalan di seluruh klaster. Karena beban kerja tersebar di seluruh klaster, apakah perlu mengakses toko? Jika proses dibuat ulang di klaster lain karena kegagalan, akankah beban kerja atau proses terus memiliki akses ke status dependen atau solusi penyimpanan tembolok? pengambilan keputusan dapat dicapai dengan banyak cara; namun, namun itu rumit untuk satu klaster Kubernetes. Kompleksitas meningkat saat menambahkan beberapa kelompok Kubernetes. Karena masalah akses regional dan kompleksitas, pertimbangkan untuk merancang aplikasi Anda untuk menggunakan layanan penyimpanan status yang didistribusikan secara global.
Implementasi referensi multi-kluster tidak menyertakan demonstrasi atau konfigurasi untuk masalah status. Jika Anda menjalankan aplikasi di seluruh instans AKS berkluster, pertimbangkan untuk merancang beban kerja Anda untuk menggunakan layanan data yang didistribusikan secara global, seperti Azure Cosmos DB. Microsoft Azure Cosmos DB adalah sistem database yang didistribusikan secara global yang memungkinkan Anda untuk membaca dan menulis data dari replika database lokal Anda. Untuk informasi selengkapnya, lihat Harga Azure Cosmos DB.
Jika beban kerja Anda menggunakan solusi penembolokan, pastikan bahwa itu dirancang sehingga layanan penembolokan tetap berfungsi. Untuk melakukannya, pastikan 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 tertentu Kubernetes.
Langkah berikutnya
- Zona ketersediaan AKS
- Manajer Armada Azure Kubernetes
- Replikasi geografis di Azure Container Registry
- Wilayah berpasangan Azure