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 yang stabil dan load balancing untuk Pod tersebut. Topik ini menjelaskan cara kerja Service Kubernetes, menguraikan pertimbangan penting, serta memberikan rekomendasi untuk memilih tipe Service.

Konsep utama

Service

Mengakses Pod secara langsung setelah dibuat dapat menimbulkan beberapa masalah:

Controller, seperti Deployment, dapat menghentikan dan membuat ulang Pod kapan saja, sehingga akses langsung menjadi tidak andal.
Alamat IP Pod ditetapkan secara dinamis saat startup dan tidak dapat diprediksi sebelumnya.
Aplikasi sering terdiri dari beberapa Pod yang menjalankan image yang sama, sehingga tidak praktis mengakses setiap Pod satu per satu.

Untuk mengatasi masalah ini, Kubernetes menyediakan objek Service yang memberikan antarmuka jaringan stabil dan alamat IP persisten untuk Pod. Service menggunakan label selector untuk mengidentifikasi sekelompok Pod target dan mendistribusikan lalu lintas di antara mereka menggunakan load balancing. Pendekatan ini mengatasi masalah akses Pod langsung dan memastikan aplikasi Anda memiliki ketersediaan tinggi serta efisiensi.

Endpoint

Dalam Kubernetes, endpoint adalah resource kunci yang digunakan Service untuk penemuan layanan. Endpoint melacak perubahan pada Pod yang sesuai dengan selector Service secara real time. Ketika sebuah Pod dihapus atau dibuat ulang dan alamat IP-nya berubah, resource endpoint segera memperbarui daftar alamat IP dan port Pod tersebut. Hal ini memastikan Service selalu mengarahkan lalu lintas ke Pod yang aktif dan sehat.

IPVS

IPVS adalah load balancer berbasis fitur Linux Virtual Server (LVS) di kernel Linux. IPVS mengelola lalu lintas Service dengan membuat IP virtual yang mendistribusikan permintaan ke Pod backend.

Saat Anda membuat Service di Kubernetes, kube-proxy mengonfigurasi aturan dalam tabel IPVS. Aturan ini menentukan bagaimana lalu lintas diteruskan dari IP virtual node 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, jalankan perintah sudo yum install ipvsadm untuk menginstalnya.

iptables

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

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

nftables

nftables adalah framework penyaringan paket generasi berikutnya di kernel Linux, dirancang untuk menggantikan iptables. nftables menggunakan satu set aturan terpadu dan mekanisme pencocokan paket yang lebih efisien untuk menangani aturan lalu lintas jaringan.

Saat Anda membuat Service di kluster Kubernetes, kube-proxy menggunakan API nftables untuk membuat tabel dan rantai yang mengelola aturan pengalihan lalu lintas Service. Anda dapat melihat semua aturan dan struktur tabel nftables aktif pada node kluster menggunakan perintah nft list ruleset.

Jenis layanan

Penting

Jika versi Cloud Controller Manager adalah v2.5.0 atau lebih baru, penggunaan instans CLB untuk membuat Service di Konsol menjadi fitur daftar putih yang hanya mendukung penagihan bayar sesuai penggunaan. Untuk membuat Service tipe CLB di Konsol, ajukan permintaan di halaman Quota Center.

Nama	Deskripsi	Kasus Penggunaan	Penagihan
ClusterIP	Tipe Service default. Service ClusterIP diberikan alamat IP virtual yang hanya dapat dijangkau dari dalam kluster.	Ideal untuk layanan yang hanya perlu berkomunikasi dalam kluster yang sama. Sebagai contoh, jika Pod aplikasi frontend perlu mengakses database backend dalam kluster yang sama, Anda dapat mengekspos database tersebut sebagai Service ClusterIP.	Gratis.
NodePort	Service NodePort membuka port tertentu pada setiap node di kluster. Anda dapat mengakses Service dari luar kluster menggunakan `<NodeIP>:<NodePort>`. Mekanisme ini terutama beroperasi pada Lapisan 4 (Transport Layer) Model OSI.	Cocok untuk mengekspos layanan ke internet untuk pengembangan, pengujian, atau aplikasi berlalu lintas rendah lainnya. Sebagai contoh, Anda dapat menggunakan Service NodePort untuk men-deploy dan men-debug aplikasi web di lingkungan pengujian. Berbeda dengan Service LoadBalancer, Service ini tidak menyediakan load balancing lintas node. Lalu lintas dikirim hanya ke satu node, yang dapat dengan mudah menjadi bottleneck sumber daya.	Gratis. Untuk mengaktifkan akses internet publik, Anda harus mengaitkan EIP ke node tersebut. Untuk informasi lebih lanjut mengenai penagihan EIP, lihat Ikhtisar penagihan.
LoadBalancer	Service LoadBalancer memperluas tipe NodePort dengan menyediakan load balancer eksternal yang mendistribusikan lalu lintas ke Pod dalam kluster. Service secara otomatis menyediakan alamat IP eksternal yang dapat digunakan klien untuk mengaksesnya. Service ini mendukung manajemen lalu lintas baik Lapisan 4 (TCP/UDP) maupun Lapisan 7 (HTTP/HTTPS).	Ideal untuk aplikasi yang berjalan di cloud publik yang memerlukan titik masuk eksternal yang stabil dan mudah dikelola. Sebagai contoh, layanan publik di lingkungan produksi yang perlu diakses dari internet dan harus menangani volume besar lalu lintas eksternal dengan ketersediaan tinggi, seperti aplikasi web atau layanan API. Penting Untuk komunikasi intra-kluster, selalu gunakan Service `ClusterIP`. Ini merupakan metode yang paling stabil, efisien, dan sesuai arsitektur. Sebaliknya, mengakses Service tipe `LoadBalancer` dari dalam kluster yang sama dapat menyebabkan perilaku tidak konsisten. Ketersediaannya dipengaruhi oleh beberapa faktor, termasuk: Implementasi spesifik LoadBalancer oleh penyedia cloud. Plugin jaringan CNI yang digunakan kluster (seperti Flannel, Terway-Eniip, atau Cilium). Mode operasi (iptables, IPVS, atau nftables) dan versi `kube-proxy`. Pengaturan `externalTrafficPolicy` Service (`Cluster` atau `Local`). Oleh karena itu, mengakses IP LoadBalancer dari dalam kluster dapat sangat bervariasi atau bahkan gagal di berbagai lingkungan dan versi Kubernetes. Contoh skenario: Flannel + IPVS + externalTrafficPolicy=Local Pertimbangkan kluster yang menggunakan plugin jaringan CNI Flannel di mana Service `LoadBalancer` dikonfigurasi dengan `externalTrafficPolicy: Local`. Jika permintaan dikirim ke IP eksternal LoadBalancer dari node yang tidak memiliki Pod backend yang sesuai: Versi Kubernetes < 1.24: Permintaan tidak akan diteruskan dengan benar, dan akses akan gagal. Versi Kubernetes ≥ 1.24: `kube-proxy` dapat fallback dari perilaku `Local` ke `Cluster` untuk mendukung akses intra-kluster. Permintaan akan berhasil diteruskan ke Pod backend di node lain.	Untuk informasi mengenai biaya instans load balancing, lihat Ikhtisar Penagihan CLB Aturan penagihan NLB.
Headless Service	Headless Service tidak memiliki alamat IP virtual. Kueri DNS untuk nama layanan mengembalikan daftar alamat IP Pod, bukan satu alamat IP layanan. Hal ini memungkinkan Anda menemukan dan terhubung langsung ke Pod tertentu.	Ideal untuk aplikasi yang perlu berkomunikasi langsung dengan Pod backend tertentu, bukan melalui proxy atau load balancer. Sebagai contoh, jika Anda men-deploy aplikasi berstatus seperti layanan database ClickHouse, Anda dapat menggunakan Headless Service. Hal ini memungkinkan Pod aplikasi mengakses langsung setiap Pod ClickHouse, menyeimbangkan pembacaan data atau melakukan penulisan terarah untuk meningkatkan efisiensi pemrosesan data.	Gratis.
ExternalName	Service ExternalName memetakan nama layanan internal ke nama domain eksternal. Hal ini memungkinkan Pod di dalam kluster mengakses domain eksternal menggunakan nama layanan internal.	Ideal ketika kluster perlu mengakses layanan yang diekspos di bawah nama domain publik. Sebagai contoh, jika Pod aplikasi Anda perlu mengakses domain database eksternal, Anda dapat menggunakan Service ExternalName untuk memetakan domain tersebut ke nama layanan internal, sehingga memungkinkan akses langsung dari dalam kluster.	Gratis.

Cara kerja

ClusterIP

Pembuatan dan alokasi
Saat Anda membuat Service ClusterIP di kluster ACK, lapisan kontrol menetapkan alamat IP virtual (ClusterIP) yang hanya dapat diakses dari dalam kluster.
Pengalihan lalu lintas
Saat Anda mengakses ClusterIP, kube-proxy mencegat lalu lintas dan meneruskannya ke Pod backend menggunakan algoritma penjadwalan round-robin.
Penemuan layanan
Saat Service ClusterIP dibuat, CoreDNS mendaftarkan rekaman DNS untuknya, memungkinkan layanan diselesaikan dan diakses berdasarkan namanya. Formatnya adalah service-name.namespace.svc.cluster.local:port, misalnya, nginx.default.svc.cluster.local:80.
Label Pod dan pelacakan endpoint
Service menggunakan label selector untuk mengidentifikasi Pod backend-nya.
Lapisan kontrol terus memantau perubahan Pod. Saat Pod yang sesuai dengan label selector Service ditambahkan, diperbarui, atau dihapus, lapisan kontrol memperbarui endpoint.

