Share via

Praktik terbaik untuk performa dan penskalaan untuk beban kerja kecil hingga menengah di Azure Kubernetes Service (AKS)

  • Artikel

Catatan

Artikel ini berfokus pada praktik terbaik umum untuk beban kerja kecil hingga menengah. Untuk praktik terbaik khusus untuk beban kerja besar, lihat Praktik terbaik performa dan penskalaan untuk beban kerja besar di Azure Kubernetes Service (AKS).

Saat Anda menyebarkan dan memelihara kluster di AKS, Anda dapat menggunakan praktik terbaik berikut untuk membantu Anda mengoptimalkan performa dan penskalakan.

Dalam artikel ini, Anda mempelajari tentang:

  • Tradeoff dan rekomendasi untuk penskalaan otomatis beban kerja Anda.
  • Mengelola penskalaan dan efisiensi simpul berdasarkan tuntutan beban kerja Anda.
  • Pertimbangan jaringan untuk lalu lintas masuk dan keluar.
  • Memantau dan memecahkan masalah sarana kontrol dan performa simpul.
  • Perencanaan kapasitas, skenario lonjakan, dan peningkatan kluster.
  • Pertimbangan penyimpanan dan jaringan untuk performa data plane.

Autoscaling aplikasi vs. autoscaling infrastruktur

Penskalakan otomatis aplikasi

Penskalaan otomatis aplikasi berguna saat menangani pengoptimalan biaya atau keterbatasan infrastruktur. Penskala otomatis yang dikonfigurasi dengan baik mempertahankan ketersediaan tinggi untuk aplikasi Anda sekaligus meminimalkan biaya. Anda hanya membayar sumber daya yang diperlukan untuk menjaga ketersediaan, terlepas dari permintaannya.

Misalnya, jika simpul yang ada memiliki ruang tetapi tidak cukup IP di subnet, simpul mungkin dapat melewati pembuatan simpul baru dan sebaliknya segera mulai menjalankan aplikasi pada pod baru.

Penskalakan otomatis Pod Horizontal

Menerapkan penskalaan otomatis pod horizontal berguna untuk aplikasi dengan permintaan sumber daya yang stabil dan dapat diprediksi. Horizontal Pod Autoscaler (HPA) secara dinamis menskalakan jumlah replika pod, yang secara efektif mendistribusikan beban di beberapa pod dan simpul. Mekanisme penskalaan ini biasanya paling bermanfaat untuk aplikasi yang dapat diurai menjadi komponen yang lebih kecil dan independen yang mampu berjalan secara paralel.

HPA menyediakan metrik pemanfaatan sumber daya secara default. Anda juga dapat mengintegrasikan metrik kustom atau memanfaatkan alat seperti Kubernetes Event-Driven Autoscaler (KEDA) (Pratinjau). Ekstensi ini memungkinkan HPA membuat keputusan penskalaan berdasarkan beberapa perspektif dan kriteria, memberikan tampilan yang lebih holistik tentang performa aplikasi Anda. Ini sangat membantu untuk aplikasi dengan berbagai persyaratan penskalaan yang kompleks.

Catatan

Jika mempertahankan ketersediaan tinggi untuk aplikasi Anda adalah prioritas utama, sebaiknya tinggalkan buffer yang sedikit lebih tinggi untuk nomor pod minimum agar HPA Anda memperhitungkan waktu penskalaan.

Penskalakan otomatis Pod Vertikal

Menerapkan penskalaan otomatis pod vertikal berguna untuk aplikasi dengan tuntutan sumber daya yang berfluktuasi dan tidak dapat diprediksi. Penskala Otomatis Pod Vertikal (VPA) memungkinkan Anda menyempurnakan permintaan sumber daya, termasuk CPU dan memori, untuk pod individual, memungkinkan kontrol yang tepat atas alokasi sumber daya. Granularitas ini meminimalkan limbah sumber daya dan meningkatkan efisiensi pemanfaatan kluster secara keseluruhan. VPA juga menyederhanakan manajemen aplikasi dengan mengotomatiskan alokasi sumber daya, membebaskan sumber daya untuk tugas penting.

