Kontainer cloud memberikan fleksibilitas untuk mengangkat dan memindahkan aplikasi ke lingkungan apa pun, cloud atau virtual atau bare metal tanpa mengkhawatirkan sistem operasi virtual, hypervisor, dll. Manajemen yang disederhanakan, pengiriman yang cepat, dan ketangkasan memaksa pengembang cloud untuk menyambut kontainerisasi. Kubernetes alias k8s (jika Anda bertanya-tanya apa kepanjangan dari k8, itu hanya pengganti 8 huruf untuk “Kubernetes”) adalah platform kontainerisasi sumber terbuka populer yang diadopsi secara luas oleh pengembang cloud. Menurut laporan CNCF baru-baru ini, ada peningkatan 67% dalam jumlah pengembang Kubernetes di seluruh dunia, yang menunjukkan popularitasnya.

Berita sedihnya adalah bahwa dengan peningkatan adopsi dan penggunaan muncullah trade-off dalam anggaran infrastruktur TI. Perusahaan dapat menyia-nyiakan hampir 80% dari pengeluaran Kubernetes untuk sumber daya yang tidak diinginkan yang tidak membantu organisasi mencapai tujuan mereka sebagaimana mestinya. Mari kita lihat di blog ini apa saja permasalahan dan cara optimasinya.

Tantangan Pengoptimalan Biaya Kubernetes

Ditagih secara keseluruhan

Sebuah cluster berisi beberapa node. Setiap node pada gilirannya akan berisi sejumlah variabel kontainer. Setiap node yang ada dalam sebuah cluster belum tentu merupakan bagian dari aplikasi yang sama dengan yang lainnya. Setiap node dapat dikelola oleh 20 tim yang berbeda untuk aplikasi yang berbeda. Tetapi cluster tersebut ditagih secara keseluruhan atau dibundel oleh penyedia layanan cloud. Penagihan dimulai segera setelah wadah diterapkan di sebuah node. Biaya tambahan sebesar $2,4/hari dikenakan untuk pemeliharaan klaster Kubernetes, lisensi perangkat lunak, pemulihan bencana, dll.

Showback dan Chargeback – Hampir Mustahil

Kedua proses ini sangat penting bagi perusahaan untuk membawa tanggung jawab keuangan mereka. (Pengisian kembali adalah proses yang memberikan visibilitas pada pengeluaran unit bisnis atas penggunaan sumber daya cloud untuk periode tertentu tetapi belum ditagih. Sedangkan penagihan kembali adalah saat unit diberi tahu dan ditagih berdasarkan penggunaannya.) Pemberian tag, yang dapat membantu teknisi dalam melacak biaya, tidak dimungkinkan di kluster Kubernetes.

Setiap sen yang kami investasikan sangat berharga saat memeriksa daftar fitur/rilis yang telah kami rencanakan. Ketika mereka tetap berada di sisi pengeluaran yang dipetakan ke tidak ada keluaran, sumber utama anomali harus diidentifikasi. Tapi itu tidak sesederhana kedengarannya untuk kluster Kubernetes. Menentukan dengan tepat tim mana yang bertanggung jawab atas pembelanjaan paling banyak memang menakutkan karena setiap penampung dapat digunakan oleh tim yang berbeda di seluruh bisnis yang mengerjakan hasil kerja yang berbeda. Di sisi lain, anggaran infrastruktur dan alokasi biaya sumber daya setiap tim berbeda-beda.

Adopsi multi-cloud

Dalam survei Gartner baru-baru ini, 81% responden mengatakan bahwa mereka menggunakan 2 atau lebih penyedia layanan cloud untuk mendapatkan berbagai keuntungan, seperti mengesampingkan vendor lock-in, diskon sumber daya, pemulihan bencana, dan lainnya. Kluster Kubernetes akan berisi beban kerja dari berbagai penyedia layanan cloud seperti AWS, Azure, GCP, dll.

Penskalaan otomatis dinamis

Salah satu alasan utama mengapa para insinyur cloud memilih kluster Kubernetes adalah fitur penskalaan otomatisnya. Bergantung pada permintaan penggunaan, Kubernetes meningkatkan atau menurunkan skala untuk memastikan sumber daya memenuhi kebutuhan komputasi selama puncak dan palung. Selain itu, dalam penskalaan otomatis horizontal, penskalaan kontainer, yang dapat mencapai 2 hingga 20 dalam sehari. Pengoptimalan biaya Kubernetes menjadi rumit karena penskalaan otomatis yang tidak terduga ini.

Praktik Terbaik Pengoptimalan Biaya Kubernetes

Mari kita lihat cara optimal untuk mengurangi pengeluaran yang tidak disengaja.

Kualitas Layanan untuk Pod (QOS)

Cluster Kubernetes menawarkan kepada para praktisi cloud kemampuan untuk mengatur kelas QoS yang berbeda pada pod. Berdasarkan hal ini, penjadwalan dan penghapusan pod menjadi lebih mudah bagi para praktisi cloud. Ini terdiri dari 3 jenis – Guaranteed, Burstable, dan Best-Effort.

Terjamin: Saat insinyur cloud membutuhkan pod, yang memiliki cukup instance untuk menangani aplikasi yang sangat kritis, mereka dapat mengonfigurasinya menjadi kelas QoS yang terjamin. Dengan demikian, batas dan permintaan CPU dan memori adalah sama dan ditetapkan. Seperti namanya, ini menjamin sumber daya minimum (permintaan adalah jumlah minimum sumber daya dan batasan adalah sumber daya maksimum yang dapat digunakan)

Eksplosif: Kelas QoS yang dapat diperluas ditugaskan ke pod ketika vCPU atau batas memori lebih besar dari permintaan atau pada dasarnya tidak sama. Jadi ketika kebutuhan muncul untuk kebutuhan komputasi yang melonjak, mereka dapat digunakan.

Usaha terbaik: Ketika batas dan permintaan tidak ditetapkan, itu diklasifikasikan sebagai kelas QoS upaya terbaik. Insinyur cloud dapat memanfaatkan aplikasi non-kritis.

Seperti yang dapat kita lihat dengan jelas, pod Best-effort adalah pilihan teratas untuk penarikan diikuti oleh Burstable dan kemudian Dijamin.

ResourceQuotas & LimitRange

Seperti yang kita lihat sebelumnya, cluster Kubernetes digunakan bersama oleh tim yang berbeda. Ada kemungkinan bagi satu tim untuk mengkonsumsi pod paling banyak, sementara tim lain langka. Membatasi pod pada level namespace dapat mengatasi masalah ini (namespace adalah cluster virtual). ResourceQuota adalah sarana dimana kita dapat membatasi penggunaan pod di namespace.

Administrator Kubernetes membuat ResourceQuota untuk setiap Namespace. Setiap kali pengguna membuat atau memperbarui pod di namespace, sistem ResourceQuota memeriksa apakah batasnya terlampaui. Jika melebihi batas, ini mengembalikan kesalahan “403 TERLARANG” yang menolak tindakan.

LimitRange adalah strategi lain yang membantu mengelola kendala sumber daya secara individual. Seperti namanya, batasi rentang “batasan dan permintaan” di namespace.