Kamu sedang menampilkan dokumentasi untuk Kubernetes versi: v1.28
Kubernetes v1.28 dokumentasi sudah tidak dirawat lagi. Versi yang kamu lihat ini hanyalah snapshot statis. Untuk dokumentasi terkini, lihat versi terbaru.
Siklus Hidup Pod
Halaman ini menjelaskan siklus hidup sebuah Pod
Fase Pod
Field status
dari sebuah Pod merupakan sebuah objek PodStatus, yang memiliki sebuah field phase
.
Fase dari sebuah Pod adalah sesuatu yang sederhana, ringkasan yang lebih tinggi tentang Pod dalam siklus hidupnya. Fase ini tidak ditujukan sebagai sebuah kesimpulan yang luas dari observasi suatu kontainer atau state suatu Pod, serta tidak ditujukan sebagai state machine yang luas.
Jumlah dan arti dari nilai-nilai fase Pod dijaga ketat. Selain yang ada dalam dokumentasi ini, tidak perlu berasumsi mengenai Pod telah diberikan nilai phase
.
Berikut adalah nilai yang mungkin diberikan untuk suatu phase
:
Nilai | Deskripsi |
---|---|
Pending | Pod telah disetujui oleh sistem Kubernetes, tapi ada satu atau lebih image kontainer yang belum terbuat. Ini termasuk saat sebelum dijadwalkan dan juga saat mengunduh image melalui jaringan, yang mungkin butuh beberapa waktu. |
Running | Pod telah terikat ke suatu node, dan semua kontainer telah terbuat. Setidaknya ada 1 kontainer yang masih berjalan, atau dalam proses memulai atau restart. |
Succeeded | Semua kontainer di dalam Pod sudah berhasil dihentikan, dan tidak akan dilakukan restart. |
Failed | Semua kontainer dalan suatu Pod telah dihentikan, dan setidaknya ada satu kontainer yang terhenti karena kegagalan. Itu merupakan kontainer yang keluar dengan kode status bukan 0 atau dihentikan oleh sistem. |
Unknown | State suatu Pod tidak dapat diperoleh karena suatu alasan, biasanya karena kesalahan dalam komunikasi dengan host yang digunakan Pod tersebut. |
Kondisi Pod
Suatu Pod memiliki sebuah PodStatus, yang merupakan array dari PodConditions yang telah atau belum dilewati oleh Pod. Setiap elemen dari array PodConditions mungkin memiliki enam field berikut:
Field
lastProbeTime
memberikan nilai timestamp yang menandakan kapan terakhir kali kondisi kondisi Pod diperiksa.Field
lastTransitionTime
memberikan nilai timestamp yang menandakan kapan terakhir kali Pod berubah status ke status lain.Field
message
adalah pesan yang bisa dibaca manusia yang mengidikasikan detail dari suatu transisi.Field
reason
adalah suatu alasan yang unik, satu kata, ditulis secara CamelCase untuk kondisi transisi terakhir.Field
status
adalah sebuah kata dengan kemungkinan nilainya berupa "True
", "False
", dan "Unknown
".Field
type
adalah sebuah kata yang memiliki kemungkinan nilai sebagai berikut:PodScheduled
: Pod telah dijadwalkan masuk ke node;Ready
: Pod sudah mampu menerima request masuk dan seharusnya sudah ditambahkan ke daftar pembagian beban kerja untuk servis yang sama;Initialized
: Semua init containers telah berjalan sempurna.Unschedulable
: scheduler belum dapat menjadwalkan Pod saat ini, sebagai contoh karena kekurangan resources atau ada batasan-batasan lain.ContainersReady
: Semua kontainer di dalam Pod telah siap.
Pemeriksaan Kontainer
Sebuah Probe adalah sebuah diagnosa yang dilakukan secara berkala oleh kubelet dalam suatu kontainer. Untuk melakukan diagnosa, kubelet memanggil sebuah Handler yang diimplementasikan oleh kontainer. Ada 3 tipe Handler yang tersedia, yaitu:
ExecAction: Mengeksekusi perintah tertentu di dalam kontainer. Diagnosa dikatakan berhasil jika perintah selesai dengan kode status 0.
TCPSocketAction: Melakukan pengecekan TCP terhadap alamat IP kontainer dengan port tertentu. Diagnosa dikatakan berhasil jika port tersebut terbuka.
HTTPGetAction: Melakukan sebuah request HTTP Get terhadap alamat IP kontainer dengan port dan path tertentu. Diagnosa dikatakan berhasil jika responnya memiliki kode status lebih besar atau sama dengan 200 dan kurang dari 400.
Setiap pemeriksaan akan menghasilkan salah satu dari tiga hasil berikut:
- Success: Kontainer berhasil melakukan diagnosa.
- Failure: Kontainer gagal melakukan diagnosa.
- Unknown: Gagal melakukan diagnosa, sehingga tidak ada aksi yang harus dilakukan.
Kubelet dapat secara optimal melakukan dan bereaksi terhadap dua jenis pemeriksaan yang sedang berjalan pada kontainer, yaitu:
livenessProbe
: Ini menunjukkan apakah kontainer sedang berjalan. Jika tidak berhasil melakukan pemeriksaan terhadap liveness dari kontainer, maka kubelet akan mematikan kontainer, dan kontainer akan mengikuti aturan dari restart policy. Jika kontainer tidak menyediakan pemeriksaan terhadap liveness, maka nilai dari state adalahSuccess
.readinessProbe
: Ini menunjukan apakah kontainer sudah siap melayani request. Jika tidak berhasil melakukan pemeriksaan terhadap kesiapan dari kontainer, maka endpoints controller akan menghapus alamat IP Pod dari daftar semua endpoint untuk servis yang sama dengan Pod. Nilai awal state sebelum jeda awal adalahFailure
. Jika kontainer tidak menyediakan pemeriksaan terhadap readiness, maka nilai awal state adalahSuccess
.
Kapan sebaiknya menggunakan pemeriksaan terhadap liveness atau readiness?
Jika proses dalam kontainer mungkin gagal yang dikarenakan menghadapi suatu masalah
atau menjadi tidak sehat, maka pemeriksaan terhadap liveness tidak diperlukan.
Kubelet akan secara otomatis melakukan aksi yang tepat mengikuti restartPolicy
dari Pod.
Jika kamu ingin kontainer bisa dimatikan dan dijalankan ulang ketika gagal melakukan
pemeriksaan, maka tentukan pemeriksaan liveness dan tentukan nilai restartPolicy
sebagai Always
atau OnFailure
.
Jika kamu ingin mulai mengirim traffic ke Pod hanya ketika pemeriksaan berhasil, maka tentukan pemeriksaan readiness. Dalam kasus ini, pemeriksaan readiness mungkin akan sama dengan pemeriksaan liveness, tapi keberadaan pemeriksaan readiness dalam spec berarti Pod akan tetap dijalankan tanpa menerima traffic apapun dan akan mulai menerima traffic ketika pemeriksaan yang dilakukan mulai berhasil. Jika kontainermu dibutuhkan untuk tetap berjalan ketika loading data yang besar, file konfigurasi, atau melakukan migrasi ketika startup, maka tentukanlah pemeriksaan readiness.
Jika kamu ingin kontainermu dalam mematikan dirinya sendiri, kamu dapat menentukan suatu pemeriksaan readiness yang melakukan pengecekan terhadap endpoint untuk readiness. endpoint tersebut berbeda dengan endpoint untuk pengecekan liveness.
Perlu dicatat, jika kamu hanya ingin bisa menutup request ketika Pod sedang dihapus maka kamu tidak perlu menggunakan pemeriksaan readiness. Dalam penghapusan, Pod akan secara otomatis mengubah state dirinya menjadi unready tanpa peduli apakah terdapat pemeriksaan readiness atau tidak. Pod tetap ada pada state unready selama menunggu kontainer dalam Pod berhenti.
Untuk informasi lebih lanjut mengenai pengaturan pemeriksaan liveness atau readiness, lihat bagian Konfigurasi Liveness dan Readiness Probe.
Status Pod dan Kontainer
Untuk informasi lebih mendalam mengenai status Pod dan kontainer, silakan lihat PodStatus dan ContainerStatus. Mohon diperhatikan, informasi tentang status Pod bergantung pada ContainerState.
State Kontainer
Ketika Pod sudah ditempatkan pada suatu node oleh scheduler, kubelet mulai membuat kontainer menggunakan runtime kontainer.
Ada tiga kemungkinan state untuk suatu kontainer, yaitu Waiting, Running, dan Terminated.
Untuk mengecek state suatu kontainer, kamu bisa menggunakan perintah kubectl describe pod [NAMA_POD]
.
State akan ditampilkan untuk masing-masing kontainer dalam Pod tersebut.
Waiting
: Merupakan state default dari kontainer. Jika state kontainer bukan Running atau Terminated, berarti dalam Wating state. Suatu kontainer dalam Waiting state akan tetap menjalan operasi-operasi yang dibutuhkan, misalnya mengunduh images, mengaplikasikan Secrets, dsb. Bersamaan dengan state ini, sebuah pesan dan alasan tentang state akan ditampilkan untuk memberi informasi lebih.... State: Waiting Reason: ErrImagePull ...
Running
: Menandakan kontainer telah berjalan tanpa masalah. Setelah kontainer masuk ke state Running, jika terdapat hookpostStart
maka akan dijalankan. State ini juga menampilkan waktu ketika kontainer masuk ke state Running.... State: Running Started: Wed, 30 Jan 2019 16:46:38 +0530 ...
Terminated
: Menandakan kontainer telah menyelesaikan "tugasnya". Kontainer akan menjadi state ini ketika telah menyelesaikan eksekusi atau terjadi kesalahan. Terlepas dari itu, sebuah alasan dan exit code akan ditampilkan, bersama dengan waktu kontainer mulai dijalankan dan waktu berhenti. Sebelum kontainer masuk ke state Terminated, jika terdapatpreStop
hook maka akan dijalankan.... State: Terminated Reason: Completed Exit Code: 0 Started: Wed, 30 Jan 2019 11:45:26 +0530 Finished: Wed, 30 Jan 2019 11:45:26 +0530 ...
Pod readiness gate
Kubernetes v1.14 [stable]
Dalam rangka menambahkan ekstensibilitas terhadap kesiapan Pod dengan menggunakan
injeksi umpan balik tambahan atau sinyal ke dalam PodStatus
,
Kubernetes 1.11 memperkenalkan sebuah fitur bernama Pod ready++.
Kamu dapat menggunakan field baru ReadinessGate
dalam sebuah PodSpec
untuk
menunjukan kondisi tambahan yang akan dievaluasi untuk kesiapan Pod. Jika Kubernetes
tidak dapat menemukan kondisi pada field status.conditions
dalam suatu Pod,
maka statusnya akan secara otomatis menjadi False
. Berikut adalah contoh pemakaiannya:
Kind: Pod
...
spec:
readinessGates:
- conditionType: "www.example.com/feature-1"
status:
conditions:
- type: Ready # ini adalah PodCondition yang telah tersedia
status: "False"
lastProbeTime: null
lastTransitionTime: 2018-01-01T00:00:00Z
- type: "www.example.com/feature-1" # sebuah PodCondition tambahan
status: "False"
lastProbeTime: null
lastTransitionTime: 2018-01-01T00:00:00Z
containerStatuses:
- containerID: docker://abcd...
ready: true
...
Kondisi Pod yang baru harus memenuhi format label pada Kubernetes.
Sejak perintah kubectl patch
belum mendukung perubahan status objek, kondisi Pod yang baru harus mengubah melalui aksi PATCH
dengan menggunakan
salah satu dari KubeClient libraries.
Dengan diperkenalkannya kondisi Pod yang baru, sebuah Pod akan dianggap siap hanya jika memenuhi dua syarat berikut:
- Semua kontainer dalam Pod telah siap.
- Semua kontainer yang diatur dalam
ReadinessGates
bernilai "True
".
Untuk memfasilitasi perubahan tersebut terhadap evaluasi kesiapan Pod, dibuatkan sebuah kondisi Pod baru yaitu ContainerReady
,
untuk dapat menangani kondisi Pod Ready
yang sudah ada.
Dalam K8s 1.11, sebagai fitur alpha, fitur "Pod Ready++" harus diaktifkan melalui pengaturan
fitur gate pada PodReadinessGates
.
Dalam K8s 1.12, fitur tersebut sudah diaktifkan dari awal.
Aturan Menjalankan Ulang
Sebuah PodSpec memiliki field restartPolicy
dengan kemungkinan nilai berupa Always, OnFailure, dan Never.
Nilai awalnya berupa Always. restartPolicy
akan berlaku untuk semua kontainer dalam Pod.
Kontainer yang mati dan dijalankan ulang oleh kubelet akan dijalankan ulang dengan jeda waktu yang ekponensial (10s, 20s, 40s, ...)
dengan batas atas senilai lima menit. Jeda waktu ini akan diatur ulang setelah sukses berjalan selama 10 menit.
Sesuai dengan diskusi pada dokumen Pod,
setelah masuk ke suatu node, sebuah Pod tidak akan pindah ke node lain.
Umur Pod
Secara umum, Pod tidak hilang sampai ada yang menghapusnya. Ini mungkin dihapus oleh orang atau pengontrol.
Satu pengecualian untuk aturan ini adalah Pod dengan phase
bernilai Succeeded atau Failed untuk waktu
beberapa lama yang akan berakhir dan secara otomatis akan dihapus.
(diatur dalam terminated-pod-gc-threshold
pada master)
Tiga tipe pengontrol yang tersedia yaitu:
Menggunakan sebuah Job untuk Pod yang diharapkan akan berakhir, sebagai contoh, penghitungan dalam jumlah banyak. Jobs hanyak cocok untuk Pod dengan
restartPolicy
yang bernilai OnFailure atau Never.Menggunakan sebuah ReplicationController, ReplicaSet, atau Deployment untuk Pod yang tidak diharapkan untuk berakhir, sebagai contoh, web servers. ReplicationControllers hanya cocok digunakan pada Pod dengan
restartPolicy
yang bernilai Always.Menggunakan sebuah DaemonSet untuk Pod yang akan berjalan hanya satu untuk setiap mesin, karena menyediakan servis yang spesifik untuk suatu mesin.
Ketiga tipe pengontrol ini memiliki sebuah PodTemplate. Direkomdasikan untuk membuat pengontrol yang sesuai dan membiarkan ini membuat Pod, daripada membuat Pod sendiri secara langsung. Karena Pod itu sendiri tidak tahan terhadap gagalnya suatu mesin, namun pengontrol tahan.
Jika node mati atau sambungannya terputus dari klaster, Kubernetes mengatur
phase
dari semua Pod pada node yang mati untuk menjadi Failed.
Contoh
Contoh Liveness Probe tingkat lanjut
Liveness probe dieksekusi oleh kubelet, jadi semua permintaan akan dilakukan di dalam namespace jaringan kubelet.
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-http
spec:
containers:
- args:
- /server
image: registry.k8s.io/liveness
livenessProbe:
httpGet:
# ketika "host" tidak ditentukan, "PodIP" akan digunakan
# host: my-host
# ketika "scheme" tidak ditentukan, _scheme_ "HTTP" akan digunakan. Hanya "HTTP" and "HTTPS" yang diperbolehkan
# scheme: HTTPS
path: /healthz
port: 8080
httpHeaders:
- name: X-Custom-Header
value: Awesome
initialDelaySeconds: 15
timeoutSeconds: 1
name: liveness
Contoh State
Pod sedang berjalan dan memiliki sebuah kontainer. Kontainer berhenti dengan sukses.
- Mencatat event penyelesaian.
- Jika nilai
restartPolicy
adalah:- Always: Jalankan ulang kontainer; nilai
phase
Pod akan tetap Running. - OnFailure: nilai
phase
Pod akan berubah menjadi Succeeded. - Never: nilai
phase
Pod akan berubah menjadi Succeeded.
- Always: Jalankan ulang kontainer; nilai
Pod sedang berjalan dan memiliki sebuah kontainer. Kontainer berhenti dengan kegagalan.
- Mencatat event kegagalan.
- Jika nilai
restartPolicy
adalah:- Always: Jalankan ulang kontainer, nilai
phase
Pod akan tetap Running. - OnFailure: Jalankan ulang kontainer, nilai
phase
Pod akan tetap Running. - Never: nilai
phase
Pod akan menjadi Failed.
- Always: Jalankan ulang kontainer, nilai
Pod sedang berjalan dan memiliki dua kontainer. Kontainer pertama berhenti dengan kegagalan.
- Mencatat event kegagalan.
- Jika nilai
restartPolicy
adalah:- Always: Jalankan ulang kontainer, nilai
phase
Pod akan tetap Running. - OnFailure: Jalankan ulang kontainer, nilai
phase
Pod akan tetap Running. - Never: Tidak akan menjalankan ulang kontainer, nilai
phase
Pod akan tetap Running.
- Always: Jalankan ulang kontainer, nilai
- Jika kontainer pertama tidak berjalan dan kontainer kedua berhenti:
- Mencatat event kegagalan.
- Jika nilai
restartPolicy
adalah:- Always: Jalankan ulang kontainer, nilai
phase
Pod akan tetap Running. - OnFailure: Jalankan ulang kontainer, nilai
phase
Pod akan tetap Running. - Never: nilai
phase
Pod akan menjadi Failed.
- Always: Jalankan ulang kontainer, nilai
Pod sedang berjalan dan memiliki satu kontainer. Kontainer berhenti karena kehabisan memory.
- Kontainer diberhentikan dengan kegagalan.
- Mencatat kejadian kehabisan memory (OOM)
- Jika nilai
restartPolicy
adalah:- Always: Jalankan ulang kontainer, nilai
phase
Pod akan tetap Running. - OnFailure: Jalankan ulang kontainer, nilai
phase
Pod akan tetap Running. - Never: Mencatat kejadian kegagalan, nilai
phase
Pod akan menjadi Failed.
- Always: Jalankan ulang kontainer, nilai
Pod sedang berjalan dan sebuah disk mati.
- Menghentikan semua kontainer.
- Mencatat kejadian yang sesuai.
- Nilai
phase
Pod menjadi Failed. - Jika berjalan menggunakan pengontrol, maka Pod akan dibuat ulang di tempat lain.
Pod sedang berjalan, dan node mengalami segmented out.
- Node pengontrol menunggu sampai suatu batas waktu.
- Node pengontrol mengisi nilai
phase
Pod menjadi Failed. - Jika berjalan menggunakan pengontrol, maka Pod akan dibuat ulang di tempat lain.
Selanjutnya
Dapatkan pengalaman langsung mengenai penambahan handlers pada kontainer lifecycle events.
Dapatkan pengalaman langsung mengenai pengaturan liveness dan readiness probes.
Pelajari lebih lanjut mengenai lifecycle hooks pada kontainer.