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 mendukung kemampuan pemulihan untuk solusi AKS, panduan ini menjelaskan 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 node 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 digunakan untuk meng-host aplikasi stateless dan/atau ketika teknologi lain juga diterapkan 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 salah satu wilayah tidak tersedia, trafik akan dialihkan ke wilayah dengan waktu muat tercepat bagi pengguna.

Jaringan hub-spoke per wilayah: Satu pasangan jaringan hub-spoke regional diterapkan untuk setiap instans AKS regional. Azure Firewall Manager kebijakan 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 menyeimbangkan beban dan merutekan lalu lintas ke instans Azure Application Gateway di wilayah, yang berada di depan setiap kluster AKS. Azure Front Door memungkinkan perutean global lapisan tujuh.

Log Analytics: Instans Log Analytics 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 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 lonjakan.
  • 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 node AKS Anda dalam solusi aktif-aktif ini agar tidak menjadi satu titik kegagalan regional, gunakan Azure Availability Zones. Zona ketersediaan memastikan bahwa simpul AKS di setiap zona ketersediaan dipisahkan secara fisik dari simpul yang berada 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