Localize liveness readiness startu probes page into Bahasa Indonesia
giri.kuncoro
parent
0f91086750
commit
838d1b180c
|
|
@ -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 %}}
|
||||
Loading…
Reference in New Issue