whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Remove trailing spaces from ID documents(#16742) (#16789)

Browse Source
This commit is contained in:
Yushiro FURUKAWA
2019-10-10 13:48:52 +09:00
committed by Kubernetes Prow Robot
parent 99619d3414
commit 520caa1264
51 changed files with 1250 additions and 1250 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/id/docs/concepts/workloads/controllers/garbage-collection.md
+2 -2
View File
@@ -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 \
content/id/docs/concepts/workloads/controllers/ttlafterfinished.md
+32 -32
View File
@@ -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 %}}