Kubernetes Resource Quotas dan Limit Ranges: Mengelola Sumber Daya dan Mencegah Monopoli di Klaster Anda

1. Pendahuluan

Pernahkah Anda mengalami salah satu skenario ini di klaster Kubernetes Anda?

• Sebuah aplikasi baru di-deploy dan tiba-tiba memakan semua CPU atau memori, menyebabkan aplikasi lain di klaster menjadi lambat atau bahkan crash.
• Tim development mengeluh karena Pod mereka tidak bisa di-schedule, padahal mereka merasa klaster masih punya banyak resource.
• Tagihan cloud membengkak karena Pod yang tidak terkontrol memohon (dan mendapatkan) resource yang terlalu besar.

Jika ya, Anda tidak sendirian. Mengelola sumber daya (CPU dan memori) di lingkungan Kubernetes yang shared bisa menjadi tantangan besar. Tanpa pengelolaan yang tepat, klaster Anda rentan terhadap masalah “noisy neighbor” di mana satu aplikasi yang rakus sumber daya dapat mengganggu kinerja aplikasi lain.

Di sinilah Resource Quotas dan Limit Ranges datang sebagai penyelamat. Keduanya adalah fondasi penting dalam membangun klaster Kubernetes yang stabil, efisien, dan adil. Artikel ini akan membawa Anda menyelami mengapa kedua fitur ini sangat krusial, bagaimana cara kerjanya, dan bagaimana Anda bisa mengimplementasikannya untuk mencegah monopoli sumber daya di klaster Anda. Mari kita mulai! 🚀

2. Memahami Resource Requests dan Limits: Fondasi Pengelolaan Sumber Daya

Sebelum kita masuk ke Quotas dan Limit Ranges, penting untuk memahami konsep dasar bagaimana Kubernetes mengelola sumber daya untuk setiap container di dalam Pod: Requests dan Limits.

Setiap container dapat menentukan resources.requests dan resources.limits untuk CPU dan memori.

• requests (Permintaan): Ini adalah jumlah minimum sumber daya yang dijamin akan dialokasikan untuk container.

  • CPU Request: Menentukan berapa banyak CPU yang “diminta” oleh container. Kubernetes Scheduler akan menggunakan nilai ini untuk menentukan Node mana yang memiliki cukup kapasitas untuk menjalankan Pod Anda. Misalnya, 100m (100 millicores) berarti 0.1 CPU core, 1 berarti 1 CPU core penuh.
  • Memory Request: Menentukan berapa banyak memori yang “diminta” oleh container. Ini juga digunakan oleh Scheduler. Misalnya, 256Mi (256 mebibytes).

• limits (Batasan): Ini adalah jumlah maksimum sumber daya yang diizinkan untuk digunakan oleh container.

  • CPU Limit: Menentukan batas atas penggunaan CPU. Jika container mencoba menggunakan lebih dari limit ini, Kubernetes akan “throttle” (memperlambat) container tersebut. Ini mencegah satu container memonopoli CPU di Node.
  • Memory Limit: Menentukan batas atas penggunaan memori. Jika container mencoba menggunakan lebih dari limit ini, kernel Linux akan menghentikan (OOMKill - Out Of Memory Kill) container tersebut. Ini sangat penting untuk mencegah Node kehabisan memori.

Contoh Konfigurasi Pod dengan Requests dan Limits:

apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
spec:
  containers:
  - name: my-app-container
    image: nginx
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

📌 Penting: Menentukan requests dan limits yang realistis adalah kunci. requests yang terlalu rendah bisa menyebabkan Pod tidak di-schedule di Node yang tepat atau mengalami starvation, sementara limits yang terlalu rendah bisa menyebabkan aplikasi sering crash (OOMKill) atau melambat. Sebaliknya, requests dan limits yang terlalu tinggi akan membuang-buang sumber daya dan uang.

3. Resource Quotas: Mengontrol Penggunaan Sumber Daya per Namespace

