Apa iku Deployment lan ReplicaSet, lan kepiyé rolling update sarta rollback makarya?

Question

IT Interview Practice · Accepted Answer

**Deployment** yaiku controller standar kanggo njalanaké aplikasi stateless. Dhèwèké ngatur **ReplicaSet**, lan sawijining ReplicaSet njaga cacah Pod sing padha plek supaya tetep mlaku. Sampeyan ngowahi Deployment; dhèwèké ngorkestrasi **rolling update** lan **rollback** kanggo sampeyan.

## Hirarki

```text
Deployment  → deklarasi desired state + strategi update (barang sing SAMPEYAN atur)
   └── ReplicaSet  → mesthèkaké ana N Pod sing padha plek (siji saben versi app)
          └── Pod  → Pod → Pod ...  (salinan sing tenanan mlaku)

Ing saben versi anyar, Deployment nggawé ReplicaSet ANYAR lan mindhah Pod menyang kono.
```

## Manifest Deployment

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 4
  selector:
    matchLabels: { app: web }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # paling akèh 1 Pod mati sajroning update
      maxSurge: 1            # paling akèh 1 Pod ekstra ngluwihi cacah sing dikarepaké
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Rolling update: ganti versi tanpa downtime

```bash
kubectl set image deployment/web web=myapp:2.0   # micu rolling update
kubectl rollout status deployment/web            # ndeleng kemajuan
```

```text
maxSurge=1, maxUnavailable=1, replicas=4:
  v1: ████        (wiwitan: 4 Pod lawas)
      █████       urubaké 1 Pod anyar (v2), saiki total 5 (surge)
      ███ █       Pod lawas mudhun dadi 3, Pod anyar wis Ready
      ...mindhah alon-alon...
  v2: ████        (pungkasan: 4 Pod anyar, ReplicaSet lawas di-scale dadi 0)
Trafik mung menyang Pod sing lulus readiness probe → ora ana downtime.
```

## Rollback nalika rilis dadi ala

```bash
kubectl rollout history deployment/web       # dhaptar revisi
kubectl rollout undo deployment/web          # mbalik menyang revisi sadurungé
kubectl rollout undo deployment/web --to-revision=3
```

Amarga ReplicaSet lawas disimpen (di-scale dadi 0), rollback iku cepet: Kubernetes mung nge-scale munggah ReplicaSet sadurungé lan sing anyar mudhun.

## Scaling

```bash
kubectl scale deployment/web --replicas=10   # ngganti cacah sing dikarepaké
```

## Kenapa iki penting

Deployment iku kuda beban kanggo njalanaké aplikasi stateless ing Kubernetes, mula ngerti dhèwèké lan sesambungané karo ReplicaSet yaiku kawruh penting saben dina. Panyusunan lapisané minangka wawasan kunci: sampeyan ngatur **Deployment**, sing nduwèni **ReplicaSet** (siji saben versi), lan saben ReplicaSet njamin cacah Pod sing padha plek lagi mlaku — rantéan reconciliation loop sing bebarengan ngirim self-healing lan cacah replica sing stabil. Kekuwatan sejatiné ana ing kepiyé Deployment nangani owah-owahan: sawijining **rolling update** nggawé ReplicaSet anyar lan mindhah Pod saka lawas menyang anyar alon-alon, diatur déning `maxSurge` lan `maxUnavailable`, dadi kapasitas dijaga lan — digabung karo readiness probe sing nemtokaké Pod ngendi sing nampa trafik — rilis kedadéan **tanpa downtime**. Amarga ReplicaSet sadurungé disimpen (di-scale dadi nol tinimbang dibusak), sawijining **rollback** iku cepet lan aman: `kubectl rollout undo` mung nge-scale versi lawas munggah manèh lan sing ala mudhun, pas karo apa sing sampeyan butuhaké nalika rilis ngadat. Ngerti mekanisme iki — plus carané nge-scale (`kubectl scale`) lan mriksa kemajuan (`kubectl rollout status/history`) — iku pondhasi kanggo ngirim piranti lunak kanthi aman ing Kubernetes, lan nyerminaké model deklaratif, sing dikendhaléni controller sing nemtokaké carané platform iki makarya ing production.

Hirarki

Manifest Deployment

Rolling update: ganti versi tanpa downtime

Rollback nalika rilis dadi ala

Scaling

Kenapa iki penting

Pitakon sing gegandhengan