Container Service for Kubernetes:Kebijakan estimasi biaya Pod

Suite manajemen biaya ACK menyediakan dua kebijakan estimasi biaya berdasarkan watermark resource (rasio pemanfaatan resource). Masing-masing menghitung bagian biaya kluster untuk pod dan namespace individual.

Pilih kebijakan estimasi biaya

Single resource cost estimation

Kebijakan default dalam suite manajemen biaya. Menghitung biaya pod berdasarkan satu dimensi resource: CPU atau memory.

Skenario yang berlaku

Watermark resource adalah rasio antara resource yang diminta terhadap resource yang dapat dialokasikan. Ketika satu watermark jauh lebih tinggi daripada yang lain, resource tersebut menjadi penentu penjadwalan dan mendominasi biaya kluster.

Contoh: Aplikasi yang bersifat memory-intensive seperti workload Java meminta jumlah memory yang besar. Jika watermark memory mencapai 90%, ketersediaan memory menentukan penjadwalan pod, dan biaya memory menyumbang 90% dari total biaya kluster. Kebijakan single resource menangkap hal ini secara akurat.

Perhitungan biaya pod

Rumus biaya CPU atau memory pod:

Perhitungan biaya namespace

Namespace mengelompokkan pod yang terkait. Biayanya sama dengan jumlah rasio biaya pod dalam namespace tersebut, dikalikan dengan total tagihan kluster.

Rumus biaya namespace:

Rumus rasio biaya namespace:

Weighted resource cost estimation

Menghitung biaya pod menggunakan CPU dan memory, dengan bobot berdasarkan rasio pemanfaatan tingkat kluster, untuk alokasi seimbang ketika workload mengonsumsi kedua jenis resource tersebut.

Skenario penerapan

Gunakan kebijakan ini ketika:

• Watermark CPU dan memory kluster saling berdekatan.

• Aplikasi mengonsumsi CPU dan memory.

Ketika biaya CPU dan memory mirip, watermark-nya memberikan dasar yang bermakna untuk alokasi berbobot.

Perhitungan biaya pod

Kebijakan ini menghitung biaya pod dari bobot CPU dan memory yang diturunkan dari watermark tingkat kluster.

Rumus biaya pod:

Rumus watermark dan bobot

Rumus watermark CPU, watermark memory, bobot CPU, dan bobot memory:

• Watermark CPU (rasio pemanfaatan CPU):

  

• Watermark memory (rasio pemanfaatan memory):

  

• Bobot CPU:

  

• Bobot memori:

  

Perbandingan hasil kebijakan

Contoh 1: Satu jenis resource mendominasi

Setup: Dua aplikasi memory-intensive dijalankan dalam satu kluster.

• Watermark memory: 90%

• Watermark CPU: 20%

• Biaya kluster harian: USD 200

Hasil estimasi biaya single resource:

Alokasi berdasarkan memory menangkap 90% biaya kluster. Alokasi berdasarkan CPU menyisakan 80% yang tidak dialokasikan, meskipun hanya tersisa 10% memory untuk penjadwalan.

Hasil estimasi biaya sumber daya tertimbang:

• Bobot memory: sekitar 80%

• Bobot CPU: sekitar 20%

• Biaya pod: USD 152 (USD 180 x 80% + USD 40 x 20%)

• Biaya tidak dialokasikan: USD 48

Hasil: Kebijakan single resource (menggunakan memory) mengalokasikan USD 180 dari USD 200, yang sangat sesuai dengan konsumsi aktual. Kebijakan weighted hanya mengalokasikan USD 152, menyisakan USD 48 yang tidak dialokasikan. Untuk kluster di mana satu resource mendominasi, kebijakan single resource lebih akurat.

Contoh 2: Kedua jenis resource dikonsumsi

Setup: Satu aplikasi memory-intensive dan satu aplikasi CPU-intensive dijalankan dalam satu kluster.

• CPU Watermark: 40%

• Watermark memory: 50%

• Biaya kluster harian: USD 200

Hasil estimasi biaya sumber daya tunggal:

Hasil estimasi biaya weighted resource:

• Bobot memory: sekitar 56%

• Bobot CPU: sekitar 44%

• Biaya pod: USD 91,2 (USD 100 x 56% + USD 80 x 44%)

• Biaya tidak dialokasikan: USD 8,8

Hasil: Watermark CPU dan memory saling berdekatan (40% dan 50%), sehingga biayanya mirip. Kebijakan weighted mempertimbangkan kedua dimensi tersebut, menghasilkan biaya tidak dialokasikan sebesar USD 8,8 dibandingkan dengan USD 100 atau USD 120 yang tidak dialokasikan pada alokasi single resource. Untuk workload campuran, kebijakan weighted menghasilkan alokasi yang lebih seimbang.

Kurangi biaya tak teralokasi dengan kebijakan berbobot

Penyebab: Biaya tidak dialokasikan terjadi ketika satu watermark resource jauh lebih tinggi daripada yang lain—resource dominan mencapai bottleneck sementara resource lain tetap idle. Misalnya, jika watermark CPU jauh melebihi watermark memory, memory idle akan tersedia. Kebijakan single resource dapat mengalokasikan biaya ini, tetapi kebijakan weighted tidak dapat.

Solusi: Pilih tipe instans Elastic Compute Service (ECS) yang sesuai dengan profil resource workload Anda agar watermark CPU dan memory tetap berdekatan. Atau, beralihlah ke kebijakan single resource.

Cost data API

• Ambil data cost insights melalui API untuk pengembangan kustom. Lihat Call an API to query cost data.