Diagnosis masalah memori kontainer dengan SysOM-Container Service for Kubernetes-Alibaba Cloud

Alibaba Cloud Container Service for Kubernetes (ACK) menyediakan SysOM, sebuah alat yang meningkatkan visibilitas terhadap masalah memori kontainer dengan menyediakan data pemantauan tingkat kernel. Fitur ini memberikan transparansi lebih besar dalam mendiagnosis masalah di lapisan container engine, sehingga menyederhanakan proses migrasi kontainer Anda. Artikel ini menjelaskan cara menggunakan SysOM untuk mendiagnosis masalah memori kontainer.

Prasyarat

Anda telah membuat ACK Managed Cluster atau ACK Serverless Cluster yang dibuat setelah Oktober 2021. Versi kluster harus 1.18.8 atau lebih baru. Untuk melakukan upgrade kluster, lihat Manually upgrade a cluster.
Anda telah mengaktifkan Prometheus Service for Alibaba Cloud.
Fitur ack-sysom-monitor harus diaktifkan. Untuk informasi selengkapnya, lihat Enable the ack-sysom-monitor feature.

Billing

Setelah Anda mengaktifkan fitur ack-sysom-monitor, komponen tersebut secara otomatis mengirim metrik pemantauan ke Prometheus Service for Alibaba Cloud. Metrik ini ditagih sebagai Custom Metrics dan dikenakan biaya tambahan.

Untuk menghindari tagihan tak terduga, tinjau Billing Overview for Prometheus Service for Alibaba Cloud guna memahami harga Custom Metrics sebelum mengaktifkan fitur ini. Biaya dapat bervariasi tergantung pada faktor seperti ukuran kluster dan jumlah aplikasi. Anda dapat memantau serta mengelola penggunaan resource melalui fitur Resource Consumption.

Latar Belakang

Kontainerisasi telah menjadi praktik terbaik dalam arsitektur TI perusahaan karena kemampuannya mengurangi biaya serta meningkatkan efisiensi, fleksibilitas, dan skalabilitas.

Namun, kontainerisasi juga menimbulkan opasitas di lapisan container engine, yang dapat menyebabkan penggunaan memori melebihi batas dan memicu masalah Out of Memory (OOM).

Tim Container Service for Kubernetes (ACK) Alibaba Cloud, bekerja sama dengan tim Alibaba Cloud GuestOS, memanfaatkan kemampuan pemantauan kontainer di tingkat kernel sistem operasi untuk mengontrol penggunaan memori secara tepat dan mencegah masalah OOM.

Komponen memori kontainer

Memori sebuah kontainer terdiri dari memori aplikasi, memori kernel, dan memori bebas.

Kategori memori	Subkategori memori	Deskripsi
Application memory	Application memory terdiri dari komponen-komponen berikut: Anonymous memory: Memori yang tidak terkait dengan file, seperti heap, stack, dan segmen data suatu proses. Memori heap dialokasikan menggunakan panggilan sistem `brk` dan `mmap`. File cache: Memori yang digunakan untuk menyimpan cache data operasi baca dan tulis file. Cache yang sering digunakan disebut ActiveFileCache dan tidak mudah diklaim kembali oleh sistem. Buffers: Memori yang digunakan untuk menyimpan metadata perangkat blok atau sistem file. HugeTLB: Memori yang dialokasikan menggunakan teknologi HugePages.	Memori yang digunakan oleh aplikasi yang sedang berjalan.
Kernel memory	Kernel memory terdiri dari komponen-komponen berikut: Slab: Pool memori untuk mengelola cache objek kernel. Vmalloc: Mekanisme untuk mengalokasikan blok besar ruang memori virtual. allocpage: Mekanisme untuk mengalokasikan memori lokal. Lainnya: Termasuk komponen seperti kernel stack, page table, dan memori yang dicadangkan.	Memori yang digunakan oleh kernel sistem operasi.
Free memory	N/A	Memori yang tidak terpakai dan tersedia.

Cara kerja

