Mempelajari Panduan Dasar Kubernetes

Konsep

Kubernetes v1.15 dokumentasi sudah tidak dirawat lagi. Versi yang kamu lihat ini hanyalah snapshot statis. Untuk dokumentasi terkini, lihat versi terkini.

Edit This Page

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:

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:

Setiap pemeriksaan akan menghasilkan salah satu dari tiga hasil berikut:

Kubelet dapat secara optimal melakukan dan bereaksi terhadap dua jenis pemeriksaan yang sedang berjalan pada kontainer, yaitu:

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.

Pod readiness gate

FEATURE STATE: Kubernetes v1.14 stable
This feature is stable, meaning:

  • The version name is vX where X is an integer.
  • Stable versions of features will appear in released software for many subsequent versions.

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:

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:

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 kluster, 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

Selanjutnya

Masukan