Pertimbangan dan kebijakan pembaruan resource CCM untuk mengonfigurasi load balancing Service - Container Service for Kubernetes

Saat Anda mengatur tipe Service menjadi LoadBalancer dengan menentukan 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). Konfigurasi mencakup resource seperti instans, listener, dan kelompok server backend. Topik ini menjelaskan pertimbangan untuk mengonfigurasi load balancing Service serta kebijakan pembaruan resource CCM.

Pertimbangan

Instans SLB mana yang dapat digunakan kembali?

Anda hanya dapat menggunakan kembali instans yang dibuat di Konsol Server Load Balancer. Anda tidak dapat menggunakan kembali instans SLB yang secara otomatis dibuat oleh cloud-controller-manager atau instans SLB lain yang dikelola oleh ACK, seperti instans yang digunakan oleh API Server.
Untuk menggunakan kembali instans SLB privat dalam kluster ACK, instans tersebut harus berada dalam VPC yang sama dengan kluster ACK. Penggunaan lintas-VPC hanya berlaku untuk instans NLB.
Tipe alamat dari instans SLB yang digunakan kembali harus sesuai dengan tipe akses Service. Jika Service diatur untuk Public Access (menggunakan anotasi service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "internet"), IP Version dari instans SLB harus Public. Jika Service diatur untuk internal access (menggunakan anotasi service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"), IP Version dari instans SLB harus Private.
Beberapa Service tidak dapat menggunakan port listener yang sama pada instans SLB yang sama.
Saat Anda menggunakan kembali instans SLB yang ada di beberapa kluster, pastikan kombinasi namespace dan nama Service bersifat unik di setiap kluster.

Pertimbangan untuk instans SLB yang dikelola CCM

CCM hanya mengonfigurasi load balancing untuk Service dengan Type=LoadBalancer. CCM tidak mengonfigurasi load balancing untuk Service dengan tipe lain.

Penting

Jika Service dengan Type=LoadBalancer diubah menjadi tipe selain LoadBalancer, CCM akan menghapus konfigurasi yang sebelumnya ditambahkan ke instans SLB. Akibatnya, Service tersebut tidak dapat diakses melalui instans SLB.

CCM menggunakan API deklaratif dan secara otomatis memperbarui konfigurasi SLB berdasarkan konfigurasi Service dalam kondisi tertentu. Setiap konfigurasi yang Anda ubah di Konsol Server Load Balancer berisiko ditimpa.

Penting

Jangan mengubah secara manual konfigurasi apa pun dari instans SLB yang dibuat dan dikelola oleh ACK di Konsol Server Load Balancer. Jika tidak, konfigurasi Anda mungkin hilang dan Service menjadi tidak dapat diakses.

Jangan menghapus atau mengubah secara manual finalizer service.k8s.alibaba/resources atau service.k8s.alibaba/nlb pada sebuah Service. Mengubah finalizer secara manual dapat mencegah resource CLB atau NLB dikembalikan dengan benar.
Jika versi Cloud Controller Manager adalah v2.5.0 atau lebih baru, opsi untuk menentukan instans CLB saat membuat Service di konsol merupakan fitur daftar putih. Untuk menggunakan fitur ini, Anda harus mengajukan permintaan di platform Quota Center.

Pertimbangan untuk mengakses IP eksternal Service LoadBalancer dari dalam kluster

Bergantung pada tipe plug-in jaringan, versi plug-in jaringan, dan versi kluster, saat Anda mengakses alamat IP SLB yang terkait dengan Service LoadBalancer dari dalam kluster, jaringan kluster mungkin mencegat traffic di node dan meneruskannya langsung ke Titik Akhir (Endpoint) layanan backend.

Proses ini melewati instans SLB eksternal. Hal ini menyebabkan konfigurasi tertentu yang bergantung pada instans SLB gagal dan dapat menimbulkan masalah akses. Skenario utama yang terpengaruh meliputi:

externalTrafficPolicy diatur ke Local: Akses ke traffic mungkin gagal karena traffic diteruskan ke node yang tidak memiliki pod backend.
Proxy Protocol diaktifkan: Layanan backend tidak dapat memperoleh header Proxy Protocol yang ditambahkan oleh instans SLB, sehingga menyebabkan kegagalan handshake protokol.
Menggunakan listener HTTP/HTTPS: Operasi yang bergantung pada instans SLB, seperti TLS termination atau penambahan header tertentu seperti X-Forwarded-For, tidak berlaku.

Oleh karena itu, untuk mengakses Service LoadBalancer dari dalam kluster:

Gunakan alamat dalam-kluster (in-cluster address) dari Service. Ini merupakan metode yang lebih standar dan stabil. Untuk komunikasi antar-layanan dalam kluster, gunakan ClusterIP Service atau nama DNS-nya, seperti <service-name>.<namespace>.svc.cluster.local.
Untuk menggunakan titik masuk SLB, akses melalui hostname. Tambahkan anotasi service.beta.kubernetes.io/alibaba-cloud-loadbalancer-hostname ke Service dan gunakan nama domain yang dikonfigurasi sebagai ganti alamat IP untuk akses. Hal ini memastikan traffic diproses dengan benar. Untuk informasi lebih lanjut tentang anotasi ini, lihat Setel hostname untuk Service.
Penting
Saat menggunakan fitur ini untuk melewati instans SLB dalam akses, hindari penjadwalan pod klien dan pod sisi server pada node yang sama. Jika tidak, akses mungkin gagal karena masalah perutean asimetris.

Pertimbangan untuk mengelola load balancing skala besar dalam satu kluster dengan CCM

Saat kluster berukuran besar, CCM memiliki keterbatasan dalam kemampuannya memproses event Service. Dalam skenario berikut, operasi seperti pembuatan atau penghapusan instans SLB serta pembaruan endpoint dalam kelompok server mungkin mengalami penundaan:

Banyak Service LoadBalancer dibuat atau dihapus secara bersamaan.
Banyak Endpoint Service diperbarui secara bersamaan.
Node ditambahkan atau dihapus secara batch saat terdapat banyak Service LoadBalancer.

Perhatikan hal-hal berikut:

Lakukan penilaian kapasitas. Sebelum melakukan perubahan skala besar, lakukan penilaian kapasitas dan uji stres. Sediakan margin pemrosesan yang cukup untuk mencegah gangguan operasi bisnis akibat penundaan.
Pastikan stabilitas traffic selama perubahan. Gunakan konfigurasi seperti readinessGates dan panggilan balik preStop untuk memastikan traffic tidak terputus selama perubahan bisnis. Untuk informasi lebih lanjut, lihat Implementasikan penyebaran bergulir tanpa downtime.
Ikuti batas kuota. Saat menggunakan banyak Service LoadBalancer, perhatikan secara ketat batas kuota CLB atau NLB. Untuk informasi lebih lanjut, lihat Batas kuota.
Perbarui komponen. Tingkatkan kluster dan CCM ke versi terbaru untuk mendapatkan manfaat dari optimasi berkelanjutan untuk skenario kluster skala besar.

Cara mengganti instans SLB untuk Service

Anda tidak dapat menggunakan kembali atau mengganti instans SLB untuk Service LoadBalancer yang sudah ada. Untuk mengganti instans SLB, Anda harus menghapus lalu membuat ulang Service tersebut.

Batas kuota

VPC

Setiap node dalam kluster berkorespondensi dengan satu entri tabel rute. Secara default, VPC hanya mendukung 200 entri tabel rute. Jika jumlah node dalam kluster Anda melebihi 200, login ke Konsol Quota Center dan kirim permohonan.
Untuk informasi lebih lanjut tentang batas VPC, lihat Batas dan kuota.
Untuk mengecek kuota VPC, lihat Manajemen kuota VPC.

Server Load Balancer

CCM membuat satu instans SLB untuk setiap Service dengan Type=LoadBalancer. Secara default, Anda dapat memiliki hingga 60 instans CLB dan 60 instans NLB. Untuk menambah kuota ini, login ke Konsol Quota Center dan kirim permohonan.
CCM menyambungkan instans ECS atau Elastic Network Interfaces (ENI) ke kelompok server backend instans SLB berdasarkan konfigurasi Service. CCM juga membuat kelompok server terpisah untuk setiap targetPort yang berbeda dalam Service. Perhatikan batas kuota berikut:
- Jumlah server backend: Secara default, Anda dapat menyambungkan hingga 200 server backend ke instans CLB dan hingga 400 server backend berbasis ECS, ENI, atau IP ke instans NLB. Kuota yang dibutuhkan dihitung sebagai berikut: Jumlah server backend × Jumlah targetPort. Untuk menambah kuota, login ke Konsol Quota Center dan kirim permohonan terlebih dahulu.
- Jumlah kali sebuah instans dapat disambungkan ke kelompok server: Secara default, instans ECS atau ENI yang sama dapat disambungkan ke maksimal 50 kelompok server backend berbeda dari instans CLB dan 200 kelompok server backend berbeda dari instans NLB. Untuk menyambungkannya ke lebih banyak kelompok server, login ke Konsol Quota Center dan kirim permohonan.
- Penggunaan kuota tambahan selama pembaruan bergulir: Selama pembaruan bergulir, pod baru dibuat sebelum pod lama dihapus. Hal ini mengonsumsi kuota tambahan. Konsumsi aktual mungkin melebihi perkiraan Anda. Sediakan kuota yang cukup terlebih dahulu.
CCM membuat listener berdasarkan port yang didefinisikan dalam Service. Secara default, Anda dapat menambahkan hingga 50 listener ke instans CLB atau NLB. Untuk menambah lebih banyak listener, login ke Konsol Quota Center dan kirim permohonan.
Untuk informasi lebih lanjut tentang batas SLB, lihat Batas CLB dan Batas NLB.
Untuk mengecek kuota SLB, lihat Manajemen kuota Server Load Balancer.

Kebijakan pembaruan instans SLB

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

Objek sumber daya	Menentukan instans SLB yang sudah ada	Instans SLB yang dikelola CCM
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 untuknya. Saat Service dihapus, CCM tidak menghapus instans SLB yang sudah ada yang Anda tentukan berdasarkan ID-nya.	CCM secara otomatis membuat dan mengonfigurasi resource seperti instans SLB, listener, dan kelompok vServer berdasarkan konfigurasi Service. Semua resource ini dikelola oleh CCM. Saat Service dihapus, CCM menghapus instans SLB yang dibuat secara otomatis.
Listener	Atur anotasi: `service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners`: Jika diatur ke `"false"`, CCM tidak mengelola konfigurasi listener apa pun untuk instans SLB. Jika diatur ke `"true"`, CCM mengelola listener berdasarkan konfigurasi Service. Jika listener sudah ada, CCM akan menimpanya.	CCM secara otomatis membuat dan mengonfigurasi kebijakan listener berdasarkan konfigurasi Service.
Kelompok server backend	Saat Endpoint backend atau node kluster yang berkorespondensi dengan Service berubah, CCM secara otomatis memperbarui kelompok vServer backend dari instans SLB. Untuk plug-in jaringan Terway, CCM secara default menyambungkan IP pod ke backend instans SLB, bukan menyambungkan node ECS. Untuk plug-in jaringan Flannel, kebijakan pembaruan kelompok server backend bervariasi tergantung pada mode Service. Mode Cluster (`spec.externalTrafficPolicy = Cluster`): Secara default, CCM menyambungkan semua node ke backend instans SLB, kecuali jika Anda mengonfigurasi backend menggunakan tag BackendLabel. Penting Instans SLB memiliki batas kuota jumlah instans SLB yang dapat digunakan setiap instans ECS. Metode ini dengan cepat menghabiskan kuota. Saat kuota habis, Service gagal melakukan rekonsiliasi. Untuk mengatasi masalah ini, gunakan Service dalam mode Local. Mode Local (`spec.externalTrafficPolicy = Local`): Secara default, CCM hanya menambahkan node tempat pod Service berada ke backend instans SLB. Hal ini mengurangi konsumsi kuota SLB dan mendukung pelestarian IP sumber Lapisan 4. Untuk plug-in jaringan Flannel, CCM tidak pernah menambahkan node master sebagai backend instans SLB. Untuk plug-in jaringan Flannel, CCM secara default tidak menghapus node yang telah di-drain (`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 operasi bisnis kritis atau data sensitif untuk mencegah penghapusan tidak disengaja dan biaya maintenance terkait. Setelah fitur ini diaktifkan, resource 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.