Peringatan

Anda tidak boleh menggunakan VPA bersama dengan HPA pada metrik CPU atau memori yang sama. Kombinasi ini dapat menyebabkan konflik, karena kedua penskala otomatis mencoba merespons perubahan permintaan menggunakan metrik yang sama. Namun, Anda dapat menggunakan VPA untuk CPU atau memori bersama dengan HPA untuk metrik kustom untuk mencegah tumpang tindih dan memastikan bahwa setiap autoscaler berfokus pada aspek penskalaan beban kerja yang berbeda.

Catatan

VPA berfungsi berdasarkan data historis. Sebaiknya tunggu setidaknya 24 jam setelah menyebarkan VPA sebelum menerapkan perubahan apa pun untuk memberinya waktu untuk mengumpulkan data rekomendasi.

Penskalakan otomatis infrastruktur

Penskalaan otomatis kluster

Menerapkan autoscaling kluster berguna jika node yang ada tidak memiliki kapasitas yang memadai, karena membantu meningkatkan dan menyediakan simpul baru.

Saat mempertimbangkan penskalaan otomatis kluster, keputusan kapan harus menghapus node melibatkan tradeoff antara mengoptimalkan pemanfaatan sumber daya dan memastikan ketersediaan sumber daya. Menghilangkan simpul yang kurang digunakan meningkatkan pemanfaatan kluster tetapi dapat mengakibatkan beban kerja baru harus menunggu sumber daya disediakan sebelum dapat disebarkan. Penting untuk menemukan keseimbangan antara kedua faktor ini yang selaras dengan persyaratan kluster dan beban kerja Anda dan mengonfigurasi pengaturan profil autoscaler kluster yang sesuai.

Pengaturan profil Autoscaler Kluster berlaku secara universal untuk semua kumpulan simpul yang diaktifkan autoscaler di kluster Anda. Ini berarti bahwa setiap tindakan penskalaan yang terjadi dalam satu kumpulan simpul berkemampuan autoscaler dapat memengaruhi perilaku penskalaan otomatis di kumpulan simpul lain. Penting untuk menerapkan pengaturan profil yang konsisten dan disinkronkan di semua kumpulan simpul yang relevan untuk memastikan bahwa autoscaler bertingkah seperti yang diharapkan.

Provisi berlebih

Provisi berlebih adalah strategi yang membantu mengurangi risiko tekanan aplikasi dengan memastikan adanya kelebihan sumber daya yang tersedia. Pendekatan ini sangat berguna untuk aplikasi yang mengalami beban yang sangat variabel dan pola penskalaan kluster yang sering menunjukkan peningkatan skala dan penurunan skala.

Untuk menentukan jumlah provisi berlebih yang optimal, Anda bisa menggunakan rumus berikut:

1-buffer/1+traffic

Misalnya, Anda ingin menghindari mencapai pemanfaatan CPU 100% di kluster Anda. Anda mungkin memilih buffer 30% untuk mempertahankan margin keamanan. Jika Anda mengantisipasi tingkat pertumbuhan lalu lintas rata-rata 40%, Anda mungkin mempertimbangkan provisi berlebih sebesar 50%, seperti yang dihitung oleh rumus:

1-30%/1+40%=50%

Metode provisi berlebihan yang efektif melibatkan penggunaan pod jeda. Pod jeda adalah penyebaran berprioritas rendah yang dapat dengan mudah digantikan oleh penyebaran berprioritas tinggi. Anda membuat pod berprioritas rendah yang melayani satu-satunya tujuan untuk mempertahankan ruang buffer. Ketika pod berprioritas tinggi membutuhkan ruang, pod jeda akan dihapus dan dijadwalkan ulang pada simpul lain atau simpul baru untuk mengakomodasi pod berprioritas tinggi.

YAML berikut menunjukkan contoh menjeda manifes pod:

