Kubernetes Terkelola

Topik ini membahas posisi layanan Kubernetes terkelola (managed) sebagai langkah dari lab lokal menuju lingkungan produksi. Lingkupnya mencakup pembagian tanggung jawab antara vendor dan pengguna kluster, posisi generik EKS, GKE, dan AKS, serta kategori biaya yang muncul pada kluster di cloud. Pada bagian akhir, perbandingan biaya bulanan tiga konfigurasi disimulasikan dengan Python sehingga setiap angkanya dapat dihitung ulang.

Yang dikelola vendor dan yang tetap dipegang#

Layanan terkelola mengurus seluruh control plane, yaitu API server, etcd, scheduler, dan controller manager. Vendor menjamin ketersediaan komponen tersebut, menerapkan patch keamanan, dan menangani cadangan data etcd. Komponen control plane tidak pernah muncul sebagai Node yang dapat diakses pengguna, sehingga beban operasional berat pada lapisan itu berpindah sepenuhnya ke vendor. Model inilah yang dikenal sebagai opsi managed, berbeda dengan kluster self-hosted yang seluruh control plane-nya dirakit sendiri.

Yang tetap dipegang pengguna adalah data plane, yaitu sekumpulan Node pekerja beserta seluruh beban yang berjalan di atasnya. Ukuran dan jumlah Node pool, penempatan Pod, manifest aplikasi, kebijakan RBAC, dan peningkatan versi aplikasi tetap ditentukan dari sisi pengguna. Vendor hanya menyiapkan Node pekerja sampai kubelet siap bergabung dengan kluster, sedangkan cara Node tersebut terisi Pod adalah hasil keputusan manifest yang dibangun sepanjang jalur ini. Kontrol atas beban kerja tidak berpindah, yang berpindah hanyalah pekerjaan penjagaan control plane.

Peningkatan versi kluster menjadi kerja sama antara vendor dan pengguna. Vendor meningkatkan control plane terlebih dahulu pada jadwalnya, kemudian Node pool ditingkatkan mengikuti versi tersebut melalui penggantian Node secara bertahap. Aplikasi tetap perlu diuji terhadap versi baru, sehingga tanggung jawab kompatibilitas beban kerja tidak pernah ikut dikelola vendor.

Posisi EKS, GKE, dan AKS#

Ketiga layanan berikut menawarkan model yang sama, yaitu API Kubernetes standar yang dijalankan pada control plane milik vendor. Karena API-nya standar, kubectl dan manifest yang digunakan di sepanjang jalur ini berfungsi sama seperti pada lab lokal. Perbedaan antarlayanan terletak pada integrasi dengan jaringan, identitas, penyimpanan, dan perkakas Node pool milik masing-masing cloud.

Tabel di atas sengaja tidak menyebut harga maupun versi. Harga berubah seiring waktu dan berbeda antarwilayah, sedangkan versi Kubernetes yang ditawarkan bergerak mengikuti rilis hulu, sehingga keduanya paling tepat diperiksa langsung pada halaman resmi vendor. Yang stabil untuk dibandingkan adalah posisi generiknya. Ketiganya sama-sama menjalankan control plane terkelola di atas infrastruktur cloud yang berbeda.

Kategori biaya yang perlu diwaspadai#

Komponen biaya pertama adalah jam Node. Node pekerja ditagih selama menyala, termasuk ketika Pod di atasnya sedang diam, sehingga kluster belajar yang ditinggalkan menyala menimbulkan biaya sepanjang waktu. Penskalaan otomatis menurunkan jumlah Node saat beban menurun, tetapi tidak menurunkannya hingga nol karena ada beban sistem yang tetap berjalan.

Komponen kedua adalah penyimpanan. PersistentVolume ditagih per GB per bulan apakah datanya digunakan atau tidak, dan jenis StorageClass yang dipilih mengubah tarifnya. PersistentVolumeClaim yang ditinggalkan setelah eksperimen selesai adalah sumber biaya yang mudah terlewat karena tidak terlihat pada daftar Pod.

Komponen ketiga adalah jalur keluar jaringan. Service tipe LoadBalancer membuat load balancer di cloud yang ditagih per jam, sedangkan gateway NAT dan pengiriman data keluar dari cloud ditagih menurut volume trafiknya. Karena itu, estimasi yang hanya menjumlahkan harga Node per jam hampir selalu lebih rendah daripada tagihan akhirnya.

Simulasi perbandingan biaya bulanan#

Perbandingan biaya antara konfigurasi dapat disimulasikan dengan rumus sederhana. Rumus latihan pada skrip berikut menetapkan biaya Node sebagai jumlah Node dikalikan dengan harga Node per jam dikalikan dengan 730 jam per bulan, ditambah biaya storage dari kapasitas GB dikalikan dengan tarif per GB. Seluruh harga pada skrip adalah angka latihan yang ditetapkan sendiri untuk keperluan perhitungan, bukan harga resmi vendor, sehingga angka lain dapat dimasukkan tanpa mengubah logikanya.

