From 838d1b180cf75f8f4f0be1f1cb75beabf7c71ea2 Mon Sep 17 00:00:00 2001 From: "giri.kuncoro" Date: Sat, 6 Jun 2020 08:04:18 +0700 Subject: [PATCH] Localize liveness readiness startu probes page into Bahasa Indonesia --- ...igure-liveness-readiness-startup-probes.md | 374 ++++++++++++++++++ 1 file changed, 374 insertions(+) create mode 100644 content/id/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md diff --git a/content/id/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/id/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md new file mode 100644 index 0000000000..231d235ed0 --- /dev/null +++ b/content/id/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -0,0 +1,374 @@ +--- +title: Mengatur Probe Liveness, Readiness dan Startup +content_template: templates/task +weight: 110 +--- + +{{% capture overview %}} + +Laman ini memperlihatkan bagaimana cara untuk mengatur _probe liveness_, _readiness_, dan +_startup_ untuk Container. + +[kubelet](/docs/admin/kubelet/) menggunakan _probe liveness_ untuk mengetahui +kapan perlu mengulang kembali (_restart_) sebuah Container. Sebagai contoh, _probe liveness_ +dapat mendeteksi _deadlock_, ketika aplikasi sedang berjalan tapi tidak dapat berfungsi dengan baik. +Mengulang Container dengan _state_ tersebut dapat membantu ketersediaan aplikasi lebih baik +walaupun ada kekutu (_bug_). + +kubelet menggunakan _probe readiness_ untuk mengetahui kapan sebuah Container telah siap untuk +menerima lalu lintas jaringan. Suatu Pod dianggap siap saat semua Container di dalamnya telah +siap. Sinyal ini berguna untuk mengontrol Pod-Pod mana yang digunakan sebagai _backend_ dari Service. +Ketika Pod dalam kondisi tidak siap, Pod tersebut dihapus dari _load balancer_ Service. + +kubelet menggunakan _probe startup_ untuk mengetahui kapan sebuah aplikasi Container telah mulai berjalan. +Jika _probe_ tersebut dinyalakan, _probe_ akan menonaktifkan pemeriksaan _liveness_ dan _readiness_ sampai +berhasil, kamu harus memastikan _probe_ tersebut tidak mengganggu _startup_ dari aplikasi. +Mekanisme ini dapat digunakan untuk mengadopsi pemeriksaan _liveness_ saat memulai Container yang lambat, +sehingga bisa terhindar dimatikan oleh kubelet sebelum Container mulai dan berjalan. + +{{% /capture %}} + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + +{{% capture steps %}} + +## Mendefinisikan perintah liveness + +Kebanyakan aplikasi yang telah berjalan dalam waktu lama pada akhirnya akan +bertransisi ke _state_ yang rusak, dan tidak dapat pulih selain diulang kembali. +Kubernetes menyediakan _probe liveness_ untuk mendeteksi dan memperbaiki situasi tersebut. + +Pada latihan ini, kamu akan membuat Pod yang menjalankan Container dari image +`k8s.gcr.io/busybox`. Berikut ini adalah berkas konfigurasi untuk Pod tersebut: + +{{< codenew file="pods/probe/exec-liveness.yaml" >}} + +Pada berkas konfigurasi di atas, kamu dapat melihat bahwa Pod memiliki satu `Container`. +_Field_ `periodSeconds` menentukan bahwa kubelet harus melakukan _probe liveness_ setiap 5 detik. +_Field_ `initialDelaySeconds` memberitahu kubelet untuk menunggu 5 detik sebelum mengerjakan +_probe_ yang pertama. Untuk mengerjakan _probe_, kubelet menjalankan perintah `cat /tmp/healthy` +pada Container tujuan. Jika perintah berhasil, kode 0 akan dikembalikan, dan kubelet menganggap +Container sedang dalam kondisi hidup (_alive_) dan sehat (_healthy_). Jika perintah mengembalikan +kode selain 0, maka kubelet akan mematikan Container dan mengulangnya. + +Saat dimulai, Container akan menjalankan perintah berikut: + +```shell +/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600" +``` + +Container memiliki berkas `/tmp/healthy` pada 30 detik pertama saat dijalankan. +Perintah `cat /tmp/healthy` mengembalikan kode sukses. Setelah 30 detik berlalu, +`cat /tmp/healthy` mengembalikan kode gagal. + +Buat sebuah Pod: + +```shell +kubectl apply -f https://k8s.io/examples/pods/probe/exec-liveness.yaml +``` + +Dalam 30 detik pertama, lihat _event_ dari Pod: + +```shell +kubectl describe pod liveness-exec +``` + +Keluaran dari perintah tersebut memperlihatkan bahwa belum ada _probe liveness_ yang gagal: + +``` +FirstSeen LastSeen Count From SubobjectPath Type Reason Message +--------- -------- ----- ---- ------------- -------- ------ ------- +24s 24s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0 +23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox" +23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox" +23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined] +23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e +``` + +Setelah 35 detik, lihat lagi _event_ Pod tersebut: + +```shell +kubectl describe pod liveness-exec +``` + +Baris terakhir dari keluaran tersebut memperlihatkan pesan bahwa _probe liveness_ +mengalami kegagalan, dan Container telah dimatikan dan dibuat ulang. + +``` +FirstSeen LastSeen Count From SubobjectPath Type Reason Message +--------- -------- ----- ---- ------------- -------- ------ ------- +37s 37s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0 +36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox" +36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox" +36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined] +36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e +2s 2s 1 {kubelet worker0} spec.containers{liveness} Warning Unhealthy Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory +``` + +Tunggu 30 detik lagi, dan verifikasi bahwa Container telah diulang kembali: + +```shell +kubectl get pod liveness-exec +``` + +Keluaran perintah tersebut memperlihatkan bahwa jumlah `RESTARTS` meningkat: + +``` +NAME READY STATUS RESTARTS AGE +liveness-exec 1/1 Running 1 1m +``` + +## Mendefinisikan probe liveness dengan permintaan HTTP + +Jenis kedua dari _probe liveness_ menggunakan sebuah permintaan GET HTTP. Berikut ini +berkas konfigurasi untuk Pod yang menjalankan Container dari image `k8s.gcr.io/liveness`. + +{{< codenew file="pods/probe/http-liveness.yaml" >}} + +Pada berkas konfigurasi tersebut, kamu dapat melihat Pod memiliki satu buah Container. +_Field_ `periodSeconds` menentukan bahwa kubelet harus mengerjakan _probe liveness_ setiap 3 detik. +_Field_ `initialDelaySeconds` memberitahu kubelet untuk menunggu 3 detik sebelum mengerjakan +_probe_ yang pertama. Untuk mengerjakan _probe_ tersebut, kubelet mengirimkan sebuah permintaan +GET HTTP ke server yang sedang berjalan di dalam Container dan mendengarkan (_listen_) pada porta 8080. +Jika _handler path_ `/healthz` yang dimiliki server mengembalikan kode sukses, kubelet menganggap +Container sedang dalam kondisi hidup dan sehat. Jika _handler_ mengembalikan kode gagal, +kubelet mematikan Container dan mengulangnya. + +Kode yang lebih besar atau sama dengan 200 dan kurang dari 400 mengindikasikan kesuksesan. +Kode selain ini mengindikasikan kegagalan. + +Kamu dapat melihat kode program untuk server ini pada [server.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/test/images/agnhost/liveness/server.go). + +Untuk 10 detik pertama setelah Container hidup, _handler_ `/healthz` mengembalikan +status 200. Setelah ini, _handler_ mengembalikan status 500. + +```go +http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) { + duration := time.Now().Sub(started) + if duration.Seconds() > 10 { + w.WriteHeader(500) + w.Write([]byte(fmt.Sprintf("error: %v", duration.Seconds()))) + } else { + w.WriteHeader(200) + w.Write([]byte("ok")) + } +}) +``` + +kubelet mulai memeriksa kesehatan (_health check_) 3 detik setelah Container dimulai, +sehingga beberapa pemeriksaaan pertama akan berhasil. Namun setelah 10 detik, +pemeriksaan akan gagal, dan kubelet akan mematikan dan mengulang Container. + +Untuk mencoba pemeriksaan _liveness_ HTTP, mari membuat sebuah Pod: + +```shell +kubectl apply -f https://k8s.io/examples/pods/probe/http-liveness.yaml +``` + +Setelah 10 detik, lihat _event_ Pod untuk memverifikasi bahwa _probe liveness_ +telah gagal dan Container telah diulang kembali: + +```shell +kubectl describe pod liveness-http +``` + +Untuk rilis sebelum v1.13 (termasuk v1.13), jika variabel lingkungan +`http_proxy` (atau `HTTP_PROXY`) telah diatur pada Node dimana Pod +berjalan, _probe liveness_ HTTP akan menggunakan proksi tersebut. +Untuk rilis setelah v1.13, pengaturan variabel lingkungan pada proksi HTTP lokal +tidak mempengaruhi _probe liveness) HTTP. + +## Mendefinisikan probe liveness TCP + +Jenis ketiga dari _probe liveness_ menggunakaan sebuah soket TCP. Dengan konfigurasi ini, +kubelet akan mencoba untuk membuka soket pada Container kamu dengan porta tertentu. +Jika koneksi dapat sukses terbentuk, maka Container dianggap dalam kondisi sehat. +Namun jika tidak berhasil terbentuk, maka Container dianggap gagal. + +{{< codenew file="pods/probe/tcp-liveness-readiness.yaml" >}} + +Seperti yang terlihat, konfigurasi untuk pemeriksaan TCP cukup mirip dengan +pemeriksaan HTTP. Contoh ini menggunakan _probe readiness_ dan _liveness_. +kubelet akan mengirimkan _probe readiness_ yang pertama, 5 detik setelah +Container mulai dijalankan. kubelet akan mencoba untuk terhubung dengan Container +`goproxy` pada porta 8080. Jika _probe_ berhasil, maka Pod akan ditandai menjadi +_siap_. kubelet akan lanjut mengerjakan pemeriksaan ini setiap 10 detik. + +Selain _probe readiness_, _probe liveness_ juga termasuk di dalam konfigurasi. +kubelet akan menjalankan _probe liveness_ yang pertama, 15 detik setelah Container +mulai dijalankan. Sama seperti _probe readiness_, kubelet akan mencoba untuk +terhubung dengan Container `goproxy` pada porta 8080. Jika _probe liveness_ gagal, +maka Container akan diulang kembali. + +Untuk mencoba pemeriksaan _liveness_ TCP, mari membuat sebuah Pod: + +```shell +kubectl apply -f https://k8s.io/examples/pods/probe/tcp-liveness-readiness.yaml +``` + +Setelah 15 detik, lihat _event_ Pod untuk memverifikasi _probe liveness_ tersebut: + +```shell +kubectl describe pod goproxy +``` + +## Menggunakan sebuah porta dengan nama + +Kamu dapat menggunakan +[ContainerPort](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerport-v1-core) +dengan nama untuk melakukan pemeriksaan _liveness_ HTTP atau TCP: + +```yaml +ports: +- name: liveness-port + containerPort: 8080 + hostPort: 8080 + +livenessProbe: + httpGet: + path: /healthz + port: liveness-port +``` + +## Melindungi Container yang lambat untuk dimulai dengan probe startup {#mendefinisikan-probe-startup} + +Terkadang kamu harus berurusan dengan aplikasi peninggalan (_legacy_) yang +memerlukan waktu tambahan untuk mulai berjalan pada saat pertama kali diinisialisasi. +Pada kasus ini, cukup rumit untuk mengatur parameter _probe liveness_ tanpa +mengkompromikan respons yang cepat terhadap _deadlock_ yang memotivasi digunakannya +_probe_ tersebut. Triknya adalah untuk mengatur _probe startup_ dengan perintah yang sama, +pemeriksaan HTTP ataupun TCP, dengan `failureThreshold * periodSeconds` yang +mencukupi untuk kemungkinan waktu memulai yang terburuk. + +Jadi, contoh sebelumnya menjadi: + +```yaml +ports: +- name: liveness-port + containerPort: 8080 + hostPort: 8080 + +livenessProbe: + httpGet: + path: /healthz + port: liveness-port + failureThreshold: 1 + periodSeconds: 10 + +startupProbe: + httpGet: + path: /healthz + port: liveness-port + failureThreshold: 30 + periodSeconds: 10 +``` + +Berkat _probe startup_, aplikasi akan memiliki paling lambat 5 menit (30 * 10 = 300 detik) +untuk selesai memulai. +Ketika _probe startup_ telah berhasil satu kali, maka _probe liveness_ akan +mengambil alih untuk menyediakan respons cepat terhadap _deadlock_ Container. +Jika _probe startup_ tidak pernah berhasil, maka Container akan dimatikan setelah +300 detik dan perilakunya akan bergantung pada `restartPolicy` yang dimiliki Pod. + +## Mendefinisikan probe readiness + +Terkadang aplikasi tidak dapat melayani lalu lintas jaringan (_traffic_) sementara. +Contohnya, aplikasi mungkin perlu untuk memuat data besar atau berkas konfigurasi +saat dimulai, atau aplikasi bergantung pada layanan eksternal setelah dimulai. +Pada kasus-kasus ini, kamu tidak ingin mematikan aplikasi, tetapi kamu tidak +ingin juga mengirimkan permintaan ke aplikasi tersebut. Kubernetes menyediakan +_probe readiness_ sebagai solusinya. Sebuah Pod dengan Container yang melaporkan +dirinya tidak siap, tidak akan menerima lalu lintas jaringan dari Kubernetes Service. + +{{< note >}} +_Probe readiness_ dijalankan di dalam Container selama siklus hidupnya. +{{< /note >}} + +_Probe readiness_ memiliki pengaturan yang mirip dengan _probe liveness_. Perbedaan +satu-satunya adalah kamu menggunakan _field_ `readinessProbe`, bukan _field_ `livenessProbe`. + +```yaml +readinessProbe: + exec: + command: + - cat + - /tmp/healthy + initialDelaySeconds: 5 + periodSeconds: 5 +``` + +Pengaturan untuk _probe readiness_ untuk HTTP dan TCP juga sama persis dengan +pengaturan untuk _probe liveness_. + +_Probe readiness_ dan _liveness_ dapat digunakan secara bersamaan untuk +Container yang sama. Apabila keduanya digunakan sekaligus, lalu lintas jaringan +tidak akan sampai ke Container yang belum siap, dan Container akan diulang kembali +(_restart_) saat mengalami kegagalan. + +## Mengatur Probe + +{{< comment >}} +Nantinya beberapa bagian dari bab ini dapat berpindah ke topik konsep. +{{< /comment >}} + +[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) memiliki +beberapa _field_ yang dapat digunakan untuk mengendalikan pemeriksaan _liveness_ dan _readiness_ +secara presisi. + +* `initialDelaySeconds`: Durasi dalam detik setelah Container dimulai, +sebelum _probe liveness_ atau _readiness_ diinisiasi. Nilai bawaannya adalah 0 detik. Nilai minimalnya adalah 0. +* `periodSeconds`: Seberapa sering (dalam detik) _probe_ dijalankan. Nilai bawaannya adalah 10 detik. +Nilai minimalnya adalah 0. +* `timeoutSeconds`: Durasi dalam detik setelah _probe_ mengalami _timeout_. Nilai bawaannya adalah 1 detik. +Nilai minimalnya adalah 0. +* `successThreshold`: Jumlah minimal sukses yang berurutan untuk _probe_ dianggap berhasil +setelah mengalami kegagalan. Nilai bawaannya adalah 1. Nilanya harus 1 untuk _liveness_. +Nilai minimalnya adalah 1. +* `failureThreshold`: Ketika sebuah Pod dimulai dan _probe_ mengalami kegagalan, Kubernetes +akan mencoba beberapa kali sesuai nilai `failureThreshold` sebelum menyerah. Menyerah karena +kasus _probe liveness_ akan membuat Container diulang kembali. Untuk _probe readiness_, menyerah +akaan menandai Pod menjadi "tidak siap" (Unready). Nilai bawaannya adalah 3. Nilai minimalnya adalah 1. + +[_Probe_ HTTP](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core) +memiliki _field-field_ tambahan yang bisa diatur melalui `httpGet`: + +* `host`: Nama dari host yang akan terhubung, nilai bawaannya adalah IP dari Pod. Kamu mungkin +juga ingin mengatur "Host" pada httpHeaders. +* `scheme`: Skema yang digunakan untuk terhubung pada host (HTTP atau HTTPS). Nilai bawaannya adalah HTTP. +* `path`: _Path_ untuk mengakses server HTTP. +* `httpHeaders`: _Header_ khusus yang diatur melalui permintaan. HTTP memperbolehkan _header_ yang berulang. +* `port`: Nama atau angka dari porta untuk mengakses Container. Angkanya harus ada di antara 1 sampai 65535. + +Untuk sebuah _probe_ HTTP, kubelet mengirimkan permintaan HTTP untuk _path_ yang ditentukan +dan porta untuk mengerjakan pemeriksaan. kubelet mengirimkan _probe_ untuk alamat IP Pod, +kecuali saat alamat digantikan oleh _field_ opsional pada `httpGet`. Jika _field_ `scheme` +diatur menjadi `HTTPS`, maka kubelet mengirimkan permintaan HTTPS dan melewati langkah verifikasi +sertifikat. Pada skenario kebanyakan, kamu tidak menginginkan _field_ `host`. +Berikut satu skenario yang memerlukan `host`. Misalkan Container mendengarkan permintaan +melalui 127.0.0.1 dan _field_ `hostNetwork` pada Pod bernilai true. Kemudian `host`, melalui +`httpGet`, harus diatur menjadi 127.0.0.1. Jika Pod kamu bergantung pada host virtual, dimana +untuk kasus-kasus umum, kamu tidak perlu menggunakan `host`, tetapi perlu mengaatur _header_ +`Host` pada `httpHeaders`. + +Untuk _probe_ TCP, kubelet membuat koneksi _probe_ pada Node, tidak pada Pod, yang berarti bahwa +kamu tidak menggunakan nama Service di dalam parameter `host` karena kubelet tidak bisa +me-_resolve_-nya. + +{{% /capture %}} + +{{% capture whatsnext %}} + +* Pelajari lebih lanjut tentang +[Probe Container](/id/docs/concepts/workloads/pods/pod-lifecycle/#container-probes). + +Kamu juga dapat membaca rujukan API untuk: + +* [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) +* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) +* [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) + +{{% /capture %}}