Panduan cepat layanan - Container Service for Kubernetes

Dalam Kubernetes, Service adalah abstraksi yang mengekspos aplikasi yang berjalan pada sekelompok Pod sebagai layanan jaringan. Service menyediakan nama DNS terpadu untuk Pod tersebut dan mengaktifkan load balancing di antara mereka. Topik ini menjelaskan cara kerja Service Kubernetes, pertimbangan utama, serta rekomendasi dalam memilih tipe Service.

Istilah

Service

Mengakses Pod secara langsung setelah dibuat menimbulkan beberapa masalah:

Controller, seperti Deployment, dapat menghapus dan membuat ulang Pod kapan saja, sehingga hasil akses menjadi tidak dapat diprediksi.
Alamat IP Pod ditetapkan secara dinamis saat startup dan tidak dapat diketahui sebelumnya.
Aplikasi sering terdiri dari beberapa Pod yang menjalankan image program yang sama. Mengakses setiap Pod secara individual tidak praktis.

Untuk mengatasi masalah ini, Kubernetes menyediakan objek Service. Objek Service menawarkan antarmuka jaringan yang stabil dan alamat IP persisten untuk Pod. Service mengidentifikasi sekelompok Pod target menggunakan label selector dan mendistribusikan trafik secara merata ke seluruh Pod melalui load balancing. Pendekatan ini menyelesaikan masalah akses Pod langsung serta memastikan ketersediaan tinggi dan efisiensi operasional untuk aplikasi.

Endpoint

Dalam Kubernetes, Endpoint adalah resource penting yang digunakan Service untuk penemuan layanan. Endpoint melacak perubahan Pod yang sesuai dengan selector Service secara real time. Saat Pod dihapus atau dibuat ulang, alamat IP-nya berubah. Endpoint segera memperbarui alamat IP dan informasi port Pod yang tersimpan untuk memastikan Service mengarahkan trafik ke Pod terbaru.

IPVS

IPVS adalah load balancer berbasis fitur LVS (Linux Kernel). IPVS menangani trafik Service dengan membuat alamat IP virtual dan mendistribusikan trafik ke Pod backend.

Dalam Kubernetes, saat Anda membuat Service, kube-proxy menetapkan aturan dalam tabel IPVS. Aturan ini menentukan cara meneruskan trafik dari alamat IP virtual pada node Kubernetes ke Pod backend. Anda dapat melihat tabel routing dan aturan IPVS saat ini pada node kluster menggunakan perintah ipvsadm.

Penting

Jika tool ipvsadm belum diinstal, Anda dapat menjalankan perintah sudo yum install ipvsadm untuk menginstalnya.

iptables

iptables bekerja melalui serangkaian tabel dan rantai yang dapat dikonfigurasi. Setiap rantai berisi sekumpulan aturan yang mengontrol aliran paket.

Dalam Kubernetes, saat Anda membuat Service, kube-proxy menambahkan aturan yang sesuai ke iptables. Aturan ini meneruskan paket ke Pod yang tepat berdasarkan label selector Service. Anda dapat melihat tabel pengalihan dan aturan iptables saat ini pada node kluster menggunakan perintah iptables -t nat -L.

Tipe Service

Penting

Saat versi Cloud Controller Manager adalah v2.5.0 atau lebih baru, pembuatan instans Classic Load Balancer (CLB) di Konsol merupakan fitur daftar putih. Fitur ini hanya mendukung metode penagihan pay-as-you-go. Untuk membuat Service bertipe CLB di Konsol, Anda dapat mengajukan permintaan melalui Quota Platform.

Nama	Deskripsi	Skenario	Penagihan
ClusterIP	Tipe Service default. Service ClusterIP menetapkan alamat IP virtual yang hanya dapat diakses dari dalam kluster.	Tipe Service ini digunakan ketika layanan hanya perlu berkomunikasi di dalam kluster dan tidak memerlukan eksposur eksternal. Sebagai contoh, Pod aplikasi frontend yang dideploy di kluster mungkin perlu mengakses database backend yang juga dideploy di kluster yang sama. Database backend tersebut dapat dijalankan sebagai Service ClusterIP.	Tidak dikenai biaya.
NodePort	Service NodePort membuka port pada setiap node di kluster. Hal ini memungkinkan akses eksternal ke Service melalui `<NodeIP>:<NodePort>`. Mekanisme ini beroperasi pada Lapisan 4 (lapisan transport) Model OSI.	Untuk aplikasi sementara atau bertrafik rendah, Anda dapat mengekspos port ke jaringan eksternal. Sebagai contoh, Anda dapat menggunakan Service NodePort untuk mendeploy dan men-debug aplikasi web selama pengujian. Berbeda dengan Service LoadBalancer, Service NodePort tidak menyediakan load balancing lintas node. Trafik dikirim ke satu node saja, yang dapat dengan mudah menyebabkan bottleneck sumber daya.	Tipe Service ini tidak dikenai biaya. Untuk mengaktifkan akses jaringan publik, Anda dapat menyambungkan EIP ke node tersebut. Untuk informasi lebih lanjut tentang penagihan EIP, lihat Ikhtisar penagihan.
LoadBalancer	Tipe Service LoadBalancer membangun di atas tipe Service NodePort dengan menambahkan load balancer eksternal. Hal ini memungkinkan distribusi lancar trafik eksternal ke beberapa Pod di kluster. Service secara otomatis menyediakan alamat IP eksternal yang dapat digunakan klien untuk mengakses layanan. Service ini mendukung baik trafik TCP dan UDP Lapisan 4 (lapisan transport) maupun manajemen trafik HTTP dan HTTPS Lapisan 7 (lapisan aplikasi).	Tipe Service ini digunakan saat Anda menjalankan aplikasi di cloud publik dan memerlukan titik masuk eksternal yang stabil serta mudah dikelola. Sebagai contoh, Anda dapat menggunakan tipe Service ini untuk layanan publik di lingkungan produksi yang harus menangani volume besar trafik eksternal dan memastikan ketersediaan tinggi, seperti aplikasi web atau layanan API. Penting Saat mengakses Service dari dalam kluster Kubernetes, kami merekomendasikan penggunaan Service `ClusterIP`. Ini merupakan pendekatan yang paling stabil, efisien, dan sesuai desain. Sebaliknya, mengakses Service `LoadBalancer` secara langsung dari dalam kluster memberikan hasil yang tidak konsisten. Ketersediaannya bergantung pada berbagai faktor, seperti: Implementasi LoadBalancer oleh penyedia cloud. Plugin jaringan kontainer (CNI) yang digunakan kluster, seperti Flannel, Terway, atau Cilium. Mode operasi (iptables atau IPVS) dan versi `kube-proxy`. Pengaturan `externalTrafficPolicy` Service (`Cluster` atau `Local`). Oleh karena itu, perilaku saat mengakses alamat IP LoadBalancer dari dalam kluster dapat sangat bervariasi di berbagai lingkungan atau versi Kubernetes. Dalam beberapa kasus, alamat IP bahkan mungkin menjadi tidak dapat dijangkau. Contoh skenario: Flannel + IPVS + externalTrafficPolicy=Local Dalam kluster yang menggunakan Flannel sebagai plugin CNI, ketika Service `LoadBalancer` dikonfigurasi dengan `externalTrafficPolicy: Local`: Jika Anda mengakses alamat IP eksternal LoadBalancer dari node kluster yang tidak menjalankan Pod backend apa pun: Versi Kubernetes sebelum 1.24: Permintaan tidak diteruskan dengan benar dan akses gagal. Kubernetes 1.24 dan seterusnya: `kube-proxy` dapat fallback ke perilaku `Cluster` dalam mode `Local` untuk mendukung akses internal kluster. Permintaan berhasil diteruskan ke Pod backend di node lain, dan akses berhasil.	Anda dikenai biaya untuk instans Server Load Balancer. Untuk informasi lebih lanjut, lihat Ikhtisar penagihan CLB dan Aturan penagihan NLB.
Headless Service	Headless Service tidak memiliki alamat IP virtual. Saat Anda melakukan kueri DNS untuk Service tersebut, daftar alamat IP Pod dikembalikan alih-alih satu alamat IP Service. Hal ini memungkinkan penemuan langsung dan koneksi ke Pod tertentu.	Aplikasi perlu berkomunikasi langsung dengan Pod backend tertentu (bukan melalui agen atau load balancer). Sebagai contoh, saat Anda mendeploy aplikasi berstatus seperti ClickHouse, Anda dapat menggunakan Headless Service agar Pod aplikasi dapat langsung mengakses setiap Pod ClickHouse. Hal ini memungkinkan Pod membaca data secara merata atau menulis data secara selektif, sehingga meningkatkan efisiensi pemrosesan data.	Tidak dikenai biaya.
ExternalName	Service ExternalName memetakan nama layanan internal di kluster ke nama domain eksternal. Pemetaan ini memungkinkan Pod di dalam kluster mengakses domain eksternal menggunakan nama Service tersebut.	Kluster perlu mengakses layanan yang diekspos di nama domain publik. Sebagai contoh, jika Pod aplikasi perlu mengakses domain database eksternal, Anda dapat menggunakan Service ExternalName untuk memetakan domain tersebut ke nama Service internal. Hal ini memungkinkan akses langsung dari dalam kluster menggunakan nama Service tersebut.	Tidak dikenai biaya.

