Membandingkan Kubernetes Gateway dan Ingress APIs

Navendu Pottekkat

Navendu Pottekkat

October 21, 2022

Ecosystem

Beberapa bulan yang lalu, Kubernetes Gateway API baru lulus ke versi beta.

Mengapa Anda memerlukan API lain untuk menangani lalu lintas eksternal ketika Anda sudah memiliki Kubernetes Ingress API yang stabil dan puluhan implementasi? Masalah apa dari Ingress API yang diselesaikan oleh Gateway API baru ini? Apakah ini berarti akhir dari Ingress API?

Saya akan mencoba menjawab pertanyaan-pertanyaan ini dalam artikel ini dengan mencoba langsung menggunakan API-API tersebut dan melihat bagaimana mereka berkembang.

Standarisasi Akses Eksternal ke Layanan: Ingress API

Kubernetes Ingress API dibuat untuk menstandarisasi cara mengekspos layanan di Kubernetes ke lalu lintas eksternal. Ingress API mengatasi keterbatasan jenis layanan default, NodePort dan LoadBalancer, dengan memperkenalkan fitur seperti routing dan terminasi SSL.

Kubernetes Ingress

Ada lebih dari 20 implementasi kontroler Ingress yang tersedia. Dalam artikel ini, saya akan menggunakan Apache APISIX dan kontroler Ingress-nya sebagai contoh.

APISIX Ingress controller

Anda dapat membuat sumber daya Ingress untuk mengonfigurasi APISIX atau implementasi Ingress lainnya.

Contoh di bawah ini menunjukkan bagaimana Anda dapat merutekan lalu lintas antara dua versi aplikasi dengan APISIX Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-routes
spec:
  ingressClassName: apisix
  rules:
    - host: local.navendu.me
      http:
        paths:
          - backend:
              service:
                name: bare-minimum-api-v1
                port:
                  number: 8080
            path: /v1
            pathType: Prefix
          - backend:
              service:
                name: bare-minimum-api-v2
                port:
                  number: 8081
            path: /v2
            pathType: Prefix

Tip: Anda dapat melihat tutorial praktis ini untuk mempelajari lebih lanjut tentang menyiapkan Ingress di Kubernetes dengan kontroler Ingress Apache APISIX.

Karena Ingress API tidak terikat pada implementasi kontroler tertentu, Anda dapat mengganti APISIX dengan kontroler Ingress lainnya, dan itu akan bekerja dengan cara yang sama.

Ini baik untuk routing sederhana. Namun, API ini terbatas, dan jika Anda ingin menggunakan fitur lengkap yang disediakan oleh kontroler Ingress Anda, Anda harus menggunakan anotasi.

Misalnya, Kubernetes Ingress API tidak menyediakan skema untuk mengonfigurasi rewrites. Rewrites berguna ketika URL upstream/backend Anda berbeda dari path yang dikonfigurasi dalam aturan Ingress Anda.

APISIX mendukung fitur ini, dan Anda harus menggunakan anotasi kustom untuk memanfaatkannya:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-routes
  annotations:
    k8s.apisix.apache.org/rewrite-target-regex: "/app/(.*)"
    k8s.apisix.apache.org/rewrite-target-regex-template: "/$1"
spec:
  ingressClassName: apisix
  rules:
    - host: local.navendu.me
      http:
        paths:
          - backend:
              service:
                name: bare-minimum-api
                port:
                  number: 8080
            path: /app
            pathType: Prefix

Ini membuat sumber daya Ingress yang mengonfigurasi APISIX untuk merutekan permintaan apa pun dengan awalan /app ke backend dengan awalan yang dihapus. Misalnya, permintaan ke /app/version akan diteruskan ke /version.

Anotasi spesifik untuk pilihan kontroler Ingress Anda. Ekstensi "proprietary" ini membatasi ruang lingkup portabilitas yang awalnya dimaksudkan dengan Ingress API.

CRD Kustom > Ingress API

Terjebak dengan anotasi juga mengorbankan kegunaan kontroler Ingress.