NodePort

Pembuatan dan alokasi
Saat Anda membuat Service NodePort, kluster membuka port (NodePort) pada nodenya untuk memungkinkan akses eksternal.
Pengalihan lalu lintas
kube-proxy mendengarkan NodePort, yang secara otomatis dipilih dari rentang default 30000–32767. kube-proxy mengarahkan permintaan eksternal ke ClusterIP, yang kemudian meneruskannya ke Pod backend.
Akses eksternal
Anda dapat mengakses Service secara eksternal menggunakan alamat IP node dan port statis (NodePort) dalam format <NodeIP>:<NodePort>.

LoadBalancer

Pembuatan dan alokasi
Saat Anda membuat Service LoadBalancer, lapisan kontrol secara otomatis berinteraksi dengan layanan load balancing untuk membuat instans load balancer guna menangani lalu lintas. Untuk informasi lebih lanjut, lihat Gunakan instans Server Load Balancer yang sudah ada untuk mengekspos aplikasi dan Ekspos aplikasi dengan Service LoadBalancer yang disediakan secara otomatis.
Pengalihan lalu lintas
Saat lalu lintas eksternal mencapai IP eksternal instans load balancer, lalu lintas tersebut diarahkan ke port pada node. Kemudian, kube-proxy meneruskan lalu lintas tersebut ke Pod backend.
Konfigurasi entri rute dan pemeriksaan kesehatan
Load balancer secara otomatis mengonfigurasi port pendengar dan melakukan pemeriksaan kesehatan untuk memastikan lalu lintas hanya diarahkan ke Pod yang sehat.

Kebijakan lalu lintas eksternal

Service LoadBalancer dan NodePort memiliki pengaturan externalTrafficPolicy yang mengontrol bagaimana lalu lintas eksternal diarahkan. Perilaku pengaturan ini berbeda antara kluster yang menggunakan plugin jaringan Terway-Eniip dan Flannel.

Catatan

Login ke Konsol ACK. Di halaman Clusters, klik nama kluster Anda. Di tab Basic Information, Anda dapat melihat plugin jaringan CNI yang digunakan kluster Anda.

Plugin jaringan Flannel

Item	Local	Cluster
Penyambungan server backend	Hanya node yang meng-host Pod backend yang ditambahkan sebagai server backend ke load balancer.	Semua node di kluster ditambahkan sebagai server backend ke load balancer.
Kuota load balancer	Mengonsumsi lebih sedikit sumber daya kuota load balancer. Untuk informasi lebih lanjut, lihat Batas kuota.	Mengonsumsi banyak sumber daya kuota load balancer karena semua node kluster ditambahkan sebagai backend. Untuk informasi lebih lanjut, lihat Batas kuota.
Akses intra-kluster ke Service	Hanya node yang meng-host Pod backend untuk Service yang dapat mengaksesnya.	Setiap node di kluster dapat mengakses Service.
Load balancing Pod	Load balancing antar Pod dinonaktifkan secara default. Untuk mengaktifkan load balancing, atur penjadwal ke WRR dengan menambahkan anotasi `service.beta.kubernetes.io/alibaba-cloud-loadbalancer-scheduler:"wrr"` ke Service.	Load balancing antar Pod diaktifkan secara default.
Pelestarian IP sumber	Didukung.	Tidak didukung.
Persistensi sesi	Didukung.	Tidak didukung.
Kasus penggunaan	Aplikasi yang perlu melestarikan alamat IP klien asli, seperti untuk logging berdasarkan IP sumber.	Saat ketersediaan layanan tinggi diperlukan dan pelestarian IP sumber bukan menjadi perhatian, seperti pada kluster aplikasi web skala besar.

Plugin jaringan Terway-Eniip

Item	Local	Cluster
Penyambungan server backend	Pod langsung ditambahkan ke load balancer sebagai server backend.
Kuota load balancer	Mengonsumsi lebih sedikit sumber daya kuota load balancer karena hanya Pod aplikasi yang ditambahkan. Untuk informasi lebih lanjut, lihat Batas kuota.
Akses intra-kluster ke Service	Saat mengakses Service dari dalam kluster, lalu lintas melewati kube-proxy pada node dan tunduk pada `externalTrafficPolicy`. Akibatnya, hanya node yang meng-host Pod backend untuk Service yang dapat mengaksesnya.	Setiap node di kluster dapat mengakses Service.
Load balancing Pod	Load balancing antar Pod diaktifkan secara default.
Pelestarian IP sumber	Didukung.
Persistensi sesi	Didukung.

Catatan penggunaan

Sebelum menggunakan fitur load balancing Service, tinjau pertimbangan yang relevan. Untuk informasi lebih lanjut, lihat Pertimbangan untuk mengonfigurasi load balancing Service.

Container Service for Kubernetes:Panduan cepat layanan