Apply suggestions from code review

Co-authored-by: Giri Kuncoro <[email protected]>

Author: deryrahman

content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md

@@ -7,19 +7,19 @@ weight: 80
 
 {{% capture overview %}}
 
-Halaman ini menjelaskan bagaimana membuat _Load Balancer_ Eksternal.
+Laman ini menjelaskan bagaimana membuat _Load Balancer_ Eksternal.
 
 {{< note >}}
-Fitur ini hanya tersedia untuk penyedia _cloud_ atau lingkungan yang mendukung _load balancer_ eksternal.
+Fitur ini hanya tersedia untuk penyedia cloud atau lingkungan yang mendukung _load balancer_ eksternal.
 {{< /note >}}
 
-Ketika membuat servis, kamu mempunyai opsi untuk membuat jaringan _cloud load balancer_ secara otomatis.
-Hal ini menyediakan akses eksternal alamat IP yang dapat mengirim lalu lintas melalui porta yang tepat pada klaster _node_ kamu
+Ketika membuat Service, kamu mempunyai opsi untuk tersambung dengan jaringan cloud _load balancer_ secara otomatis.
+Hal ini menyediakan akses eksternal alamat IP yang dapat mengirim lalu lintas melalui porta yang tepat pada klaster Node kamu
 _asalkan klaster kamu beroperasi pada lingkungan yang mendukung dan terkonfigurasi dengan paket penyedia cloud load balancer yang benar_.
 
-Untuk informasi mengenai penyediaan dan penggunaan sumber daya _Ingress_ yang dapat memberikan
+Untuk informasi mengenai penyediaan dan penggunaan sumber daya Ingress yang dapat memberikan
 servis URL yang dapat dijangkau secara eksternal, penyeimbang beban lalu lintas, terminasi SSL, dll.,
-silahkan cek dokumentasi [_Ingress_](/docs/concepts/services-networking/ingress/)
+silahkan cek dokumentasi [Ingress](/docs/concepts/services-networking/ingress/)
 
 {{% /capture %}}
 
@@ -33,8 +33,8 @@ silahkan cek dokumentasi [_Ingress_](/docs/concepts/services-networking/ingress/
 
 ## Berkas konfigurasi
 
-Untuk membuat _load balancer_ eksternal, tambahkan baris dibawah ini ke
-[berkas konfigurasi servis](/docs/concepts/services-networking/service/#loadbalancer) kamu:
+Untuk membuat _load balancer_ eksternal, tambahkan baris di bawah ini ke
+[berkas konfigurasi Service](/docs/concepts/services-networking/service/#loadbalancer) kamu:
 
 ```yaml
     type: LoadBalancer
@@ -58,24 +58,24 @@ spec:
 
 ## Menggunakan kubectl
 
-Kamu dapat membuat servis dengan perintah `kubectl expose` dan
+Kamu dapat membuat Service dengan perintah `kubectl expose` dan
 _flag_ `--type=LoadBalancer`:
 
 ```bash
 kubectl expose rc example --port=8765 --target-port=9376 \
         --name=example-service --type=LoadBalancer
 ```
 
-Perintah ini membuat servis baru dengan menggunakan pemilih yang sama dengan
-sumber daya yang dirujuk (dalam hal contoh diatas, pengendali replikasi bernama `example`).
+Perintah ini membuat Service baru dengan menggunakan pemilih yang sama dengan
+sumber daya yang dirujuk (dalam hal contoh di atas, ReplicationController bernama `example`).
 
 Untuk informasi lebih lanjut, termasuk opsi _flag_, mengacu kepada
 [referensi `kubectl expose`](/docs/reference/generated/kubectl/kubectl-commands/#expose).
 
 ## Menemukan alamat IP kamu
 
-Kamu dapat menemukan alamat IP yang telah dibuat untuk servis kamu dengan mendapatkan
-informasi servis melalui `kubectl`:
+Kamu dapat menemukan alamat IP yang telah dibuat untuk Service kamu dengan mendapatkan
+informasi Service melalui `kubectl`:
 
 ```bash
 kubectl describe services example-service
@@ -102,7 +102,7 @@ yang seharusnya menghasilkan keluaran seperti ini:
 Alamat IP tercantum di sebelah `LoadBalancer Ingress`.
 
 {{< note >}}
-Juka kamu menjalankan servis dari Minikube, kamu dapat menemukan alamat IP dan porta yang ditetapkan dengan:
+Jika kamu menjalankan Service dari Minikube, kamu dapat menemukan alamat IP dan porta yang ditetapkan dengan:
 {{< /note >}}
 
 ```bash
@@ -111,26 +111,26 @@ minikube service example-service --url
 
 ## Preservasi IP sumber klien
 
-Dikarenakan implementasi fitur ini, sumber IP yang terlihat pada _container_
+Implementasi dari fitur ini menyebabkan sumber IP yang terlihat pada Container
 target *bukan sebagai sumber IP asli* dari klien. Untuk mengaktifkan
-preservasi IP klien, bidang berikut dapat dikonfigurasikan didalam
-spek servis (mendukung lingkungan GCE/Google Kubernetes Engine):
+preservasi IP klien, bidang berikut dapat dikonfigurasikan di dalam
+spek Service (mendukung lingkungan GCE/Google Kubernetes Engine):
 
-* `service.spec.externalTrafficPolicy` - menunjukan jika Service menginginkan untuk merute lalu lintas
+* `service.spec.externalTrafficPolicy` - menunjukkan jika Service menginginkan rute lalu lintas
 eksternal ke titik akhir _node-local_ atau _cluster-wide_. Terdapat dua opsi yang tersedia:
-Cluster (_default_) dan Local. Cluster mengaburkan sumber IP klien dan mungkin menyebabkan
-hop kedua ke _node_ berbeda, namun harus mempunyai _load-spreading_ yang baik secara keseluruhan.
-Local mempreservasi sumber IP client dan menghindari hop kedua _LoadBalancer_ dan servis tipe _NodePort_, namun
+`Cluster` (bawaan) dan `Local`. `Cluster` mengaburkan sumber IP klien dan mungkin menyebabkan
+hop kedua ke Node berbeda, namun harus mempunyai penyebaran beban (_load-spreading_) yang baik secara keseluruhan.
+`Local` mempreservasi sumber IP client dan menghindari hop kedua `LoadBalancer` dan Service dengan tipe `NodePort`, namun
 resiko berpotensi penyebaran lalu lintas yang tidak merata.
-* `service.spec.healthCheckNodePort` - menentukan cek kesehatan _node_ porta (nomor porta numerik) untuk servis.
-Jika `healthCheckNodePort` tidak ditentukan, pengendali servis mengalokasi
-porta dari rentang _NodePort_ dari klaster kamu. Kamu dapat mengonfigurasi
+* `service.spec.healthCheckNodePort` - menentukan pemeriksaan kesehatan porta dari sebuah Node (angka porta numerik) untuk Service.
+Jika `healthCheckNodePort` tidak ditentukan, pengendali Service mengalokasi
+porta dari rentang `NodePort` dari klaster kamu. Kamu dapat mengonfigurasi
 rentangan tersebut dari pengaturan opsi barisan perintah API server,
 `--service-node-port-range`. Hal itu menggunakan nilai `healthCheckNodePort` pengguna spesifik
-jika ditentukan oleh klien. Hal itu dapat berefek hanya ketika `type` diset ke _LoadBalancer_ dan
-`externalTrafficPolicy` diset ke Local.
+jika ditentukan oleh klien. Hal itu dapat berefek hanya ketika `type` diset ke `LoadBalancer` dan
+`externalTrafficPolicy` diset ke `Local`.
 
-Pengaturan `externalTrafficPolicy` ke Local pada berkas konfigurasi Service mengaktifkan
+Pengaturan `externalTrafficPolicy` ke `Local` pada berkas konfigurasi Service mengaktifkan
 fitur ini.
 
 ```yaml
@@ -148,49 +148,49 @@ spec:
   type: LoadBalancer
 ```
 
-## Pengumpul Sampah Load Balancers
+## Pengumpul Sampah (Garbage Collector) Load Balancer
 
 {{< feature-state for_k8s_version="v1.17" state="stable" >}}
 
-Pada kasus biasa, sumber daya _load balancer_ yang berkorelasi pada penyedia _cloud_ perlu
+Pada kasus biasa, sumber daya _load balancer_ yang berkorelasi pada penyedia cloud perlu
 dibersihkan segera setelah Service bertipe _LoadBalancer_ dihapus. Namun perlu diketahui
-bahwa terdapat kasus tepi dimana sumber daya _cloud_ yatim piatu (_orphaned_) setelah
+bahwa terdapat kasus tepi dimana sumber daya cloud yatim piatu (_orphaned_) setelah
 Service yang berkaitan dihapus. _Finalizer Protection_ untuk Service _LoadBalancer_
 diperkenalkan untuk mencegah hal ini terjadi. Dengan menggunakan _finalizers_, sebuah sumber daya Service
 tidak akan pernah dihapus hingga sumber daya _load balancer_ yang berkorelasi juga dihapus.
 
-Secara khusus, jika Service mempunyai `type` _LoadBalancer_, pengendali servis akan melekatkan
+Secara khusus, jika Service mempunyai `type LoadBalancer`, pengendali Service akan melekatkan
 _finalizer_ bernama `service.kubernetes.io/load-balancer-cleanup`.
 _Finalizer_ hanya akan dihapus setelah sumber daya _load balancer_ dibersihkan.
 Hal ini mencegah sumber daya _load balancer_ yang teruntai bahkan setelah kasus tepi seperti
-pengendali servis berhenti.
+pengendali Service berhenti.
 
 ## Penyedia Load Balancer Eksternal
 
 Penting untuk dicatat bahwa jalur data untuk fungsionalitas ini disediakan oleh _load balancer_ eksternal ke klaster Kubernetes.
 
-Ketika Service `type` diset `LoadBalancer`, Kubernetes menediakan fungsionalitas yang ekuivalen dengan `type` sebanding ClusterIP
-ke _pods_ dalam klaster dan mengekstensinya dengan pemrograman (eksternal ke Kubernetes) _load balancer_ dengan entri pada pods
-Kubernetes. Pengendali servis Kubernetes mengotomasi pembuatan _load balancer_ eksternal, cek kesehatan (jika dibutuhkan),
-dinding api (jika dibutuhkan), dan mengambil IP eksternal yang dialokasikan oleh penyedia _cloud_ dan mengisinya pada objek servis.
+Ketika Service `type` diset `LoadBalancer`, Kubernetes menyediakan fungsionalitas yang ekuivalen dengan `type` sebanding `ClusterIP`
+ke berbagai Pod di dalam klaster dan mengekstensinya dengan pemrograman (eksternal dari Kubernetes) _load balancer_ dengan entri pada Pod
+Kubernetes. Pengendali Service Kubernetes mengotomasi pembuatan _load balancer_ eksternal, cek kesehatan (jika dibutuhkan),
+dinding api (_firewall_) (jika dibutuhkan), dan mengambil IP eksternal yang dialokasikan oleh penyedia cloud dan mengisinya pada objek Service.
 
 ## Peringatan dan and Limitasi ketika preservasi sumber IP
 
 _Load balancers_ GCE/AWS tidak menyediakan bobot pada kolam targetnya. Hal ini bukan merupakan isu dengan aturan kube-proxy
-LB lama yang akan menyeimbangkan semua titik akhir dengan benar.
+_Load balancer_ lama yang akan menyeimbangkan semua titik akhir dengan benar.
 
-Dengan fungsionalitas yang baru, lalu lintas eksternal tidak menyeimbangkan beban secara merata pada seluruh pods, namun
-sebaliknya menyeimbangkan secara merata pada level _node_ (karena GCE/AWS dan implementasi LB eksternal lainnya tidak mempunyai
-kemampuan untuk menentukan bobot setiap _node_, mereka menyeimbangkan secara merata pada semua _node_ target, mengabaikan jumlah
-_pods_ pada tiap _node_).
+Dengan fungsionalitas yang baru, lalu lintas eksternal tidak menyeimbangkan beban secara merata pada seluruh Pod, namun
+sebaliknya menyeimbangkan secara merata pada level Node (karena GCE/AWS dan implementasi _load balancer_ eksternal lainnya tidak mempunyai
+kemampuan untuk menentukan bobot setiap Node, mereka menyeimbangkan secara merata pada semua Node target, mengabaikan jumlah
+Pod pada tiap Node).
 
 
-Namun demikian, kita dapat menyatakan bahwa NumServicePods << NumNodes or NumServicePods >> NumNodes, distribusi yang cukup mendekati
+Namun demikian, kita dapat menyatakan bahwa NumServicePods << NumNodes atau NumServicePods >> NumNodes, distribusi yang cukup mendekati
 sama akan terlihat, meski tanpa bobot.
 
-Sekali _load balancers_ eksternal menyediakan bobot, fungsionalitas ini dapat ditambahkan pada jalur pemrograman LB.
+Sekali _load balancer_ eksternal menyediakan bobot, fungsionalitas ini dapat ditambahkan pada jalur pemrograman _load balancer_.
 *Pekerjaan Masa Depan: Tidak adanya dukungan untuk bobot yang disediakan untuk rilis 1.4, namun dapat ditambahkan di masa mendatang*
 
-_Pod_ internal ke lalu lintas _pod_ harus berperilaku sama seperti servis ClusterIP, dengan probabilitas yang sama pada seluruh _pods_. 
+Pod internal ke lalu lintas Pod harus berperilaku sama seperti Service ClusterIP, dengan probabilitas yang sama pada seluruh Pod. 
 
 {{% /capture %}}