Setelah memahami requests dan limits untuk Pod/Container, sekarang kita naik satu tingkat ke Resource Quotas. Resource Quotas adalah kebijakan yang diterapkan pada sebuah namespace untuk membatasi total konsumsi sumber daya oleh semua Pod di dalam namespace tersebut.

Bayangkan Anda memiliki sebuah klaster Kubernetes yang dibagi untuk beberapa tim (misalnya, dev-team, qa-team, prod-team). Tanpa Resource Quotas, dev-team bisa saja secara tidak sengaja (atau sengaja) menggunakan semua sumber daya klaster, meninggalkan prod-team tanpa resource yang cukup untuk aplikasi kritikal mereka. Resource Quotas mencegah skenario ini dengan menetapkan “batas anggaran” sumber daya untuk setiap namespace.

Jenis-jenis Sumber Daya yang Bisa Dikuota:

Resource Quotas bisa membatasi berbagai jenis sumber daya, antara lain:

• Compute Resources: CPU (requests.cpu, limits.cpu), Memory (requests.memory, limits.memory).
• Storage Resources: Jumlah Persistent Volume Claim (persistentvolumeclaims), kapasitas storage (requests.storage).
• Object Count: Jumlah objek Kubernetes tertentu seperti Pods (pods), Services (services), Deployments (deployments), ConfigMaps (configmaps), dll.

Contoh YAML Resource Quota:

Mari kita buat Resource Quota untuk namespace dev-team:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-team-quota
  namespace: dev-team
spec:
  hard:
    requests.cpu: "2"      # Total CPU requests di namespace ini tidak boleh melebihi 2 core
    requests.memory: "4Gi" # Total Memory requests di namespace ini tidak boleh melebihi 4 GiB
    limits.cpu: "4"        # Total CPU limits di namespace ini tidak boleh melebihi 4 core
    limits.memory: "8Gi"   # Total Memory limits di namespace ini tidak boleh melebihi 8 GiB
    pods: "10"             # Maksimal 10 Pod di namespace ini
    services: "5"          # Maksimal 5 Services di namespace ini
    configmaps: "20"       # Maksimal 20 ConfigMaps di namespace ini

Untuk menerapkan ini, pastikan namespace dev-team sudah ada, lalu apply YAML di atas:

kubectl apply -f dev-team-quota.yaml

✅ Manfaat Resource Quotas:

• Isolasi Sumber Daya: Mencegah satu namespace memonopoli sumber daya klaster.
• Keadilan: Memastikan setiap tim atau proyek mendapatkan porsi sumber daya yang adil.
• Efisiensi Biaya: Mengontrol konsumsi sumber daya secara keseluruhan, membantu mengelola biaya cloud.
• Stabilitas Klaster: Mencegah kegagalan klaster karena kehabisan sumber daya.

⚠️ Catatan: Jika sebuah Pod mencoba di-deploy ke namespace yang sudah mencapai batas quotanya, Pod tersebut akan ditolak oleh API Server.

4. Limit Ranges: Menetapkan Batasan Default untuk Pod/Container

Sementara Resource Quotas bekerja di tingkat namespace, Limit Ranges bekerja di tingkat yang lebih granular: Pod atau Container. Limit Ranges memungkinkan Anda untuk:

• Menetapkan nilai default untuk requests dan limits jika Pod/Container tidak menentukannya sendiri.
• Menetapkan nilai minimum dan maximum yang diizinkan untuk requests dan limits untuk setiap container di dalam namespace.

Ini sangat berguna untuk menegakkan standar dan praktik terbaik di seluruh namespace. Misalnya, Anda ingin memastikan tidak ada Pod yang di-deploy tanpa requests dan limits yang jelas, atau tidak ada Pod yang mencoba meminta memori yang sangat besar.

Contoh YAML Limit Range:

Mari kita buat Limit Range untuk namespace dev-team juga:

apiVersion: v1
kind: LimitRange
metadata:
  name: dev-team-limits
  namespace: dev-team