apiVersion: scheduling.k8s.io/v1 
kind: PriorityClass 
metadata: 
  name: overprovisioning 
value: -1 
globalDefault: false 
description: "Priority class used by overprovisioning." 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: overprovisioning 
  namespace: kube-system 
spec: 
  replicas: 1 
  selector: 
    matchLabels: 
      run: overprovisioning 
  template: 
    metadata: 
      labels: 
        run: overprovisioning 
    spec: 
      priorityClassName: overprovisioning 
      containers: 
      - name: reserve-resources 
        image: your-custome-pause-image 
        resources: 
          requests: 
            cpu: 1 
            memory: 4Gi

Penskalaan dan efisiensi node

Panduan praktik terbaik:

Pantau pemanfaatan sumber daya dan kebijakan penjadwalan dengan cermat untuk memastikan simpul digunakan secara efisien.

Penskalaan simpul memungkinkan Anda untuk menyesuaikan jumlah simpul di kluster Anda secara dinamis berdasarkan tuntutan beban kerja. Penting untuk dipahami bahwa menambahkan lebih banyak simpul ke kluster bukanlah solusi terbaik untuk meningkatkan performa. Untuk memastikan performa optimal, Anda harus memantau pemanfaatan sumber daya dan kebijakan penjadwalan dengan cermat untuk memastikan simpul digunakan secara efisien.

Gambar simpul

Panduan praktik terbaik:

Gunakan versi gambar simpul terbaru untuk memastikan bahwa Anda memiliki patch keamanan terbaru dan perbaikan bug.

Menggunakan versi gambar simpul terbaru memberikan pengalaman performa terbaik. AKS mengirimkan peningkatan performa dalam rilis gambar mingguan. Gambar daemonset terbaru di-cache pada gambar VHD terbaru, yang memberikan manfaat latensi yang lebih rendah untuk provisi node dan bootstrapping. Tertinggal pada pembaruan mungkin berdampak negatif pada performa, jadi penting untuk menghindari kesenjangan besar antar versi.

Azure Linux

Azure Linux Container Host di AKS menggunakan gambar AKS asli dan menyediakan satu tempat untuk pengembangan Linux. Setiap paket dibangun dari sumber dan divalidasi, memastikan layanan Anda berjalan pada komponen yang terbukti.

Azure Linux ringan, hanya menyertakan sekumpulan paket yang diperlukan untuk menjalankan beban kerja kontainer. Ini menyediakan permukaan serangan yang berkurang dan menghilangkan patching dan pemeliharaan paket yang tidak perlu. Pada lapisan dasarnya, ia memiliki kernel yang diperkeras Microsoft yang disetel untuk Azure. Gambar ini sangat ideal untuk beban kerja yang sensitif terhadap performa dan teknisi platform atau operator yang mengelola armada kluster AKS.

Ubuntu 2204

Gambar Ubuntu 2204 adalah gambar simpul default untuk AKS. Ini adalah sistem operasi yang ringan dan efisien yang dioptimalkan untuk menjalankan beban kerja kontainer. Ini berarti bahwa ini dapat membantu mengurangi penggunaan sumber daya dan meningkatkan performa keseluruhan. Gambar ini mencakup patch dan pembaruan keamanan terbaru, yang membantu memastikan bahwa beban kerja Anda terlindungi dari kerentanan.

Gambar Ubuntu 2204 didukung penuh oleh Microsoft, Canonical, dan komunitas Ubuntu dan dapat membantu Anda mencapai performa dan keamanan yang lebih baik untuk beban kerja kontainer Anda.

Komputer virtual (VM)

Panduan praktik terbaik:

Saat memilih VM, pastikan ukuran dan performa disk OS dan SKU VM tidak memiliki perbedaan besar. Perbedaan ukuran atau performa dapat menyebabkan masalah performa dan ketidakcocokan sumber daya.

