Gambaran umum solusi pasif-dingin 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 pasif-dingin 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 secara aktif melayani lalu lintas saat aplikasi diperlukan.
Catatan
Praktik berikut telah ditinjau secara internal dan diperiksa bersama dengan mitra Microsoft kami.
Gambaran umum solusi pasif-dingin
Dalam pendekatan ini, kami memiliki dua kluster AKS independen yang disebarkan di dua wilayah Azure. Ketika aplikasi diperlukan, kami mengaktifkan kluster pasif untuk menerima lalu lintas. Jika kluster pasif turun, kita harus mengaktifkan kluster dingin secara manual untuk mengambil alih arus lalu lintas. Kita dapat mengatur kondisi ini melalui input manual setiap kali atau untuk menentukan peristiwa tertentu.
Skenario dan konfigurasi
Solusi ini paling baik diimplementasikan sebagai beban kerja "gunakan sesuai kebutuhan", yang berguna untuk skenario yang mengharuskan beban kerja berjalan pada waktu tertentu dalam sehari atau berjalan sesuai permintaan. Contoh kasus penggunaan untuk pendekatan pasif-dingin meliputi:
- Perusahaan manufaktur yang perlu menjalankan simulasi kompleks dan intensif sumber daya pada himpunan data besar. Dalam hal ini, kluster pasif terletak di wilayah cloud yang menawarkan layanan komputasi dan penyimpanan berkinerja tinggi. Kluster pasif hanya digunakan ketika simulasi dipicu oleh pengguna atau oleh jadwal. Jika kluster tidak berfungsi saat memicu, kluster dingin dapat digunakan sebagai cadangan dan beban kerja dapat berjalan di atasnya sebagai gantinya.
- Lembaga pemerintah yang perlu mempertahankan cadangan sistem dan data pentingnya jika terjadi serangan cyber atau bencana alam. Dalam hal ini, kluster pasif terletak di lokasi yang aman dan terisolasi yang tidak dapat diakses oleh publik.
Komponen
Solusi pemulihan bencana pasif-dingin 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. Ketika aplikasi diperlukan, kluster pasif diaktifkan untuk menerima lalu lintas jaringan.
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.
Pasangan hub-spoke: Pasangan hub-spoke disebarkan untuk setiap instans AKS regional. Kebijakan Azure Firewall Manager mengelola aturan firewall di setiap wilayah.
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 kluster pasif tidak berfungsi dengan baik karena masalah di wilayah Azure tertentu, Anda dapat mengaktifkan kluster dingin dan mengalihkan semua lalu lintas ke wilayah kluster tersebut. Anda dapat menggunakan proses ini saat kluster pasif dinonaktifkan sampai mulai bekerja lagi. Kluster dingin dapat memakan waktu beberapa menit untuk online, karena telah dimatikan dan perlu menyelesaikan proses penyiapan. Pendekatan ini tidak ideal untuk aplikasi yang sensitif terhadap waktu. Dalam hal ini, sebaiknya pertimbangkan failover aktif-aktif.
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: