NodePort dan LoadBalancer

Tipe Service NodePort dan LoadBalancer sebagai opsi akses eksternal beserta trade-off masing-masing.

Daftar isi

Tipe Service NodePort dan LoadBalancer membuka jalur akses dari luar kluster menuju Pod di dalamnya. NodePort mengekspos satu port statis pada setiap Node, sedangkan LoadBalancer menyediakan load balancer eksternal di depannya. Topik ini membahas cara kerja keduanya, trade-off yang menyertai masing-masing, dan perbandingannya dengan ClusterIP, ditutup dengan skrip validasi rentang nodePort yang dapat dijalankan di sandbox. Setelah membacanya, pemilihan tipe Service dapat dilakukan sesuai jangkauan akses yang dibutuhkan.

NodePort dan rentang port 30000-32767#

Service tipe NodePort membuat setiap Node membuka satu port statis dari rentang bawaan 30000 sampai 32767. Permintaan yang ditujukan ke alamat IP satu Node pada port tersebut diteruskan ke salah satu Pod yang cocok dengan selector Service. Port ini disebut nodePort dan dapat ditetapkan sendiri pada manifest, seperti nilai 30123 pada berkas berikut.

yaml service-nodeport.yaml

apiVersion: v1
kind: Service
metadata:
  name: service-aplikasi-nodeport
spec:
  type: NodePort
  selector:
    app: aplikasi-catatan
  ports:
    - name: http
      port: 80
      targetPort: 8080
      nodePort: 30123

Bidang port tetap berarti port Service di dalam kluster, sedangkan nodePort adalah port yang dibuka pada setiap Node. Keduanya terpisah, sehingga pemanggil dari dalam kluster tetap menggunakan port 80 sementara pemanggil dari luar mengarahkan trafiknya ke port 30123. NodePort tidak menggantikan ClusterIP, melainkan membangun di atasnya. Service tipe NodePort tetap memperoleh IP virtual internal, dan nodePort yang dibuka pada setiap Node hanyalah pintu tambahan menuju penyeimbangan endpoint yang sama. Apabila tipe tersebut dikembalikan menjadi ClusterIP, komunikasi internal tidak berubah sama sekali, karena jalur internal tidak pernah bergantung pada nodePort.

Perintah berikut menerapkan manifest tersebut, menampilkan Service yang terbentuk, lalu mengujinya dari komputer di luar kluster melalui alamat satu Node.

bash

# tidak-dijalankan
# terapkan manifest Service tipe NodePort
kubectl apply -f service-nodeport.yaml
# tampilkan pemetaan port Service ke nodePort
kubectl get service
# uji akses dari komputer luar kluster melalui alamat satu Node
curl http://192.0.2.50:30123/

text Contoh keluaran

NAME                        TYPE       CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
service-aplikasi-nodeport   NodePort   10.96.43.55   <none>        80:30123/TCP   5s
{"aplikasi":"aplikasi-catatan","status":"ok"}

Trade-off NodePort#

NodePort sederhana untuk disiapkan, tetapi konsekuensinya perlu dipahami sebelum dipilih. Pertama, port yang dibuka selalu berada di rentang 30000-32767, yang jauh dari port standar 80 dan 443. URL yang dihasilkan memuat nomor port tidak lazim seperti :30123, sehingga NodePort kurang cocok disajikan langsung kepada pengguna akhir.

Kedua, satu nodePort menempati satu slot pada semua Node. Jumlah Service yang dapat diekspos dengan cara ini dibatasi oleh panjang rentang, dan port tersebut terbuka pada setiap Node, termasuk Node yang tidak menjalankan Pod tujuan sama sekali.

Konsekuensi tambahan berada pada sisi keamanan jaringan. Firewall di depan kluster perlu mengizinkan seluruh rentang 30000-32767, karena nomor port yang digunakan bergantung pada alokasi kluster. Rentang yang lebar tersebut memperluas permukaan jaringan yang harus dipantau.

Ketiga, klien perlu mengetahui alamat Node yang hidup. Node dibuat dan dihapus seiring penskalaan kluster, sehingga klien bertanggung jawab menemukan Node yang tersedia. Penyeimbangan beban antara Node bukan tanggung jawab Kubernetes, karena permintaan hanya diseimbangkan antara endpoint pada Node yang diakses. Keempat konsekuensi ini membuat NodePort paling tepat untuk pengujian, akses sementara, atau integrasi dengan penyeimbang beban yang dikelola di luar kluster.

LoadBalancer dan load balancer eksternal#

Tipe LoadBalancer membangun di atas NodePort. Pada kluster yang terintegrasi dengan penyedia cloud, controller Service meminta satu load balancer eksternal untuk Service tersebut, dan load balancer itu meneruskan trafik menuju nodePort yang dialokasikan secara otomatis. Kolom EXTERNAL-IP pada Service kemudian terisi alamat publik, sehingga pemanggil tidak perlu mengetahui daftar Node dan dapat menggunakan port standar seperti 80 dan 443.

Berkas berikut mendefinisikan Service tipe LoadBalancer untuk Pod yang sama dengan contoh sebelumnya.

yaml service-loadbalancer.yaml

apiVersion: v1
kind: Service
metadata:
  name: service-aplikasi-lb
spec:
  type: LoadBalancer
  selector:
    app: aplikasi-catatan
  ports:
    - name: http
      port: 80
      targetPort: 8080

Perintah berikut menerapkan kedua manifest lalu menampilkan status keduanya. Nilai <pending> pada kolom EXTERNAL-IP berarti load balancer masih dalam proses penyediaan.

bash

# tidak-dijalankan
# terapkan kedua manifest Service ke kluster
kubectl apply -f service-nodeport.yaml
kubectl apply -f service-loadbalancer.yaml
# tampilkan kedua Service beserta pemetaan port dan alamat eksternalnya
kubectl get service

text Contoh keluaran

NAME                        TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
service-aplikasi-lb         LoadBalancer   10.96.44.28   <pending>     80:31245/TCP   5s
service-aplikasi-nodeport   NodePort       10.96.43.55   <none>        80:30123/TCP   5s

Trade-off utamanya berada di sisi biaya dan ketersediaan. Setiap Service tipe LoadBalancer memerlukan satu load balancer eksternal, dan setiap load balancer biasanya berbayar pada penyedia cloud. Pada lab lokal seperti minikube tanpa integrasi cloud, kolom EXTERNAL-IP dapat terus berstatus <pending> karena tidak ada penyedia load balancer yang menjawab permintaan tersebut.

Perbandingan tiga tipe Service#

Tabel berikut merangkum ketiga tipe Service dalam satu pandangan. Ketiganya membangun di atas mekanisme yang sama, yaitu selector, Endpoints, dan penyeimbangan antara endpoint oleh kube-proxy, sehingga perbedaannya terletak pada jangkauan akses dan komponen tambahan yang menyertainya. Perbedaan tersebut menentukan biaya dan kompleksitas operasional yang menyertai setiap pilihan.

Aspek	ClusterIP	NodePort	LoadBalancer
Jangkauan akses	di dalam kluster	dari luar melalui alamat Node	dari luar melalui alamat publik
Port yang dipanggil	port Service, misalnya 80	nodePort pada rentang 30000-32767	port standar, misalnya 80 dan 443
Penyeimbang beban	antara endpoint oleh kube-proxy	antara endpoint pada Node yang diakses	tambahan di luar kluster
Biaya infrastruktur	tidak ada	tidak ada	satu load balancer per Service
Penggunaan khas	komunikasi antara komponen	akses lab dan pengujian	ekspos layanan publik

Aturan praktisnya berangkat dari yang paling sempit. Mulai dari ClusterIP untuk komunikasi internal antara komponen. Tambahkan NodePort apabila akses dari luar kluster dibutuhkan untuk pengujian atau alat administratif. Gunakan LoadBalancer untuk layanan yang benar-benar perlu dijangkau publik, dan gabungkan dengan Ingress apabila banyak layanan HTTP berbagi satu titik masuk.

Validasi rentang nodePort#

API server menolak manifest yang menetapkan nodePort di luar rentang yang diizinkan, dan pesan error validasinya muncul saat kubectl apply dijalankan. Rentang bawaan 30000-32767 bersifat inklusif, artinya nilai tepat pada kedua batas masih sah. Skrip berikut menguji beberapa nilai port terhadap rentang tersebut, termasuk nilai yang berada satu langkah di luar kedua batasnya.

python validasi-nodeport.py

"""Validasi port terhadap rentang NodePort bawaan 30000-32767."""
BATAS_BAWAH = 30000
BATAS_ATAS = 32767

# nilai port sampel yang diuji, termasuk nilai tepat pada kedua batas
kasus = [80, 443, 29999, 30000, 30123, 32767, 32768]

print(f"Rentang nodePort bawaan: {BATAS_BAWAH}-{BATAS_ATAS}")
print()
for port in kasus:
    if BATAS_BAWAH <= port <= BATAS_ATAS:
        status = "SAH, dapat ditetapkan sebagai nodePort"
    else:
        status = "TIDAK SAH, di luar rentang nodePort"
    print(f"  port {port:5d} : {status}")

text Keluaran

Rentang nodePort bawaan: 30000-32767

  port    80 : TIDAK SAH, di luar rentang nodePort
  port   443 : TIDAK SAH, di luar rentang nodePort
  port 29999 : TIDAK SAH, di luar rentang nodePort
  port 30000 : SAH, dapat ditetapkan sebagai nodePort
  port 30123 : SAH, dapat ditetapkan sebagai nodePort
  port 32767 : SAH, dapat ditetapkan sebagai nodePort
  port 32768 : TIDAK SAH, di luar rentang nodePort

Port 80 dan 443 ditolak karena berada di bawah batas bawah, sedangkan 32768 hanya satu nilai di atas batas atas. Hasil ini menjelaskan mengapa penyesuaian firewall untuk NodePort selalu menyasar rentang yang panjangnya 2768 port. Apabila nilai di luar rentang benar-benar dibutuhkan, rentangnya harus diubah terlebih dahulu pada konfigurasi API server, dan perubahan semacam itu jarang diperlukan. Alokasi otomatis memilih port dari sisa rentang yang tersedia, sehingga dua penerapan berturut-turut dapat menghasilkan nomor berbeda. Nilai yang ditetapkan secara eksplisit pada manifest dipertahankan sepanjang hidup Service, dan kestabilan inilah yang membuat nilai eksplisit lebih mudah dinyatakan pada aturan firewall.

Ringkasan#

NodePort membuka satu port statis pada rentang 30000-32767 di setiap Node, sehingga akses eksternal menuntut port tidak lazim dan pengetahuan tentang alamat Node yang hidup.
LoadBalancer menyediakan satu load balancer eksternal per Service dengan alamat publik dan port standar, tetapi menambah biaya per Service dan hanya berfungsi bila kluster terintegrasi dengan penyedia load balancer.
Ketiga tipe berbagi mekanisme selector, Endpoints, dan penyeimbangan antara endpoint, sehingga pemilihan tipe bergantung pada jangkauan akses, bukan pada cara Pod dipilih.

Referensi#

Service — Dokumentasi Kubernetes — Konsep tipe Service, termasuk NodePort, rentang nodePort, dan LoadBalancer.
Service v1 — Dokumentasi Kubernetes — Referensi API untuk bidang spec.ports, termasuk nodePort.