Performa aplikasi terkait erat dengan SKU VM yang Anda gunakan dalam beban kerja Anda. VM yang lebih besar dan lebih kuat, umumnya memberikan performa yang lebih baik. Untuk beban kerja misi penting atau produk, sebaiknya gunakan VM dengan setidaknya CPU 8 inti. VM dengan generasi perangkat keras yang lebih baru, seperti v4 dan v5, juga dapat membantu meningkatkan performa. Perlu diingat bahwa latensi pembuatan dan skala mungkin bervariasi tergantung pada SKU VM yang Anda gunakan.

Menggunakan kumpulan simpul sistem khusus

Untuk menskalakan performa dan keandalan, sebaiknya gunakan kumpulan simpul sistem khusus. Dengan konfigurasi ini, kumpulan simpul sistem khusus mencadangkan ruang untuk sumber daya sistem penting seperti daemon OS sistem. Beban kerja aplikasi Anda kemudian dapat berjalan di kumpulan simpul pengguna untuk meningkatkan ketersediaan sumber daya yang dapat dialokasikan untuk aplikasi Anda. Konfigurasi ini juga membantu mengurangi risiko persaingan sumber daya antara sistem dan aplikasi.

Operasi buat

Tinjau ekstensi dan add-on yang telah Anda aktifkan selama membuat provisi. Ekstensi dan add-on dapat menambahkan latensi ke durasi keseluruhan operasi pembuatan. Jika Anda tidak memerlukan ekstensi atau add-on, sebaiknya hapus untuk meningkatkan latensi buat.

Anda juga dapat menggunakan zona ketersediaan untuk memberikan tingkat ketersediaan yang lebih tinggi untuk melindungi dari potensi kegagalan perangkat keras atau peristiwa pemeliharaan terencana. Kluster AKS mendistribusikan sumber daya di seluruh bagian logis dari infrastruktur Azure yang mendasar. Zona ketersediaan secara fisik memisahkan simpul dari simpul lain untuk membantu memastikan bahwa satu kegagalan tidak memengaruhi ketersediaan aplikasi Anda. Zona ketersediaan hanya tersedia di wilayah tertentu. Untuk mengetahui informasi selengkapnya, lihat Zona ketersediaan di Azure.

Server API Kubernetes

Operasi LIST dan WATCH

Kubernetes menggunakan operasi LIST dan WATCH untuk berinteraksi dengan server API Kubernetes dan memantau informasi tentang sumber daya kluster. Operasi ini sangat mendasar tentang bagaimana Kubernetes melakukan manajemen sumber daya.

Operasi LIST mengambil daftar sumber daya yang sesuai dengan kriteria tertentu, seperti semua pod dalam namespace tertentu atau semua layanan dalam kluster. Operasi ini berguna ketika Anda ingin mendapatkan gambaran umum sumber daya kluster Anda atau Anda perlu operator pada beberapa sumber daya sekaligus.

Operasi LIST dapat mengambil data dalam jumlah besar, terutama dalam kluster besar dengan beberapa sumber daya. Perhatikan fakta bahwa melakukan panggilan LIST yang tidak terbatas atau sering menempatkan beban yang signifikan di server API dan dapat menutup waktu respons.

Operasi WATCH melakukan pemantauan sumber daya real time. Saat Anda menyiapkan WATCH pada sumber daya, server API mengirimkan pembaruan kepada Anda setiap kali ada perubahan pada sumber daya tersebut. Ini penting untuk pengontrol, seperti pengontrol ReplicaSet, yang mengandalkan WATCH untuk mempertahankan status sumber daya yang diinginkan.

Perhatikan fakta bahwa menonton terlalu banyak sumber daya yang dapat diubah atau membuat terlalu banyak permintaan WATCH bersamaan dapat membanjiri server API dan menyebabkan konsumsi sumber daya yang berlebihan.

Untuk menghindari potensi masalah dan memastikan stabilitas sarana kontrol Kube, Anda dapat menggunakan strategi berikut:

Kuota sumber daya

