Banyak orang berpikir, termasuk saya sebelum membaca artikel yang ditulis oleh Natan Yelin :p bahwa Anda harus menerapkan konfigurasi limits pada CPU untuk mencegah satu pod menggangu kinerja pod lainnya. Kenyataannya, Anda bisa menghapus konfigurasi CPU limits tersebut dan tetap menjaga kestabilan kinerja pod yang sedang membutuhkan resources berlebih. Caranya adalah hanya dengan mendefinisikan CPU requests. Hal ini dikarenakan CPU merupakan compressible resources, yang mana suatu pod A bisa menggunakan resources tambahan apabila pod B sedang tidak memerlukan resources CPU berlebih. Apabila pod B sedang menggunakan resources yang berlebih, pod A hanya perlu menunggu sampai pod B tidak menggunakannya lagi. Seperti halnya bendungan air, apabila air yang mengalir melebihi kapasitas pipa bendungan yang tersedia, maka air yang mengalir hanya perlu menunggu waktu sampai bendungan penuh terisi.

Cerita berikut saya dapatkan dari laman ini dan akan memberikan Anda gambaran detail betapa implementasi CPU limits sebaiknya tidak diterapkan.

Bayu dan Aji sedang mendaki Gunung selama 5 hari. Mereka memiliki alat ajaib yang bisa menghasilkan air sebanyak 5 liter dalam sehari. Setiap orang membutuhkan 2 liter air per hari untuk dikonsumsi agar stamina tetap terjaga.

Cerita 1 – Tanpa CPU limits, tanpa CPU requests: Bayu serakah jadi dia minum semua air sebelum Aji bisa minum. Aji mengalami dehidrasi karena kehausan kehabisan stok air. Peristiwa tersebut bisa terjadi karena tidak adanya implementasi limits atau requests. Bayu dapat meminum semua air, yang menyebabkan CPU starvation, dan Aji mengalami CPU throttled.

Cerita 2 – Implementasi CPU limits, dengan atau tanpa CPU requests: Di tengah pendakian Aji dehidrasi dan membutuhkan air tambahan. Bayu meminum dua liter air dan ada tiga liter air yang tersisa. Aji meminum dua liter air namun masih kurang dan sekarang tinggal satu liter. Bayu tidak akan membiarkan Aji meminum air lagi karena adanya ketentuan konsumsi air sebanyak dua liter per hari. Inilah yang terjadi ketika Anda mengimplementasikan CPU limits. Resources tersedia tetapi Anda tidak diperbolehkan menggunakannya.

Cerita 3 – Tanpa CPU limits, implementasi CPU requests: Bayu sedang dehidrasi di tengah pendakian dan membutuhkan air tambahan. Dia mencoba meminum seluruh botol tetapi berhenti ketika air hanya tersisa dua liter. Dua liter air tersebut harus disimpan untuk Aji karena Dia butuh mengkonsumsi air dua liter sehari agar tetap bugar saat mendaki, jadi Bayu hanya meminum tambahan 1 liter air sehingga tidak ada lagi air yang tersisa dan kebugaran mereka tetap terjaga saat mendaki. Inilah yang terjadi ketika Anda tidak mengimplementasikan CPU limits namun mengimplementasikan CPU requests. Semua akan berjalan baik, dan akan ada sisa resources yang sewaktu-waktu bisa digunakan apabila dibutuhkan.

Bagaimana dengan Memory?

Berbeda dengan memory, memory adalah incompressible resources yang mana apabila pod A memerlukan kapasitas memory berlebih maka opsinya hanya dua yaitu pod A tidak bisa berjalan atau pod B akan dihentikan prosesnya agar pod A mendapatkan kapasitas tambahan. Peristiwa ini pada Kubernetes dikenal dengan Out of Memory Kill (OOM Kill). Terdengar familiar? 😀

Praktik Terbaik untuk Kubernetes Limits dan Requests

Mengutip Tim Hockin, salah satu pengelola Kubernetes di Google, praktik terbaik untuk mengelola resources pada Kubernetes adalah dengan mengkonfigurasi nilai memory limits sama dengan requests, dan tidak mengkonfigurasi limits pada CPU untuk mencegah CPU throttled.

apiVersion: v1
kind: Pod
metadata:
  name: konfigurasi-limits-requests
spec:
  containers:
  - name: app
    image: contoh.implementasi/resources:limits-requests
    resources:
      requests:
        memory: "100Mi"
        cpu: "250m"
      limits:
        memory: "100Mi"

Pembahasan ini hanya salah satu upaya yang bisa diterapkan untuk mengoptimalkan pengoperasian aplikasi yang berjalan pada Kubernetes. Kegiatan monitoring dan peninjauan kapasitas secara berkala adalah upaya yang tetap harus dilakukan. Semoga bermanfaat 🙂