Siklus Hidup Pod

Halaman ini menjelaskan siklus hidup sebuah Pod

Fase Pod
Kondisi Pod
Pemeriksaan Kontainer
Status Pod dan Kontainer
State Kontainer
Pod readiness gate
Aturan Menjalankan Ulang
Umur Pod
Contoh
Selanjutnya

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 adalah Success.
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 adalah Failure. Jika kontainer tidak menyediakan pemeriksaan terhadap readiness, maka nilai awal state adalah Success.

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 hook postStart 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 terdapat preStop 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

FEATURE STATE: Kubernetes v1.14 stable

该功能是“稳定的”，意味着：

版本名是 vX，其中 X 是整数。
该功能将出现在多个后续释出的软件稳定版中。

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: k8s.gcr.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.
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.
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.
- 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.
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.
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.

Masukan

Apakah halaman ini berguna?

感谢反馈。如果您有一个关于如何使用 Kubernetes 的特定的、需要答案的问题，可以访问 Stack Overflow. 在 GitHub 仓库上登记新的问题报告问题或者提出改进建议.

Konsep