Terapkan kuota sumber daya untuk membatasi jumlah sumber daya yang dapat dicantumkan atau ditonton oleh pengguna atau namespace tertentu untuk mencegah panggilan yang berlebihan.

Prioritas dan Kewajaran API

Kubernetes memperkenalkan konsep API Priority and Fairness (APF) untuk memprioritaskan dan mengelola permintaan API. Anda dapat menggunakan APF di Kubernetes untuk melindungi server API kluster dan mengurangi jumlah HTTP 429 Too Many Requests respons yang dilihat oleh aplikasi klien.

Sumber daya kustom Fitur utama
PriorityLevelConfigurations • Tentukan tingkat prioritas yang berbeda untuk permintaan API.
• Menentukan nama unik dan menetapkan nilai bilangan bulat yang mewakili tingkat prioritas. Tingkat prioritas yang lebih tinggi memiliki nilai bilangan bulat yang lebih rendah, menunjukkan tingkat tersebut lebih penting.
• Dapat menggunakan beberapa untuk mengategorikan permintaan ke dalam tingkat prioritas yang berbeda berdasarkan kepentingannya.
• Memungkinkan Anda menentukan apakah permintaan pada tingkat prioritas tertentu harus tunduk pada batas tarif.
FlowSchemas • Tentukan bagaimana permintaan API harus dirutekan ke tingkat prioritas yang berbeda berdasarkan atribut permintaan.
• Tentukan aturan yang cocok dengan permintaan berdasarkan kriteria seperti grup API, versi, dan sumber daya.
• Ketika permintaan cocok dengan aturan tertentu, permintaan diarahkan ke tingkat prioritas yang ditentukan dalam PriorityLevelConfiguration terkait.
• Dapat digunakan untuk mengatur urutan evaluasi ketika beberapa FlowSchemas cocok dengan permintaan untuk memastikan bahwa aturan tertentu diutamakan.

Mengonfigurasi API dengan PriorityLevelConfigurations dan FlowSchemas memungkinkan prioritas permintaan API penting atas permintaan yang kurang penting. Ini memastikan bahwa operasi penting tidak kelaparan atau mengalami penundaan karena permintaan prioritas yang lebih rendah.

Mengoptimalkan pelabelan dan pemilih

Saat menggunakan operasi LIST, optimalkan pemilih label untuk mempersempit cakupan sumber daya yang ingin Anda kueri untuk mengurangi jumlah data yang dikembalikan dan beban di server API.

Dalam operasi CREATE dan UPDATE Kubernetes, lihat tindakan yang mengelola dan memodifikasi sumber daya kluster.

Operasi CREATE dan UPDATE

Operasi CREATE membuat sumber daya baru di kluster Kubernetes, seperti pod, layanan, penyebaran, peta konfigurasi, dan rahasia. Selama operasi CREATE, klien, seperti kubectl atau pengontrol, mengirim permintaan ke server API Kubernetes untuk membuat sumber daya baru. Server API memvalidasi permintaan, memastikan kepatuhan terhadap kebijakan pengontrol penerimaan apa pun, lalu membuat sumber daya dalam status kluster yang diinginkan.

Operasi UPDATE memodifikasi sumber daya yang ada di kluster Kubernetes, termasuk perubahan pada spesifikasi sumber daya, seperti jumlah replika, gambar kontainer, variabel lingkungan, atau label. Selama operasi UPDATE, klien mengirim permintaan ke server API untuk memperbarui sumber daya yang ada. Server API memvalidasi permintaan, menerapkan perubahan pada definisi sumber daya, dan memperbarui sumber daya kluster.

