Pahami cara kerja Deployment dan Service di Kubernetes untuk mengelola Pod otomatis dan mengekspos aplikasi secara stabil. Lengkap contoh YAML!

Bagi siapa pun yang baru terjun ke dunia container orchestration, Kubernetes sering terasa seperti hutan istilah: Pod, ReplicaSet, Deployment, Service, Ingress, dan masih banyak lagi. Namun jika ditelusuri satu per satu, setiap komponen sebenarnya menjawab satu masalah nyata yang dihadapi tim operasional aplikasi modern.

Dua komponen yang paling sering berinteraksi langsung dengan pekerjaan sehari-hari seorang DevOps atau Sysadmin adalah Deployment dan Service. Deployment menjawab pertanyaan “bagaimana aplikasi saya tetap berjalan meski ada Pod yang mati atau perlu diperbarui?”, sementara Service menjawab “bagaimana pengguna atau aplikasi lain bisa mengakses Pod saya secara stabil, padahal alamat IP Pod bisa berubah-ubah?”.

Memahami dua konsep ini adalah fondasi wajib sebelum melangkah ke topik yang lebih lanjut seperti Ingress, Horizontal Pod Autoscaler, atau StatefulSet. Artikel ini akan membahas keduanya secara mendalam, lengkap dengan contoh manifest YAML, studi kasus sederhana, dan kesalahan umum yang sering terjadi di lapangan.

Apa Itu Pod, dan Kenapa Tidak Cukup Berdiri Sendiri?

Sebelum masuk ke Deployment, penting memahami bahwa unit terkecil yang dijalankan di Kubernetes adalah Pod. Satu Pod biasanya membungkus satu (atau beberapa) container aplikasi.

Masalahnya, Pod yang dibuat secara manual bersifat ephemeral alias sementara. Jika Pod tersebut crash, node tempatnya berjalan mati, atau container di dalamnya error, Kubernetes tidak akan membuat ulang Pod itu secara otomatis jika Pod dibuat langsung tanpa pengontrol di atasnya. Di sinilah Deployment berperan.

Deployment: Manajer Otomatis untuk Pod

Deployment adalah objek Kubernetes yang bertugas mengelola siklus hidup sekumpulan Pod identik melalui perantara bernama ReplicaSet. Secara sederhana, alur kerjanya seperti ini:

Anda mendefinisikan “template” Pod dan jumlah replika yang diinginkan di dalam Deployment.
Deployment membuat ReplicaSet.
ReplicaSet memastikan jumlah Pod yang berjalan selalu sesuai dengan angka yang diminta.
Jika ada Pod yang mati, ReplicaSet otomatis membuat Pod baru sebagai pengganti.

Analoginya, bayangkan Deployment seperti seorang manajer restoran yang punya aturan “harus selalu ada 3 pelayan aktif di lantai”. Jika satu pelayan izin sakit, manajer akan langsung memanggil pelayan cadangan agar jumlahnya tetap 3, tanpa perlu diminta.

Selain menjaga jumlah replika, Deployment juga mengatur:

Rolling update: memperbarui versi aplikasi secara bertahap tanpa downtime.
Rollback: mengembalikan ke versi sebelumnya jika update baru bermasalah.
Scaling: menambah atau mengurangi jumlah replika sesuai kebutuhan beban.

Contoh Manifest YAML: Deployment

Berikut contoh Deployment sederhana untuk aplikasi web berbasis Nginx dengan 3 replika:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app-deployment
  labels:
    app: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: web-app
          image: nginx:1.27
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "250m"
              memory: "256Mi"

Beberapa hal penting untuk diperhatikan:

spec.selector.matchLabels harus cocok dengan spec.template.metadata.labels. Jika tidak cocok, Kubernetes akan menolak manifest ini.
replicas: 3 berarti Deployment akan selalu menjaga agar ada 3 Pod yang berjalan.
resources sebaiknya selalu didefinisikan agar scheduler dapat mengalokasikan node dengan tepat dan mencegah satu Pod “memakan” seluruh resource node.

Service: Menjaga Akses Tetap Stabil Meski Pod Berganti

Setelah Deployment berjalan, muncul masalah baru: setiap Pod memiliki IP internal sendiri, dan IP tersebut berubah setiap kali Pod dibuat ulang (misalnya saat crash atau rolling update). Jika aplikasi lain atau pengguna mengakses Pod langsung via IP, koneksi akan terputus setiap kali terjadi pergantian Pod.

