Belajar Kubernetes - Episode 11 - Pengenalan dan Penjelasan ReplicationController
#devops

Belajar Kubernetes - Episode 11 - Pengenalan dan Penjelasan ReplicationController

Di episode ini kita akan coba bahas konsep penting di Kubernetes yaitu ReplicationController. Kita akan mempelajari bagaimana ReplicationController memastikan jumlah Pod replica yang di-specify berjalan pada waktu tertentu.

Arman Dwi Pangestu
Arman Dwi PangestuMarch 14, 2026
0 views
8 min read

Pendahuluan

Catatan

Untuk kalian yang ingin membaca episode sebelumnya, bisa click thumbnail episode 10 di bawah ini

Episode 10Episode 10

Di episode sebelumnya kita sudah belajar tentang Probe di Kubernetes untuk memastikan kesehatan dan ketersediaan aplikasi. Selanjutnya di episode 11 kali ini, kita akan coba bahas konsep penting untuk mengelola Pod replica yaitu ReplicationController.

Catatan: Disini saya akan menggunakan Kubernetes Cluster yang di install melalui K3s.

ReplicationController adalah salah satu controller fundamental di Kubernetes yang memastikan jumlah Pod replica yang di-specify berjalan pada waktu tertentu. Sementara ReplicationController sudah sebagian besar digantikan oleh ReplicaSet dan Deployment di modern Kubernetes, memahaminya penting karena memperkenalkan core concept yang digunakan di seluruh Kubernetes.

Important

Catatan Penting: ReplicationController dianggap legacy. Di modern Kubernetes, kalian harus menggunakan ReplicaSet (yang akan kita bahas di episode berikutnya) atau Deployment. Namun, memahami ReplicationController membantu kalian memahami fundamental concept dari replica management di Kubernetes.

Apa Itu ReplicationController?

ReplicationController memastikan bahwa jumlah Pod replica yang di-specify berjalan pada waktu tertentu. Jika ada terlalu banyak Pod, dia akan kill beberapa. Jika terlalu sedikit, dia akan start lebih banyak. Bayangkan seperti supervisor yang terus-menerus memonitor Pod kalian dan maintain desired state.

Tanggung jawab kunci ReplicationController:

  • Maintain desired replica count - Memastikan jumlah Pod yang di-specify selalu berjalan
  • Self-healing - Otomatis replace Pod yang fail atau dihapus
  • Scaling - Memungkinkan kalian scale Pod up atau down
  • Load distribution - Mendistribusikan Pod di berbagai node

Cara Kerja ReplicationController

ReplicationController terus-menerus memonitor cluster dan membandingkan actual state dengan desired state:

  1. Desired State: Kalian specify ingin 3 replica
  2. Actual State: ReplicationController menghitung running Pod
  3. Reconciliation: Jika actual ≠ desired, ReplicationController mengambil tindakan
    • Terlalu sedikit Pod → Buat Pod baru
    • Terlalu banyak Pod → Hapus excess Pod

Kenapa Kita Butuh ReplicationController?

Tanpa ReplicationController, jika kalian manually membuat Pod:

  • Tidak ada automatic recovery - Jika Pod crash, dia tetap crash
  • Tidak ada scaling - Kalian harus manually create/delete Pod
  • Tidak ada load distribution - Kalian harus manually distribute Pod di berbagai node
  • Manual management - Kalian harus track dan manage setiap Pod secara individual

Dengan ReplicationController:

  • Automatic recovery - Failed Pod otomatis di-replace
  • Easy scaling - Ubah replica count dan Kubernetes handle sisanya
  • High availability - Multiple replica memastikan service continuity
  • Simplified management - Manage multiple Pod sebagai single unit

Komponen ReplicationController

ReplicationController terdiri dari tiga komponen utama:

1. Replica Count

Jumlah Pod replica yang ingin kalian jalankan:

Kubernetesyml
spec:
    replicas: 3  # Jalankan 3 Pod

2. Pod Selector

Label yang digunakan untuk mengidentifikasi Pod mana yang dikelola ReplicationController:

Kubernetesyml
spec:
    selector:
        app: nginx
        environment: production

3. Pod Template

Template yang digunakan untuk membuat Pod baru:

Kubernetesyml
spec:
    template:
        metadata:
            labels:
                app: nginx
        spec:
            containers:
                - name: nginx
                  image: nginx:1.25

Membuat ReplicationController

Mari kita buat basic ReplicationController:

Contoh 1: Basic ReplicationController

Buat file bernama replication-controller.yml:

Kubernetesreplication-controller.yml
apiVersion: v1
kind: ReplicationController
metadata:
    name: nginx-rc
    labels:
        app: nginx
spec:
    replicas: 3
    selector:
        app: nginx
    template:
        metadata:
            labels:
                app: nginx
        spec:
            containers:
                - name: nginx
                  image: nginx:1.25
                  ports:
                      - containerPort: 80

ReplicationController ini:

  • Membuat 3 replica nginx Pod
  • Memilih Pod dengan label app: nginx
  • Menggunakan image nginx:1.25

Apply konfigurasi:

Kubernetesbash
sudo kubectl apply -f replication-controller.yml

Verifikasi ReplicationController dibuat:

Kubernetesbash
sudo kubectl get replicationcontroller

Atau gunakan shorthand:

Kubernetesbash
sudo kubectl get rc

Output:

Kubernetesbash
NAME       DESIRED   CURRENT   READY   AGE
nginx-rc   3         3         3       30s

Cek Pod yang dibuat oleh ReplicationController:

Kubernetesbash
sudo kubectl get pods

Output:

Kubernetesbash
NAME             READY   STATUS    RESTARTS   AGE
nginx-rc-abc12   1/1     Running   0          30s
nginx-rc-def34   1/1     Running   0          30s
nginx-rc-ghi56   1/1     Running   0          30s

Perhatikan bahwa nama Pod otomatis di-generate dengan nama ReplicationController sebagai prefix.

Melihat Detail ReplicationController

Untuk melihat informasi detail tentang ReplicationController:

Kubernetesbash
sudo kubectl describe rc nginx-rc

Output:

Kubernetesbash
Name:         nginx-rc
Namespace:    default
Selector:     app=nginx
Labels:       app=nginx
Annotations:  <none>
Replicas:     3 current / 3 desired
Pods Status:  3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx:1.25
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Events:
  Type    Reason            Age   From                    Message
  ----    ------            ----  ----                    -------
  Normal  SuccessfulCreate  2m    replication-controller  Created pod: nginx-rc-abc12
  Normal  SuccessfulCreate  2m    replication-controller  Created pod: nginx-rc-def34
  Normal  SuccessfulCreate  2m    replication-controller  Created pod: nginx-rc-ghi56

Demonstrasi Self-Healing

Mari kita demonstrasikan bagaimana ReplicationController otomatis replace failed Pod:

Step 1: Cek Current Pod

Kubernetesbash
sudo kubectl get pods

Output:

Kubernetesbash
NAME             READY   STATUS    RESTARTS   AGE
nginx-rc-abc12   1/1     Running   0          5m
nginx-rc-def34   1/1     Running   0          5m
nginx-rc-ghi56   1/1     Running   0          5m

Step 2: Hapus Pod

Kubernetesbash
sudo kubectl delete pod nginx-rc-abc12

Step 3: Watch ReplicationController Membuat Pod Baru

Kubernetesbash
sudo kubectl get pods -w

Kalian akan melihat:

Kubernetesbash
NAME             READY   STATUS              RESTARTS   AGE
nginx-rc-abc12   1/1     Terminating         0          5m
nginx-rc-def34   1/1     Running             0          5m
nginx-rc-ghi56   1/1     Running             0          5m
nginx-rc-xyz78   0/1     ContainerCreating   0          1s
nginx-rc-xyz78   1/1     Running             0          3s

ReplicationController segera membuat Pod baru (nginx-rc-xyz78) untuk maintain desired count 3 replica.

Step 4: Verifikasi Replica Count

Kubernetesbash
sudo kubectl get rc nginx-rc

Output:

Kubernetesbash
NAME       DESIRED   CURRENT   READY   AGE
nginx-rc   3         3         3       6m

Replica count tetap di 3, sesuai yang diharapkan.

Scaling ReplicationController

Kalian bisa scale ReplicationController up atau down dengan beberapa cara:

Cara 1: Menggunakan kubectl scale Command

Scale up ke 5 replica:

Kubernetesbash
sudo kubectl scale rc nginx-rc --replicas=5

Verifikasi:

Kubernetesbash
sudo kubectl get pods

Output:

Kubernetesbash
NAME             READY   STATUS    RESTARTS   AGE
nginx-rc-def34   1/1     Running   0          10m
nginx-rc-ghi56   1/1     Running   0          10m
nginx-rc-xyz78   1/1     Running   0          5m
nginx-rc-jkl90   1/1     Running   0          10s
nginx-rc-mno12   1/1     Running   0          10s

Scale down ke 2 replica:

Kubernetesbash
sudo kubectl scale rc nginx-rc --replicas=2

ReplicationController akan terminate 3 Pod untuk maintain 2 replica.

Cara 2: Edit ReplicationController

Edit ReplicationController secara langsung:

Kubernetesbash
sudo kubectl edit rc nginx-rc

Ubah field replicas:

Kubernetesyml
spec:
    replicas: 4  # Ubah dari 3 ke 4

Save dan exit. Kubernetes akan otomatis membuat satu Pod lagi.

Cara 3: Update File YAML

Update file replication-controller.yml kalian:

Kubernetesreplication-controller.yml
spec:
    replicas: 6  # Ubah dari 3 ke 6

Apply perubahan:

Kubernetesbash
sudo kubectl apply -f replication-controller.yml

Behavior Label Selector

ReplicationController menggunakan label selector untuk mengidentifikasi Pod mana yang dikelola. Mari kita explore ini:

Contoh: Membuat Pod dengan Matching Label

Buat Pod secara manual dengan label yang sama:

Kubernetesmanual-pod.yml
apiVersion: v1
kind: Pod
metadata:
    name: manual-nginx
    labels:
        app: nginx  # Label yang sama dengan ReplicationController selector
spec:
    containers:
        - name: nginx
          image: nginx:1.25

Apply:

Kubernetesbash
sudo kubectl apply -f manual-pod.yml

Cek Pod:

Kubernetesbash
sudo kubectl get pods

Kalian akan notice bahwa ReplicationController akan menghapus salah satu Pod nya sendiri karena total count (termasuk manual Pod kalian) melebihi desired replica count.

Contoh: Menghapus Label dari Pod

Dapatkan Pod yang dikelola ReplicationController:

Kubernetesbash
sudo kubectl get pods -l app=nginx

Hapus label dari satu Pod:

Kubernetesbash
sudo kubectl label pod nginx-rc-def34 app-

Pod tidak lagi dikelola oleh ReplicationController. ReplicationController akan membuat Pod baru untuk maintain desired count.

Cek Pod:

Kubernetesbash
sudo kubectl get pods

Kalian akan melihat:

  • Pod dengan label yang dihapus masih berjalan (tapi tidak dikelola)
  • Pod baru dibuat oleh ReplicationController

Update Pod Template

Saat kalian update Pod template di ReplicationController, hanya mempengaruhi Pod baru. Existing Pod tidak di-update.

Contoh: Update Image Version

Edit ReplicationController:

Kubernetesbash
sudo kubectl edit rc nginx-rc

Ubah image version:

Kubernetesyml
spec:
    template:
        spec:
            containers:
                - name: nginx
                  image: nginx:1.26  # Ubah dari 1.25 ke 1.26

Save dan exit.

Cek existing Pod:

Kubernetesbash
sudo kubectl get pods -o wide

Existing Pod masih menggunakan old image (nginx:1.25).

Untuk apply template baru, kalian perlu menghapus existing Pod:

Kubernetesbash
# Hapus semua Pod (ReplicationController akan recreate dengan template baru)
sudo kubectl delete pods -l app=nginx

Atau scale down ke 0 dan back up:

Kubernetesbash
sudo kubectl scale rc nginx-rc --replicas=0
sudo kubectl scale rc nginx-rc --replicas=3

Tip

Limitasi ini adalah salah satu alasan kenapa Deployment lebih disukai daripada ReplicationController. Deployment handle rolling update secara otomatis.

Menghapus ReplicationController

Ada dua cara untuk menghapus ReplicationController:

Cara 1: Hapus ReplicationController dan Pod

Ini menghapus ReplicationController dan semua Pod nya:

Kubernetesbash
sudo kubectl delete rc nginx-rc

Semua Pod yang dikelola ReplicationController akan di-terminate.

Cara 2: Hapus ReplicationController tapi Jaga Pod

Ini hanya menghapus ReplicationController, membiarkan Pod berjalan:

Kubernetesbash
sudo kubectl delete rc nginx-rc --cascade=orphan

Pod akan terus berjalan tapi tidak lagi dikelola controller apapun.

Verifikasi:

Kubernetesbash
sudo kubectl get rc

Tidak ada ReplicationController.

Kubernetesbash
sudo kubectl get pods

Pod masih berjalan.

Warning

Orphaned Pod tidak akan otomatis di-replace jika mereka fail. Kalian perlu manage mereka secara manual atau buat ReplicationController baru untuk adopt mereka.

Contoh Praktis

Contoh 1: Web Application dengan Multiple Replica

Buat ReplicationController untuk web application:

Kubernetesweb-app-rc.yml
apiVersion: v1
kind: ReplicationController
metadata:
    name: web-app-rc
    labels:
        app: web-app
        tier: frontend
spec:
    replicas: 5
    selector:
        app: web-app
        tier: frontend
    template:
        metadata:
            labels:
                app: web-app
                tier: frontend
        spec:
            containers:
                - name: web-app
                  image: nginx:1.25
                  ports:
                      - containerPort: 80
                  resources:
                      requests:
                          memory: "128Mi"
                          cpu: "100m"
                      limits:
                          memory: "256Mi"
                          cpu: "200m"

Contoh 2: ReplicationController dengan Environment Variable

Kubernetesapp-with-env-rc.yml
apiVersion: v1
kind: ReplicationController
metadata:
    name: app-with-env-rc
spec:
    replicas: 3
    selector:
        app: myapp
    template:
        metadata:
            labels:
                app: myapp
        spec:
            containers:
                - name: app
                  image: nginx:1.25
                  env:
                      - name: ENVIRONMENT
                        value: "production"
                      - name: LOG_LEVEL
                        value: "info"
                  ports:
                      - containerPort: 80

Contoh 3: ReplicationController dengan Probe

Kubernetesrc-with-probes.yml
apiVersion: v1
kind: ReplicationController
metadata:
    name: nginx-with-probes-rc
spec:
    replicas: 3
    selector:
        app: nginx-probes
    template:
        metadata:
            labels:
                app: nginx-probes
        spec:
            containers:
                - name: nginx
                  image: nginx:1.25
                  ports:
                      - containerPort: 80
                  livenessProbe:
                      httpGet:
                          path: /
                          port: 80
                      initialDelaySeconds: 3
                      periodSeconds: 10
                  readinessProbe:
                      httpGet:
                          path: /
                          port: 80
                      initialDelaySeconds: 5
                      periodSeconds: 5

ReplicationController vs ReplicaSet

Sementara ReplicationController masih di-support, ReplicaSet adalah modern replacement. Berikut perbedaan kunci:

FiturReplicationControllerReplicaSet
SelectorEquality-based onlySet-based selector
API Versionv1apps/v1
StatusLegacyCurrent standard
Digunakan olehStandaloneDigunakan oleh Deployment
Selector flexibilityLimitedLebih flexible

Equality-based selector (ReplicationController):

Kubernetesyml
selector:
    app: nginx
    tier: frontend

Set-based selector (ReplicaSet):

Kubernetesyml
selector:
    matchLabels:
        app: nginx
    matchExpressions:
        - key: tier
          operator: In
          values:
              - frontend
              - backend

Important

Rekomendasi: Gunakan ReplicaSet atau Deployment daripada ReplicationController untuk aplikasi baru. ReplicationController di-maintain untuk backward compatibility tapi kurang modern feature.

Kesalahan Umum dan Pitfall

Kesalahan 1: Mismatched Label

Pod template label harus match dengan selector:

Salah:

Kubernetesyml
spec:
    selector:
        app: nginx  # Selector
    template:
        metadata:
            labels:
                app: web  # Tidak match!

Benar:

Kubernetesyml
spec:
    selector:
        app: nginx
    template:
        metadata:
            labels:
                app: nginx  # Match dengan selector

Kesalahan 2: Mengharapkan Automatic Update

Update Pod template tidak update existing Pod secara otomatis.

Solusi: Gunakan Deployment untuk rolling update, atau manually delete Pod untuk force recreation.