Operasi CREATE dan UPDATE dapat memengaruhi performa server API Kubernetes dalam kondisi berikut:

  • Konkurensi tinggi: Ketika beberapa pengguna atau aplikasi membuat permintaan CREATE atau UPDATE bersamaan, itu dapat menyebabkan lonjakan permintaan API yang tiba di server secara bersamaan. Ini dapat menekankan kapasitas pemrosesan server API dan menyebabkan masalah performa.
  • Definisi sumber daya kompleks: Definisi sumber daya yang terlalu kompleks atau melibatkan beberapa objek berlapis dapat meningkatkan waktu yang diperlukan server API untuk memvalidasi dan memproses permintaan CREATE dan UPDATE, yang dapat menyebabkan penurunan performa.
  • Validasi sumber daya dan kontrol penerimaan: Kubernetes memberlakukan berbagai kebijakan kontrol penerimaan dan pemeriksaan validasi pada permintaan CREATE dan UPDATE yang masuk. Definisi sumber daya besar, seperti yang memiliki anotasi atau konfigurasi yang luas, mungkin memerlukan lebih banyak waktu pemrosesan.
  • Pengontrol kustom: Pengontrol kustom yang mengawasi perubahan sumber daya, seperti Penyebaran atau pengontrol StatefulSet, dapat menghasilkan sejumlah besar pembaruan saat menskalakan atau meluncurkan perubahan. Pembaruan ini dapat membatasi sumber daya server API.

Untuk informasi selengkapnya, lihat Memecahkan masalah server API dan dll di AKS.

Performa sarana data

Bidang data Kubernetes bertanggung jawab untuk mengelola lalu lintas jaringan antara kontainer dan layanan. Masalah dengan bidang data dapat menyebabkan waktu respons yang lambat, performa terdegradasi, dan waktu henti aplikasi. Penting untuk memantau dan mengoptimalkan konfigurasi sarana data dengan cermat, seperti latensi jaringan, alokasi sumber daya, kepadatan kontainer, dan kebijakan jaringan, untuk memastikan aplikasi kontainer Anda berjalan dengan lancar dan efisien.

Tipe penyimpanan

AKS merekomendasikan dan default untuk menggunakan disk OS ephemeral. Disk OS Ephemeral dibuat pada penyimpanan VM lokal dan tidak disimpan ke penyimpanan Azure jarak jauh seperti disk OS terkelola. Mereka memiliki waktu pencitraan ulang dan boot yang lebih cepat, memungkinkan operasi kluster yang lebih cepat, dan memberikan latensi baca/tulis yang lebih rendah pada disk OS simpul agen AKS. Disk OS sementara bekerja dengan baik untuk beban kerja tanpa status, di mana aplikasi toleran terhadap kegagalan VM individual tetapi bukan waktu penyebaran VM atau instans penilai ulang VM individual. Hanya SKU VM tertentu yang mendukung disk OS ephemeral, jadi Anda perlu memastikan bahwa pembuatan dan ukuran SKU yang Anda inginkan kompatibel. Untuk informasi selengkapnya, lihat Disk OS Ephemeral di Azure Kubernetes Service (AKS).

Jika beban kerja Anda tidak dapat menggunakan disk OS sementara, AKS default menggunakan disk OS SSD Premium. Jika disk OS SSD Premium tidak kompatibel dengan beban kerja Anda, AKS default ke disk SSD Standar. Saat ini, satu-satunya jenis disk OS lain yang tersedia adalah HDD Standar. Untuk informasi selengkapnya, lihat Opsi penyimpanan di Azure Kubernetes Service (AKS).

Tabel berikut ini menyediakan perincian kasus penggunaan yang disarankan untuk disk OS yang didukung di AKS:

