Gunakan Layanan untuk mengimplementasikan penemuan layanan dan load balancing - Container Service for Kubernetes

Dalam Kubernetes, Layanan adalah abstraksi yang membantu mengekspos sekelompok pod melalui jaringan. Layanan menyediakan nama domain untuk pod-pod yang diekspos serta mengimplementasikan load balancing di antara pod tersebut. Topik ini menjelaskan cara kerja Layanan, tindakan pencegahan dalam mengonfigurasi Layanan LoadBalancer, serta cara memilih jenis Layanan yang sesuai untuk mengekspos aplikasi.

Istilah

Layanan

Setelah membuat pod, Anda mungkin menghadapi masalah berikut ketika mencoba mengakses pod secara langsung:

Pod dapat dihapus dan dibuat ulang oleh pengontrolnya (seperti Deployment), sehingga akses ke pod menjadi tidak stabil.
Alamat IP dialokasikan secara dinamis setelah pod diluncurkan, sehingga alamat IP tidak dapat diprediksi sebelumnya.
Sebuah aplikasi terdiri dari beberapa pod yang menjalankan gambar yang sama, sehingga tidak praktis untuk mengakses pod individu dari suatu aplikasi.

Untuk mengatasi masalah-masalah ini, Kubernetes menyediakan objek Layanan. Layanan menyediakan antarmuka jaringan yang stabil dan alamat IP persisten untuk pod-pod yang diekspos. Layanan menggunakan pemilih label untuk memilih pod yang akan diekspos dan mengimplementasikan load balancing di antara pod tersebut. Hal ini memastikan ketersediaan tinggi serta efisiensi untuk aplikasi.

Titik Akhir

Dalam Kubernetes, titik akhir memainkan peran penting dalam implementasi penemuan layanan berdasarkan Layanan. Titik akhir melacak perubahan pada pod yang sesuai dengan pemilih label dari Layanan secara real-time. Ketika pod dihapus atau dibuat ulang, alamat IP pod berubah. Dalam kasus ini, titik akhir yang sesuai memperbarui alamat IP dan port dari pod baru untuk memastikan bahwa Layanan dapat meneruskan trafik ke pod baru.

IPVS

IP Virtual Server (IPVS) adalah load balancer berbasis Linux Virtual Server (LVS). IPVS menciptakan alamat IP virtual untuk mendistribusikan trafik yang diterima oleh Layanan ke pod backend.

Ketika Anda membuat Layanan, kube-proxy menentukan aturan routing untuk Layanan dalam tabel rute IPVS. Aturan ini menentukan bagaimana trafik diteruskan dari alamat IP virtual node ke pod backend. Anda dapat menjalankan perintah ipvsadm pada node untuk menanyakan tabel rute IPVS dan aturan routing dalam tabel tersebut.

Penting

Jika alat ipvsadm belum diinstal, Anda dapat menginstalnya dengan menjalankan perintah sudo yum install ipvsadm.

iptables

iptables menggunakan serangkaian tabel dan rantai yang dapat dikonfigurasi untuk menentukan bagaimana paket-paket diteruskan. Setiap rantai sesuai dengan satu set aturan.

Ketika Anda membuat Layanan, kube-proxy menentukan aturan routing untuk Layanan dalam tabel iptables. Aturan ini menentukan bagaimana paket-paket diteruskan ke pod yang sesuai dengan pemilih label dari Layanan. Anda dapat menjalankan perintah iptables -t nat -L pada node untuk menanyakan tabel iptables dan aturan routing dalam tabel tersebut.

Tipe Layanan

