Pertimbangan ketahanan zona untuk Azure Kubernetes Service (AKS)
Dalam artikel ini, Anda mempelajari berbagai pertimbangan untuk ketahanan zona di Azure Kubernetes Service (AKS), termasuk cara:
- Membuat zona komponen kluster AKS Anda tangguh
- Merancang aplikasi stateless
- Membuat keputusan disk penyimpanan Anda
- Uji ketahanan zona ketersediaan (AZ)
Ketahanan AZ adalah bagian penting dari menjalankan kluster Kubernetes tingkat produksi. Dengan skalabilitas pada intinya, Kubernetes memanfaatkan sepenuhnya infrastruktur independen di pusat data tanpa menimbulkan biaya tambahan dengan menyediakan simpul baru hanya jika diperlukan.
Penting
Cukup meningkatkan atau menurunkan jumlah simpul dalam kluster tidak cukup untuk memastikan ketahanan aplikasi. Anda harus mendapatkan pemahaman yang lebih mendalam tentang aplikasi Anda dan dependensinya untuk merencanakan ketahanan dengan lebih baik. AKS memungkinkan Anda menyiapkan zona ketersediaan (AZ) untuk kluster dan kumpulan simpul Anda untuk memastikan bahwa aplikasi Anda tahan terhadap kegagalan dan dapat terus melayani lalu lintas meskipun seluruh zona tidak berfungsi.
Bagian berikut memberikan panduan tentang poin keputusan utama untuk membuat zona komponen kluster AKS Anda tangguh, tetapi tidak lengkap. Anda harus mempertimbangkan faktor lain berdasarkan persyaratan dan batasan spesifik Anda dan memeriksa dependensi Anda yang lain untuk memastikannya dikonfigurasi untuk ketahanan zona.
AKS memungkinkan Anda memilih beberapa AZ selama pembuatan kumpulan kluster dan simpul. Saat Anda membuat kluster dengan beberapa AZ, sarana kontrol tersebar di AZ yang dipilih. Simpul di kumpulan simpul juga tersebar di AZ yang dipilih. Pendekatan ini memastikan bahwa sarana kontrol dan simpul didistribusikan di beberapa AZ, memberikan ketahanan jika terjadi kegagalan AZ. Anda dapat mengonfigurasi AZ menggunakan templat portal Azure, Azure CLI, atau Azure Resource Manager.
Contoh berikut menunjukkan cara membuat kluster dengan tiga simpul yang tersebar di tiga AZ menggunakan Azure CLI:
az aks create --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --generate-ssh-keys --vm-set-type VirtualMachineScaleSets --load-balancer-sku standard --node-count 3 --zones 1 2 3
Setelah kluster dibuat, Anda dapat menggunakan perintah berikut untuk mengambil wilayah dan zona ketersediaan untuk setiap simpul agen dari label:
kubectl describe nodes | grep -e "Name:" -e "topology.kubernetes.io/zone"
Contoh output berikut menunjukkan wilayah dan zona ketersediaan untuk setiap simpul agen:
Name: aks-nodepool1-28993262-vmss000000
topology.kubernetes.io/zone=eastus2-1
Name: aks-nodepool1-28993262-vmss000001
topology.kubernetes.io/zone=eastus2-2
Name: aks-nodepool1-28993262-vmss000002
topology.kubernetes.io/zone=eastus2-3
Untuk informasi selengkapnya, lihat Menggunakan zona ketersediaan di Azure Kubernetes Service (AKS).
Anda dapat menggunakan batasan spread topologi pod berdasarkan zone
label dan hostname
untuk menyebarkan pod di seluruh AZ dalam suatu wilayah dan di seluruh simpul dalam AZ.
Misalnya, Anda memiliki kluster empat node di mana tiga pod berlabel foo:bar
berada di node1
, node2
, dan node3
masing-masing. Jika Anda ingin pod masuk didistribusikan secara merata dengan pod yang ada di seluruh zona, Anda dapat menggunakan manifes yang mirip dengan contoh berikut:
kind: Pod
apiVersion: v1
metadata:
name: mypod
labels:
foo: bar
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: "topology.kubernetes.io/zone"
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
foo: bar
containers:
- name: pause
image: registry.k8s.io/pause:3.1
Untuk informasi selengkapnya, lihat Batasan Sebaran Topologi Pod Kubernetes.
Jika Anda memiliki pod yang melayani lalu lintas jaringan, Anda harus memuat lalu lintas keseimbangan di beberapa AZ untuk memastikan bahwa aplikasi Anda sangat tersedia dan tahan terhadap kegagalan. Anda dapat menggunakan Azure Load Balancer untuk mendistribusikan lalu lintas masuk di seluruh simpul di kluster AKS Anda.
Azure Load Balancer mendukung penyeimbangan beban internal dan eksternal, dan Anda dapat mengonfigurasinya untuk menggunakan SKU Standar untuk penyeimbangan beban zona-redundan. SKU Standar adalah SKU default di AKS, dan mendukung ketahanan regional dengan zona ketersediaan untuk memastikan aplikasi Anda tidak terpengaruh oleh kegagalan wilayah. Jika terjadi skenario kegagalan zona, load balancer SKU Standar yang berlebihan zona tidak terpengaruh oleh kegagalan dan memungkinkan penyebaran Anda untuk terus melayani lalu lintas dari zona yang tersisa. Anda dapat menggunakan load balancer global, seperti Front Door atau Traffic Manager, atau Anda dapat menggunakan load balancer lintas wilayah di depan kluster AKS regional Anda untuk memastikan bahwa aplikasi Anda tidak terpengaruh oleh kegagalan regional. Untuk membuat load balancer SKU Standar di AKS, lihat Menggunakan load balancer standar di Azure Kubernetes Service (AKS).
Untuk memastikan bahwa lalu lintas jaringan aplikasi Anda tahan terhadap kegagalan, Anda harus mengonfigurasi jaringan sadar AZ untuk beban kerja AKS Anda. Azure menawarkan berbagai layanan jaringan yang mendukung AZ:
- Azure VPN Gateway: Anda dapat menyebarkan gateway VPN dan ExpressRoute di Azure AZs untuk memungkinkan ketahanan, skalabilitas, dan ketersediaan yang lebih baik ke gateway jaringan virtual. Untuk informasi selengkapnya, lihat Membuat gateway jaringan virtual zona-redundan di zona ketersediaan.
- Azure Application Gateway v2: Azure Application Gateway menyediakan load balancer L7 regional dengan dukungan zona ketersediaan. Untuk informasi selengkapnya, lihat Lalu lintas web langsung dengan Azure Application Gateway.
- Azure Front Door: Azure Front Door menyediakan load balancer L7 global dan memanfaatkan titik kehadiran (POP) atau Azure Content Delivery Network (CDN). Untuk informasi selengkapnya, lihat Lokasi POP Azure Front Door.
Penting
Dengan Azure NAT Gateway, Anda dapat membuat gateway NAT di AZ tertentu atau menggunakan penyebaran zona untuk isolasi ke zona tertentu. NAT Gateway mendukung penyebaran zona tetapi bukan penyebaran zona-redundan. Ini mungkin masalah jika Anda mengonfigurasi kluster AKS dengan jenis keluar yang sama dengan gateway NAT dan gateway NAT berada dalam satu zona. Dalam hal ini, jika zona yang menghosting gateway NAT Anda tidak berfungsi, kluster Anda kehilangan konektivitas keluar. Untuk informasi selengkapnya, lihat NAT Gateway dan zona ketersediaan.
Untuk memastikan bahwa gambar kontainer Anda sangat tersedia dan tahan terhadap kegagalan, Anda harus menyiapkan registri kontainer zona-redundan. SKU Premium Azure Container Registry (ACR) mendukung replikasi geografis dan redundansi zona opsional. Fitur-fitur ini memberikan ketersediaan dan mengurangi latensi untuk operasi regional.
Azure Key Vault menyediakan beberapa lapisan redundansi untuk memastikan kunci dan rahasia Anda tetap tersedia untuk aplikasi Anda meskipun komponen individual layanan gagal, atau jika wilayah Azure atau AZ tidak tersedia. Untuk informasi selengkapnya, lihat Ketersediaan dan redundansi Azure Key Vault.
Anda dapat meningkatkan ketersediaan dan ketahanan aplikasi di AKS menggunakan fitur penskalaan otomatis, yang membantu Anda mencapai tujuan berikut:
- Optimalkan pemanfaatan sumber daya dan efisiensi biaya dengan meningkatkan atau menurunkan skala berdasarkan penggunaan CPU dan memori pod Anda.
- Tingkatkan toleransi dan pemulihan kesalahan dengan menambahkan lebih banyak simpul atau pod ketika kegagalan zona terjadi.
Anda dapat menggunakan Horizontal Pod Autoscaler (HPA) dan Cluster Autoscaler untuk mengimplementasikan autoscaling di AKS. HPA secara otomatis menskalakan jumlah pod dalam penyebaran berdasarkan pemanfaatan CPU yang diamati, pemanfaatan memori, metrik kustom, dan metrik layanan lain. Autoscaler Kluster secara otomatis menyesuaikan jumlah simpul dalam kumpulan simpul berdasarkan permintaan sumber daya pod yang berjalan pada simpul. Jika Anda ingin menggunakan kedua penskala otomatis bersama-sama, pastikan kumpulan simpul dengan penskala otomatis diaktifkan mencakup beberapa zona. Jika kumpulan simpul berada dalam satu zona dan zona tersebut turun, autoscaler tidak dapat menskalakan kluster di seluruh zona.
Fitur pratinjau Penyedia Karpenter AKS memungkinkan provisi otomatis simpul menggunakan Karpenter pada kluster AKS Anda. Untuk informasi selengkapnya, lihat gambaran umum fitur Penyedia Karpenter AKS.
Add-on Autoscaling berbasis Peristiwa (KEDA) Kubernetes untuk AKS menerapkan penskalaan otomatis berbasis peristiwa untuk menskalakan aplikasi Anda berdasarkan metrik layanan eksternal untuk memenuhi permintaan. Untuk informasi selengkapnya, lihat Menginstal add-on KEDA di Azure Kubernetes Service (AKS).
Ketika aplikasi tanpa status, logika aplikasi dan data dipisahkan, dan pod tidak menyimpan data persisten atau sesi pada disk lokal mereka. Desain ini memungkinkan aplikasi untuk dengan mudah ditingkatkan atau diturunkan tanpa khawatir tentang kehilangan data. Aplikasi stateless lebih tahan terhadap kegagalan karena dapat dengan mudah diganti atau dijadwalkan ulang pada node yang berbeda jika terjadi kegagalan node.
Saat merancang aplikasi stateless dengan AKS, Anda harus menggunakan layanan Azure terkelola, seperti Azure Database, Azure Cache for Redis, atau Azure Storage untuk menyimpan data aplikasi. Menggunakan layanan ini memastikan lalu lintas Anda dapat dipindahkan di seluruh simpul dan zona tanpa memperkirakan kehilangan data atau berdampak pada pengalaman pengguna. Anda dapat menggunakan Penyebaran, Layanan, dan Pemeriksaan Kesehatan Kubernetes untuk mengelola pod tanpa status dan memastikan distribusi yang merata di seluruh zona.
Azure menawarkan dua jenis disk untuk penyimpanan persisten: penyimpanan redundan lokal (LRS) dan penyimpanan redundan zona (ZRS). LRS mereplikasi data Anda dalam satu AZ. ZRS mereplikasi data Anda di beberapa AZ dalam suatu wilayah. Mulai dari AKS versi 1.29, kelas penyimpanan default menggunakan disk ZRS untuk penyimpanan persisten. Untuk informasi selengkapnya, lihat Kelas penyimpanan bawaan AKS.
Cara aplikasi Anda mereplikasi data dapat memengaruhi pilihan disk Anda. Jika aplikasi Anda terletak di beberapa zona dan mereplikasi data dari dalam aplikasi, Anda dapat mencapai ketahanan dengan disk LRS di setiap AZ karena jika satu AZ turun, AZ lain akan memiliki data terbaru yang tersedia untuk mereka. Jika lapisan aplikasi Anda tidak menangani replikasi tersebut, disk ZRS adalah pilihan yang lebih baik, karena Azure menangani replikasi di lapisan penyimpanan.
Tabel berikut menguraikan pro dan kontra dari setiap jenis disk:
Jenis disk OS | Pro | Kontra |
---|---|---|
LRS | • Biaya lebih rendah • Didukung untuk semua ukuran dan wilayah disk • Mudah digunakan dan disediakan |
• Ketersediaan dan durabilitas yang lebih rendah • Rentan terhadap kegagalan zona • Tidak mendukung zona atau replikasi geografis |
ZRS | • Ketersediaan dan durabilitas yang lebih tinggi • Lebih tahan terhadap kegagalan zonal • Mendukung replikasi zona untuk ketahanan intra-wilayah |
• Biaya lebih tinggi • Tidak didukung untuk semua ukuran dan wilayah disk • Memerlukan konfigurasi tambahan untuk mengaktifkan |
Untuk informasi selengkapnya tentang jenis disk LRS dan ZRS, lihat Redundansi Azure Storage. Untuk memprovisikan disk penyimpanan di AKS, lihat Memprovisikan penyimpanan Azure Disks di Azure Kubernetes Service (AKS).
Untuk memastikan performa dan ketersediaan disk penyimpanan yang optimal di AKS, Anda harus memantau metrik utama, seperti IOPS, throughput, dan latensi. Metrik ini dapat membantu Anda mengidentifikasi masalah atau hambatan yang mungkin memengaruhi performa aplikasi Anda. Jika Anda melihat masalah performa yang konsisten, Anda mungkin ingin mempertimbangkan kembali jenis atau ukuran disk penyimpanan Anda. Anda dapat menggunakan Azure Monitor untuk mengumpulkan dan memvisualisasikan metrik ini dan menyiapkan pemberitahuan untuk memberi tahu Anda tentang masalah performa apa pun.
Untuk informasi selengkapnya, lihat Memantau Azure Kubernetes Service (AKS) dengan Azure Monitor.
Salah satu cara untuk menguji kluster AKS Anda untuk ketahanan AZ adalah dengan menguras node di satu zona dan melihat bagaimana hal itu memengaruhi lalu lintas sampai gagal ke zona lain. Metode ini mensimulasikan skenario dunia nyata di mana seluruh zona tidak tersedia karena bencana atau pemadaman. Untuk menguji skenario ini, Anda dapat menggunakan kubectl drain
perintah untuk mengeluarkan semua pod dengan anggun dari simpul dan menandainya sebagai tidak dapat dischedulable. Anda kemudian dapat memantau lalu lintas dan performa kluster menggunakan alat seperti Azure Monitor atau Prometheus.
Tabel berikut menguraikan pro dan kontra dari metode ini:
Pro | Kontra |
---|---|
• Menipu skenario kegagalan realistis dan menguji proses pemulihan • Memungkinkan Anda memverifikasi ketersediaan dan durabilitas data Anda di seluruh wilayah • Membantu Anda mengidentifikasi potensi masalah atau hambatan dalam konfigurasi kluster atau desain aplikasi Anda |
• Dapat menyebabkan gangguan sementara atau degradasi layanan untuk pengguna Anda • Memerlukan intervensi dan koordinasi manual untuk mengkuras dan memulihkan node • Mungkin dikenakan biaya tambahan karena peningkatan lalu lintas jaringan atau replikasi penyimpanan |
Cara lain untuk menguji kluster AKS Anda untuk ketahanan AZ adalah dengan menyuntikkan kesalahan ke kluster Anda dan mengamati dampaknya pada aplikasi Anda menggunakan Azure Chaos Studio. Azure Chaos Studio adalah layanan yang memungkinkan Anda membuat dan mengelola eksperimen chaos pada sumber daya dan layanan Azure. Anda dapat menggunakan Chaos Studio untuk mensimulasikan kegagalan AZ dengan membuat eksperimen injeksi kesalahan yang menargetkan zona tertentu dan menghentikan atau memulai ulang komputer virtual (VM) di zona tersebut. Anda kemudian dapat mengukur ketersediaan, latensi, dan tingkat kesalahan aplikasi Anda menggunakan metrik dan log.
Tabel berikut menguraikan pro dan kontra dari metode ini:
Pro | Kontra |
---|---|
• Menyediakan cara terkontrol dan otomatis untuk menyuntikkan kesalahan dan memantau hasilnya • Mendukung berbagai jenis kesalahan dan skenario, seperti latensi jaringan, stres CPU, kegagalan disk, dll. • Terintegrasi dengan Azure Monitor dan alat lain untuk mengumpulkan dan menganalisis data |
• Mungkin memerlukan konfigurasi dan penyiapan tambahan untuk membuat dan menjalankan eksperimen • Mungkin tidak mencakup semua kemungkinan mode kegagalan dan zona tepi yang dapat terjadi selama pemadaman nyata • Mungkin memiliki batasan atau batasan pada cakupan dan/atau durasi eksperimen |
Untuk informasi selengkapnya, lihat Apa itu Azure Chaos Studio?.
Untuk detail implementasi selengkapnya, lihat Panduan untuk kluster dan penyimpanan AKS zona redundan.
Umpan balik Azure Kubernetes Service
Azure Kubernetes Service adalah proyek sumber terbuka. Pilih tautan untuk memberikan umpan balik: