Merge pull request #21406 from deryrahman/tasks/access-application-cluster/create-external-load-balancer

ID translation for create external load balancer

Author: k8s-ci-robot

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

@@ -0,0 +1,196 @@
+---
+title: Membuat Load Balancer Eksternal
+content_template: templates/task
+weight: 80
+---
+
+
+{{% capture overview %}}
+
+Laman ini menjelaskan bagaimana membuat _Load Balancer_ Eksternal.
+
+{{< note >}}
+Fitur ini hanya tersedia untuk penyedia cloud atau lingkungan yang mendukung _load balancer_ eksternal.
+{{< /note >}}
+
+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
+servis URL yang dapat dijangkau secara eksternal, penyeimbang beban lalu lintas, terminasi SSL, dll.,
+silahkan cek dokumentasi [Ingress](/docs/concepts/services-networking/ingress/)
+
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+
+* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+## Berkas konfigurasi
+
+Untuk membuat _load balancer_ eksternal, tambahkan baris di bawah ini ke
+[berkas konfigurasi Service](/docs/concepts/services-networking/service/#loadbalancer) kamu:
+
+```yaml
+    type: LoadBalancer
+```
+
+Berkas konfigurasi kamu mungkin terlihat seperti ini:
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: example-service
+spec:
+  selector:
+    app: example
+  ports:
+    - port: 8765
+      targetPort: 9376
+  type: LoadBalancer
+```
+
+## Menggunakan kubectl
+
+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 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 Service kamu dengan mendapatkan
+informasi Service melalui `kubectl`:
+
+```bash
+kubectl describe services example-service
+```
+
+yang seharusnya menghasilkan keluaran seperti ini:
+
+```bash
+    Name:                   example-service
+    Namespace:              default
+    Labels:                 <none>
+    Annotations:            <none>
+    Selector:               app=example
+    Type:                   LoadBalancer
+    IP:                     10.67.252.103
+    LoadBalancer Ingress:   192.0.2.89
+    Port:                   <unnamed> 80/TCP
+    NodePort:               <unnamed> 32445/TCP
+    Endpoints:              10.64.0.4:80,10.64.1.5:80,10.64.2.4:80
+    Session Affinity:       None
+    Events:                 <none>
+```
+
+Alamat IP tercantum di sebelah `LoadBalancer Ingress`.
+
+{{< note >}}
+Jika kamu menjalankan Service dari Minikube, kamu dapat menemukan alamat IP dan porta yang ditetapkan dengan:
+{{< /note >}}
+
+```bash
+minikube service example-service --url
+```
+
+## Preservasi IP sumber klien
+
+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 di dalam
+spek Service (mendukung lingkungan GCE/Google Kubernetes Engine):
+
+* `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` (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 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`.
+
+Pengaturan `externalTrafficPolicy` ke `Local` pada berkas konfigurasi Service mengaktifkan
+fitur ini.
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: example-service
+spec:
+  selector:
+    app: example
+  ports:
+    - port: 8765
+      targetPort: 9376
+  externalTrafficPolicy: Local
+  type: LoadBalancer
+```
+
+## 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
+dibersihkan segera setelah Service bertipe _LoadBalancer_ dihapus. Namun perlu diketahui
+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 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 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 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 (target pools). Hal ini bukan merupakan isu dengan aturan kube-proxy
+_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 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 atau NumServicePods >> NumNodes, distribusi yang cukup mendekati
+sama akan terlihat, meski tanpa bobot.
+
+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 Service ClusterIP, dengan probabilitas yang sama pada seluruh Pod. 
+
+{{% /capture %}}