spec:
  limits:
  - type: Pod
    max:
      cpu: "1"
      memory: "2Gi"
    min:
      cpu: "100m"
      memory: "128Mi"
  - type: Container
    defaultRequest:
      cpu: "100m"
      memory: "128Mi"
    default:
      cpu: "200m"
      memory: "256Mi"
    max:
      cpu: "500m"
      memory: "1Gi"
    min:
      cpu: "50m"
      memory: "64Mi"

Apply Limit Range ini:

kubectl apply -f dev-team-limits.yaml

🎯 Penjelasan Contoh di Atas:

• type: Pod: Menetapkan batasan untuk total sumber daya yang diminta oleh semua container dalam satu Pod.
  • max.cpu: "1", max.memory: "2Gi": Satu Pod tidak boleh meminta lebih dari 1 CPU atau 2GiB memori.
  • min.cpu: "100m", min.memory: "128Mi": Satu Pod harus meminta setidaknya 100m CPU dan 128MiB memori.
• type: Container: Menetapkan batasan untuk setiap container individu.
  • defaultRequest.cpu: "100m", defaultRequest.memory: "128Mi": Jika container tidak menentukan requests, nilai ini akan otomatis ditambahkan.
  • default.cpu: "200m", default.memory: "256Mi": Jika container tidak menentukan limits, nilai ini akan otomatis ditambahkan (penting: default adalah untuk limits, bukan requests).
  • max.cpu: "500m", max.memory: "1Gi": Satu container tidak boleh memiliki limits lebih dari 500m CPU atau 1GiB memori.
  • min.cpu: "50m", min.memory: "64Mi": Satu container tidak boleh memiliki requests kurang dari 50m CPU atau 64MiB memori.

💡 Tips Praktis Limit Ranges:

• Enforce Standards: Pastikan semua Pod memiliki requests dan limits yang sesuai dengan standar organisasi Anda.
• Mencegah Kesalahan: Otomatis mengisi nilai default mengurangi risiko Pod di-deploy tanpa batasan, yang bisa menyebabkan masalah.
• Membatasi Ukuran: Mencegah developer secara tidak sengaja meminta atau menggunakan sumber daya yang terlalu besar untuk satu container.

5. Sinergi Quotas dan Limit Ranges: Membangun Kebijakan Sumber Daya yang Komprehensif

Resource Quotas dan Limit Ranges adalah dua alat yang saling melengkapi. Resource Quotas adalah “kebijakan makro” yang membatasi total penggunaan sumber daya di tingkat namespace, sementara Limit Ranges adalah “kebijakan mikro” yang membatasi dan memberikan nilai default untuk sumber daya di tingkat Pod/Container di dalam namespace tersebut.

Contoh Skenario:

Misalkan Anda memiliki klaster dengan total 10 CPU core dan 20GiB memori. Anda ingin membagi klaster ini untuk dua tim: dev-team dan prod-team.

1. Untuk prod-team (aplikasi kritikal):

   • Resource Quota: Berikan alokasi yang lebih besar, misalnya 5 CPU dan 10GiB memori.
   • Limit Range: Tentukan min dan max yang ketat untuk memastikan Pod tidak di-deploy tanpa requests dan limits yang realistis, dan limits yang cukup tinggi untuk performa, tetapi tidak berlebihan.

2. Untuk dev-team (aplikasi non-kritikal, eksperimen):

   • Resource Quota: Berikan alokasi yang lebih kecil, misalnya 3 CPU dan 6GiB memori.
   • Limit Range: Tentukan default requests dan limits agar developer tidak perlu pusing menentukannya, tetapi dengan max yang lebih rendah untuk mencegah eksperimen yang boros sumber daya.

Dengan kombinasi ini, Anda bisa:

• Mencegah dev-team mengambil alokasi prod-team (via Resource Quotas).
• Memastikan setiap Pod di dev-team memiliki requests dan limits yang masuk akal (via Limit Ranges), bahkan jika developer lupa menentukannya.
• Mencegah satu Pod di prod-team secara individu meminta resource yang terlalu besar (via Limit Ranges).

Ini adalah pendekatan berlapis untuk manajemen sumber daya yang efektif, mencegah “mon