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 diaktifkan, kluster dingin dapat digunakan sebagai cadangan, dan beban kerja dapat dijalankan di kluster tersebut 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.

Log Analytics: Instans Log Analytics 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 spesifiknya, 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 memerlukan waktu beberapa menit untuk kembali online, karena sebelumnya 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 salah satunya tidak tersedia, lalu lintas dirutekan ke replika-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, liveness probe akan menghapus pod tersebut, 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 meningkat.
  • Gunakan Horizontal Pod Autoscaler untuk menambah jumlah replika pod guna mengimbangi peningkatan permintaan regional.
  • Gunakan AKS Cluster Autoscaler untuk meningkatkan jumlah node instans Kubernetes guna mengimbangi peningkatan permintaan di wilayah tersebut.

Kumpulan simpul Kubernetes (Regional)

Terkadang, gangguan lokal dapat terjadi pada sumber daya komputasi, misalnya ketika pasokan listrik tidak tersedia pada satu rak server Azure. Untuk melindungi simpul AKS Anda agar tidak menjadi kegagalan regional satu titik, gunakan Azure Availability Zones. 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 total pada suatu wilayah, Azure Front Door mengarahkan lalu lintas ke wilayah lain yang masih sehat. Sekali lagi, pastikan untuk mengimbangi peningkatan lalu lintas dan permintaan ke kluster yang tersisa.

Strategi pengujian failover

Meskipun saat ini tidak ada mekanisme dalam AKS untuk menghapus seluruh wilayah penyebaran untuk tujuan pengujian, Anda dapat menggunakan Azure Chaos Studio Ruang Kerja untuk mensimulasikan pemadaman zona ketersediaan untuk kumpulan simpul kluster Anda.

Langkah berikutnya

Jika Anda mempertimbangkan solusi yang berbeda, lihat artikel berikut ini:

  • Terakhir diperbarui pada