Istilah Dasar Kubernetes, Pod, Deployment, dan Service

Seorang developer yang sudah lancar memakai Docker biasanya membuka dokumentasi Kubernetes untuk pertama kali dan langsung tenggelam. Ia ingin menjalankan satu aplikasi web, tapi yang ditemui adalah pod, ReplicaSet, deployment, service, ingress, dan selector, semuanya dalam satu halaman. Padahal sebagian besar pekerjaan sehari-hari hanya memakai segelintir istilah itu.

Kabar baiknya, tiga istilah inti sudah menjelaskan hampir semuanya: pod menjalankan container, deployment menjaga pod tetap hidup dan memperbaruinya, dan service memberi alamat tetap untuk menjangkau pod. Sisanya adalah pelengkap yang bisa dipelajari sambil jalan.

Peta besarnya: cluster, node, dan control plane

Cluster adalah sekumpulan mesin yang dikelola sebagai satu kesatuan. Setiap mesin di dalamnya disebut node, bisa berupa VPS, server fisik, atau mesin virtual.

Di dalam cluster ada control plane, yaitu "otak" yang menerima perintah, menyimpan keadaan cluster, dan memutuskan pod berjalan di node mana. Node pekerja menjalankan kubelet, agen yang memastikan container di node itu sesuai dengan yang diminta control plane.

Kamu berbicara dengan cluster lewat kubectl, alat baris perintah yang mengirim permintaan ke API server. Perintah seperti kubectl get pods atau kubectl apply -f app.yaml akan sangat sering kamu ketik.

Satu konsep lagi yang membedakan Kubernetes dari Docker biasa: Kubernetes bersifat deklaratif. Kamu tidak menyuruh "jalankan tiga container", tapi menulis "keadaan yang diinginkan adalah tiga replika". Kubernetes terus membandingkan keadaan nyata dengan keinginan itu dan memperbaiki selisihnya, misalnya membuat pod baru bila ada yang mati.

Apa itu pod di Kubernetes?

Pod adalah unit terkecil yang bisa dijalankan Kubernetes. Satu pod berisi satu container atau lebih yang selalu ditempatkan bersama di node yang sama, berbagi alamat IP, dan bisa berbagi volume. Dalam praktik, kebanyakan pod hanya berisi satu container aplikasi. Container tambahan (sering disebut sidecar) dipakai untuk tugas pendamping, seperti mengirim log atau menjadi proxy.

Sifat terpenting pod: sementara. Pod tidak dirancang untuk hidup selamanya, dan data yang ditulis ke filesystem container ikut hilang bila tidak memakai volume. Pod bisa dihapus, dipindah, atau diganti kapan saja, dan pod pengganti mendapat nama serta IP baru. Karena itu, hampir tidak ada yang membuat pod secara langsung. Pod dibuat dan dirawat oleh objek lain, terutama deployment.

Deployment, penjaga jumlah dan versi pod

Deployment menyatakan aplikasi apa yang dijalankan, dari image mana, dan berapa replika. Di baliknya, deployment membuat ReplicaSet yang tugasnya menjaga jumlah pod tetap sesuai angka itu.

Kekuatan deployment terasa saat update. Bila kamu mengganti versi image, deployment membuat ReplicaSet baru dan mengganti pod lama secara bertahap (rolling update), sehingga aplikasi tetap melayani selama proses berjalan. Bila versi baru bermasalah, kubectl rollout undo deployment/web mengembalikannya ke versi sebelumnya.

Deployment juga mengatur seberapa cepat penggantian itu, misalnya berapa pod boleh tidak tersedia sekaligus, lewat bagian strategy di manifest.

Untuk aplikasi yang butuh identitas tetap dan penyimpanan per replika, seperti database, Kubernetes menyediakan StatefulSet. Untuk agen yang harus berjalan di setiap node, seperti pengumpul log, ada DaemonSet. Keduanya bekerja dengan prinsip yang mirip dengan deployment.

Kenapa butuh service bila sudah ada pod?

Karena IP pod selalu berubah, aplikasi lain tidak bisa mengandalkannya. Service menyelesaikan masalah ini dengan memberi satu alamat IP virtual dan nama DNS yang tetap, lalu meneruskan lalu lintas ke pod-pod yang cocok. Di dalam cluster, aplikasi lain cukup memanggil nama service, misalnya http://web.

Service menemukan pod lewat label dan selector. Label adalah pasangan kunci-nilai yang ditempel pada objek, misalnya app: web. Selector pada service berbunyi "teruskan ke semua pod berlabel app: web". Label inilah benang merah yang menghubungkan deployment, pod, dan service.

Ada beberapa jenis service:

Untuk website, biasanya service ClusterIP dipadukan dengan Ingress, aturan yang memetakan domain dan path ke service, dijalankan oleh ingress controller. Perkembangan terbaru soal pilihan ingress controller dibahas di Ingress NGINX pensiun dan alternatifnya.

Contoh yang menyatukan semuanya

Manifest berikut membuat deployment dengan dua replika Nginx dan service yang mengarah ke sana:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.27
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80

Simpan sebagai web.yaml, jalankan kubectl apply -f web.yaml, lalu lihat hasilnya dengan kubectl get deployment,pods,service. Perhatikan label app: web muncul tiga kali: di selector deployment, di template pod, dan di selector service. Bila salah satunya tidak cocok, service tidak menemukan pod dan permintaan tidak sampai ke aplikasi.

Beberapa istilah lain akan segera kamu temui. Namespace memisahkan objek dalam satu cluster, misalnya staging dan produksi. ConfigMap menyimpan konfigurasi, sedangkan Secret menyimpan data sensitif seperti password; isi Secret secara bawaan hanya di-encode base64, bukan dienkripsi, jadi akses ke objek ini tetap harus dibatasi. PersistentVolumeClaim adalah permintaan penyimpanan yang tetap ada meski pod diganti.

Untuk mencoba semua ini tanpa biaya besar, cluster kecil di satu atau dua VPS dengan K3s sudah cukup, caranya ada di membuat cluster Kubernetes ringan dengan K3s. Sebelum memutuskan memakai Kubernetes untuk produksi, timbang juga alternatif yang lebih sederhana di Docker Swarm atau Kubernetes untuk tim kecil.

Ringkasnya, pod menjalankan container, deployment menjaga jumlah dan versinya, dan service memberi alamat yang tidak berubah, sementara label mengikat ketiganya. Begitu tiga hal ini terasa wajar, istilah Kubernetes lain tinggal variasi dari pola yang sama.