# Simulasi biaya bulanan tiga konfigurasi kluster terkelola.
# SELURUH harga pada skrip ini adalah angka latihan, bukan harga resmi vendor.
# Rumus latihan: biaya node = jumlah node x harga node per jam x 730 jam,
# dan biaya storage = kapasitas GB x harga storage per GB per bulan.

KONFIGURASI = [
    {"nama": "lab satu node", "node": 1, "harga_node_jam": 0.05, "storage_gb": 8},
    {"nama": "staging dua node", "node": 2, "harga_node_jam": 0.05, "storage_gb": 32},
    {"nama": "produksi tiga node", "node": 3, "harga_node_jam": 0.10, "storage_gb": 128},
]

JAM_PER_BULAN = 730
HARGA_STORAGE_BULAN = 0.10  # angka latihan, USD per GB per bulan


def biaya_bulanan(jumlah_node, harga_node_jam, storage_gb):
    biaya_node = jumlah_node * harga_node_jam * JAM_PER_BULAN
    biaya_storage = storage_gb * HARGA_STORAGE_BULAN
    return biaya_node, biaya_storage, biaya_node + biaya_storage


print("angka latihan, bukan harga resmi vendor")
print(f"{'konfigurasi':20} {'node':>4} {'biaya node':>11} {'biaya storage':>14} {'total':>9}")
for k in KONFIGURASI:
    node, storage, total = biaya_bulanan(k["node"], k["harga_node_jam"], k["storage_gb"])
    print(f"{k['nama']:20} {k['node']:>4} {node:>11.2f} {storage:>14.2f} {total:>9.2f}")

angka latihan, bukan harga resmi vendor
konfigurasi          node  biaya node  biaya storage     total
lab satu node           1       36.50           0.80     37.30
staging dua node        2       73.00           3.20     76.20
produksi tiga node      3      219.00          12.80    231.80

Pada angka latihan di atas, biaya Node mendominasi total karena dihitung per jam sepanjang bulan, sedangkan biaya storage pada skala kecil masih kecil namun tumbuh mengikuti kapasitas. Konfigurasi produksi dengan Node yang lebih besar dan lebih banyak berada sekitar enam kali lipat di atas konfigurasi lab, sehingga jumlah dan kelas Node adalah faktor biaya yang paling besar. Control plane biasanya ditagih terpisah oleh vendor dan tidak ikut dalam rumus ini, demikian pula load balancer dan egress, sehingga perbandingan nyata perlu menambahkan ketiganya.

Kesalahan umum#

Kesalahan pada tahap ini biasanya berupa asumsi yang tidak dihitung, bukan kesalahan teknis kluster. Tiga kesalahan berikut paling sering muncul ketika kluster pertama kali dibawa ke layanan terkelola.

• Menganggap harga Node per jam sebagai total tagihan. Biaya storage, load balancer, gateway NAT, dan egress berada di luar angka tersebut, sehingga estimasi yang hanya memperhitungkan Node menyesatkan. Perbaikannya adalah menghitung setiap kategori biaya secara terpisah, lalu memeriksanya pada kalkulator resmi vendor.
• Membiarkan kluster belajar menyala di luar jam latihan. Node ditagih selama menyala, sehingga biaya menumpuk tanpa ada yang memperoleh manfaatnya. Perbaikannya adalah menjadwalkan penghapusan kluster percobaan dan membangunnya ulang dari manifest ketika dibutuhkan kembali.
• Mengira peningkatan versi aplikasi ikut dikelola vendor. Vendor hanya menaikkan control plane, sedangkan Node pool dan beban kerja tetap menjadi tanggung jawab pengguna. Perbaikannya adalah menjadwalkan peningkatan Node pool dan pengujian aplikasi sebagai bagian dari siklus pemeliharaan.

Ketiga kesalahan tersebut dicegah dengan kebiasaan yang sama, yaitu memperlakukan tagihan cloud sebagai besaran yang dihitung pada awal dan akhir setiap eksperimen, bukan sebagai angka yang hanya muncul di akhir bulan. Kalkulator resmi vendor menjadi titik periksa terakhir sebelum kluster benar-benar dibuat.

Ringkasan#

• Vendor mengelola seluruh control plane, sedangkan data plane, manifest, dan peningkatan versi aplikasi tetap menjadi tanggung jawab pengguna.
• EKS, GKE, dan AKS menyajikan API Kubernetes standar dengan integrasi masing-masing cloud, dan tabel perbandingan cukup berhenti pada posisi generik tanpa harga dan versi.
• Biaya kluster terbagi menjadi jam Node, penyimpanan, load balancer, dan egress, sehingga harga Node per jam saja tidak mewakili tagihan akhirnya.
• Simulasi latihan dengan angka hipotetis menunjukkan jumlah dan kelas Node sebagai faktor biaya terbesar, dan setiap angkanya dapat dihitung ulang dari rumusnya.

Referensi#

• Amazon EKS — AWS — Halaman resmi layanan Kubernetes terkelola EKS beserta ringkasan fiturnya.
• Google Kubernetes Engine — Google Cloud — Halaman resmi layanan Kubernetes terkelola GKE beserta ringkasan fiturnya.
• Azure Kubernetes Service (AKS) — Microsoft Azure — Halaman resmi layanan Kubernetes terkelola AKS beserta ringkasan fiturnya.