Untuk mengatasi keterbatasan visibilitas di lapisan container engine, SysOM menyediakan pemantauan kontainer tingkat kernel OS yang meningkatkan observabilitas terhadap masalah memori dan mendukung migrasi kontainer. Topik ini menjelaskan cara menggunakan SysOM untuk mendiagnosis masalah memori kontainer, termasuk rincian working set yang lebih detail dibandingkan metrik standar.
Prasyarat
Pastikan Anda telah:
-
Membuat ACK Managed Cluster atau ACK Serverless Cluster setelah Oktober 2021 yang menjalankan Kubernetes 1.18.8 atau versi lebih baru. Lakukan upgrade manual jika diperlukan.
-
Mengaktifkan Prometheus Service for Alibaba Cloud.
-
Mengaktifkan fitur ack-sysom-monitor.
Penagihan
Saat diaktifkan, ack-sysom-monitor mengirimkan metrik pemantauan ke Prometheus Service for Alibaba Cloud. Metrik ini ditagih sebagai Custom Metrics dan menimbulkan biaya tambahan.
Tinjau ikhtisar penagihan untuk Prometheus Service for Alibaba Cloud sebelum mengaktifkan fitur ini. Biaya bergantung pada ukuran kluster dan jumlah aplikasi. Gunakan Resource Consumption untuk memantau penggunaan.
Konsep utama
Komponen memori kontainer
ACK menyediakan pemantauan kontainer tingkat kernel OS untuk melacak penggunaan memori secara akurat dan mencegah masalah OOM.
Memori kontainer terdiri dari tiga kategori:
| Category | Subcategory | Description |
|---|---|---|
| Application memory | Anonymous memory: heap, stack, dan segmen data suatu proses, dialokasikan melalui panggilan sistem brk dan mmap |
Memori yang digunakan oleh aplikasi yang sedang berjalan |
File cache: data yang di-cache untuk I/O file. Cache yang sering diakses (ActiveFileCache) tidak mudah direklaim. |
||
| Buffers: metadata untuk perangkat blok atau sistem file | ||
| HugeTLB: memori yang dialokasikan melalui HugePages | ||
| Kernel memory | Slab: pool memori untuk cache objek kernel | Memori yang digunakan oleh kernel OS |
| Vmalloc: mengalokasikan blok memori virtual besar | ||
| allocpage: mengalokasikan memori lokal | ||
| Others: kernel stack, page table, dan memori yang dicadangkan | ||
| Free memory | — | Memori yang tidak terpakai dan tersedia |
Working set vs. RSS
Kubernetes melacak dua metrik memori utama:
-
Working set — memori yang aktif digunakan oleh kontainer:
working set = inactive_anon + active_anon + active_file. OOM killer dan Kubernetes menggunakan nilai ini untuk menentukan apakah kontainer harus dievakuasi atau dihentikan. -
RSS (resident set size) — memori fisik yang dipetakan ke ruang alamat kontainer, tidak termasuk file cache. RSS mencerminkan memori aplikasi aktual tetapi tidak mencakup memori cache yang dihitung Kubernetes terhadap batas memori.
Karena Kubernetes menggunakan working set untuk keputusan evakuasi, file cache dapat diam-diam meningkatkan nilai tersebut dan memicu OOM kill meskipun memori aplikasi stabil. SysOM memecah working set menjadi komponen-komponennya untuk mengidentifikasi jenis memori yang menyebabkan masalah.
Cara kerja
SysOM menampilkan metrik tingkat kernel OS pada dasbor Pemantauan Prometheus di Konsol ACK, mengelompokkan memori Pod ke dalam komponen working set untuk melacak penggunaan tinggi ke jenis memori tertentu.
Gunakan rumus berikut saat mendiagnosis masalah memori:
-
Total pod memory = RSS + Cache ≈ inactive_anon + active_anon + inactive_file + active_file -
working set = inactive_anon + active_anon + active_file
Temukan dan perbaiki masalah memori kontainer
Langkah 1: Buka dasbor SysOM
-
Masuk ke ACK console. Di panel navigasi kiri, klik Clusters.
-
Pada halaman Clusters, klik nama kluster Anda. Di panel navigasi kiri, klik Operations > Prometheus Monitoring.
-
Pada halaman Prometheus Monitoring, klik tab SysOM, lalu klik SysOM - Pods.
Langkah 2: Identifikasi memory black hole
-
Di bagian Pod Memory Monitor, terapkan rumus total memori Pod untuk memecah memori menjadi cache dan RSS. Tinjau proporsi cache (
active_file,inactive_file,shmem) dan RSS (active_anon,inactive_anon). Pada contoh ini,inactive_anonmendominasi.
-
Di bagian Pod Resource Analysis, gunakan top untuk mengidentifikasi Pod dengan konsumsi InactiveAnon tertinggi. Pada contoh ini, arms-prom memiliki konsumsi tertinggi.
-
Di bagian Pod Memory Details, lihat komposisi memori Pod yang telah diidentifikasi. Komponen-komponennya mencakup Pod Cache, InactiveFile (cache file tidak aktif), InactiveAnon (memori anonim tidak aktif), dan dirty memory (modifikasi yang belum ditulis). Gunakan rincian ini untuk mengidentifikasi memory black hole.
Langkah 3: Selidiki penggunaan file cache
Di bagian Pod File Cache, identifikasi penyebab tingginya memori cache.
File cache yang tidak dapat direklaim meningkatkan working set, menjadi memory black hole yang dihitung terhadap batas memori Pod dan dapat memicu evakuasi atau OOM kill tanpa peningkatan memori aplikasi.
Langkah 4: Perbaiki memory black hole
Setelah mengidentifikasi memory black hole, atasi masalah tersebut dengan penjadwalan detail halus ACK. Lihat Enable container memory QoS.
Langkah selanjutnya
-
Untuk semua metrik SysOM, lihat SysOM kernel-level container monitoring.
-
Untuk kemampuan kernel di balik ACK memory QoS, lihat Overview of kernel features and interfaces.