Gambaran umum solusi pemulihan bencana pasif aktif 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. Ketika wilayah menjadi tidak tersedia selama bencana, 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.
Panduan ini menguraikan solusi pemulihan bencana pasif aktif untuk AKS. Dalam solusi ini, kami menyebarkan dua kluster AKS independen dan identik ke dalam dua wilayah Azure yang dipasangkan hanya dengan satu kluster yang melayani lalu lintas secara aktif.
Catatan
Praktik berikut telah ditinjau secara internal dan diperiksa bersama dengan mitra Microsoft kami.
Gambaran umum solusi pasif aktif
Dalam pendekatan pemulihan bencana ini, kami memiliki dua kluster AKS independen yang disebarkan di dua wilayah Azure. Namun, hanya salah satu kluster yang secara aktif melayani lalu lintas kapan saja. Kluster sekunder (tidak secara aktif melayani lalu lintas) berisi konfigurasi dan data aplikasi yang sama dengan kluster utama tetapi tidak menerima lalu lintas apa pun kecuali diarahkan oleh manajer lalu lintas Azure Front Door.
Skenario dan konfigurasi
Solusi ini paling baik diterapkan ketika menghosting aplikasi bergantung pada sumber daya, seperti database, yang secara aktif melayani lalu lintas di satu wilayah. Dalam skenario di mana Anda perlu menghosting aplikasi stateless yang disebarkan di kedua wilayah, seperti penskalaan horizontal, sebaiknya pertimbangkan solusi aktif-aktif, karena pasif aktif melibatkan latensi tambahan.
Komponen
Solusi pemulihan bencana pasif aktif menggunakan banyak layanan Azure. Contoh arsitektur ini melibatkan komponen berikut:
Beberapa kluster dan wilayah: Anda menyebarkan beberapa kluster AKS, masing-masing di wilayah Azure terpisah. Selama operasi normal, lalu lintas jaringan dirutekan ke kluster AKS utama yang diatur dalam konfigurasi Azure Front Door.
Prioritas kluster yang dikonfigurasi: Anda menetapkan tingkat prioritas antara 1-5 untuk setiap kluster (dengan 1 menjadi prioritas tertinggi dan 5 menjadi prioritas terendah). Anda dapat mengatur beberapa kluster ke tingkat prioritas yang sama dan menentukan bobot untuk setiap kluster. Jika kluster utama menjadi tidak tersedia, lalu lintas secara otomatis merutekan ke wilayah berikutnya yang dipilih di Azure Front Door. Semua lalu lintas harus melalui Azure Front Door agar sistem ini berfungsi.
Azure Front Door: Azure Front Door memuat keseimbangan dan merutekan lalu lintas ke instans Azure Application Gateway di wilayah utama (kluster harus ditandai dengan prioritas 1). Jika terjadi kegagalan wilayah, layanan mengalihkan lalu lintas ke kluster berikutnya dalam daftar prioritas.
Untuk informasi selengkapnya, lihat Perutean lalu lintas berbasis prioritas.
Pasangan hub-spoke: Pasangan hub-spoke disebarkan untuk setiap instans AKS regional. Kebijakan Azure Firewall Manager mengelola aturan firewall di setiap wilayah.
Key Vault: Anda menyediakan Azure Key Vault di setiap wilayah untuk menyimpan rahasia dan kunci.
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: