Change kluster to klaster mentioned in https://github.com/jk8s/sig-docs-id/issues/20 (#18130)

content/id/docs/concepts/workloads/controllers/garbage-collection.md

@@ -50,8 +50,8 @@ 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.
-2) Dependen dengan cakupan kluster hanya bisa menspesifikasikan pemilik yang memiliki cakupan kluster, tetapi tidak berlaku untuk pemilik yang memiliki cakupan kluster.
+1) Dependen dengan cakupan _namespace_ hanya bisa menspesifikasikan pemilik jika berada di _namespace_ yang sama, dan pemilik memiliki cakupan klaster.
+2) Dependen dengan cakupan klaster hanya bisa menspesifikasikan pemilik yang memiliki cakupan klaster, tetapi tidak berlaku untuk pemilik yang memiliki cakupan klaster.
 {{< /note >}}
 
 ## Mengontrol bagaimana _garbage collector_ menghapus dependen

content/id/docs/concepts/workloads/controllers/replicaset.md

@@ -31,7 +31,7 @@ Hal ini berarti kamu boleh jadi tidak akan membutuhkan manipulasi objek ReplicaS
 
 {{< codenew file="controllers/frontend.yaml" >}}
 
-Menyimpan _manifest_ ini dalam `frontend.yaml` dan mengirimkannya ke kluster Kubernetes akan membuat ReplicaSet yang telah didefinisikan beserta dengan Pod yang dikelola.
+Menyimpan _manifest_ ini dalam `frontend.yaml` dan mengirimkannya ke klaster Kubernetes akan membuat ReplicaSet yang telah didefinisikan beserta dengan Pod yang dikelola.
 
 ```shell
 kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml
@@ -259,7 +259,7 @@ Pengaturan jumlah Pod pada ReplicaSet juga dapat dilakukan mengunakan [Horizonta
 
 {{< codenew file="controllers/hpa-rs.yaml" >}}
 
-Menyimpan _manifest_ ini dalam `hpa-rs.yaml` dan mengirimkannya ke kluster Kubernetes akan membuat HPA tersebut yang akan mengatur jumlah Pod pada ReplicaSet yang telah didefinisikan bergantung terhadap penggunaan CPU dari Pod yang direplikasi.
+Menyimpan _manifest_ ini dalam `hpa-rs.yaml` dan mengirimkannya ke klaster Kubernetes akan membuat HPA tersebut yang akan mengatur jumlah Pod pada ReplicaSet yang telah didefinisikan bergantung terhadap penggunaan CPU dari Pod yang direplikasi.
 
 ```shell
 kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml

content/id/docs/concepts/workloads/controllers/statefulset.md

@@ -127,7 +127,7 @@ dengan nama `web-0,web-1,web-2`.
 Sebuah StatefulSet dapat menggunakan sebuah [Service Headless](/docs/concepts/services-networking/service/#headless-services)
 untuk mengontrol domain dari Pod yang ada. Domain yang diatur oleh Service ini memiliki format:
 `$(service name).$(namespace).svc.cluster.local`, dimana "cluster.local" merupakan 
-domain kluster.
+domain klaster.
 Seiring dibuatnya setiap Pod, Pod tersebut akan memiliki subdomain DNS-nya sendiri, yang memiliki format:
 `$(podname).$(governing service domain)`, dimana Service yang mengatur didefinisikan oleh 
 _field_ `serviceName` pada StatefulSet.
@@ -136,17 +136,17 @@ Seperti sudah disebutkan di dalam bagian [keterbatasan](#keterbatasan), kamulah
 untuk membuat [Service Headless](/docs/concepts/services-networking/service/#headless-services)
 yang bertanggung jawab terhadap identitas jaringan pada Pod.
 
-Di sini terdapat beberapa contoh penggunaan Domain Kluster, nama Service, 
+Di sini terdapat beberapa contoh penggunaan Domain Klaster, nama Service, 
 nama StatefulSet, dan bagaimana hal tersebut berdampak pada nama DNS dari Pod StatefulSet.
 
-Domain Kluster | Service (ns/nama) | StatefulSet (ns/nama)  | Domain StatefulSet  | DNS Pod | Hostname Pod |
+Domain Klaster | Service (ns/nama) | StatefulSet (ns/nama)  | Domain StatefulSet  | DNS Pod | Hostname Pod |
 -------------- | ----------------- | ----------------- | -------------- | ------- | ------------ |
  cluster.local | default/nginx     | default/web       | nginx.default.svc.cluster.local | web-{0..N-1}.nginx.default.svc.cluster.local | web-{0..N-1} |
  cluster.local | foo/nginx         | foo/web           | nginx.foo.svc.cluster.local     | web-{0..N-1}.nginx.foo.svc.cluster.local     | web-{0..N-1} |
  kube.local    | foo/nginx         | foo/web           | nginx.foo.svc.kube.local        | web-{0..N-1}.nginx.foo.svc.kube.local        | web-{0..N-1} |
 
 {{< note >}}
-Domain kluster akan diatur menjadi `cluster.local` kecuali
+Domain klaster akan diatur menjadi `cluster.local` kecuali
 [nilainya dikonfigurasi](/docs/concepts/services-networking/dns-pod-service/#how-it-works).
 {{< /note >}}
 

content/id/docs/concepts/workloads/controllers/ttlafterfinished.md

@@ -28,7 +28,7 @@ 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
+Pengendali TTL untuk saat ini hanya mendukung Job. Sebuah operator klaster
 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
@@ -49,7 +49,7 @@ Waktu TTL dalam detik dapat diatur kapan pun. Terdapat beberapa contoh untuk men
 * 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
+  Administrator klaster dapat menggunakan hal ini untuk menjamin kebijakan (_policy_) TTL pada
   sumber daya yang telah selesai digunakan.
 * Gunakan sebuah
   [mengubah (_mutating_) _admission](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
@@ -70,7 +70,7 @@ menjamin Job tersebut akan tetap ada, meskipun nilai TTL berhasil diubah.
 
 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
+terhadap _time skew_ yang ada pada klaster 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_