Fitur	Deskripsi	Skenario	Tagihan
ClusterIP	Tipe Layanan default. Layanan ClusterIP menggunakan alamat IP virtual intra-cluster.	Cocok untuk skenario di mana Anda hanya perlu mengekspos aplikasi di dalam cluster. Contohnya, jika sebuah pod aplikasi frontend perlu mengakses database backend di cluster yang sama, Anda dapat menggunakan Layanan ClusterIP untuk mengekspos database di dalam cluster.	Gratis.
NodePort	Layanan NodePort mengekspos port node. Anda dapat mengakses Layanan NodePort dengan mengirim permintaan ke `<NodeIP>:<NodePort>`. Layanan NodePort bekerja di Lapisan 4 model Open Systems Intercommunication (OSI).	Cocok untuk skenario di mana Anda perlu sementara mengekspos aplikasi ke Internet atau aplikasi Anda perlu menerima sejumlah kecil trafik eksternal pada port tertentu. Contohnya, jika Anda ingin menerapkan aplikasi web di lingkungan pengujian, Anda dapat menggunakan Layanan NodePort untuk mengekspos aplikasi. Dibandingkan dengan Layanan LoadBalancer, Layanan NodePort tidak mengimplementasikan load balancing di antara node. Jika Anda mengakses aplikasi menggunakan Layanan NodePort, trafik hanya diteruskan ke node tempat Anda mengirim permintaan. Dalam hal ini, kemacetan sumber daya dapat dengan mudah terjadi pada node tersebut.	Gratis. Jika Anda ingin mengaktifkan akses Internet, asosiasikan alamat IP elastis (EIP) dengan node. Untuk informasi lebih lanjut tentang tagihan EIP, lihat Ikhtisar Tagihan.
LoadBalancer	Layanan LoadBalancer mirip dengan Layanan NodePort yang dikonfigurasikan dengan load balancer. Tipe Layanan ini dapat mendistribusikan trafik secara merata ke beberapa pod. Layanan LoadBalancer secara otomatis menyediakan alamat IP publik untuk mengekspos pod backend ke akses eksternal. Layanan LoadBalancer dapat memproses permintaan TCP dan UDP di Lapisan 4 dan mengelola permintaan HTTP dan HTTPS di Lapisan 7.	Cocok untuk skenario di mana Anda ingin menyediakan ingress yang stabil dan mudah dikelola untuk aplikasi yang diterapkan di cloud. Contohnya, Anda dapat menggunakan Layanan LoadBalancer untuk mengekspos layanan publik yang diterapkan di lingkungan produksi, seperti aplikasi web dan layanan API, ke Internet. Ini memastikan ketersediaan tinggi layanan dan memungkinkan mereka menahan lonjakan trafik.	Server Load Balancer (SLB) mengenakan biaya untuk instance SLB yang digunakan oleh Layanan LoadBalancer. Untuk informasi lebih lanjut, lihat Ikhtisar Tagihan CLB dan Aturan Tagihan NLB.
Layanan Headless	Layanan headless tidak memiliki alamat IP virtual tetap. Ketika Anda mengakses pod backend dari Layanan headless, Layanan melakukan pencarian DNS dan mengembalikan daftar alamat IP. Kemudian, Anda dapat langsung terhubung ke alamat IP apa pun dalam daftar sesuai kebutuhan Anda.	Cocok untuk skenario di mana Anda perlu langsung mengakses pod backend individu menggunakan catatan DNS daripada proxy atau load balancer. Contohnya, Anda dapat menggunakan Layanan headless untuk mengekspos aplikasi ClickHouse yang diterapkan sebagai StatefulSet. Dengan cara ini, Anda dapat mengakses setiap pod dari aplikasi ClickHouse. Ini memungkinkan Anda menyeimbangkan pembacaan dan penulisan di antara pod dan meningkatkan efisiensi pemrosesan data.	Gratis.
ExternalName	Layanan ExternalName digunakan untuk memetakan Layanan ke nama domain eksternal. Ini memungkinkan pod di cluster mengakses nama domain eksternal menggunakan Layanan.	Cocok untuk skenario di mana cluster Anda perlu mengakses nama domain publik. Contohnya, jika aplikasi Anda perlu mengakses nama domain database eksternal, Anda dapat memetakan nama domain tersebut ke Layanan ExternalName. Dengan cara ini, pod aplikasi dapat mengakses nama domain menggunakan Layanan ExternalName dari dalam cluster.	Gratis.

Cara Kerja Layanan

ClusterIP

Pembuatan dan alokasi
Ketika Anda membuat Layanan ClusterIP di kluster Container Service for Kubernetes (ACK), bidang kontrol kluster mengalokasikan alamat IP virtual ke Layanan. Alamat IP ini hanya dapat diakses dari dalam kluster.
Penerusan trafik
Ketika Anda mengakses Layanan ClusterIP, permintaan ditangkap oleh kube-proxy. Kemudian, kube-proxy meneruskan permintaan ke pod backend menggunakan algoritma penjadwalan round-robin.
Penemuan layanan
Ketika Layanan ClusterIP dibuat, CoreDNS mendaftarkan catatan DNS yang memungkinkan Layanan diselesaikan dan diakses melalui namanya. Untuk mengakses Layanan ClusterIP, kirim permintaan ke endpoint dalam format Service.Namespace.svc.cluster.local:port. Contoh: nginx.default.svc.cluster.local:80.
Label pod dan pelacakan titik akhir
Setiap Layanan memiliki serangkaian pemilih label yang digunakan untuk memilih pod backend.
Bidang kontrol kluster memantau perubahan pod di kluster secara real-time. Ketika pod baru sesuai dengan pemilih label Layanan atau pod yang ada yang sesuai dengan pemilih label diperbarui atau dihapus, bidang kontrol kluster memperbarui titik akhir Layanan.

NodePort

