Perbandingan Komprehensif antara API Gateways, Kubernetes Gateways, dan Service Meshes
June 9, 2023
Masih banyak kebingungan tentang API gateway, Kubernetes gateway, dan service mesh. Sebagian besar ini disebabkan oleh:
- Orang sering menyebut teknologi ini dengan kata kunci yang sama, seperti canary deployments, rate limiting, dan service discovery.
- Semua teknologi ini menggunakan reverse proxy.
- Beberapa API gateway memiliki Kubernetes gateway dan service mesh mereka sendiri, dan sebaliknya.
- Ada banyak artikel/video yang membandingkan ketiga teknologi ini dan menyimpulkan mengapa satu lebih baik daripada yang lain.
Dalam artikel ini, saya akan mencoba menjelaskan teknologi-teknologi ini dan membagikan bagaimana mereka secara fundamental berbeda dan melayani kasus penggunaan yang berbeda.
API Gateway
API gateway berada di antara aplikasi klien dan API Anda. Ia menerima semua permintaan klien, meneruskannya ke API yang diperlukan, dan mengembalikan respons ke klien dalam paket yang digabungkan.
Pada dasarnya, ini adalah reverse proxy dengan banyak kemampuan.
Selain itu, API gateway juga dapat memiliki fitur seperti autentikasi, keamanan, kontrol lalu lintas yang detail, dan pemantauan, sehingga pengembang API hanya perlu fokus pada kebutuhan bisnis.
Ada banyak solusi API gateway yang tersedia. Beberapa solusi open source populer adalah:
- Apache APISIX: API gateway berkinerja tinggi, dapat diperluas, dan cloud native yang dibangun di atas Nginx.
- Gloo Edge: API gateway yang dibangun di atas Envoy proxy.
- Kong: API gateway yang dapat dipasang plugin, juga dibangun di atas Nginx.
- Tyk: API gateway yang ditulis dalam Go yang mendukung protokol REST, GraphQL, TCP, dan gRPC.
Platform cloud seperti GCP, AWS, dan Azure juga memiliki API gateway proprietary mereka sendiri.
API gateway, Kubernetes gateway, dan service mesh mendukung canary deployments—secara bertahap meluncurkan versi perangkat lunak baru ke subset kecil pengguna sebelum membuatnya tersedia secara umum.
Contoh di bawah ini menunjukkan cara mengkonfigurasi canary deployment di Apache APISIX.
Anda dapat mengirim permintaan ke APISIX Admin API dengan konfigurasi berikut:
curl http://127.0.0.1:9180/apisix/admin/routes/1 \ -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d ' { "uri":"/*", "plugins":{ "traffic-split":{ "rules":[ { "weighted_upstreams":[ { "upstream":{ "name":"api-v1", "type":"roundrobin", "nodes":{ "api-v1:8080":1 } }, "weight":95 }, { "weight":5 } ] } ] } }, "upstream":{ "type":"roundrobin", "nodes":{ "api-v2:8080":1 } } }'
APISIX sekarang akan mengarahkan 95% lalu lintas ke layanan api-v1 dan 5% ke layanan api-v2.
Kubernetes Gateway
Kubernetes gateway hanyalah API gateway yang native untuk Kubernetes. Artinya, Anda dapat mengelola API gateway ini dengan API Kubernetes, mirip dengan pod, layanan, atau deployment Kubernetes.
Di Kubernetes, API Anda adalah pod dan layanan yang di-deploy dalam sebuah cluster. Kemudian Anda menggunakan Kubernetes gateway untuk mengarahkan lalu lintas eksternal ke cluster Anda.
Kubernetes menyediakan dua API untuk mencapai ini, yaitu Ingress API dan Gateway API.
Kubernetes Ingress API
Ingress API dibuat untuk mengatasi keterbatasan jenis layanan default, NodePort dan LoadBalancer, dengan memperkenalkan fitur seperti routing dan terminasi SSL. Ini juga menstandarisasi cara Anda mengekspos layanan Kubernetes ke lalu lintas eksternal.
Ia memiliki dua komponen, yaitu Ingress dan Ingress controller.
Objek native Kubernetes Ingress mendefinisikan seperangkat aturan tentang bagaimana lalu lintas eksternal dapat mengakses layanan Anda.
Contoh konfigurasi ini menunjukkan routing lalu lintas berdasarkan path URI dengan objek Kubernetes Ingress:
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: api-routes spec: ingressClassName: apisix rules: - http: paths: - backend: service: name: api-v1 port: number: 8080 path: /v1 pathType: Exact - backend: service: name: api-v2 port: number: 8080 path: /v2 pathType: Exact
Ingress controller mengimplementasikan aturan ini dan mengarahkan lalu lintas ke cluster Anda menggunakan reverse proxy.
Ada lebih dari 20 implementasi Ingress controller. APISIX memiliki Ingress controller yang membungkus API gateway APISIX untuk bekerja sebagai Kubernetes Ingress.
APISIX Ingress controller mengubah objek Kubernetes Ingress menjadi konfigurasi APISIX.
APISIX kemudian mengimplementasikan konfigurasi ini.
Anda dapat mengganti APISIX dengan Ingress controller lain, karena Ingress API tidak terikat pada implementasi tertentu.
Netralitas vendor ini bekerja dengan baik untuk konfigurasi sederhana. Tetapi jika Anda ingin melakukan routing kompleks seperti canary deployment, Anda harus mengandalkan anotasi khusus vendor.
Contoh di bawah ini menunjukkan cara mengkonfigurasi canary deployment menggunakan Nginx Ingress. Anotasi khusus yang digunakan di sini spesifik untuk Nginx:
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-weight: "5" name: api-canary spec: rules: - http: paths: - backend: serviceName: api-v2 servicePort: 8080 path: /
Konfigurasi di atas akan mengarahkan 5% lalu lintas ke layanan api-v2.
Selain anotasi, Ingress controller seperti APISIX memiliki Kubernetes CRD khusus untuk mengatasi keterbatasan Ingress API.
Contoh di bawah ini menggunakan CRD APISIX, ApisixRoute untuk mengkonfigurasi canary deployment:
apiVersion: apisix.apache.org/v2 kind: ApisixRoute metadata: name: api-canary spec: http: - name: route match: paths: - /* backends: - serviceName: api-v1 servicePort: 8080 weight: 95 - serviceName: api-v2 servicePort: 8080 weight: 5
CRD khusus ini membuatnya lebih mudah untuk mengkonfigurasi Ingress dan memanfaatkan kemampuan penuh dari API gateway di bawahnya, tetapi dengan mengorbankan portabilitas.
Kubernetes Gateway API
Gateway API adalah objek Kubernetes baru yang bertujuan untuk "memperbaiki" Ingress API.
Ia terinspirasi dari CRD khusus yang dikembangkan oleh Ingress controller untuk menambahkan pencocokan berdasarkan header HTTP, pemisahan lalu lintas berbobot, dan fitur lainnya yang memerlukan anotasi proprietary khusus dengan Ingress API.
Contoh di bawah ini menunjukkan mengkonfigurasi canary deployment dengan Kubernetes Gateway API:
apiVersion: gateway.networking.k8s.io/v1alpha2 kind: HTTPRoute metadata: name: api-canary spec: rules: - backendRefs: - name: api-v1 port: 8080 weight: 95 - name: api-v2 port: 8080 weight: 5
Setiap Ingress controller (yang mengimplementasikan Gateway API) sekarang dapat mengimplementasikan konfigurasi ini.
Gateway API juga membuat banyak perbaikan dibandingkan Ingress API, tetapi masih dalam tahap alpha, dan implementasi Gateway API terus berubah.
Service Mesh
API gateway dan Kubernetes gateway bekerja melintasi batas aplikasi untuk menyelesaikan masalah edge sambil mengabstraksi API Anda.
Service Mesh menyelesaikan tantangan yang berbeda.
Service mesh lebih peduli tentang komunikasi antar-layanan (lalu lintas east-west) daripada komunikasi layanan-klien (lalu lintas north-south).
Biasanya, ini dicapai dengan men-deploy sidecar proxy bersama API/layanan.
Di sini, sidecar proxy menangani komunikasi antar-layanan alih-alih pengembang harus mengkodekan logika jaringan ke dalam layanan.
Ada banyak service mesh yang tersedia. Beberapa yang populer adalah:
- Istio: Sejauh ini service mesh paling populer. Dibangun di atas Envoy proxy, yang digunakan oleh banyak service mesh.
- Linkerd: Service mesh ringan yang menggunakan linkerd2-proxy, ditulis dalam Rust khusus untuk Linkerd.
- Consul Connect: Service mesh yang menekankan keamanan dan observabilitas. Ia dapat bekerja dengan proxy bawaan atau Envoy.
Penawaran service mesh baru seperti Cilium menawarkan alternatif untuk service mesh berbasis sidecar dengan menggunakan kemampuan jaringan langsung dari kernel melalui eBPF.
Service mesh biasa membutuhkan 8 proxy untuk 8 layanan, sedangkan service mesh berbasis eBPF seperti Cilium tidak. Diadaptasi dari Cilium Service Mesh – Everything You Need to Know.
Service mesh juga memiliki gateway ingress/egress dasar untuk menangani lalu lintas north-south ke dan dari layanan. Gateway ingress adalah titik masuk lalu lintas eksternal ke service mesh, dan gateway egress memungkinkan layanan di dalam mesh untuk mengakses layanan eksternal.
Apache APISIX juga memiliki implementasi service mesh yang disebut Amesh. Ia bekerja dengan control plane Istio menggunakan protokol xDS menggantikan proxy Envoy default di sidecar.
Service mesh memungkinkan Anda mengkonfigurasi canary deployments. Misalnya, Anda dapat membagi permintaan dari satu layanan antara dua versi layanan lain.
Contoh di bawah ini menunjukkan mengkonfigurasi canary deployment dengan Istio service mesh:
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: api-virtual-service spec: hosts: - api http: - route: - destination: host: api subset: v1 weight: 80 - destination: host: api subset: v2 weight: 20
apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: api-destination-rule spec: host: api subsets: - name: v1 labels: version: "1.0" - name: v2 labels: version: "2.0"
Konfigurasi ini spesifik untuk Istio. Untuk beralih ke service mesh yang berbeda, Anda harus membuat konfigurasi yang berbeda tetapi serupa dan bergantung pada vendor.
Spesifikasi Service Mesh Interface (SMI) dibuat untuk menyelesaikan masalah portabilitas ini.
Spesifikasi SMI spec adalah seperangkat Kubernetes CRD yang dapat digunakan oleh pengguna service mesh untuk mendefinisikan aplikasi tanpa terikat pada implementasi service mesh.
Upaya standarisasi hanya akan berhasil jika semua proyek ikut serta. Tetapi ini tidak terjadi dengan spesifikasi SMI, dan hanya beberapa proyek yang berpartisipasi aktif.
Baru-baru ini, Kubernetes SIG Network telah mengembangkan Gateway API untuk mendukung service mesh.
Inisiatif GAMMA (Gateway API for Mesh Management and Administration) adalah grup khusus dalam proyek Gateway API dengan tujuan untuk "menyelidiki, merancang, dan melacak sumber daya Gateway API, semantik, dan artefak lain yang terkait dengan teknologi service mesh dan kasus penggunaan."
Gateway API adalah langkah alami berikutnya setelah Ingress API, tetapi kita harus menunggu untuk melihat bagaimana ia akan bekerja untuk service mesh. Istio telah mengumumkan niatnya untuk menggunakan Gateway API sebagai API default untuk semua manajemen lalu lintas dan terus mendorong proyek ini ke depan.
Contoh di bawah ini menunjukkan mengkonfigurasi canary deployment di Istio dengan Gateway API. Ide dasarnya adalah menggunakan parentRefs untuk menempel ke layanan lain alih-alih gateway:
apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: api-canary spec: parentRefs: - kind: Service name: api-a port: 8080 rules: - backendRefs: - name: api-b-v1 port: 8080 weight: 95 - name: api-b-v2 port: 8080 weight: 5
Ada beberapa kekhawatiran bahwa proyek GAMMA mungkin menjadi bias untuk melayani kebutuhan satu proyek tertentu daripada komunitas yang lebih besar, yang pada akhirnya akan menyebabkan proyek lain menggunakan API mereka sendiri, mirip dengan skenario CRD khusus setelah Kubernetes Ingress API.
Tetapi proyek Gateway API telah menjadi upaya terbaik untuk menstandarisasi manajemen lalu lintas di service mesh. Proyek SMI juga bergabung dengan inisiatif GAMMA dengan visi bersama dan akan membantu mendorong implementasi konsisten dari Gateway API oleh proyek service mesh.
Proyek lain seperti Flagger dan Argo Rollouts juga telah terintegrasi dengan Gateway API.
Apa yang Harus Anda Gunakan?
Hanya ada satu jawaban yang benar untuk pertanyaan ini; "tergantung."
Jika Anda mengembangkan API dan membutuhkan autentikasi, keamanan, routing, atau metrik, Anda lebih baik menggunakan API gateway daripada membangun ini sendiri di API Anda.
Jika Anda ingin melakukan sesuatu yang serupa di lingkungan Kubernetes, Anda harus menggunakan Kubernetes gateway alih-alih mencoba mengatur API gateway Anda untuk bekerja di Kubernetes. Untungnya, banyak API gateway juga bekerja dengan konfigurasi native Kubernetes.
Tetapi terkadang, fitur yang ditawarkan oleh API gateway + Ingress controller mungkin berlebihan untuk lingkungan Kubernetes, dan Anda mungkin ingin kembali ke manajemen lalu lintas yang sederhana.
Di sisi lain, service mesh menyelesaikan serangkaian masalah yang sama sekali berbeda. Mereka juga membawa gateway mereka sendiri untuk menangani lalu lintas north-south (biasanya cukup) tetapi juga memungkinkan Anda menggunakan gateway Anda sendiri dengan lebih banyak fitur.
Konvergensi API gateway dan service mesh melalui Kubernetes Gateway API seharusnya memudahkan pengembang aplikasi untuk fokus menyelesaikan masalah daripada khawatir tentang implementasi yang mendasarinya.
Proyek seperti Apache APISIX menggunakan teknologi yang sama untuk membangun penawaran API gateway dan service mesh serta terintegrasi dengan baik dengan spesifikasi ini, mendorong pilihan yang netral terhadap vendor.
Ada kemungkinan juga bahwa Anda tidak memerlukan semua ini. Anda mungkin bahkan tidak memerlukan microservices atau arsitektur terdistribusi, tetapi ketika Anda membutuhkannya, gateway dan mesh dapat membuat hidup Anda jauh lebih mudah.