ReplicaSet #
ReplicaSet adalah resource Kubernetes yang memastikan sejumlah replica Pod selalu berjalan di cluster. Jika ada Pod yang mati, ReplicaSet membuat penggantinya. Jika ada Pod yang tiba-tiba lebih banyak dari yang diinginkan, ReplicaSet menghapus kelebihannya. Sederhana, tapi di balik kesederhanaan itu ada mekanisme yang perlu dipahami — terutama hubungannya dengan Deployment yang menjadi cara utama men-deploy aplikasi di Kubernetes.
Cara Kerja ReplicaSet #
ReplicaSet bekerja dengan satu control loop sederhana:
Loop ReplicaSet Controller:
desired = spec.replicas (misalnya: 3)
current = jumlah Pod dengan label yang cocok dengan selector
if current < desired:
buat (desired - current) Pod baru menggunakan template
if current > desired:
hapus (current - desired) Pod (pilih berdasarkan priority)
if current == desired:
tidak ada tindakan
Yang membuat ini menarik adalah cara ReplicaSet mengidentifikasi Pod yang “miliknya”. Ia tidak melacak Pod berdasarkan nama atau ID internal — melainkan menggunakan label selector.
Label Selector dan Ownership #
ReplicaSet menggunakan selector untuk menemukan Pod yang dikelolanya:
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: api-replicaset
spec:
replicas: 3
selector:
matchLabels:
app: api # ← ReplicaSet ini mengelola Pod berlabel app=api
tier: backend
template:
metadata:
labels:
app: api # ← Pod yang dibuat harus punya label yang sama
tier: backend
spec:
containers:
- name: api
image: my-api:v2
Implikasi penting dari pola ini: ReplicaSet tidak peduli apakah Pod yang ia temukan dibuat olehnya atau oleh proses lain. Jika ada Pod berlabel app=api, tier=backend yang berjalan di namespace yang sama, ReplicaSet akan mengadopsinya — atau menghapusnya jika jumlahnya melebihi spec.replicas.
Skenario adopsi Pod "yatim":
1. ReplicaSet "api-rs" dengan selector app=api, replicas: 3
→ mengelola 3 Pod
2. Seseorang membuat Pod manual dengan label app=api
3. ReplicaSet mendeteksi: current = 4, desired = 3
→ Hapus 1 Pod (mungkin yang baru saja dibuat manual)
Jangan membuat Pod manual dengan label yang cocok dengan selector ReplicaSet yang sudah ada. Pod tersebut akan langsung diadopsi oleh ReplicaSet, dan jika jumlah total melebihi spec.replicas, Pod terbaru yang dibuat manual kemungkinan akan langsung dihapus.ReplicaSet vs Deployment #
Dalam praktik sehari-hari, kamu hampir tidak pernah membuat ReplicaSet secara langsung. Kamu membuat Deployment, dan Deployment yang membuat serta mengelola ReplicaSet untukmu.
Hubungan Deployment ↔ ReplicaSet ↔ Pod:
Deployment "api-deployment" (spec.replicas: 3, image: api:v1)
│
└── ReplicaSet "api-deployment-abc123" (template: api:v1)
├── Pod "api-deployment-abc123-xyz01"
├── Pod "api-deployment-abc123-xyz02"
└── Pod "api-deployment-abc123-xyz03"
Saat update image ke api:v2:
Deployment "api-deployment" (spec.replicas: 3, image: api:v2)
│
├── ReplicaSet "api-deployment-abc123" (template: api:v1) ← scale down ke 0
│ (tapi tidak dihapus)
└── ReplicaSet "api-deployment-def456" (template: api:v2) ← scale up ke 3
├── Pod "api-deployment-def456-pqr01"
├── Pod "api-deployment-def456-pqr02"
└── Pod "api-deployment-def456-pqr03"
ReplicaSet lama tidak langsung dihapus — Deployment menyimpan history-nya (default 10 ReplicaSet) untuk memungkinkan rollback.
Berinteraksi dengan ReplicaSet #
Meskipun jarang dikelola langsung, mengetahui cara membaca state ReplicaSet berguna untuk debugging:
# Lihat semua ReplicaSet
kubectl get replicasets
# Output:
# NAME DESIRED CURRENT READY AGE
# api-deployment-abc123 0 0 0 5d ← versi lama
# api-deployment-def456 3 3 3 2h ← versi aktif
# Detail ReplicaSet termasuk selector dan events
kubectl describe replicaset api-deployment-def456
# Lihat ReplicaSet mana yang dimiliki oleh Deployment tertentu
kubectl get replicasets -l app=api
# Lihat owner reference Pod — menunjukkan ReplicaSet mana yang memilikinya
kubectl get pod api-deployment-def456-pqr01 -o yaml | grep -A 5 ownerReferences
Scaling ReplicaSet #
ReplicaSet bisa di-scale secara langsung, tapi jika ReplicaSet dikelola oleh Deployment, selalu scale Deployment-nya — bukan ReplicaSet-nya langsung.
# ANTI-PATTERN: scale ReplicaSet yang dikelola Deployment
kubectl scale replicaset api-deployment-def456 --replicas=5
# Ini akan langsung di-override oleh Deployment Controller
# kembali ke nilai di Deployment spec
# BENAR: scale melalui Deployment
kubectl scale deployment api-deployment --replicas=5
# Atau update manifest dan apply
# (perubahan di spec.replicas)
kubectl apply -f deployment.yaml
Kapan Membuat ReplicaSet Langsung? #
Sangat jarang. Hampir semua kasus lebih baik menggunakan Deployment. Satu-satunya alasan valid membuat ReplicaSet langsung adalah jika kamu tidak butuh fitur update strategy yang disediakan Deployment — misalnya untuk Pod yang template-nya tidak pernah berubah setelah dibuat. Tapi bahkan dalam kasus ini, Deployment dengan satu ReplicaSet masih lebih mudah dikelola.
Gunakan ReplicaSet langsung jika:
(hampir tidak ada alasan valid di production)
Gunakan Deployment (yang mengelola ReplicaSet) jika:
✓ Semua kasus aplikasi stateless yang perlu rolling update
✓ Butuh rollback ke versi sebelumnya
✓ Butuh history deployment
✓ Butuh kontrol atas update strategy (RollingUpdate atau Recreate)
Ringkasan #
- ReplicaSet menjaga jumlah replica — control loop sederhana: jika kurang, buat Pod baru; jika lebih, hapus kelebihan.
- Ownership via label selector, bukan referensi langsung — ReplicaSet mengadopsi semua Pod yang labelnya cocok, termasuk Pod yang dibuat secara manual.
- Deployment mengelola ReplicaSet — dalam praktik produksi, kamu membuat Deployment; Deployment yang membuat dan mengelola ReplicaSet.
- Rolling update = swap ReplicaSet — Deployment membuat ReplicaSet baru untuk versi baru, lalu secara bertahap scale down ReplicaSet lama.
- ReplicaSet lama disimpan untuk rollback — Deployment menyimpan history ReplicaSet (default 10) sehingga rollback ke versi sebelumnya bisa dilakukan tanpa membuat ulang Pod template.
- Scale selalu via Deployment — scaling ReplicaSet langsung akan di-override oleh Deployment Controller dalam hitungan detik.