Jenis disk OS Fitur utama Kasus penggunaan yang disarankan
Disk OS sementara • Waktu penilaian ulang dan boot yang lebih cepat.
• Latensi baca/tulis yang lebih rendah pada disk OS simpul agen AKS.
• Performa dan ketersediaan tinggi.		 • Menuntut beban kerja perusahaan, seperti SQL Server, Oracle, Dynamics, Server Exchange, MySQL, Cassandra, MongoDB, SAP Business Suite, dll.
• Beban kerja produksi stateless yang membutuhkan ketersediaan tinggi dan latensi rendah.
Disk OS SSD premium • Performa yang konsisten dan latensi rendah.
• Ketersediaan tinggi.		 • Menuntut beban kerja perusahaan, seperti SQL Server, Oracle, Dynamics, Server Exchange, MySQL, Cassandra, MongoDB, SAP Business Suite, dll.
• Beban kerja perusahaan intensif input/output (IO).
Disk OS SSD standar • Performa yang konsisten.
• Ketersediaan dan latensi yang lebih baik dibandingkan dengan disk HDD Standar.		 • Server web.
• Operasi input/output rendah per detik (IOPS) server aplikasi.
• Aplikasi perusahaan yang digunakan secara ringan.
• Beban kerja dev/test.
Disk HDD standar • Biaya rendah.
• Menunjukkan varianbilitas dalam performa dan latensi.		 • Penyimpanan cadangan.
• Penyimpanan massal dengan akses yang jarang.

IOPS dan throughput

Operasi input/output per detik (IOPS) mengacu pada jumlah operasi baca dan tulis yang dapat dilakukan disk dalam hitungan detik. Throughput mengacu pada jumlah data yang dapat ditransfer dalam periode waktu tertentu.

Disk OS bertanggung jawab untuk menyimpan sistem operasi dan file terkaitnya, dan VM bertanggung jawab untuk menjalankan aplikasi. Saat memilih VM, pastikan ukuran dan performa disk OS dan SKU VM tidak memiliki perbedaan besar. Perbedaan ukuran atau performa dapat menyebabkan masalah performa dan ketidakcocokan sumber daya. Misalnya, jika disk OS secara signifikan lebih kecil dari VM, disk tersebut dapat membatasi jumlah ruang yang tersedia untuk data aplikasi dan menyebabkan sistem kehabisan ruang disk. Jika disk OS memiliki performa yang lebih rendah daripada VM, disk tersebut dapat menjadi hambatan dan membatasi performa keseluruhan sistem. Pastikan ukuran dan performa seimbang untuk memastikan performa optimal di Kubernetes.

Anda dapat menggunakan langkah-langkah berikut untuk memantau pengukur IOPS dan bandwidth pada disk OS di portal Azure:

  1. Arahkan ke portal Microsoft Azure.
  2. Cari Set skala komputer virtual dan pilih set skala komputer virtual Anda.
  3. Di bawahPemantauan, pilih Metrik.

Disk OS sementara dapat menyediakan IOPS dan throughput dinamis untuk aplikasi Anda, sedangkan disk terkelola telah membatasi IOPS dan throughput. Untuk informasi selengkapnya, lihat Disk OS Ephemeral untuk Azure VM.

Azure Premium SSD v2 dirancang untuk beban kerja perusahaan intens IO yang memerlukan latensi disk sub-milidetik dan IOPS dan throughput tinggi dengan biaya rendah. Ini cocok untuk berbagai beban kerja, seperti server SQL, Oracle, MariaDB, SAP, Cassandra, MongoDB, big data/analitik, game, dan banyak lagi. Jenis disk ini adalah opsi berkinerja tertinggi yang saat ini tersedia untuk volume persisten.

Penjadwalan pod

Memori dan sumber daya CPU yang dialokasikan untuk VM berdampak langsung pada performa pod yang berjalan pada VM. Ketika pod dibuat, pod diberi sejumlah memori dan sumber daya CPU, yang digunakan untuk menjalankan aplikasi. Jika VM tidak memiliki cukup memori atau sumber daya CPU yang tersedia, itu dapat menyebabkan pod melambat atau bahkan crash. Jika VM memiliki terlalu banyak memori atau sumber daya CPU yang tersedia, itu dapat menyebabkan pod berjalan secara tidak efisien, membuang-buang sumber daya dan meningkatkan biaya. Sebaiknya pantau total permintaan pod di seluruh beban kerja Anda terhadap total sumber daya yang dapat dialokasi untuk prediktabilitas dan performa penjadwalan terbaik. Anda juga dapat mengatur pod maksimum per simpul berdasarkan perencanaan kapasitas Anda menggunakan --max-pods.