Pod

Pod adalah unit penjadwalan terkecil di Kubernetes, yaitu sekumpulan satu atau lebih container yang berbagi jaringan, penyimpanan, dan aturan cara berjalan. Topik ini membahas alasan Pod dirancang sebagai unit yang lebih besar daripada satu container, fase-fase pada siklus hidupnya, serta manifest pertama yang diterapkan ke kluster. Setiap konsep disertai berkas contoh dan skrip pembacaannya, sehingga struktur Pod dapat diperiksa langsung dari keluaran program.

Mengapa Pod bukan container tunggal#

Kubernetes tidak menjadwalkan container satu per satu, melainkan menjadwalkan Pod. Seluruh container di dalam satu Pod dijamin berada pada Node yang sama, dijalankan dan dihentikan sebagai satu kesatuan, serta tidak dapat dipisahkan ke Node yang berbeda. Apabila Node tujuan tidak mampu menampung Pod, seluruh container dalam Pod tersebut menunggu bersama pada fase Pending. Penjadwalan atomik semacam ini tidak dapat dicapai apabila setiap container dikelola secara terpisah.

Container dalam satu Pod berbagi tiga lingkup penting. Pertama, jaringan: Pod menerima satu alamat IP, dan seluruh container di dalamnya berbagi ruang port tersebut, sehingga container dapat saling memanggil melalui localhost seolah-olah berjalan pada satu mesin. Kedua, penyimpanan: volume yang dideklarasikan pada tingkat Pod dapat dipasang ke salah satu container atau ke semuanya. Ketiga, konfigurasi: aturan seperti restartPolicy, permintaan sumber daya, dan variabel lingkungan diatur pada lingkup Pod.

Sifat tersebut menjadikan Pod sebagai model mesin logis bagi satu aplikasi. Container utama menjalankan fungsi inti, sedangkan container penolong yang kebutuhannya melekat pada fungsi inti dapat ditambahkan dalam Pod yang sama. Sebaliknya, komponen yang siklus hidup dan penskalaannya berbeda, misalnya web server dan database, dipisahkan ke Pod yang berbeda agar masing-masing dapat dijadwalkan dan diganti secara mandiri.

Siklus hidup Pod#

Sejak dibuat sampai dihapus, Pod melewati fase-fase yang dilaporkan API server. Fase adalah status tingkat tinggi yang menggambarkan posisi Pod dalam siklus hidupnya, bukan status tiap container secara rinci. Diagram berikut merangkum perpindahan antarfase tersebut.

Empat fase utamanya adalah berikut:

• Pending: Pod telah diterima kluster, tetapi belum semua container berjalan, misalnya image masih diunduh atau penjadwalan belum tuntas.
• Running: Pod terikat pada sebuah Node dan semua container telah dibuat, baik sedang berjalan maupun sedang dimulai ulang.
• Succeeded: semua container berhenti dengan kode keluar nol dan tidak akan dijalankan lagi.
• Failed: semua container berhenti dan minimal satu container berhenti dengan kode keluar bukan nol.

Perilaku restart ditentukan oleh restartPolicy pada spesifikasi Pod. Nilai Always, yang menjadi default, membuat kubelet menghidupkan kembali container yang berhenti tanpa memandang kode keluarnya, sehingga Pod jarang mencapai fase Succeeded. Nilai OnFailure menghidupkan ulang hanya container yang berhenti karena gagal, sedangkan Never membiarkan Pod berakhir pada fase Succeeded atau Failed. Selain fase, Pod juga melaporkan kondisi yang lebih rinci seperti PodScheduled, ContainersReady, dan Ready, yang digunakan Service untuk menilai apakah Pod boleh menerima trafik.

Manifest Pod pertama#

Manifest adalah berkas YAML yang mendeklarasikan keadaan yang diinginkan untuk sebuah objek. Manifest pertama yang dibuat adalah Pod dengan satu container web server berbasis image nginx. Berkas pod.yaml berikut menyimpan manifest tersebut dan dapat disalin langsung dari bundle topik ini.

apiVersion: v1
kind: Pod
metadata:
  name: web-statis
  labels:
    app: web
    komponen: frontend
spec:
  containers:
    - name: web
      image: nginx:1.27
      ports:
        - containerPort: 80

