Apply suggestions from code review

Co-authored-by: Giri Kuncoro <girikuncoro@users.noreply.github.com>
This commit is contained in:
Dery Rahman Ahaddienata 2020-06-12 05:37:28 +07:00
parent 959f1a39ac
commit 9e182b6199
1 changed files with 44 additions and 44 deletions

View File

@ -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,7 +58,7 @@ 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
@ -66,16 +66,16 @@ 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 %}}