Baca dalam bahasa Inggris

Bagikan melalui


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)

Gambaran Umum

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.

Membuat zona komponen kluster AKS Anda tangguh

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.

Membuat kluster zona redundan dan kumpulan simpul

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).

Pastikan pod tersebar di AZ

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.

Mengonfigurasi jaringan sadar AZ

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:

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.

Menyiapkan registri kontainer zona-redundan dan direplikasi secara geografis

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.

Memastikan ketersediaan dan redundansi untuk kunci dan rahasia

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.

Memanfaatkan fitur penskalakan otomatis

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).

Merancang aplikasi stateless

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.

Membuat keputusan disk penyimpanan Anda

Pilih jenis disk yang tepat berdasarkan kebutuhan aplikasi

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).

Memantau performa disk

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.

Uji ketahanan AZ

Metode 1: Cordon dan node pengurasan dalam satu AZ

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

Metode 2: Mensimulasikan kegagalan AZ menggunakan Azure Chaos Studio

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?.

Langkah berikutnya

Untuk detail implementasi selengkapnya, lihat Panduan untuk kluster dan penyimpanan AKS zona redundan.