Kubernetes menggunakan working set untuk memantau dan mengelola penggunaan memori kontainer. Ketika konsumsi memori kontainer melebihi batas yang dikonfigurasi atau node mengalami tekanan memori, Kubernetes menggunakan working set untuk menentukan apakah akan mengeluarkan (evict) atau menghentikan tugas (terminate) kontainer tersebut. Pemantauan working set Pod dengan SysOM memberikan analisis memori yang lebih komprehensif dan akurat, membantu tim mengidentifikasi serta menyelesaikan masalah terkait penggunaan working set yang tinggi secara cepat sehingga meningkatkan performa dan stabilitas kontainer.

Working set mengacu pada bagian memori yang aktif digunakan oleh kontainer dalam jangka waktu tertentu, yaitu memori yang diperlukan untuk operasi saat ini. Working set dihitung menggunakan rumus berikut: working set = inactive_anon + active_anon + active_file. Dalam rumus ini, inactive_anon dan active_anon merepresentasikan ukuran total memori anonim aplikasi, sedangkan active_file merepresentasikan ukuran cache file aktif aplikasi. Tingkat analisis ini membantu tim operasi mengelola sumber daya secara lebih efektif dan memastikan stabilitas aplikasi.

Gunakan fitur SysOM

SysOM menyediakan dasbor pemantauan tingkat kernel OS untuk Pod dan node, memungkinkan Anda memantau metrik tingkat sistem untuk memori, jaringan, dan penyimpanan secara real time. Untuk informasi selengkapnya tentang metrik yang tersedia di SysOM, lihat SysOM kernel-level container monitoring.

Masuk ke ACK console. Di panel navigasi kiri, klik Clusters.
Di halaman Clusters, klik nama kluster Anda. Di panel navigasi kiri, klik Operations > Prometheus Monitoring.
Di halaman Prometheus Monitoring, klik tab SysOM, lalu klik tab SysOM - Pods untuk melihat data memori Pod di dasbor.

Gunakan rumus berikut untuk membantu mendiagnosis masalah memory black hole.

Total memori Pod = resident set size (RSS) + Cache ≈ inactive_anon + active_anon + inactive_file + active_file

working set = inactive_anon + active_anon + active_file
1. Di bagian Pod Memory Monitor, Anda dapat menggunakan rumus total memori Pod untuk memecah memori Pod menjadi cache dan RSS. Kemudian, Anda dapat melihat komposisi proporsional cache, yang terdiri dari active_file, inactive_file, dan shmem (shared memory), serta RSS, yang terdiri dari active_anon dan inactive_anon.
  
  Seperti yang ditunjukkan pada gambar berikut, memori inactive_anon memiliki proporsi terbesar.
2. Di bagian Pod Resource Analysis, gunakan tool top untuk dengan cepat menemukan Pod yang paling banyak mengonsumsi memori InactiveAnon di kluster.
  
  Seperti yang ditunjukkan pada gambar berikut, Pod arms-prom memiliki konsumsi memori tertinggi.
3. Di bagian Pod Memory Details, lihat komposisi memori detail Pod tersebut. Dasbor menampilkan berbagai komponen memori, seperti Pod Cache, InactiveFile (penggunaan cache file tidak aktif), InactiveAnon (penggunaan memori anonim tidak aktif), dan dirty memory (penggunaan memori dirty sistem). Hal ini memungkinkan Anda mengidentifikasi masalah umum memory black hole pada Pod.
Di bagian Pod File Cache, identifikasi penyebab tingginya penggunaan memori cache.

Jika cache memori Pod besar, penggunaan working set-nya juga dapat meningkat. Memori cache ini dapat menjadi memory black hole dalam working set Pod, yang berdampak negatif terhadap performa aplikasi.
Perbaiki masalah memory black hole.

Setelah Anda mengidentifikasi masalah memory black hole kontainer, Anda dapat menyelesaikannya dengan menggunakan fitur penjadwalan detail halus (fine-grained scheduling) dari ACK. Untuk informasi selengkapnya, lihat Enable container memory QoS.

Dokumen terkait

Untuk informasi selengkapnya tentang metrik yang tersedia di SysOM, lihat SysOM kernel-level container monitoring.
Untuk informasi selengkapnya tentang kemampuan kernel yang diaktifkan oleh container memory QoS ACK, lihat Overview of kernel features and interfaces.