|
| 1 | +--- |
| 2 | +title: Pengendali TTL untuk Sumber Daya yang Telah Selesai Digunakan |
| 3 | +content_template: templates/concept |
| 4 | +weight: 65 |
| 5 | +--- |
| 6 | + |
| 7 | +{{% capture overview %}} |
| 8 | + |
| 9 | +{{< feature-state for_k8s_version="v1.12" state="alpha" >}} |
| 10 | + |
| 11 | +Pengendali TTL menyediakan mekanisme TTL yang membatasi umur dari suatu |
| 12 | +objek sumber daya yang telah selesai digunakan. Pengendali TTL untuk saat ini hanya menangani |
| 13 | +[Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/), |
| 14 | +dan nantinya bisa saja digunakan untuk sumber daya lain yang telah selesai digunakan |
| 15 | +misalnya saja Pod atau sumber daya khusus (_custom resource_) lainnya. |
| 16 | + |
| 17 | +Peringatan Fitur Alpha: fitur ini tergolong datam fitur alpha dan dapat diaktifkan dengan |
| 18 | +[_feature gate_](/docs/reference/command-line-tools-reference/feature-gates/) |
| 19 | +`TTLAfterFinished`. |
| 20 | + |
| 21 | + |
| 22 | +{{% /capture %}} |
| 23 | + |
| 24 | + |
| 25 | + |
| 26 | + |
| 27 | +{{% capture body %}} |
| 28 | + |
| 29 | +## Pengendali TTL |
| 30 | + |
| 31 | +Pengendali TTL untuk saat ini hanya mendukung Job. Sebuah operator kluster |
| 32 | +dapat menggunakan fitur ini untuk membersihkan Job yang telah dieksekusi (baik |
| 33 | +`Complete` atau `Failed`) secara otomatis dengan menentukan _field_ |
| 34 | +`.spec.ttlSecondsAfterFinished` pada Job, seperti yang tertera di |
| 35 | +[contoh](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically). |
| 36 | +Pengendali TTL akan berasumsi bahwa sebuah sumber daya dapat dihapus apabila |
| 37 | +TTL dari sumber daya tersebut telah habis. Proses dihapusnya sumber daya ini |
| 38 | +dilakukan secara berantai, dimana sumber daya lain yang |
| 39 | +berkaitan akan ikut terhapus. Perhatikan bahwa ketika sebuah sumber daya dihapus, |
| 40 | +siklus hidup yang ada akan menjaga bahwa _finalizer_ akan tetap dijalankan sebagaimana mestinya. |
| 41 | + |
| 42 | +Waktu TTL dalam detik dapat diatur kapan pun. Terdapat beberapa contoh untuk mengaktifkan _field_ |
| 43 | +`.spec.ttlSecondsAfterFinished` pada suatu Job: |
| 44 | + |
| 45 | +* Spesifikasikan _field_ ini pada _manifest_ sumber daya, sehingga Job akan |
| 46 | + dihapus secara otomatis beberapa saat setelah selesai dieksekusi. |
| 47 | +* Aktifkan _field_ ini pada sumber daya yang sudah selesai dieksekusi untuk |
| 48 | + menerapkan fitur ini. |
| 49 | +* Gunakan sebuah |
| 50 | + [mengubah (_mutating_) _admission)](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) |
| 51 | + untuk mengaktifkan _field_ ini secara dinamis pada saat pembuatan sumber daya. |
| 52 | + Administrator kluster dapat menggunakan hal ini untuk menjamin kebijakan (_policy_) TTL pada |
| 53 | + sumber daya yang telah selesai digunakan. |
| 54 | +* Gunakan sebuah |
| 55 | + [mengubah (_mutating_) _admission](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) |
| 56 | + untuk mengaktifkan _field_ ini secara dinamis setelah sumber daya |
| 57 | + selesai digunakan dan TTL didefinisikan sesuai dengan status, label, atau hal lain |
| 58 | + yang diinginkan. |
| 59 | + |
| 60 | +## Peringatan |
| 61 | + |
| 62 | +### Mengubah TTL Detik |
| 63 | + |
| 64 | +Perhatikan bahwa periode TTL, yaitu _field_ `.spec.ttlSecondsAfterFinished` pada Job, |
| 65 | +dapat dimodifikasi baik setelah sumber daya dibuat atau setelah selesai digunakan. |
| 66 | +Meskipun begitu, setelah Job dapat dihapus (TTL sudah habis), sistem tidak akan |
| 67 | +menjamin Job tersebut akan tetap ada, meskipun nilai TTL berhasil diubah. |
| 68 | + |
| 69 | +### _Time Skew_ |
| 70 | + |
| 71 | +Karena pengendali TTL menggunakan cap waktu (_timestamp_) yang disimpan di sumber daya |
| 72 | +Kubernetes untuk menentukan apakah TTL sudah habis atau belum, fitur ini tidak sensitif |
| 73 | +terhadap _time skew_ yang ada pada kluster dan bisa saja menghapus objek pada waktu yang salah |
| 74 | +bagi objek tersebut akibat adanya _time skew_. |
| 75 | + |
| 76 | +Pada Kubernetes, NTP haruslah dilakukan pada semua node untuk mecegah adanya _time skew_ |
| 77 | +(lihat [#6159](https://github.com/kubernetes/kubernetes/issues/6159#issuecomment-93844058)). |
| 78 | +_Clock_ tidak akan selalu tepat, meskipun begitu perbedaan yang ada haruslah diminimalisasi. |
| 79 | +Perhatikan bahwa hal ini dapat terjadi apabila TTL diaktifkan dengan nilai selain 0. |
| 80 | + |
| 81 | +{{% /capture %}} |
| 82 | + |
| 83 | +{{% capture whatsnext %}} |
| 84 | + |
| 85 | +[Membersikan Job secara Otomatis](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically) |
| 86 | + |
| 87 | +[Dokumentasi Rancangan](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) |
| 88 | + |
| 89 | +{{% /capture %}} |
0 commit comments