Kunci apiVersion dan kind menyatakan bahwa objek ini adalah Pod pada API versi v1. Kunci metadata menamai Pod sebagai web-statis dan melampirkan dua label, sedangkan kunci spec mendeklarasikan daftar container beserta image dan portnya. Nama pada metadata bersifat unik di dalam namespace tempat Pod dibuat, sehingga dua Pod bernama sama tidak dapat hidup berdampingan di satu namespace.

Struktur manifest tersebut dapat dibaca ulang secara terprogram untuk memastikan tidak ada kesalahan pengetikan pada kunci pentingnya. Skrip Python berikut mem-parse pod.yaml menggunakan PyYAML, kemudian mencetak struktur kuncinya.

"""Membaca pod.yaml dan menampilkan struktur kuncinya."""
import yaml

with open("pod.yaml") as berkas:
    manifest = yaml.safe_load(berkas)

print(f"kind       : {manifest['kind']}")
print(f"apiVersion : {manifest['apiVersion']}")
print(f"nama pod   : {manifest['metadata']['name']}")
print(f"label      : {manifest['metadata']['labels']}")

container = manifest["spec"]["containers"][0]
print(f"container  : {container['name']} (image {container['image']})")
print(f"port       : {container['ports'][0]['containerPort']}")

kind       : Pod
apiVersion : v1
nama pod   : web-statis
label      : {'app': 'web', 'komponen': 'frontend'}
container  : web (image nginx:1.27)
port       : 80

Dalam praktiknya, manifest diterapkan ke kluster melalui perintah kubectl. Perintah berikut memuat pod.yaml ke dalam API server, kemudian menampilkan daftar Pod yang berjalan. Keluarannya adalah contoh dari kluster lokal, dan nilainya berbeda antarlingkungan.

# tidak-dijalankan
# menerapkan manifest pod.yaml ke kluster
kubectl apply -f pod.yaml
# menampilkan daftar pod beserta statusnya
kubectl get pods

pod/web-statis created

NAME         READY   STATUS    RESTARTS   AGE
web-statis   1/1     Running   0          10s

Pod sebagai objek yang mudah diganti#

Pod tidak dirancang sebagai objek yang tahan lama. Apabila Pod dihapus, apabila Node tempatnya berjalan mati, atau apabila Pod diusir karena kehabisan sumber daya, Pod tersebut tidak dibuat ulang secara otomatis oleh Kubernetes. Nama baru dan alamat IP baru muncul setiap kali Pod dibuat lagi, sehingga Pod tunggal tidak layak menjadi landasan layanan. Kelangsungan layanan diperoleh dengan menjalankan beberapa Pod yang identik, dan pembuatan serta pemeliharaannya diserahkan kepada controller seperti Deployment.

Pengelolaan Pod secara langsung tetap berguna untuk percobaan dan penelusuran masalah. Perintah kubectl describe pod menampilkan event yang menjelaskan alasan Pod macet pada fase tertentu, sedangkan kubectl logs membaca keluaran container yang bersangkutan. Untuk beban kerja yang bersifat jangka panjang, manifest Pod jarang ditulis berdiri sendiri, melainkan menjadi template di dalam Deployment, yaitu controller yang memelihara jumlah replika Pod.

Ringkasan#

• Pod adalah unit penjadwalan atomik: container di dalamnya berbagi satu alamat IP, ruang port, dan volume, serta selalu ditempatkan pada Node yang sama.
• Fase Pod bergerak dari Pending menuju Running, lalu berakhir di Succeeded atau Failed, dengan perilaku restart yang ditentukan restartPolicy.
• Manifest Pod mendeklarasikan keadaan yang diinginkan melalui empat kunci tingkat atas, yaitu apiVersion, kind, metadata, dan spec.
• Pod mudah diganti dan tidak dibuat ulang secara otomatis, sehingga kelangsungan layanan ditangani controller di atas Pod.

Referensi#

• Pods — Kubernetes Docs — Konsep Pod, lingkup yang dibagikan antarcontainer, dan peran Pod sebagai unit penjadwalan.
• Pod Lifecycle — Kubernetes Docs — Fase Pod, kondisi status, penjadwalan, dan perilaku restart container.
• Pod v1 — Kubernetes API Reference — Definisi lengkap field Pod pada API v1 beserta tipe datanya.