Gambaran umum solusi ketersediaan tinggi aktif-aktif yang direkomendasikan untuk Azure Kubernetes Service (AKS)
Saat Anda membuat aplikasi di Azure Kubernetes Service (AKS) dan memilih wilayah Azure selama pembuatan sumber daya, ini adalah aplikasi wilayah tunggal. Jika terjadi bencana yang menyebabkan wilayah menjadi tidak tersedia, aplikasi Anda juga menjadi tidak tersedia. Jika Anda membuat penyebaran yang identik di wilayah Azure sekunder, aplikasi Anda menjadi kurang rentan terhadap bencana satu wilayah, yang menjamin kelangsungan bisnis, dan replikasi data apa pun di seluruh wilayah memungkinkan Anda memulihkan status aplikasi terakhir Anda.
Meskipun ada beberapa pola yang dapat memberikan pemulihan untuk solusi AKS, panduan ini menguraikan solusi ketersediaan tinggi aktif-aktif yang direkomendasikan untuk AKS. Dalam solusi ini, kami menyebarkan dua kluster AKS independen dan identik ke dalam dua wilayah Azure yang dipasangkan dengan kedua kluster secara aktif melayani lalu lintas.
Catatan
Kasus penggunaan berikut dapat dianggap sebagai praktik standar dalam AKS. Ini telah ditinjau secara internal dan diperiksa bersama dengan mitra Microsoft kami.
Gambaran umum solusi ketersediaan tinggi aktif-aktif
Solusi ini bergantung pada dua kluster AKS yang identik yang dikonfigurasi untuk melayani lalu lintas secara aktif. Anda menempatkan manajer lalu lintas global, seperti Azure Front Door, di depan dua kluster untuk mendistribusikan lalu lintas di seluruhnya. Anda harus secara konsisten mengonfigurasi kluster untuk menghosting instans semua aplikasi yang diperlukan agar solusi berfungsi.
Zona ketersediaan adalah cara lain untuk memastikan ketersediaan tinggi dan toleransi kesalahan untuk kluster AKS Anda dalam wilayah yang sama. Zona ketersediaan memungkinkan Anda mendistribusikan simpul kluster di beberapa lokasi terisolasi dalam wilayah Azure. Dengan cara ini, jika satu zona tidak berfungsi karena pemadaman listrik, kegagalan perangkat keras, atau masalah jaringan, kluster Anda dapat terus berjalan dan melayani aplikasi Anda. Zona ketersediaan juga meningkatkan performa dan skalabilitas kluster Anda dengan mengurangi latensi dan ketidakcocokan di antara simpul. Untuk menyiapkan zona ketersediaan untuk kluster AKS, Anda perlu menentukan nomor zona saat membuat atau memperbarui kumpulan simpul Anda. Untuk informasi selengkapnya, lihat Apa itu zona ketersediaan Azure?
Catatan
Banyak wilayah mendukung zona ketersediaan. Pertimbangkan untuk menggunakan wilayah dengan zona ketersediaan untuk memberikan lebih banyak ketahanan dan ketersediaan untuk beban kerja Anda. Untuk informasi selengkapnya, lihat Memulihkan dari gangguan layanan di seluruh wilayah.
Skenario dan konfigurasi
Solusi ini paling baik diterapkan saat menghosting aplikasi stateless dan/atau dengan teknologi lain juga disebarkan di kedua wilayah, seperti penskalaan horizontal. Dalam skenario di mana aplikasi yang dihosting bergantung pada sumber daya, seperti database, yang secara aktif hanya di satu wilayah, sebaiknya terapkan solusi pasif aktif untuk potensi penghematan biaya, karena pasif aktif memiliki lebih banyak waktu henti daripada aktif-aktif.
Komponen
Solusi ketersediaan tinggi aktif-aktif menggunakan banyak layanan Azure. Bagian ini hanya mencakup komponen yang unik untuk arsitektur multi-kluster ini. Untuk informasi selengkapnya tentang komponen yang tersisa, lihat arsitektur garis besar AKS.
Beberapa kluster dan wilayah: Anda menyebarkan beberapa kluster AKS, masing-masing di wilayah Azure terpisah. Selama operasi normal, konfigurasi Azure Front Door Anda merutekan lalu lintas jaringan antara semua wilayah. Jika satu wilayah menjadi tidak tersedia, lalu lintas merutekan ke wilayah dengan waktu pemuatan tercepat untuk pengguna.
Jaringan hub-spoke per wilayah: Pasangan jaringan hub-spoke regional disebarkan untuk setiap instans AKS regional. Kebijakan Azure Firewall Manager mengelola kebijakan firewall di semua wilayah.
Penyimpanan kunci regional: Anda menyediakan Azure Key Vault di setiap wilayah untuk menyimpan nilai dan kunci sensitif khusus untuk instans AKS dan untuk mendukung layanan yang ditemukan di wilayah tersebut.
Azure Front Door: Azure Front Door 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 tujuh .
Analitik Log: Instans Analitik Log Regional menyimpan metrik jaringan regional dan log diagnostik. Instans bersama menyimpan metrik dan log diagnostik untuk semua instans AKS.
Container Registry: Gambar kontainer untuk beban kerja disimpan dalam registri kontainer terkelola. Dengan solusi ini, satu instans Azure Container Registry digunakan untuk semua instans Kubernetes dalam kluster. Replikasi geografis untuk Azure Container Registry memungkinkan Anda mereplikasi gambar ke wilayah Azure yang dipilih dan menyediakan akses berkelanjutan ke gambar bahkan jika suatu wilayah mengalami pemadaman.
Proses failover
Jika komponen layanan atau layanan menjadi tidak tersedia di satu wilayah, lalu lintas harus dirutekan ke wilayah tempat layanan tersebut tersedia. Arsitektur multi-wilayah mencakup banyak titik kegagalan yang berbeda-beda. Di bagian ini, kami membahas potensi titik kegagalan.
Pod Aplikasi (Regional)
Objek penyebaran Kubernetes membuat beberapa replika pod (ReplicaSet). Jika tidak tersedia, lalu lintas dirutekan di antara replika yang tersisa. ReplicaSet Kubernetes mencoba untuk menjaga jumlah replika yang ditentukan tetap aktif dan berjalan. Jika satu instans tidak berfungsi, instans baru harus dibuat ulang. Pemeriksaan keaktifan dapat memeriksa status aplikasi atau proses yang berjalan di pod. Jika pod 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, instans Azure Front Door merutekan semua lalu lintas ke wilayah kesehatan yang tersisa. Kluster dan pod Kubernetes di wilayah ini terus melayani permintaan. Untuk mengimbangi peningkatan lalu lintas dan permintaan ke kluster yang tersisa, ingatlah panduan berikut:
- Pastikan sumber daya jaringan dan komputasi berukuran tepat untuk menyerap peningkatan lalu lintas yang tiba-tiba karena kegagalan wilayah. Misalnya, saat menggunakan Azure Container Network Interface (CNI), pastikan Anda memiliki subnet yang dapat mendukung semua IP pod dengan beban lalu lintas yang berduri.
- 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.
Kumpulan simpul Kubernetes (Regional)
Terkadang, kegagalan yang dilokalkan dapat terjadi pada sumber daya komputasi, seperti daya menjadi tidak tersedia dalam satu rak server Azure. Untuk melindungi simpul AKS Anda agar tidak menjadi kegagalan regional satu titik, gunakan Zona Ketersediaan Azure. Zona ketersediaan memastikan bahwa simpul AKS di setiap zona ketersediaan dipisahkan secara fisik dari yang ditentukan di zona ketersediaan lain.
Kumpulan simpul Kubernetes (Global)
Dalam kegagalan regional yang lengkap, Azure Front Door merutekan lalu lintas ke wilayah yang sehat yang tersisa. Sekali lagi, pastikan untuk mengimbangi peningkatan lalu lintas dan permintaan ke kluster yang tersisa.
Strategi pengujian failover
Meskipun saat ini tidak ada mekanisme yang tersedia dalam AKS untuk menurunkan seluruh wilayah penyebaran untuk tujuan pengujian, Azure Chaos Studio menawarkan kemampuan untuk membuat eksperimen chaos pada kluster Anda.
Langkah berikutnya
Jika Anda mempertimbangkan solusi yang berbeda, lihat artikel berikut ini: