Service

Autopilot Standard

---

Halaman ini menjelaskan Service Kubernetes dan penggunaannya di Google Kubernetes Engine (GKE). Ada berbagai jenis Service yang dapat Anda gunakan untuk mengelompokkan serangkaian endpoint Pod ke dalam satu resource. Untuk mempelajari cara membuat Service, lihat Mengekspos aplikasi menggunakan layanan.

Apa yang dimaksud dengan Service Kubernetes?

Tujuan dari Service adalah mengelompokkan set endpoint Pod ke dalam satu resource. Anda dapat mengonfigurasi berbagai cara untuk mengakses pengelompokan. Secara default, Anda mendapatkan alamat IP cluster stabil yang dapat digunakan klien di dalam cluster untuk menghubungi Pod di Service. Klien mengirim permintaan ke alamat IP yang stabil, dan permintaan tersebut dirutekan ke salah satu Pod di Service.

Service mengidentifikasi Pod anggotanya dengan pemilih. Agar Pod dapat menjadi anggota Service, Pod harus memiliki semua label yang ditentukan dalam pemilih. Label adalah pasangan nilai kunci arbitrer yang dilampirkan ke sebuah objek.

Manifes Service berikut memiliki pemilih yang menentukan dua label. Kolom selector menyatakan setiap Pod yang memiliki label app: metrics dan label department:engineering adalah anggota Service ini.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: metrics
    department: engineering
  ports:
  ...

Mengapa menggunakan Service Kubernetes?

Dalam cluster Kubernetes, setiap Pod memiliki alamat IP internal. Tapi Pod di Deployment itu datang dan pergi, dan alamat IP-nya berubah. Jadi, tidak masuk akal menggunakan alamat IP Pod secara langsung. Dengan Service, Anda mendapatkan alamat IP stabil yang berlaku selama masa pakai Service, meskipun alamat IP Pod anggota berubah.

Service juga menyediakan load balancing. Klien memanggil satu alamat IP yang stabil, dan permintaannya diseimbangkan di seluruh Pod yang menjadi anggota Service.

Jenis Service Kubernetes

Ada lima jenis Service:

• ClusterIP (default): Klien internal mengirim permintaan ke alamat IP internal yang stabil.

• NodePort: Klien mengirim permintaan ke alamat IP sebuah node pada satu atau beberapa nilai nodePort yang ditentukan oleh Service.

• LoadBalancer: Klien mengirim permintaan ke alamat IP load balancing jaringan.

• ExternalName: Klien internal menggunakan nama DNS Service sebagai alias untuk nama DNS eksternal.

• Headless: Anda dapat menggunakan layanan headless saat menginginkan pengelompokan Pod, tetapi tidak memerlukan alamat IP yang stabil.

Jenis NodePort adalah ekstensi dari jenis ClusterIP. Jadi, Service jenis NodePort memiliki alamat IP cluster.

Jenis LoadBalancer adalah ekstensi dari jenis NodePort. Jadi, Service jenis LoadBalancer memiliki alamat IP cluster dan satu atau beberapa nilai nodePort.

Service dari jenis ClusterIP

Saat Anda membuat Service jenis ClusterIP, Kubernetes akan membuat alamat IP stabil yang dapat diakses dari node di cluster.

Berikut adalah manifes untuk Service jenis ClusterIP:

apiVersion: v1
kind: Service
metadata:
  name: my-cip-service
spec:
  selector:
    app: metrics
    department: sales
  type: ClusterIP
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Anda dapat membuat Service menggunakan kubectl apply -f [MANIFEST_FILE]. Setelah membuat Service, Anda dapat menggunakan kubectl get service untuk melihat alamat IP yang stabil:

NAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)
my-cip-service   ClusterIP   10.11.247.213   none          80/TCP

Klien di cluster memanggil Service menggunakan alamat IP cluster dan port TCP yang ditentukan dalam kolom port di manifes Service. Permintaan diteruskan ke salah satu Pod anggota di port TCP yang ditentukan di kolom targetPort. Untuk contoh sebelumnya, klien memanggil Service di 10.11.247.213 pada port TCP 80. Permintaan diteruskan ke salah satu Pod anggota di port TCP 8080. Pod anggota harus memiliki container yang memproses TCP port 8080. Jika tidak ada container yang memproses di port 8080, klien akan melihat pesan seperti "Gagal terhubung" atau "Situs ini tidak dapat dijangkau".

Service jenis NodePort

Saat Anda membuat Service jenis NodePort, Kubernetes memberi Anda nilai nodePort. Kemudian, Service dapat diakses menggunakan alamat IP node mana pun beserta nilai nodePort.

Berikut manifes untuk Service jenis NodePort:

apiVersion: v1
kind: Service
metadata:
  name: my-np-service
spec:
  selector:
    app: products
    department: sales
  type: NodePort
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Setelah membuat Service, Anda dapat menggunakan kubectl get service -o yaml untuk melihat spesifikasinya dan melihat nilai nodePort.

spec:
  clusterIP: 10.11.254.114
  externalTrafficPolicy: Cluster
  ports:
  - nodePort: 32675
    port: 80
    protocol: TCP
    targetPort: 8080

Klien eksternal memanggil Service menggunakan alamat IP eksternal node bersama dengan port TCP yang ditentukan oleh nodePort. Permintaan diteruskan ke salah satu Pod anggota di port TCP yang ditentukan oleh kolom targetPort.

Misalnya, alamat IP eksternal dari salah satu node cluster adalah 203.0.113.2. Kemudian untuk contoh sebelumnya, klien eksternal memanggil Service di 203.0.113.2 pada port TCP 32675. Permintaan diteruskan ke salah satu Pod anggota di TCP port 8080. Pod anggota harus memiliki container yang memproses port TCP 8080.

Jenis Service NodePort adalah ekstensi dari jenis Service ClusterIP. Jadi, klien internal memiliki dua cara untuk memanggil Service:

• Gunakan clusterIP dan port.
• Gunakan alamat IP node dan nodePort.

Untuk beberapa konfigurasi cluster, Load Balancer Aplikasi eksternal menggunakan Service jenis NodePort.

Untuk mengetahui informasi selengkapnya, lihat Menyiapkan Load Balancer Aplikasi eksternal dengan Ingress.

Load Balancer Aplikasi eksternal adalah server proxy, dan pada dasarnya berbeda denganLoad Balancer Jaringan passthrough eksternal yang dijelaskan dalam topik ini berdasarkan Service jenis LoadBalancer.

Catatan: Anda dapat menentukan nilai nodePort Anda sendiri dalam rentang 30000--32767. Namun, sebaiknya hapus kolom ini dan biarkan Kubernetes mengalokasikan nodePort untuk Anda. Tindakan ini akan menghindari konflik antar-Service.

Service jenis LoadBalancer

Untuk mempelajari Service jenis LoadBalancer lebih lanjut, lihat Konsep Service LoadBalancer.

Service jenis ExternalName

Service jenis ExternalName menyediakan alias internal untuk nama DNS eksternal. Klien internal membuat permintaan menggunakan nama DNS internal, dan permintaan tersebut akan dialihkan ke nama eksternal.

Berikut manifes untuk Service jenis ExternalName:

apiVersion: v1
kind: Service
metadata:
  name: my-xn-service
spec:
  type: ExternalName
  externalName: example.com

Saat Anda membuat Service, Kubernetes akan membuat nama DNS yang dapat digunakan klien internal untuk memanggil Service. Untuk contoh sebelumnya, nama DNS-nya adalah my-xn-service.default.svc.cluster.local. Saat klien internal membuat permintaan ke my-xn-service.default.svc.cluster.local, permintaan akan dialihkan ke example.com.

Jenis Service ExternalName pada dasarnya berbeda dari jenis Service lainnya. Bahkan, Service jenis ExternalName tidak sesuai dengan definisi Service yang diberikan pada awal topik ini. Service jenis ExternalName tidak terkait dengan kumpulan Pod, dan tidak memiliki alamat IP yang stabil. Namun, Service jenis ExternalName adalah pemetaan dari nama DNS internal ke nama DNS eksternal.

Service Headless

Service headless adalah jenis Service Kubernetes yang tidak mengalokasikan alamat IP cluster. Sebagai gantinya, Service headless menggunakan DNS untuk mengekspos alamat IP Pod yang terkait dengan Service. Dengan begitu, Anda dapat terhubung langsung ke Pod, bukan melalui proxy.

Service Headless berguna untuk berbagai skenario, termasuk:

• Load balancing di seluruh pod: Anda dapat menggunakan Service headless untuk melakukan load balancing di seluruh Pod. Untuk menerapkannya, buat Service dengan pemilih yang cocok dengan Pod tempat Anda melakukan load balancing. Service kemudian akan mendistribusikan traffic secara merata ke semua Pod yang cocok dengan pemilih.

• Penemuan layanan: Anda dapat menggunakan Service headless untuk mengimplementasikan Penemuan layanan. Untuk menerapkannya, buat Service dengan nama dan pemilih. Data DNS untuk layanan headless berisi semua IP Pod di belakang Service yang cocok dengan pemilih. Klien dapat menggunakan data DNS ini untuk menemukan alamat IP Pod yang dikaitkan dengan Service.

• Akses Pod langsung: Klien dapat terhubung langsung ke Pod yang terkait dengan Service headless, yang dapat berguna untuk Service yang memerlukan akses langsung ke Pod pokok, seperti load balancer dan server DNS.

• Fleksibilitas: Service headless dapat digunakan untuk membuat beragam topologi, seperti load balancer, server DNS, dan database terdistribusi.

Jika Anda memiliki persyaratan jaringan khusus untuk workload yang tidak dapat diselesaikan menggunakan Service headless dengan pemilih, ada juga kemungkinan menggunakan Service headless tanpa pemilih. Service Headless adalah alat yang berguna untuk mengakses Service yang tidak berada dalam cluster Kubernetes itu sendiri. Karena bidang kontrol tidak membuat objek EndpointSlice. Anda dapat membaca hal ini lebih lanjut di Service tanpa pemilih

Contoh berikut adalah manifes untuk Service Headless:

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  clusterIP: None
  selector:
    app: nginx
  ports:
  - name: http
    port: 80
    targetPort: 80

Setelah membuat Service headless, Anda dapat menemukan alamat IP Pod yang dikaitkan dengan Service tersebut dengan membuat kueri DNS. Misalnya, perintah berikut mencantumkan alamat IP Pod yang terkait dengan Service nginx:

Catatan: Contoh ini mengasumsikan bahwa Pod yang dibuat diberi tag dengan label nginx.

dig +short nginx.default.svc.cluster.local

Contoh lain yang menggunakan ekspansi kueri Kubernetes:

dig +short +search nginx

Anda dapat membuat Service headless dengan satu perintah, dan Service headless mudah diperbarui dan diskalakan.

kubectl create service clusterip my-svc --clusterip="None" --dry-run=client -o yaml > [file.yaml]

Abstraksi Service

Service adalah abstraksi dalam arti bahwa bukan proses yang memantau beberapa antarmuka jaringan. Bagian dari abstraksi diimplementasikan dalam aturan iptables dari node cluster. Bergantung pada jenis Service, bagian lain dari abstraksi diterapkan oleh Load Balancer Jaringan passthrough eksternal atau Load Balancer Aplikasi eksternal.

Port Service Arbitrer

Nilai kolom port dalam manifes Service bersifat arbitrer. Namun, nilai targetPort tidak bersifat arbitrer. Setiap Pod anggota harus memiliki container yang memproses di targetPort.

Berikut adalah Service, dari jenis LoadBalancer, yang memiliki nilai port 50000:

apiVersion: v1
kind: Service
metadata:
  name: my-ap-service
spec:
  clusterIP: 10.11.241.93
  externalTrafficPolicy: Cluster
  ports:
  - nodePort: 30641
    port: 50000
    protocol: TCP
    targetPort: 8080
  selector:
    app: parts
    department: engineering
  sessionAffinity: None
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 203.0.113.200

Klien memanggil Service di 203.0.113.200 pada port TCP 50000. Permintaan ini diteruskan ke salah satu Pod anggota di port TCP 8080.

Beberapa port

Kolom ports Service adalah array objek ServicePort. Objek ServicePort memiliki kolom berikut:

• name
• protocol
• port
• targetPort
• nodePort

Jika Anda memiliki lebih dari satu ServicePort, setiap ServicePort harus memiliki nama yang unik.

Berikut adalah Service, dari jenis LoadBalancer, yang memiliki dua objek ServicePort:

apiVersion: v1
kind: Service
metadata:
  name: my-tp-service
spec:
  clusterIP: 10.11.242.196
  externalTrafficPolicy: Cluster
  ports:
  - name: my-first-service-port
    nodePort: 31233
    port: 60000
    protocol: TCP
    targetPort: 50000
  - name: my-second-service-port
    nodePort: 31081
    port: 60001
    protocol: TCP
    targetPort: 8080
  selector:
    app: tests
    department: engineering
  sessionAffinity: None
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 203.0.113.201

Catatan: Anda dapat menentukan maksimum lima port untuk layanan LoadBalancer.

Pada contoh sebelumnya, jika klien memanggil Service di 203.0.113.201 di TCP port 60000, permintaan akan diteruskan ke Pod anggota di port TCP 50000. Namun, jika klien memanggil Service di 203.0.113.201 pada port TCP 60001, permintaan akan diteruskan ke Pod anggota di port TCP 8080.

Setiap Pod anggota harus memiliki container yang memproses port TCP 50000 dan container yang memproses port TCP 8080. Ini dapat berupa satu container dengan dua thread, atau dua container yang berjalan di Pod yang sama.

Endpoint Service

Saat Anda membuat Service, Kubernetes akan membuat objek Endpoint yang memiliki nama yang sama dengan Service Anda. Kubernetes menggunakan objek Endpoint untuk melacak Pod mana yang merupakan anggota Service.

Service Single-stack dan Dual-stack

Anda dapat membuat Service IPv6 jenis ClusterIP atau NodePort. GKE mendukung Service stack ganda LoadBalancer selama Pratinjau yang tidak memiliki SLA atau dukungan teknis.

Untuk setiap jenis Service ini, Anda dapat menentukan kolom ipFamilies dan ipFamilyPolicy sebagai Service IPv4, IPv6, atau dual-stack.

Langkah berikutnya

• Pelajari Service Kubernetes lebih lanjut
• Mengekspos Aplikasi menggunakan Service
• Pelajari StatefulSets lebih lanjut
• Pelajari Ingress lebih lanjut

• Menyelesaikan tutorial Menyiapkan Load Balancer Aplikasi eksternal dengan Ingress