Oleh karena itu, kontroler mengatasi keterbatasan Ingress API dengan membuat sumber daya kustom mereka sendiri. Contoh di bawah ini menunjukkan cara mengonfigurasi Ingress untuk merutekan lalu lintas antara dua versi aplikasi menggunakan sumber daya kustom APISIX:

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: api-routes
spec:
  http:
    - name: route-1
      match:
        hosts:
          - local.navendu.me
        paths:
          - /v1
      backends:
        - serviceName: bare-minimum-api-v1
          servicePort: 8080
    - name: route-2
      match:
        hosts:
          - local.navendu.me
        paths:
          - /v2
      backends:
        - serviceName: bare-minimum-api-v2
          servicePort: 8081

CRD ini membuat konfigurasi Ingress menjadi jauh lebih mudah, tetapi Anda terikat pada implementasi kontroler Ingress tertentu. Tanpa evolusi Ingress API, Anda harus memilih antara kegunaan atau portabilitas.

Memperluas Ingress dan Evolusi ke Gateway API

Ingress API tidak rusak; itu terbatas. Gateway API dirancang untuk mengatasi keterbatasan ini.

(Gateway API) bertujuan untuk mengembangkan jaringan layanan Kubernetes melalui antarmuka yang ekspresif, dapat diperluas, dan berorientasi pada peran ...

Ini terinspirasi dari CRD kustom dari berbagai kontroler Ingress yang disebutkan sebelumnya.

Gateway API menambahkan banyak fitur "di atas" kemampuan Ingress API. Ini termasuk pencocokan berbasis header HTTP, pemisahan lalu lintas berbobot, dan fitur lain yang memerlukan anotasi proprietary kustom dengan Ingress API.

Pemisahan lalu lintas dengan sumber daya Ingress APISIX (lihat referensi ApisixRoute/v2):

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: traffic-split
spec:
  http:
    - name: rule-1
      match:
        hosts:
          - local.navendu.me
        paths:
          - /get*
      backends:
        - serviceName: bare-minimum-api-v1
          servicePort: 8080
          weight: 90
        - serviceName: bare-minimum-api-v2
          servicePort: 8081
          weight: 10

Pemisahan lalu lintas dengan Gateway API (lihat Canary traffic rollout):

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: traffic-split
spec:
  hostnames:
  - local.navendu.me
  rules:
  - backendRefs:
    - name: bare-minimum-api-v1
      port: 8080
      weight: 90
    - name: bare-minimum-api-v2
      port: 8081
      weight: 10

Peningkatan lain dari Ingress API adalah bagaimana Gateway API memisahkan kepentingan. Dengan Ingress, pengembang aplikasi dan operator kluster bekerja pada objek Ingress yang sama, tidak menyadari tanggung jawab masing-masing dan membuka pintu untuk kesalahan konfigurasi.

Gateway API memisahkan konfigurasi menjadi objek Route dan Gateway, memberikan otonomi untuk pengembang aplikasi dan operator kluster. Diagram di bawah ini menjelaskan ini dengan jelas:

Pemisahan kepentingan dalam Gateway API

Apakah Ini Akhir dari Ingress API?

Gateway API relatif baru, dan implementasinya terus berkembang. Sebaliknya, Ingress API sudah dalam rilis stabil dan telah melewati ujian waktu.

Jika kasus penggunaan Anda hanya melibatkan routing sederhana dan jika Anda tidak masalah menggunakan anotasi kustom untuk mendapatkan fitur tambahan, Ingress API masih merupakan pilihan yang solid.

Dengan Gateway API yang merupakan superset dari Ingress API, mungkin masuk akal untuk menggabungkan keduanya. Berkat komunitas SIG Network, Gateway API masih berkembang dan akan segera siap produksi.

Sebagian besar kontroler Ingress dan service mesh telah mengimplementasikan Gateway API bersama dengan Ingress API, dan seiring berkembangnya proyek ini, lebih banyak implementasi akan muncul.

Secara pribadi, setidaknya untuk saat ini, saya akan tetap menggunakan CRD kustom yang disediakan oleh kontroler Ingress seperti Apache APISIX daripada Ingress atau Gateway API.

Tags:
Kubernetes
Ingress API