Pertimbangan untuk mengonfigurasi load balancer Service dan kebijakan pembaruan sumber daya CCM - Container Service for Kubernetes

Ketika Anda mengatur tipe Service menjadi load balancing (Type=LoadBalancer), komponen cloud-controller-manager (CCM) dari ACK membuat atau mengonfigurasi sebuah instans Server Load Balancer (SLB) untuk Service tersebut. Instans tersebut dapat berupa Classic Load Balancer (CLB) atau Network Load Balancer (NLB). Konfigurasinya mencakup sumber daya seperti instans, pendengar (listener), dan kelompok server backend. Topik ini menjelaskan pertimbangan dalam mengonfigurasi load balancer Service serta kebijakan pembaruan sumber daya oleh CCM.

Pertimbangan

Instans SLB mana yang dapat digunakan kembali?

Hanya instans SLB yang dibuat di Konsol SLB yang dapat digunakan kembali. Instans SLB yang dibuat secara otomatis oleh cloud-controller-manager tidak dapat digunakan kembali.
Jika Anda ingin menggunakan kembali instans SLB privat dalam kluster ACK, instans tersebut harus berada dalam Virtual Private Cloud (VPC) yang sama dengan kluster tersebut. Penggunaan lintas-VPC hanya didukung untuk instans NLB.
Tipe alamat pada instans SLB yang digunakan kembali harus sesuai dengan tipe akses Service. Jika Service dikonfigurasi untuk Public Network Access (service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "internet"), Address Type pada instans SLB harus Public. Jika Service dikonfigurasi untuk Internal Access (service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"), Address Type pada instans SLB harus Private.
Beberapa Service tidak dapat menggunakan port pendengar yang sama pada instans SLB yang sama.
Saat menggunakan kembali instans SLB yang sudah ada di beberapa kluster, pastikan kombinasi namespace dan nama Service bersifat unik di setiap kluster.

Pertimbangan untuk mengelola instans SLB dengan CCM

CCM hanya mengonfigurasi instans SLB untuk Service bertipe Type=LoadBalancer. CCM tidak mengonfigurasi instans SLB untuk Service bertipe lainnya.

Penting

Ketika Service bertipe Type=LoadBalancer diubah menjadi Type!=LoadBalancer, CCM akan menghapus konfigurasi yang ditambahkan untuk load balancer tersebut, sehingga Service tidak lagi dapat diakses melalui load balancer.

CCM menggunakan API deklaratif dan secara otomatis memperbarui konfigurasi SLB berdasarkan konfigurasi Service dalam kondisi tertentu. Jika Anda mengatur service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: menjadi "true", konfigurasi apa pun yang Anda ubah di Konsol SLB berisiko ditimpa.

Penting

Jangan mengubah secara manual konfigurasi apa pun pada instans SLB yang dibuat dan dikelola oleh ACK di Konsol SLB. Jika tidak, konfigurasi tersebut mungkin hilang dan Service bisa menjadi tidak dapat diakses.

Jangan menghapus atau mengubah secara manual finalizer service.k8s.alibaba/resources atau service.k8s.alibaba/nlb pada Service. Mengubah finalizer secara manual dapat mencegah sumber daya CLB atau NLB dicabut dengan benar.
Ketika versi Cloud Controller Manager adalah v2.5.0 atau lebih baru, opsi untuk menggunakan instans CLB saat membuat Service di konsol merupakan fitur daftar putih. Untuk menggunakan fitur ini, ajukan permintaan di platform Quota Center.

Pertimbangan untuk mengelola instans SLB skala besar dalam satu kluster dengan CCM

CCM memiliki batasan dalam kemampuannya memproses event Service. Di kluster besar dengan banyak node atau banyak Service bertipe LoadBalancer, CCM mungkin mengalami latensi. Hal ini dapat terjadi ketika Anda membuat atau menghapus banyak Service, mengubah banyak Endpoint Service secara bersamaan, atau menambah/menghapus node. Latensi ini memengaruhi operasi seperti pembuatan dan penghapusan instans SLB serta pembaruan Endpoint dalam kelompok server.

Untuk melakukan perubahan batch demi kebutuhan bisnis Anda, evaluasi kapasitas dan lakukan uji stres terlebih dahulu. Hal ini membantu mencegah gangguan bisnis akibat latensi pemrosesan CCM.

Bagaimana cara mengganti instans SLB untuk sebuah Service?

Anda tidak dapat menetapkan ulang instans SLB untuk Service bertipe LoadBalancer yang sudah ada. Untuk mengganti instans SLB, hapus lalu buat ulang Service tersebut.

Batasan kuota

VPC

Setiap node dalam kluster berkorespondensi dengan satu entri rute. Secara default, sebuah VPC hanya mendukung 200 entri rute. Jika kluster Anda memiliki lebih dari 200 node, log on to the Quota Center console and submit an application.
Untuk informasi lebih lanjut mengenai batasan VPC, lihat Batasan dan kuota.
Untuk menanyakan kuota VPC, lihat Manajemen kuota VPC.

Server Load Balancer

CCM membuat satu instans SLB untuk setiap Service bertipe Type=LoadBalancer. Secara default, seorang pengguna dapat memiliki hingga 60 instans. Jika Anda memerlukan lebih dari 60 instans, log on to the Quota Center console and submit an application.
CCM menyambungkan instance Elastic Compute Service (ECS) ke kelompok server backend instans SLB berdasarkan konfigurasi Service.
- Secara default, sebuah instance ECS dapat disambungkan ke 50 kelompok server backend. Jika sebuah instance ECS perlu disambungkan ke lebih banyak kelompok server backend, log on to the Quota Center console and submit an application.
- Secara default, sebuah instans SLB dapat memiliki 200 server backend. Untuk menambahkan lebih banyak server backend, log on to the Quota Center console and submit an application.
CCM membuat pendengar berdasarkan port yang didefinisikan dalam Service. Secara default, sebuah instans SLB dapat memiliki 50 pendengar. Untuk menambahkan lebih banyak pendengar, log on to the Quota Center console and submit an application.
Untuk informasi lebih lanjut mengenai batasan SLB, lihat Batasan CLB dan Batasan NLB.
Untuk menanyakan kuota SLB, lihat Manajemen kuota Server Load Balancer.

Kebijakan pembaruan instans SLB

ACK memungkinkan Anda menentukan instans SLB yang sudah ada untuk sebuah Service atau membiarkan CCM membuat instans baru secara otomatis. Kebijakan pembaruan sumber daya untuk kedua metode ini berbeda, seperti yang ditunjukkan dalam tabel berikut.

Objek sumber daya	Menentukan instans SLB yang sudah ada	Biarkan CCM mengelola instans SLB
Server Load Balancer	Atur anotasi: `service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id`. CCM menggunakan instans ini sebagai load balancer untuk Service. CCM mengonfigurasi instans SLB berdasarkan anotasi lain dan secara otomatis membuat beberapa Kelompok vServer. Ketika Service dihapus, CCM tidak menghapus instans SLB yang sudah ada yang Anda tentukan berdasarkan ID-nya.	CCM secara otomatis membuat dan mengonfigurasi sumber daya seperti instans SLB, pendengar, dan kelompok vServer berdasarkan konfigurasi Service. Semua sumber daya ini dikelola oleh CCM. Ketika Service dihapus, CCM menghapus instans SLB yang dibuat secara otomatis.
Pendengar	Atur anotasi: `service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners`: Jika diatur ke `"false"`, CCM tidak mengelola konfigurasi pendengar apa pun untuk instans SLB. Jika diatur ke `"true"`, CCM mengelola pendengar berdasarkan konfigurasi Service. Jika pendengar sudah ada, CCM akan menimpanya.	CCM secara otomatis membuat dan mengonfigurasi kebijakan pendengar berdasarkan konfigurasi Service.
Kelompok server backend	Ketika Endpoint backend Service atau node kluster berubah, CCM secara otomatis memperbarui kelompok vServer backend pada instans SLB. Untuk plugin jaringan Terway, CCM secara default menyambungkan IP Pod ke backend instans SLB, bukan menyambungkan node ECS. Untuk plugin jaringan Flannel, kebijakan pembaruan kelompok server backend bervariasi berdasarkan mode Service. Mode Cluster (`spec.externalTrafficPolicy = Cluster`): CCM secara default menyambungkan semua node ke backend instans SLB (kecuali jika Anda mengonfigurasi backend menggunakan tag BackendLabel). Penting SLB memiliki batasan kuota jumlah instans SLB tempat sebuah instance ECS dapat ditambahkan. Metode ini dengan cepat menghabiskan kuota. Ketika kuota habis, rekonsiliasi Service gagal. Untuk mengatasi masalah ini, gunakan mode Local untuk Service. Mode Local (`spec.externalTrafficPolicy = Local`): CCM secara default hanya menambahkan node yang menjalankan Pod untuk Service ke backend instans SLB. Hal ini memperlambat konsumsi kuota SLB dan mendukung pelestarian IP sumber Lapisan 4. Untuk plugin jaringan Flannel, CCM tidak pernah menambahkan node master ke backend instans SLB. Untuk plugin jaringan Flannel, CCM secara default tidak menghapus node yang telah dikosongkan (`kubectl drain`) atau tidak dapat dijadwalkan (`kubectl cordon`) dari backend instans SLB. Untuk menghapus node tersebut, atur `service.beta.kubernetes.io/alibaba-cloud-loadbalancer-remove-unscheduled-backend` ke `on`.

Aktifkan perlindungan penghapusan untuk Service

Anda dapat mengaktifkan perlindungan penghapusan untuk Service yang melibatkan bisnis kritis atau data sensitif untuk mencegah penghapusan yang tidak disengaja. Jika Anda mengaktifkan fitur ini, sumber daya terkait hanya dapat dihapus setelah Anda menonaktifkan perlindungan penghapusan secara manual. Untuk informasi lebih lanjut tentang cara mengaktifkan perlindungan penghapusan untuk Service, lihat Aktifkan perlindungan penghapusan untuk Service.