Service hadir sebagai solusi. Service menyediakan satu alamat jaringan (baik berupa ClusterIP, DNS name, maupun endpoint eksternal) yang stabil, lalu secara otomatis meneruskan trafik ke Pod-Pod yang sehat berdasarkan label selector, bukan berdasarkan IP Pod secara langsung.

Analoginya, Service seperti nomor customer service sebuah perusahaan. Nomor teleponnya tidak pernah berubah, meskipun staf yang menjawab telepon (Pod) bisa berganti-ganti setiap shift.

Kubernetes menyediakan beberapa tipe Service, yang paling umum digunakan:

ClusterIP (default): hanya bisa diakses dari dalam cluster. Cocok untuk komunikasi antar-microservice internal.
NodePort: membuka port statis di setiap node, memungkinkan akses dari luar cluster melalui <IP-Node>:<Port>.
LoadBalancer: meminta penyedia cloud (AWS, GCP, Azure, dll.) membuat load balancer eksternal yang mengarah ke Service.
ExternalName: memetakan Service ke nama domain eksternal, tanpa proxy trafik.

Contoh Manifest YAML: Service

Berikut contoh Service tipe ClusterIP yang mengekspos Deployment web-app-deployment di atas:

apiVersion: v1
kind: Service
metadata:
  name: web-app-service
spec:
  type: ClusterIP
  selector:
    app: web-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

Penjelasan bagian penting:

selector.app: web-app harus sama persis dengan label pada Pod (spec.template.metadata.labels di Deployment). Inilah mekanisme Service menemukan Pod tujuan.
port adalah port yang diekspos oleh Service itu sendiri.
targetPort adalah port yang dibuka container di dalam Pod (containerPort).

Jika ingin diakses dari luar cluster tanpa cloud load balancer, cukup ubah type menjadi NodePort:

apiVersion: v1
kind: Service
metadata:
  name: web-app-service-nodeport
spec:
  type: NodePort
  selector:
    app: web-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30080

Materi Praktis

Studi Kasus Sederhana: Aplikasi Tetap Hidup Meski Satu Pod Dihapus

Skenario ini yang biasanya didemonstrasikan dalam bentuk video/reels: aplikasi tetap bisa diakses meski salah satu Pod sengaja dihapus.

Terapkan Deployment dengan 3 replika seperti contoh di atas.
Cek Pod yang berjalan: kubectl get pods -l app=web-app
Terapkan Service ClusterIP atau NodePort agar aplikasi bisa diakses.
Hapus salah satu Pod secara sengaja: kubectl delete pod <nama-salah-satu-pod>
Amati bahwa:
- ReplicaSet segera membuat Pod baru untuk menggantikan Pod yang dihapus.
- Selama proses ini, akses melalui Service tidak terputus total, karena trafik tetap diarahkan ke Pod-Pod lain yang masih sehat.
Verifikasi ulang jumlah Pod kembali ke 3: kubectl get pods -l app=web-app

Studi kasus ini membuktikan nilai inti Kubernetes: self-healing (Deployment/ReplicaSet) dikombinasikan dengan stable networking (Service).

Best Practice

Selalu gunakan label yang konsisten dan bermakna (misalnya app, tier, env) agar selector Deployment dan Service mudah dikelola.
Tetapkan resources.requests dan resources.limits pada setiap container agar scheduler bekerja optimal dan menghindari resource starvation.
Gunakan readiness probe dan liveness probe agar Service hanya mengarahkan trafik ke Pod yang benar-benar siap menerima request.
Untuk lingkungan produksi, hindari NodePort sebagai akses utama publik; gunakan LoadBalancer atau Ingress Controller.
Simpan manifest YAML di dalam version control (Git) agar perubahan konfigurasi mudah dilacak (praktik GitOps).

Tutorial Step-by-Step: Deploy dari Nol

Pastikan cluster Kubernetes aktif (bisa Minikube, kind, atau cluster cloud).
Buat file deployment.yaml berisi manifest Deployment seperti contoh di atas.
Terapkan ke cluster: kubectl apply -f deployment.yaml
Buat file service.yaml berisi manifest Service.
Terapkan Service: kubectl apply -f service.yaml
Cek status Deployment: kubectl get deployments
Cek status Service dan catat ClusterIP/NodePort-nya: kubectl get services
Uji akses aplikasi sesuai tipe Service yang digunakan (port-forward untuk ClusterIP, atau langsung akses IP Node untuk NodePort). kubectl port-forward service/web-app-service 8080:80

