Yushiro FURUKAWA
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
99619d3414
commit
520caa1264
@@ -49,7 +49,7 @@ metadata:
|
||||
```
|
||||
{{< note >}}
|
||||
Referensi pemilik lintas _namespace_ tidak diperbolehkan oleh desain. Artinya:
|
||||
1) Dependen dengan cakupan _namespace_ hanya bisa menspesifikasikan pemilik jika berada di _namespace_ yang sama, dan pemilik memiliki cakupan kluster.
|
||||
1) Dependen dengan cakupan _namespace_ hanya bisa menspesifikasikan pemilik jika berada di _namespace_ yang sama, dan pemilik memiliki cakupan kluster.
|
||||
2) Dependen dengan cakupan kluster hanya bisa menspesifikasikan pemilik yang memiliki cakupan kluster, tetapi tidak berlaku untuk pemilik yang memiliki cakupan kluster.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -82,7 +82,7 @@ Pada *foreground cascading deletion*, pertama objek utama akan memasuki keadaan
|
||||
Sebelum Kubernetes 1.9, kebijakan _default_ dari _garbage collection_ untuk banyak _resource controller_ adalah **orphan**. Ini meliputi ReplicationController, ReplicaSet, StatefulSet, DaemonSet, dan Deployment. Untuk jenis pada kelompok versi `extensions/v1beta1`, `apps/v1beta1`, dan `apps/v1beta2`, kecuali kamu menspesifikasikan dengan cara lain, objek dependen adalah _orphan_ secara _default_. Pada Kubernetes 1.9, untuk semua jenis pada kelompok versi `apps/v1`, objek dependen dihapus secara _default_.
|
||||
|
||||
Berikut sebuah contoh yang menghapus dependen di _background_:
|
||||
|
||||
|
||||
```shell
|
||||
kubectl proxy --port=8080
|
||||
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
|
||||
|
||||
@@ -8,13 +8,13 @@ weight: 65
|
||||
|
||||
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
|
||||
|
||||
Pengendali TTL menyediakan mekanisme TTL yang membatasi umur dari suatu
|
||||
objek sumber daya yang telah selesai digunakan. Pengendali TTL untuk saat ini hanya menangani
|
||||
[Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/),
|
||||
dan nantinya bisa saja digunakan untuk sumber daya lain yang telah selesai digunakan
|
||||
misalnya saja Pod atau sumber daya khusus (_custom resource_) lainnya.
|
||||
Pengendali TTL menyediakan mekanisme TTL yang membatasi umur dari suatu
|
||||
objek sumber daya yang telah selesai digunakan. Pengendali TTL untuk saat ini hanya menangani
|
||||
[Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/),
|
||||
dan nantinya bisa saja digunakan untuk sumber daya lain yang telah selesai digunakan
|
||||
misalnya saja Pod atau sumber daya khusus (_custom resource_) lainnya.
|
||||
|
||||
Peringatan Fitur Alpha: fitur ini tergolong datam fitur alpha dan dapat diaktifkan dengan
|
||||
Peringatan Fitur Alpha: fitur ini tergolong datam fitur alpha dan dapat diaktifkan dengan
|
||||
[_feature gate_](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
`TTLAfterFinished`.
|
||||
|
||||
@@ -28,33 +28,33 @@ Peringatan Fitur Alpha: fitur ini tergolong datam fitur alpha dan dapat diaktifk
|
||||
|
||||
## Pengendali TTL
|
||||
|
||||
Pengendali TTL untuk saat ini hanya mendukung Job. Sebuah operator kluster
|
||||
dapat menggunakan fitur ini untuk membersihkan Job yang telah dieksekusi (baik
|
||||
`Complete` atau `Failed`) secara otomatis dengan menentukan _field_
|
||||
`.spec.ttlSecondsAfterFinished` pada Job, seperti yang tertera di
|
||||
Pengendali TTL untuk saat ini hanya mendukung Job. Sebuah operator kluster
|
||||
dapat menggunakan fitur ini untuk membersihkan Job yang telah dieksekusi (baik
|
||||
`Complete` atau `Failed`) secara otomatis dengan menentukan _field_
|
||||
`.spec.ttlSecondsAfterFinished` pada Job, seperti yang tertera di
|
||||
[contoh](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically).
|
||||
Pengendali TTL akan berasumsi bahwa sebuah sumber daya dapat dihapus apabila
|
||||
TTL dari sumber daya tersebut telah habis. Proses dihapusnya sumber daya ini
|
||||
dilakukan secara berantai, dimana sumber daya lain yang
|
||||
berkaitan akan ikut terhapus. Perhatikan bahwa ketika sebuah sumber daya dihapus,
|
||||
Pengendali TTL akan berasumsi bahwa sebuah sumber daya dapat dihapus apabila
|
||||
TTL dari sumber daya tersebut telah habis. Proses dihapusnya sumber daya ini
|
||||
dilakukan secara berantai, dimana sumber daya lain yang
|
||||
berkaitan akan ikut terhapus. Perhatikan bahwa ketika sebuah sumber daya dihapus,
|
||||
siklus hidup yang ada akan menjaga bahwa _finalizer_ akan tetap dijalankan sebagaimana mestinya.
|
||||
|
||||
Waktu TTL dalam detik dapat diatur kapan pun. Terdapat beberapa contoh untuk mengaktifkan _field_
|
||||
Waktu TTL dalam detik dapat diatur kapan pun. Terdapat beberapa contoh untuk mengaktifkan _field_
|
||||
`.spec.ttlSecondsAfterFinished` pada suatu Job:
|
||||
|
||||
* Spesifikasikan _field_ ini pada _manifest_ sumber daya, sehingga Job akan
|
||||
dihapus secara otomatis beberapa saat setelah selesai dieksekusi.
|
||||
* Aktifkan _field_ ini pada sumber daya yang sudah selesai dieksekusi untuk
|
||||
* Spesifikasikan _field_ ini pada _manifest_ sumber daya, sehingga Job akan
|
||||
dihapus secara otomatis beberapa saat setelah selesai dieksekusi.
|
||||
* Aktifkan _field_ ini pada sumber daya yang sudah selesai dieksekusi untuk
|
||||
menerapkan fitur ini.
|
||||
* Gunakan sebuah
|
||||
* Gunakan sebuah
|
||||
[mengubah (_mutating_) _admission)](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
|
||||
untuk mengaktifkan _field_ ini secara dinamis pada saat pembuatan sumber daya.
|
||||
Administrator kluster dapat menggunakan hal ini untuk menjamin kebijakan (_policy_) TTL pada
|
||||
untuk mengaktifkan _field_ ini secara dinamis pada saat pembuatan sumber daya.
|
||||
Administrator kluster dapat menggunakan hal ini untuk menjamin kebijakan (_policy_) TTL pada
|
||||
sumber daya yang telah selesai digunakan.
|
||||
* Gunakan sebuah
|
||||
* Gunakan sebuah
|
||||
[mengubah (_mutating_) _admission](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
|
||||
untuk mengaktifkan _field_ ini secara dinamis setelah sumber daya
|
||||
selesai digunakan dan TTL didefinisikan sesuai dengan status, label, atau hal lain
|
||||
untuk mengaktifkan _field_ ini secara dinamis setelah sumber daya
|
||||
selesai digunakan dan TTL didefinisikan sesuai dengan status, label, atau hal lain
|
||||
yang diinginkan.
|
||||
|
||||
## Peringatan
|
||||
@@ -62,20 +62,20 @@ Waktu TTL dalam detik dapat diatur kapan pun. Terdapat beberapa contoh untuk men
|
||||
### Mengubah TTL Detik
|
||||
|
||||
Perhatikan bahwa periode TTL, yaitu _field_ `.spec.ttlSecondsAfterFinished` pada Job,
|
||||
dapat dimodifikasi baik setelah sumber daya dibuat atau setelah selesai digunakan.
|
||||
Meskipun begitu, setelah Job dapat dihapus (TTL sudah habis), sistem tidak akan
|
||||
dapat dimodifikasi baik setelah sumber daya dibuat atau setelah selesai digunakan.
|
||||
Meskipun begitu, setelah Job dapat dihapus (TTL sudah habis), sistem tidak akan
|
||||
menjamin Job tersebut akan tetap ada, meskipun nilai TTL berhasil diubah.
|
||||
|
||||
### _Time Skew_
|
||||
|
||||
Karena pengendali TTL menggunakan cap waktu (_timestamp_) yang disimpan di sumber daya
|
||||
Kubernetes untuk menentukan apakah TTL sudah habis atau belum, fitur ini tidak sensitif
|
||||
terhadap _time skew_ yang ada pada kluster dan bisa saja menghapus objek pada waktu yang salah
|
||||
Karena pengendali TTL menggunakan cap waktu (_timestamp_) yang disimpan di sumber daya
|
||||
Kubernetes untuk menentukan apakah TTL sudah habis atau belum, fitur ini tidak sensitif
|
||||
terhadap _time skew_ yang ada pada kluster dan bisa saja menghapus objek pada waktu yang salah
|
||||
bagi objek tersebut akibat adanya _time skew_.
|
||||
|
||||
Pada Kubernetes, NTP haruslah dilakukan pada semua node untuk mecegah adanya _time skew_
|
||||
(lihat [#6159](https://github.com/kubernetes/kubernetes/issues/6159#issuecomment-93844058)).
|
||||
_Clock_ tidak akan selalu tepat, meskipun begitu perbedaan yang ada haruslah diminimalisasi.
|
||||
Pada Kubernetes, NTP haruslah dilakukan pada semua node untuk mecegah adanya _time skew_
|
||||
(lihat [#6159](https://github.com/kubernetes/kubernetes/issues/6159#issuecomment-93844058)).
|
||||
_Clock_ tidak akan selalu tepat, meskipun begitu perbedaan yang ada haruslah diminimalisasi.
|
||||
Perhatikan bahwa hal ini dapat terjadi apabila TTL diaktifkan dengan nilai selain 0.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -58,7 +58,7 @@ Berikut beberapa contoh kasus penggunaan Init Container:
|
||||
* Menunggu beberapa waktu sebelum menjalankan Container aplikasi dengan perintah seperti `sleep 60`.
|
||||
* Mengklon sebuah _git repository_ ke dalam sebuah _volume_.
|
||||
* Menaruh nilai-nilai tertentu ke dalam sebuah _file_ konfigurasi dan menjalankan peralatan _template_ untuk membuat _file_ konfigurasi secara dinamis untuk Container aplikasi utama. Misalnya, untuk menaruh nilai POD_IP ke dalam sebuah konfigurasi dan membuat konfigurasi aplikasi utama menggunakan Jinja.
|
||||
|
||||
|
||||
Contoh-contoh penggunaan yang lebih detail dapat dilihat pada [dokumentasi StatefulSet](/docs/concepts/workloads/controllers/statefulset/) dan [petunjuk Produksi Pod](/docs/tasks/configure-pod-container/configure-pod-initialization/).
|
||||
|
||||
### Menggunakan Init Container
|
||||
|
||||
@@ -30,7 +30,7 @@ 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_.
|
||||
`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.
|
||||
|
||||
@@ -38,7 +38,7 @@ Nilai | Deskripsi
|
||||
|
||||
Suatu Pod memiliki sebuah PodStatus, yang merupakan _array_ dari [PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core) 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_ `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.
|
||||
|
||||
@@ -48,16 +48,16 @@ Suatu Pod memiliki sebuah PodStatus, yang merupakan _array_ dari [PodConditions]
|
||||
|
||||
* _Field_ `status` adalah sebuah kata dengan kemungkinan nilainya berupa "`True`", "`False`", dan "`Unknown`".
|
||||
|
||||
* _Field_ `type` adalah sebuah kata yang memiliki kemungkinan nilai sebagai berikut:
|
||||
* _Field_ `type` adalah sebuah kata yang memiliki kemungkinan nilai sebagai berikut:
|
||||
|
||||
* `PodScheduled`: Pod telah dijadwalkan masuk ke node;
|
||||
* `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](/docs/concepts/workloads/pods/init-containers) telah berjalan sempurna.
|
||||
* `Initialized`: Semua [init containers](/docs/concepts/workloads/pods/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.
|
||||
* `ContainersReady`: Semua kontainer di dalam Pod telah siap.
|
||||
|
||||
|
||||
## Pemeriksaan Kontainer
|
||||
## Pemeriksaan Kontainer
|
||||
|
||||
Sebuah [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) adalah sebuah diagnosa yang dilakukan secara berkala oleh [kubelet](/docs/admin/kubelet/) dalam suatu kontainer. Untuk melakukan diagnosa, kubelet memanggil sebuah [Handler](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler) yang diimplementasikan oleh kontainer. Ada 3 tipe _Handler_ yang tersedia, yaitu:
|
||||
|
||||
@@ -79,21 +79,21 @@ _Kubelet_ dapat secara optimal melakukan dan bereaksi terhadap dua jenis pemerik
|
||||
|
||||
* `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_?
|
||||
### Kapan sebaiknya menggunakan pemeriksaan terhadap _liveness_ atau _readiness_?
|
||||
|
||||
Jika proses dalam kontainer mungkin gagal yang dikarenakan menghadapi suatu masalah
|
||||
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
|
||||
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
|
||||
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
|
||||
_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,
|
||||
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
|
||||
@@ -103,30 +103,30 @@ _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
|
||||
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_](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/).
|
||||
|
||||
## Status Pod dan Kontainer
|
||||
## Status Pod dan Kontainer
|
||||
|
||||
Untuk informasi lebih mendalam mengenai status Pod dan kontainer, silakan lihat
|
||||
Untuk informasi lebih mendalam mengenai status Pod dan kontainer, silakan lihat
|
||||
[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)
|
||||
dan
|
||||
dan
|
||||
[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core).
|
||||
Mohon diperhatikan, informasi tentang status Pod bergantung pada
|
||||
Mohon diperhatikan, informasi tentang status Pod bergantung pada
|
||||
[ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core).
|
||||
|
||||
## State Kontainer
|
||||
|
||||
Ketika Pod sudah ditempatkan pada suatu node oleh scheduler, kubelet mulai membuat kontainer menggunakan _runtime_ 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.
|
||||
* `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.
|
||||
|
||||
```yaml
|
||||
@@ -135,7 +135,7 @@ Bersamaan dengan _state_ ini, sebuah pesan dan alasan tentang _state_ akan ditam
|
||||
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.
|
||||
|
||||
```yaml
|
||||
@@ -143,8 +143,8 @@ Bersamaan dengan _state_ ini, sebuah pesan dan alasan tentang _state_ akan ditam
|
||||
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.
|
||||
|
||||
```yaml
|
||||
@@ -155,18 +155,18 @@ Bersamaan dengan _state_ ini, sebuah pesan dan alasan tentang _state_ akan ditam
|
||||
Started: Wed, 30 Jan 2019 11:45:26 +0530
|
||||
Finished: Wed, 30 Jan 2019 11:45:26 +0530
|
||||
...
|
||||
```
|
||||
```
|
||||
|
||||
## Pod readiness gate
|
||||
|
||||
{{< feature-state for_k8s_version="v1.14" state="stable" >}}
|
||||
|
||||
Dalam rangka menambahkan ekstensibilitas terhadap kesiapan Pod dengan menggunakan
|
||||
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++](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/0007-pod-ready%2B%2B.md).
|
||||
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,
|
||||
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:
|
||||
|
||||
```yaml
|
||||
@@ -201,7 +201,7 @@ Dengan diperkenalkannya kondisi Pod yang baru, sebuah Pod akan dianggap siap han
|
||||
* Semua kontainer yang diatur dalam `ReadinessGates` bernilai "`True`".
|
||||
|
||||
|
||||
Untuk memfasilitasi perubahan tersebut terhadap evaluasi kesiapan Pod, dibuatkan sebuah kondisi Pod baru yaitu `ContainerReady`,
|
||||
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
|
||||
@@ -216,13 +216,13 @@ Sebuah PodSpec memiliki _field_ `restartPolicy` dengan kemungkinan nilai berupa
|
||||
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](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof),
|
||||
Sesuai dengan diskusi pada [dokumen Pod](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof),
|
||||
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
|
||||
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)
|
||||
|
||||
@@ -232,9 +232,9 @@ Tiga tipe pengontrol yang tersedia yaitu:
|
||||
sebagai contoh, penghitungan dalam jumlah banyak. Jobs hanyak cocok untuk Pod dengan `restartPolicy` yang
|
||||
bernilai OnFailure atau Never.
|
||||
|
||||
- Menggunakan sebuah [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/),
|
||||
- Menggunakan sebuah [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/),
|
||||
[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/), atau
|
||||
[Deployment](/docs/concepts/workloads/controllers/deployment/) untuk Pod yang tidak diharapkan untuk berakhir,
|
||||
[Deployment](/docs/concepts/workloads/controllers/deployment/) untuk Pod yang tidak diharapkan untuk berakhir,
|
||||
sebagai contoh, _web servers_. ReplicationControllers hanya cocok digunakan pada Pod dengan `restartPolicy`
|
||||
yang bernilai Always.
|
||||
|
||||
@@ -242,7 +242,7 @@ Tiga tipe pengontrol yang tersedia yaitu:
|
||||
hanya satu untuk setiap mesin, karena menyediakan servis yang spesifik untuk suatu mesin.
|
||||
|
||||
|
||||
Ketiga tipe pengontrol ini memiliki sebuah PodTemplate. Direkomdasikan untuk membuat
|
||||
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.
|
||||
|
||||
@@ -253,7 +253,7 @@ Jika node mati atau sambungannya terputus dari kluster, Kubernetes mengatur
|
||||
|
||||
### Contoh _Liveness Probe_ tingkat lanjut
|
||||
|
||||
_Liveness probe_ dieksekusi oleh kubelet, jadi semua permintaan akan dilakukan
|
||||
_Liveness probe_ dieksekusi oleh kubelet, jadi semua permintaan akan dilakukan
|
||||
di dalam _namespace_ jaringan kubelet.
|
||||
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: Pengenalan Pod
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
card:
|
||||
card:
|
||||
name: concepts
|
||||
weight: 60
|
||||
---
|
||||
@@ -36,7 +36,7 @@ Setiap *Pod* dimaksudkan untuk menjalankan satu *instance* aplikasi. Jika kamu i
|
||||
### Bagaimana *Pod* mengelola beberapa Kontainer
|
||||
*Pod* didesain untuk mendukung banyak proses (sebagai kontainer) yang membentuk sebuah layanan. Kontainer di dalam sebuah *Pod* akan otomatis ditempatkan bersama di dalam satu mesin fisik atau mesin *virtual* di dalam kluster. Kontainer tersebut dapat berbagi *resource* dan dependensi, berkomunikasi satu sama lain, dan berkoordinasi kapan dan bagaimana mereka diterminasi.
|
||||
|
||||
Perhatikan bahwa mengelompokan kontainer di dalam satu *Pod* merupakan kasus lanjutan. Kamu dapat menggunakan pola ini hanya dalam kasus tertentu. Sebagai contoh, kamu memiliki kontainer yang bertindak sebagai *web server* yang menyajikan berkas dari *resource* penyimpanan bersama, dan kontainer *sidecar* melakukan pembaharuan terhadap berkas tersebut dari sumber lain, seperti dalam diagram *Pod* berikut:
|
||||
Perhatikan bahwa mengelompokan kontainer di dalam satu *Pod* merupakan kasus lanjutan. Kamu dapat menggunakan pola ini hanya dalam kasus tertentu. Sebagai contoh, kamu memiliki kontainer yang bertindak sebagai *web server* yang menyajikan berkas dari *resource* penyimpanan bersama, dan kontainer *sidecar* melakukan pembaharuan terhadap berkas tersebut dari sumber lain, seperti dalam diagram *Pod* berikut:
|
||||
{{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}}
|
||||
|
||||
*Pod* menyediakan dua jenis *resource* sebagai penyusun dari kontainer: *jaringan* dan *penyimpanan*.
|
||||
|
||||
Reference in New Issue
Block a user