Pembuatan dan alokasi
Ketika Anda membuat Layanan NodePort, kluster membuka port pada node untuk Layanan, memungkinkan akses eksternal.
Penerusan trafik
kube-proxy mendengarkan port yang diekspos untuk Layanan NodePort. Port ini dialokasikan secara otomatis dari rentang port tertentu (30000 hingga 32767 secara default). Ketika permintaan eksternal mencapai port pada node, kube-proxy merutekan permintaan ke Layanan ClusterIP, lalu meneruskannya ke pod backend.
Akses Eksternal
Anda dapat mengakses Layanan NodePort dengan mengirim permintaan ke endpoint eksternalnya dalam format <NodeIP>:<NodePort>.

LoadBalancer

Pembuatan dan alokasi
Ketika Anda membuat Layanan LoadBalancer, bidang kontrol kluster secara otomatis membuat instance SLB untuk Layanan. Untuk informasi lebih lanjut, lihat Gunakan instance SLB yang ada untuk mengekspos aplikasi dan Gunakan instance SLB yang dibuat secara otomatis untuk mengekspos aplikasi.
Penerusan trafik
Ketika permintaan eksternal mencapai alamat IP eksternal instance SLB, instance SLB merutekan permintaan ke port pada node. Kemudian, kube-proxy meneruskan permintaan ke pod backend.
Konfigurasi pengaturan routing dan pemeriksaan kesehatan
Instance SLB secara otomatis menggunakan port pendengaran dan melakukan pemeriksaan kesehatan, memastikan bahwa permintaan hanya dirutekan ke pod yang sehat.

Kebijakan trafik eksternal: Lokal dan Kluster

Anda dapat mengonfigurasi kebijakan trafik eksternal Layanan LoadBalancer atau NodePort dengan menentukan parameter externalTrafficPolicy. Kebijakan trafik eksternal menentukan bagaimana permintaan eksternal dirutekan ke pod backend. Dua kebijakan trafik eksternal didukung: Lokal dan Kluster. Fitur kebijakan trafik eksternal bervariasi berdasarkan plug-in jaringan yang digunakan oleh kluster. Bagian berikut menjelaskan fitur kebijakan trafik eksternal ketika Terway-Eniip atau Flannel digunakan sebagai plug-in jaringan.

Catatan

Masuk ke Konsol ACK. Pada halaman Clusters, klik nama kluster Anda. Pada tab Basic Information, Anda dapat melihat plug-in jaringan kluster di bagian Cluster Information.

Flannel

Dalam plug-in jaringan Flannel:

Lokal: Trafik hanya dirutekan ke pod pada node tempat permintaan dikirim.
Kluster: Trafik dapat dirutekan ke pod pada node lain di kluster.

Tabel berikut menjelaskan perbedaan antara kebijakan Lokal dan kebijakan Kluster.

Item	Lokal	Kluster
Server backend	Hanya node tempat pod backend diterapkan yang ditambahkan ke instance SLB sebagai server backend.	Semua node di kluster ditambahkan ke instance SLB sebagai server backend.
Kuota sumber daya SLB	Kebijakan ini mengonsumsi sedikit sumber daya SLB dan tidak memerlukan kuota sumber daya SLB yang tinggi. Untuk informasi lebih lanjut tentang kuota sumber daya SLB, lihat Kuota.	Kebijakan ini memerlukan kuota sumber daya SLB yang tinggi karena semua node di kluster ditambahkan ke instance SLB sebagai server backend. Untuk informasi lebih lanjut tentang kuota sumber daya SLB, lihat Kuota.
Akses ke alamat IP instance SLB	Hanya node tempat pod backend diterapkan yang dapat mengakses alamat IP instance SLB.	Semua node di kluster dapat mengakses alamat IP instance SLB.
Load balancing di antara pod	Secara default, load balancing di antara pod dinonaktifkan. Untuk mengaktifkan load balancing di antara pod, atur algoritma penjadwalan ke weighted round-robin (WRR) dengan menambahkan anotasi `service.beta.kubernetes.io/alibaba-cloud-loadbalancer-scheduler:"wrr"` ke file YAML Layanan.	Secara default, load balancing di antara pod diaktifkan.
Preservasi alamat IP sumber	Didukung	Tidak didukung
Persistensi sesi	Didukung	Tidak didukung
Skema penggunaan	Aplikasi yang perlu melestarikan alamat IP klien, seperti aplikasi yang perlu mencatat alamat IP klien dalam log.	Aplikasi yang memerlukan ketersediaan tinggi tetapi tidak perlu melestarikan alamat IP klien, seperti kluster aplikasi web besar.

Terway-Eniip

Jika klustermenggunakan plug-in jaringan Terway-Eniip, trafik langsung diteruskan ke pod backend, terlepas dari kebijakan trafik eksternal yang digunakan.