Kesalahan 3: Tidak Set Resource Limit

Tanpa resource limit, Pod bisa mengkonsumsi semua node resource.

Solusi: Selalu set resource request dan limit:

Kubernetesyml
resources:
    requests:
        memory: "128Mi"
        cpu: "100m"
    limits:
        memory: "256Mi"
        cpu: "200m"

Kesalahan 4: Menggunakan ReplicationController untuk Stateful Application

ReplicationController dirancang untuk stateless application.

Solusi: Gunakan StatefulSet untuk stateful application (database, dll).

Kesalahan 5: Tidak Menggunakan Probe

Tanpa Probe, ReplicationController tidak bisa mendeteksi unhealthy Pod.

Solusi: Selalu tambahkan Liveness dan Readiness Probe.

Best Practice

Gunakan Nama yang Meaningful

Gunakan nama deskriptif untuk ReplicationController:

Kubernetesyml
metadata:
    name: web-app-frontend-rc  # Clear dan descriptive

Tambahkan Label untuk Organisasi

Tambahkan label untuk organisasi yang lebih baik:

Kubernetesyml
metadata:
    labels:
        app: web-app
        tier: frontend
        environment: production
        version: v1.0

Set Replica Count yang Tepat

Pertimbangkan kebutuhan aplikasi kalian:

  • High availability: Setidaknya 3 replica
  • Development: 1-2 replica
  • Production: 3+ replica di berbagai node

Gunakan Resource Limit

Selalu set resource request dan limit:

Kubernetesyml
resources:
    requests:
        memory: "128Mi"
        cpu: "100m"
    limits:
        memory: "256Mi"
        cpu: "200m"

Implementasikan Health Check

Selalu tambahkan Probe:

Kubernetesyml
livenessProbe:
    httpGet:
        path: /healthz
        port: 8080
readinessProbe:
    httpGet:
        path: /ready
        port: 8080

Pertimbangkan Migrasi ke ReplicaSet/Deployment

Untuk aplikasi baru, gunakan ReplicaSet atau Deployment:

Kubernetesyml
# Modern approach - gunakan Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
    name: nginx-deployment
spec:
    replicas: 3
    selector:
        matchLabels:
            app: nginx
    template:
        metadata:
            labels:
                app: nginx
        spec:
            containers:
                - name: nginx
                  image: nginx:1.25

Monitoring ReplicationController

Cek Status ReplicationController

Kubernetesbash
sudo kubectl get rc

Watch ReplicationController Event

Kubernetesbash
sudo kubectl get events --sort-by='.lastTimestamp' | grep ReplicationController

Monitor Status Pod

Kubernetesbash
sudo kubectl get pods -l app=nginx -w

Cek Resource Usage

Kubernetesbash
sudo kubectl top pods -l app=nginx

Penutup

Pada episode 11 ini, kita telah membahas ReplicationController di Kubernetes secara mendalam. Kita sudah belajar apa itu ReplicationController, cara kerjanya, dan cara menggunakannya untuk manage Pod replica.

Key takeaway:

  • ReplicationController memastikan jumlah Pod replica yang di-specify berjalan
  • Menyediakan self-healing dengan otomatis replace failed Pod
  • Support scaling up dan down
  • Menggunakan label selector untuk identify managed Pod
  • Legacy technology - gunakan ReplicaSet atau Deployment untuk aplikasi baru
  • Pod template update tidak mempengaruhi existing Pod
  • Bisa delete ReplicationController sambil keep Pod (orphan mode)

Sementara ReplicationController masih di-support, dia dianggap legacy. Modern Kubernetes application harus menggunakan ReplicaSet (yang akan kita bahas di episode berikutnya) atau Deployment untuk fitur yang lebih baik seperti rolling update, rollback capability, dan selector yang lebih flexible.

Bagaimana, makin jelas kan tentang ReplicationController di Kubernetes? Di episode 12 berikutnya, kita akan membahas ReplicaSet, modern replacement untuk ReplicationController dengan enhanced feature dan better selector support. Jadi, pastikan tetap semangat belajar dan nantikan episode selanjutnya!

Catatan

Untuk kalian yang ingin lanjut ke episode berikutnya, bisa click thumbnail episode 12 di bawah ini

Episode 12Episode 12

Related Posts