Cara kerja Service

ClusterIP

Pembuatan dan penugasan
Saat Anda membuat Service ClusterIP di kluster ACK, lapisan kontrol kluster menetapkan alamat IP virtual (ClusterIP) yang hanya dapat diakses dari dalam kluster.
Pengalihan trafik
Saat Anda mengakses ClusterIP, kube-proxy menangkap trafik dan meneruskannya ke Pod backend menggunakan penjadwalan round-robin.
Penemuan layanan
Saat Anda membuat Service ClusterIP, CoreDNS mendaftarkan rekaman DNS. Hal ini memungkinkan akses melalui resolusi nama layanan. Formatnya adalah service-name.namespace.svc.cluster.local:port, misalnya, nginx.default.svc.cluster.local:80.
Label Pod dan pelacakan endpoint
Setiap Service didefinisikan oleh label selector yang menentukan Pod mana yang termasuk dalam backend-nya.
Lapisan kontrol kluster memantau perubahan Pod secara real time. Saat Pod yang sesuai dengan label selector Service ditambahkan, diperbarui, atau dihapus, lapisan kontrol memperbarui Endpoint.

NodePort

Pembuatan dan penugasan
Saat Anda membuat Service NodePort, kluster membuka port (NodePort) pada setiap node untuk memungkinkan akses eksternal.
Pengalihan trafik
kube-proxy mendengarkan NodePort, yang secara otomatis dipilih dari rentang default 30000 hingga 32767. NodePort tersebut mengarahkan permintaan eksternal ke ClusterIP lalu ke Pod backend.
Akses eksternal
Anda dapat mengakses Service menggunakan alamat IP node dan NodePort statis dalam format <NodeIP>:<NodePort> sebagai titik akhir eksternal.

LoadBalancer

