Membuat Load Balancer Eksternal

Laman ini menjelaskan bagaimana membuat Load Balancer Eksternal.

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

Sebelum kamu memulai

• Kamu harus memiliki klaster Kubernetes, dan perangkat baris perintah kubectl juga harus dikonfigurasikan untuk berkomunikasi dengan klastermu. Jika kamu belum memiliki klaster, kamu dapat membuatnya dengan menggunakan minikube, atau kamu juga dapat menggunakan salah satu dari tempat mencoba Kubernetes berikut ini:

  • Killercoda
  • KodeKloud
  • Bermain dengan Kubernetes

  Untuk melihat versi, tekan kubectl version.

Berkas konfigurasi

Untuk membuat load balancer eksternal, tambahkan baris di bawah ini ke berkas konfigurasi Service kamu:

type:LoadBalancer

Berkas konfigurasi kamu mungkin terlihat seperti ini:

apiVersion:v1kind:Servicemetadata:name:example-servicespec:selector:app:exampleports:- port:8765targetPort:9376type:LoadBalancer

Menggunakan kubectl

Kamu dapat membuat Service dengan perintah kubectl expose dan flag--type=LoadBalancer:

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.

Menemukan alamat IP kamu

Kamu dapat menemukan alamat IP yang telah dibuat untuk Service kamu dengan mendapatkan informasi Service melalui kubectl:

kubectl describe services example-service 

yang seharusnya menghasilkan keluaran seperti ini:

 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.

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.

apiVersion:v1kind:Servicemetadata:name:example-servicespec:selector:app:exampleports:- port:8765targetPort:9376externalTrafficPolicy:Localtype:LoadBalancer

Pengumpul Sampah (Garbage Collector) Load Balancer

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.