Kesalahan yang Sering Terjadi

Kesalahan	Penyebab	Dampak	Cara Mengatasi
Service tidak menemukan Pod	`selector` di Service tidak cocok dengan `labels` di Pod	Trafik tidak sampai ke Pod (endpoint kosong)	Samakan persis nilai label antara Deployment dan Service
`targetPort` salah	Port container berbeda dari yang ditulis di Service	Koneksi refused/timeout	Sesuaikan `targetPort` dengan `containerPort` pada Deployment
Rolling update menyebabkan downtime singkat	Tidak ada readiness probe	Trafik sempat diarahkan ke Pod yang belum siap	Tambahkan `readinessProbe` pada container
Replika tidak sesuai harapan	Resource node tidak cukup (CPU/memory)	Pod berstatus `Pending`	Cek `kubectl describe pod` dan sesuaikan resource request atau tambah kapasitas node
Menggunakan NodePort di produksi publik	Kurang memahami perbedaan tipe Service	Keamanan dan skalabilitas terbatas	Gunakan LoadBalancer atau Ingress Controller

Tips dan Rekomendasi

Gunakan kubectl describe service <nama-service> untuk memeriksa apakah Endpoints sudah terisi Pod yang sesuai.
Manfaatkan kubectl rollout status deployment/<nama-deployment> untuk memantau progres rolling update secara real-time.
Untuk debugging cepat, kubectl get endpoints <nama-service> akan menunjukkan apakah Service benar-benar terhubung ke Pod.
Pertimbangkan Helm chart untuk mengelola manifest Deployment dan Service yang kompleks agar lebih terstruktur dan mudah di-versioning.

Kesimpulan

Deployment dan Service adalah dua fondasi utama dalam mengelola aplikasi di Kubernetes. Deployment menjaga agar jumlah Pod selalu sesuai target dan memungkinkan update aplikasi tanpa downtime, sementara Service memastikan aplikasi tetap dapat diakses secara stabil meski Pod di baliknya terus berganti.

Poin penting yang perlu diingat:

Deployment mengelola siklus hidup Pod melalui ReplicaSet.
Service menghubungkan trafik ke Pod menggunakan label selector, bukan IP statis.
Label yang konsisten adalah kunci agar Deployment dan Service saling terhubung dengan benar.
Kombinasi keduanya menghasilkan sistem yang self-healing dan highly available.

Frequently Asked Questions (FAQ)

Pertanyaan: Apa perbedaan utama antara Deployment dan Service di Kubernetes? Jawaban: Deployment mengelola siklus hidup dan jumlah replika Pod, sedangkan Service menyediakan akses jaringan yang stabil ke Pod-Pod tersebut.

Pertanyaan: Apakah Service bisa berjalan tanpa Deployment? Jawaban: Bisa secara teknis, selama ada Pod dengan label yang sesuai selector. Namun tanpa Deployment, Pod tidak akan dibuat ulang otomatis jika mati.

Pertanyaan: Kapan sebaiknya menggunakan NodePort dibanding LoadBalancer? Jawaban: NodePort cocok untuk pengujian lokal atau on-premise sederhana, sedangkan LoadBalancer lebih sesuai untuk produksi di lingkungan cloud.

Pertanyaan: Mengapa Pod baru tidak langsung menerima trafik dari Service? Jawaban: Biasanya karena readiness probe belum “sukses”, sehingga Kubernetes menganggap Pod belum siap menerima request.

Pertanyaan: Bagaimana cara memastikan Service sudah terhubung dengan Pod yang benar? Jawaban: Jalankan kubectl get endpoints <nama-service> untuk melihat daftar Pod yang terhubung ke Service tersebut.

Sudah paham perbedaan Deployment dan Service di Kubernetes? Yuk share pengalamanmu di kolom komentar

pernahkah Pod-mu tiba-tiba mati dan aplikasi tetap jalan berkat Service? Jangan lupa bagikan artikel ini ke rekan tim DevOps-mu, dan pantau terus konten seputar Kubernetes, Docker, dan Cloud Infrastructure lainnya di website ini!