Ringkasan ketersediaan tinggi dan pemulihan bencana untuk Azure Kubernetes Service (AKS)
Saat membuat dan mengelola aplikasi di cloud, selalu ada risiko gangguan dari pemadaman dan bencana. Untuk memastikan kelangsungan bisnis (SM), Anda perlu merencanakan ketersediaan tinggi (HA) dan pemulihan bencana (DR).
HA mengacu pada desain dan implementasi sistem atau layanan yang sangat andal dan mengalami waktu henti minimal. HA adalah kombinasi alat, teknologi, dan proses yang memastikan sistem atau layanan tersedia untuk melakukan fungsi yang dimaksudkan. HA adalah komponen penting dari perencanaan DR. DR adalah proses pemulihan dari bencana dan memulihkan operasi bisnis ke keadaan normal. DR adalah subset SM, yang merupakan proses mempertahankan fungsi bisnis atau dengan cepat membalasnya jika terjadi gangguan besar.
Artikel ini membahas beberapa praktik yang direkomendasikan untuk aplikasi yang disebarkan ke AKS, tetapi sama sekali tidak dimaksudkan sebagai daftar lengkap kemungkinan solusi.
Ikhtisar teknologi
Kluster Kube dibagi menjadi dua komponen:
- Sarana kontrol, yang menyediakan layanan inti Kubernetes dan orkestrasi beban kerja aplikasi, dan
- Simpul, yang menjalankan beban kerja aplikasi Anda.
Saat Anda membuat kluster AKS, platform Azure secara otomatis membuat dan mengonfigurasi sarana kontrol. AKS menawarkan dua tingkat harga untuk manajemen kluster: tingkat Gratis dan tingkat Standar. Untuk informasi selengkapnya, lihat Tingkat harga Gratis dan Standar untuk manajemen kluster AKS.
Sarana kontrol dan sumber dayanya hanya berada di wilayah tempat Anda membuat kluster. AKS menyediakan sarana kontrol penyewa tunggal dengan server API khusus, penjadwal, dll. Anda menentukan jumlah dan ukuran simpul, dan platform Azure mengonfigurasi komunikasi aman antara sarana kontrol dan simpul. Interaksi dengan sarana kontrol terjadi melalui API Kube, seperti kubectl atau dasbor Kube.
Untuk menjalankan aplikasi dan layanan pendukung, Anda memerlukan Node kube. Kluster AKS memiliki setidaknya satu kesimpulan, yaitu komputer virtual Azure yang menjalankan komponen simpul Kube dan runtime bahasa umum kontainer. Ukuran Azure VM untuk simpul Anda menentukan CPU, memori, ukuran, dan jenis penyimpanan yang tersedia (seperti SSD berkinerja tinggi atau HDD reguler). Rencanakan VM dan ukuran penyimpanan di sekitar apakah aplikasi Anda mungkin memerlukan CPU dan memori dalam jumlah besar atau penyimpanan berkinerja tinggi. Di AKS, gambar VM untuk simpul kluster Anda didasarkan pada Ubuntu Linux, Azure Linux, atau Windows Server 2022. Saat Anda membuat kluster AKS atau meluaskan skala jumlah simpul, platform Azure secara otomatis membuat dan mengonfigurasi jumlah komputer virtual yang diminta.
Untuk informasi selengkapnya tentang komponen kluster dan beban kerja di AKS, lihat Konsep inti Kubernetes untuk AKS.
Pertimbangan penting
Sumber daya regional dan global
Sumber daya regional disediakan sebagai bagian dari stempel penyebaran ke satu wilayah Azure. Sumber daya ini tidak berbagi apa pun dengan sumber daya di wilayah lain, dan dapat dihapus atau direplikasi secara independen ke wilayah lain. Untuk informasi selengkapnya, lihat Sumber daya regional.
Sumber daya global berbagi masa pakai sistem, dan mereka dapat tersedia secara global dalam konteks penyebaran multi-wilayah. Untuk informasi selengkapnya, lihat Sumber daya global.
Tujuan pemulihan
Rencana pemulihan bencana lengkap harus menentukan persyaratan bisnis untuk setiap proses yang diterapkan aplikasi:
- Tujuan Titik Pemulihan (RPO) adalah durasi maksimum kehilangan data yang dapat diterima. RPO diukur dalam satuan waktu, seperti menit, jam, atau hari.
- Tujuan Waktu Pemulihan (RTO) adalah durasi maksimum waktu henti yang dapat diterima, dengan waktu henti yang ditentukan oleh spesifikasi Anda. Misalnya, jika durasi waktu henti yang dapat diterima dalam bencana adalah delapan jam, maka RTO adalah delapan jam.
Zona ketersediaan
Anda dapat menggunakan zona ketersediaan untuk menyebarkan data Anda di beberapa zona di wilayah yang sama. Dalam suatu wilayah, zona ketersediaan cukup dekat untuk memiliki koneksi latensi rendah ke zona ketersediaan lain, tetapi cukup jauh untuk mengurangi kemungkinan bahwa lebih dari satu akan dipengaruhi oleh pemadaman atau cuaca lokal. Untuk informasi selengkapnya, lihat Rekomendasi untuk menggunakan zona dan wilayah ketersediaan.
Ketahanan zona
Kluster AKS tahan terhadap kegagalan zonal. Jika zona gagal, kluster terus berjalan di zona yang tersisa. Sarana kontrol dan simpul kluster tersebar di seluruh zona, dan platform Azure secara otomatis menangani distribusi simpul. Untuk informasi selengkapnya, lihat Ketahanan zona AKS.
Penyeimbangan Beban
Penyeimbangan beban global
Layanan penyeimbangan beban global mendistribusikan lalu lintas di seluruh backend regional, cloud, atau layanan lokal hibrid. Layanan ini merutekan lalu lintas pengguna akhir ke backend terdekat yang tersedia. Mereka juga bereaksi terhadap perubahan keandalan atau performa layanan untuk memaksimalkan ketersediaan dan performa. Layanan Azure berikut ini menyediakan penyeimbangan beban global:
- Azure Front Door
- Azure Traffic Manager
- Azure Load Balancer lintas wilayah
- Manajer Armada Azure Kubernetes
Penyeimbangan Muatan Internal
Layanan penyeimbangan beban regional mendistribusikan lalu lintas dalam jaringan virtual di seluruh VM atau titik akhir layanan zona dan zona-redundan dalam suatu wilayah. Layanan Azure berikut ini menyediakan penyeimbangan beban regional:
Observabilitas
Anda perlu mengumpulkan data dari aplikasi dan infrastruktur untuk memungkinkan operasi yang efektif dan keandalan yang dimaksimalkan. Azure menyediakan alat untuk membantu Anda memantau dan mengelola beban kerja AKS Anda. Untuk informasi selengkapnya, lihat Sumber daya Observabilitas.
Definisi cakupan
Waktu aktif aplikasi menjadi penting saat Anda mengelola kluster AKS. Secara default, AKS menyediakan ketersediaan tinggi dengan menggunakan beberapa simpul dalam Set Skala Komputer Virtual, tetapi simpul ini tidak melindungi sistem Anda dari kegagalan wilayah. Untuk memaksimalkan waktu aktif Anda, rencanakan ke depan untuk menjaga kelangsungan bisnis dan mempersiapkan pemulihan bencana menggunakan praktik terbaik berikut:
- Merencanakan kluster AKS di beberapa wilayah.
- Merutekan lalu lintas di beberapa kluster menggunakan Azure Traffic Manager.
- Menggunakan replikasi geo untuk registri citra kontainer Anda.
- Merencanakan status aplikasi di beberapa kluster.
- Mereplikasi penyimpanan di beberapa wilayah.
Implementasi model penyebaran
| Model Penyebaran | Pro | Kontra |
|---|---|---|
| Aktif-aktif | • Tidak ada kehilangan data atau ketidakkonsistensian selama failover • Ketahanan tinggi • Pemanfaatan sumber daya yang lebih baik dengan performa yang lebih tinggi |
• Implementasi dan manajemen yang kompleks • Biaya lebih tinggi • Memerlukan load balancer dan bentuk perutean lalu lintas |
| Aktif-pasif | • Implementasi dan manajemen yang lebih sederhana • Biaya lebih rendah • Tidak memerlukan load balancer atau traffic manager |
• Potensi kehilangan data atau inkonsistensi selama failover • Waktu pemulihan dan waktu henti yang lebih lama • Kurangnya penggunaan sumber daya |
| Pasif-dingin | • Biaya terendah • Tidak memerlukan sinkronisasi, replikasi, load balancer, atau manajer lalu lintas • Cocok untuk beban kerja berprioritas rendah dan tidak penting |
• Risiko tinggi kehilangan data atau inkonsistensi selama failover • Waktu pemulihan dan waktu henti terpanjang • Memerlukan intervensi manual untuk mengaktifkan kluster dan memicu pencadangan |
Model penyebaran ketersediaan tinggi aktif-aktif
Dalam model penyebaran ketersediaan tinggi aktif-aktif (HA), Anda memiliki dua kluster AKS independen yang disebarkan di dua wilayah Azure yang berbeda (biasanya wilayah yang dipasangkan, seperti Kanada Tengah dan Kanada Timur atau US Timur 2 dan US Tengah) yang secara aktif melayani lalu lintas.
Dengan contoh arsitektur ini:
- Anda menyebarkan dua kluster AKS di wilayah Azure terpisah.
- Selama operasi normal, lalu lintas jaringan merutekan antara kedua wilayah. Jika satu wilayah menjadi tidak tersedia, lalu lintas secara otomatis merutekan ke wilayah yang paling dekat dengan pengguna yang mengeluarkan permintaan.
- Ada pasangan hub-spoke yang disebarkan untuk setiap instans AKS regional. Kebijakan Azure Firewall Manager mengelola aturan firewall di seluruh wilayah.
- Azure Key Vault disediakan di setiap wilayah untuk menyimpan rahasia dan kunci.
- Azure Front Door menyeimbangkan beban dan merutekan lalu lintas ke instans Azure Application Gateway regional, yang berada di depan setiap kluster AKS.
- Instans Analitik Log Regional menyimpan metrik jaringan regional dan log diagnostik.
- Gambar kontainer untuk beban kerja disimpan dalam registri kontainer terkelola. Satu Azure Container Registry digunakan untuk semua instans Kubernetes dalam kluster. Replikasi geografis untuk Azure Container Registry memungkinkan replikasi gambar ke wilayah Azure yang dipilih dan menyediakan akses berkelanjutan ke gambar, bahkan jika suatu wilayah mengalami pemadaman.
Untuk membuat model penyebaran aktif-aktif di AKS, Anda melakukan langkah-langkah berikut:
Buat dua penyebaran yang identik di dua wilayah Azure yang berbeda.
Buat dua instans aplikasi web Anda.
Buat profil Azure Front Door dengan sumber daya berikut:
- Titik akhir.
- Dua grup asal, masing-masing dengan prioritas satu.
- Sebuah rute.
Batasi lalu lintas jaringan ke aplikasi web hanya dari instans Azure Front Door. 5. Konfigurasikan semua layanan Azure backend lainnya, seperti database, akun penyimpanan, dan penyedia autentikasi.
Sebarkan kode ke kedua aplikasi web dengan penyebaran berkelanjutan.
Untuk informasi selengkapnya, lihat Ringkasan solusi ketersediaan tinggi aktif-aktif yang direkomendasikan untuk AKS.
Model penyebaran pemulihan bencana pasif aktif
Dalam model penyebaran pemulihan bencana aktif-pasif (DR), Anda memiliki dua kluster AKS independen yang disebarkan di dua wilayah Azure yang berbeda (biasanya wilayah yang dipasangkan, seperti Kanada Tengah dan Kanada Timur atau US Timur 2 dan US Tengah) yang secara aktif melayani lalu lintas. Hanya salah satu kluster yang secara aktif melayani lalu lintas pada waktu tertentu. Kluster lain berisi konfigurasi dan data aplikasi yang sama dengan kluster aktif, tetapi tidak menerima lalu lintas kecuali diarahkan oleh manajer lalu lintas.
Dengan contoh arsitektur ini:
- Anda menyebarkan dua kluster AKS di wilayah Azure terpisah.
- Selama operasi normal, lalu lintas jaringan merutekan ke kluster AKS utama, yang Anda tetapkan dalam konfigurasi Azure Front Door.
- Prioritas perlu diatur antara 1-5 dengan 1 menjadi yang tertinggi dan 5 menjadi yang terendah.
- Anda dapat mengatur beberapa kluster ke tingkat prioritas yang sama dan dapat menentukan bobot masing-masing kluster.
- Jika kluster utama menjadi tidak tersedia (bencana terjadi), lalu lintas secara otomatis merutekan ke wilayah berikutnya yang dipilih di Azure Front Door.
- Semua lalu lintas harus melalui manajer lalu lintas Azure Front Door agar sistem ini berfungsi.
- Azure Front Door merutekan lalu lintas ke Azure App Gateway di wilayah utama (kluster harus ditandai dengan prioritas 1). Jika wilayah ini gagal, layanan mengalihkan lalu lintas ke kluster berikutnya dalam daftar prioritas.
- Aturan berasal dari Azure Front Door.
- Pasangan hub-spoke disebarkan untuk setiap instans AKS regional. Kebijakan Azure Firewall Manager mengelola aturan firewall di seluruh wilayah.
- Azure Key Vault disediakan di setiap wilayah untuk menyimpan rahasia dan kunci.
- Instans Analitik Log Regional menyimpan metrik jaringan regional dan log diagnostik.
- Gambar kontainer untuk beban kerja disimpan dalam registri kontainer terkelola. Satu Azure Container Registry digunakan untuk semua instans Kubernetes dalam kluster. Replikasi geografis untuk Azure Container Registry memungkinkan replikasi gambar ke wilayah Azure yang dipilih dan menyediakan akses berkelanjutan ke gambar, bahkan jika suatu wilayah mengalami pemadaman.
Untuk membuat model penyebaran pasif aktif di AKS, Anda melakukan langkah-langkah berikut:
Buat dua penyebaran yang identik di dua wilayah Azure yang berbeda.
Konfigurasikan aturan penskalaan otomatis untuk aplikasi sekunder sehingga diskalakan ke jumlah instans yang sama dengan yang utama ketika wilayah utama menjadi tidak aktif. Meskipun tidak aktif, tidak perlu ditingkatkan skalanya. Ini membantu mengurangi biaya.
Buat dua instans aplikasi web Anda, dengan satu di setiap kluster.
Buat profil Azure Front Door dengan sumber daya berikut:
- Titik akhir.
- Grup asal dengan prioritas satu untuk wilayah utama.
- Grup asal kedua dengan prioritas dua untuk wilayah sekunder.
- Sebuah rute.
Batasi lalu lintas jaringan ke aplikasi web hanya dari instans Azure Front Door.
Konfigurasikan semua layanan Azure backend lainnya, seperti database, akun penyimpanan, dan penyedia autentikasi.
Sebarkan kode ke kedua aplikasi web dengan penyebaran berkelanjutan.
Untuk informasi selengkapnya, lihat Ringkasan solusi pemulihan bencana pasif aktif yang direkomendasikan untuk AKS.
Model penyebaran failover pasif-dingin
Model penyebaran failover pasif-dingin dikonfigurasi dengan cara yang sama seperti model penyebaran pemulihan bencana pasif aktif, kecuali kluster tetap tidak aktif sampai pengguna mengaktifkannya jika terjadi bencana. Kami menganggap pendekatan ini di luar cakupan karena melibatkan konfigurasi serupa dengan pasif aktif, tetapi dengan kompleksitas intervensi manual yang ditambahkan untuk mengaktifkan kluster dan memicu cadangan.
Dengan contoh arsitektur ini:
- Anda membuat dua kluster AKS, sebaiknya di wilayah atau zona yang berbeda untuk ketahanan yang lebih baik.
- Ketika Anda perlu melakukan failover, Anda mengaktifkan penyebaran untuk mengambil alih arus lalu lintas.
- Jika kluster pasif utama turun, Anda perlu mengaktifkan kluster dingin secara manual untuk mengambil alih arus lalu lintas.
- Kondisi ini perlu diatur baik oleh input manual setiap kali atau peristiwa tertentu seperti yang Ditentukan oleh Anda.
- Azure Key Vault disediakan di setiap wilayah untuk menyimpan rahasia dan kunci.
- Instans Analitik Log Regional menyimpan metrik jaringan regional dan log diagnostik untuk setiap kluster.
Untuk membuat model penyebaran failover pasif-dingin di AKS, Anda melakukan langkah-langkah berikut:
- Buat dua penyebaran yang identik di zona/wilayah yang berbeda.
- Konfigurasikan aturan penskalaan otomatis untuk aplikasi sekunder sehingga diskalakan ke jumlah instans yang sama dengan yang utama ketika wilayah utama menjadi tidak aktif. Meskipun tidak aktif, tidak perlu ditingkatkan skalanya, yang membantu mengurangi biaya.
- Buat dua instans aplikasi web Anda, dengan satu di setiap kluster.
- Konfigurasikan semua layanan Azure backend lainnya, seperti database, akun penyimpanan, dan penyedia autentikasi.
- Atur kondisi ketika kluster dingin harus dipicu. Anda dapat menggunakan load balancer jika anda membutuhkan.
Untuk informasi selengkapnya, lihat Ringkasan solusi failover pasif-dingin yang direkomendasikan untuk AKS.
Kuota dan batas layanan
AKS menetapkan batas dan kuota default untuk sumber daya dan fitur, termasuk pembatasan penggunaan untuk SKU VM tertentu.
| Sumber daya | Batasan |
|---|---|
| Kluster maksimum per langganan | 5000 Catatan: menyebarkan kluster di berbagai wilayah untuk memperhitungkan batas pembatasan Azure API |
| Node maksimum per kluster dengan Virtual Machine Scale Sets dan SKU Load Balancer Dasar | 5000 di semua kumpulan simpul Catatan: Jika Anda tidak dapat menskalakan hingga 5000 simpul per kluster, lihat Praktik Terbaik untuk Kluster Besar. |
| Simpul maksimum per kumpulan simpul (kumpulan simpul Virtual Machine Scale Sets) | 1000 |
| Kumpulan node maksimum per kluster | 100 |
| Pod maksimum per simpul: dengan plug-injaringan Kubenet 1 | Maksimum: 250 Default Azure CLI: 110 Default templat Azure Resource Manager: 110 Default penyebaran portal Azure: 30 |
| Pod maksimum per simpul: dengan Antarmuka Jaringan Kontainer Azure (Azure CNI)1 | Maksimum: 250 Maksimum yang direkomendasikan untuk kontainer Windows Server: 110 Default: 30. |
| Add-on AKS Open Service Mesh (OSM) | Versi Kluster Kubernetes: Versi AKS yang Didukung Pengontrol OSM per kluster: 1 Pod per pengontrol OSM: 1600 Akun layanan Kubernetes yang dikelola OSM: 160 |
| Layanan kubernetes seimbang beban maksimum per kluster dengan SKU Load Balancer Standar | 300 |
| Node maksimum per kluster dengan Virtual Machine Availability Sets dan SKU Load Balancer Dasar | 100 |
1 kontainer Windows Server harus menggunakan plug-in jaringan Azure CNI. Kubenet tidak didukung untuk kontainer Windows Server.
| Batas Sarana Kontrol Kube | Batas |
|---|---|
| Tingkat standar | Secara otomatis menskalakan server API Kubernetes berdasarkan beban. Batas komponen sarana kontrol yang lebih besar dan server API/instans dll. |
| Tingkat gratis | Sumber daya terbatas dengan batas permintaan dalam penerbangan 50 bermutasi dan 100 panggilan baca-saja. Batas simpul yang direkomendasikan sebesar 10 simpul per kluster. Terbaik untuk bereksperimen, belajar, dan pengujian sederhana. Tidak disarankan untuk beban kerja produksi/kritis. |
Untuk informasi selengkapnya, lihat Kuota dan batas layanan AKS.
Cadangan
Azure Backup mendukung pencadangan sumber daya kluster AKS dan volume persisten yang terpasang pada kluster menggunakan ekstensi cadangan. Vault Backup berkomunikasi dengan kluster AKS melalui ekstensi untuk melakukan operasi pencadangan dan pemulihan.
Untuk informasi lebih lanjut, baca artikel berikut: