Membuat Load Balancer Eksternal
Laman ini menjelaskan bagaimana membuat Load Balancer Eksternal.
Catatan:
Fitur ini hanya tersedia untuk penyedia cloud atau lingkungan yang mendukung 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:
Untuk melihat versi, tekankubectl 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: 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
:
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
.
Catatan:
Jika kamu menjalankan Service dari Minikube, kamu dapat menemukan alamat IP dan porta yang ditetapkan dengan: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) danLocal
.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 keduaLoadBalancer
dan Service dengan tipeNodePort
, namun resiko berpotensi penyebaran lalu lintas yang tidak merata.service.spec.healthCheckNodePort
- menentukan pemeriksaan kesehatan porta dari sebuah Node (angka porta numerik) untuk Service. JikahealthCheckNodePort
tidak ditentukan, pengendali Service mengalokasi porta dari rentangNodePort
dari klaster kamu. Kamu dapat mengonfigurasi rentangan tersebut dari pengaturan opsi barisan perintah API server,--service-node-port-range
. Hal itu menggunakan nilaihealthCheckNodePort
pengguna spesifik jika ditentukan oleh klien. Hal itu dapat berefek hanya ketikatype
diset keLoadBalancer
danexternalTrafficPolicy
diset keLocal
.
Pengaturan externalTrafficPolicy
ke Local
pada berkas konfigurasi Service mengaktifkan
fitur ini.
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
Kubernetes v1.17 [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.