Pembuatan dan penugasan
Saat Anda membuat Service LoadBalancer, lapisan kontrol kluster secara otomatis berinteraksi dengan layanan load balancing untuk membuat instans load balancer guna menangani trafik. Untuk informasi lebih lanjut, lihat Ekspos aplikasi menggunakan Service dengan Server Load Balancer yang sudah ada dan Ekspos aplikasi menggunakan Service dengan Server Load Balancer yang dibuat secara otomatis.
Pengalihan trafik
Saat trafik eksternal mencapai alamat IP eksternal instans load balancer, trafik tersebut diarahkan ke port pada node lalu diteruskan ke Pod backend oleh kube-proxy.
Konfigurasi routing dan pemeriksaan kesehatan
Load balancer secara otomatis mengonfigurasi port pendengar dan melakukan pemeriksaan kesehatan untuk memastikan trafik hanya diarahkan ke Pod yang sehat.

Kebijakan trafik eksternal

Service LoadBalancer dan NodePort mendukung konfigurasi externalTrafficPolicy untuk mengontrol cara trafik eksternal diarahkan ke Service. Pengaturan ini memiliki perilaku berbeda di kluster yang menggunakan Terway dan kluster yang menggunakan Flannel.

Catatan

Masuk ke Konsol Container Service for Kubernetes (ACK). Pada halaman Clusters, klik nama kluster target. Pada tab Basic Information, Anda dapat melihat plugin jaringan kontainer yang digunakan oleh kluster tersebut.

Plugin jaringan Flannel

Item perbandingan	Local	Cluster
Perilaku penambahan backend load balancer	Hanya node yang menjalankan Pod yang ditambahkan ke backend load balancer.	Semua node di kluster ditambahkan ke backend load balancer.
Penggunaan kuota load balancer	Mode ini menggunakan kuota load balancer lebih sedikit. Untuk informasi lebih lanjut, lihat Batas kuota.	Menambahkan semua node kluster ke backend load balancer menghabiskan kuota dalam jumlah besar. Untuk informasi lebih lanjut, lihat Batas kuota.
Akses internal kluster ke Service	Hanya node yang menjalankan Pod backend untuk Service tersebut yang dapat mengaksesnya.	Node mana pun di kluster dapat mengakses Service tersebut.
Load balancing Pod	Pod tidak diseimbangkan secara default. Untuk menyeimbangkan trafik di seluruh Pod, Anda dapat menentukan penjadwal wrr dengan menambahkan anotasi `service.beta.kubernetes.io/alibaba-cloud-loadbalancer-scheduler:"wrr"` ke Service.	Pod diseimbangkan secara default.
Pertahankan IP sumber	Didukung.	Tidak didukung.
Persistensi sesi	Didukung.	Tidak didukung.
Skenario	Mode ini cocok untuk aplikasi yang memerlukan pelestarian alamat IP sumber klien, misalnya untuk tujuan logging.	Mode ini cocok untuk skenario di mana ketersediaan tinggi sangat penting dan pelestarian alamat IP sumber tidak diperlukan, misalnya untuk kluster aplikasi web berskala besar.

Plugin jaringan Terway

Item perbandingan	Local	Cluster
Perilaku penambahan backend load balancer	Pod langsung ditambahkan ke backend load balancer.
Penggunaan kuota load balancer	Hanya Pod aplikasi yang ditambahkan, sehingga menghasilkan konsumsi kuota lebih rendah. Untuk detailnya, lihat Batas kuota.
Akses internal kluster ke Service	Saat mengakses Service dari dalam kluster, trafik melewati kube-proxy pada node dan tunduk pada pengaturan `externalTrafficPolicy`. Hanya node yang menjalankan Pod backend untuk Service tersebut yang dapat mengaksesnya.	Node mana pun di kluster dapat mengakses Service tersebut.
Load balancing Pod	Pod diseimbangkan secara default.
Pertahankan IP sumber	Didukung.
Persistensi sesi	Didukung.

Pertimbangan

Sebelum menggunakan fitur load balancing Service, perhatikan hal-hal berikut. Untuk informasi lebih lanjut, lihat Pertimbangan untuk konfigurasi load balancing Service.

Container Service for Kubernetes：Panduan cepat layanan