Sekilas tentang Kubernetes Gateway API

Nicolas Fränkel

Nicolas Fränkel

September 7, 2022

Ecosystem

Dalam salah satu posting blog saya baru-baru ini, saya menjelaskan beberapa cara untuk mengakses pod Kubernetes. Seseorang dapat mengakses pod melalui IP-nya, tetapi pod secara alami bersifat sementara. Cara yang umum adalah dengan mengonfigurasi Service: IP-nya stabil, dan tugas Kubernetes adalah menjaga pemetaan antara Service dan pod yang mendasarinya tetap mutakhir. Berbagai jenis layanan tersedia: internal saja, NodePort untuk memungkinkan akses dari luar cluster, dan LoadBalancer yang bergantung pada komponen pihak ketiga - umumnya, penyedia cloud. Terakhir, saya menyebutkan objek Ingress, yang juga memungkinkan routing.

Saya sengaja tidak membahas pendatang baru, yaitu Gateway API. Itulah topik posting ini.

Dari Ingress ke Gateway API

Akses eksternal ke pod Kubernetes telah melalui beberapa langkah evolusi, misalnya, Ingress adalah jawaban atas masalah kurangnya routing di LoadBalancer. Masalah terbesar dari Ingress adalah ketergantungannya pada objek "proprietary". Sebagai pengingat, berikut adalah cuplikan untuk membuat routing menggunakan Apache APISIX:

apiVersion: apisix.apache.org/v2beta3 #1
kind: ApisixRoute #1
metadata:
  name: apisix-route
spec:
  http:
    - name: left
      match:
        paths:
          - "/left"
      backends:
        - serviceName: left
          servicePort: 80
    - name: right
      match:
        paths:
          - "/right"
      backends:
        - serviceName: right
          servicePort: 80
  1. Objek proprietary

Objek proprietary menjadi masalah saat migrasi. Meskipun migrasi dari satu penyedia ke penyedia lain mungkin jarang terjadi, migrasi tersebut harus semulus mungkin. Saat menggunakan objek proprietary, Anda pertama-tama perlu memetakan dari objek lama ke yang baru. Kemungkinan besar itu bukan pemetaan satu-ke-satu. Kemudian, Anda perlu menerjemahkan spesifikasi ke model baru: kemungkinan besar itu akan menjadi proyek yang lengkap.

Ide di balik Gateway API adalah memiliki pemisahan yang jelas antara objek standar dan implementasi proprietary.

Gateway API

Gateway API adalah proyek open source yang dikelola oleh komunitas SIG-NETWORK. Ini adalah kumpulan sumber daya yang memodelkan jaringan layanan di Kubernetes. Sumber daya ini - GatewayClass, Gateway, HTTPRoute, TCPRoute, Service, dll - bertujuan untuk mengembangkan jaringan layanan Kubernetes melalui antarmuka yang ekspresif, dapat diperluas, dan berorientasi peran yang diimplementasikan oleh banyak vendor dan memiliki dukungan industri yang luas.

-- https://gateway-api.sigs.k8s.io

Definisi di atas juga menyebutkan masalah organisasi: peran yang berbeda harus mengelola set objek yang berbeda.

Model Gateway API

Gambar dari gateway-api.sigs.k8s.io

Memang, perhatian operator cluster dan pengembang cukup berbeda. Ini cukup mirip dengan server aplikasi Java EE lama, yang menawarkan spesifikasi yang diorganisir berdasarkan peran: pengembang, penyebar, dan operator. Menurut saya, perbedaan terbesar adalah bahwa spesifikasi tersebut terutama berfokus pada pengalaman pengembang; sisanya diserahkan kepada implementor. Gateway API tampaknya peduli dengan semua persona.

Mengonfigurasi akses pod melalui Gateway API

Mari kita ganti Ingress yang sebelumnya kita konfigurasi dengan Gateway API. Beberapa langkah diperlukan.

Instal CRD Gateway baru

k apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v0.5.0/standard-install.yaml

Instal implementasi

Saya akan menggunakan Apache APISIX. Alternatifnya, situs SIG memelihara daftar implementasi.

helm install apisix apisix/apisix \
  --namespace ingress-apisix \
  --create-namespace \
  --devel \                                                                #1
  --set gateway.type=NodePort \                                            #2
  --set gateway.http.nodePort=30800 \                                      #2
  --set ingress-controller.enabled=true \                                  #2
  --set ingress-controller.config.kubernetes.enableApiGateway=true \       #3
  --set ingressPublishService="ingress-apisix/apisix-gateway"              #4
  1. Tanpa opsi --devel, Helm akan menginstal rilis terbaru, yang tidak bekerja dengan Gateway API
  2. Gateway perlu dapat diakses dari luar cluster
  3. Di sinilah keajaiban terjadi!
  4. Saya akan membahasnya nanti

Mari kita periksa apakah semuanya berfungsi:

k get all -n ingress-apisix

NAME                                             READY   STATUS    RESTARTS   AGE
pod/apisix-5fc9b45c69-cf42m                      1/1     Running   0          14m    #1
pod/apisix-etcd-0                                1/1     Running   0          14m    #2
pod/apisix-etcd-1                                1/1     Running   0          14m    #2
pod/apisix-etcd-2                                1/1     Running   0          14m    #2
pod/apisix-ingress-controller-6f8bd94d9d-wkzfn   1/1     Running   0          14m    #3

NAME                                TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)
service/apisix-admin                ClusterIP   10.96.69.19     <none>        9180/TCP
service/apisix-etcd                 ClusterIP   10.96.226.79    <none>        2379/TCP,2380/TCP
service/apisix-etcd-headless        ClusterIP   None            <none>        2379/TCP,2380/TCP
service/apisix-gateway              NodePort    10.96.101.224   <none>        80:30800/TCP #4
service/apisix-ingress-controller   ClusterIP   10.96.141.230   <none>        80/TCP
  1. Apache APISIX itu sendiri
  2. Apache APISIX menyimpan konfigurasinya di etcd. Chart ini menjadwalkan tiga pod secara default, praktik yang baik untuk menangani kegagalan dalam sistem terdistribusi
  3. Kontroler Apache APISIX: kontroler Kubernetes adalah loop kontrol yang memindahkan keadaan yang ada ke arah keadaan yang diinginkan
  4. Layanan Gateway Apache APISIX: ini adalah Service NodePort yang kita instal melalui Helm Chart. Ini juga nama yang kita rujuk selama instalasi Helm Chart - ingressPublishService

Pada titik ini, infrastruktur sudah siap.

Deklarasikan implementasi Gateway

Seperti yang saya sebutkan di atas, API membuat pemisahan yang jelas antara spesifikasi dan implementasi. Namun, kita perlu mengikatnya dengan cara tertentu. Itu adalah tanggung jawab objek GatewayClass:

apiVersion: gateway.networking.k8s.io/v1alpha2 #1
kind: GatewayClass #2
metadata:
  name: apisix-gateway-class #3
spec:
  controllerName: apisix.apache.org/gateway-controller #4
  1. Kami sengaja tidak menggunakan versi terbaru, karena Apache APISIX menggunakan versi ini. Sadarilah bahwa ini akan berkembang di masa (dekat) depan
  2. Objek GatewayClass
  3. Beri nama sesuka Anda; namun, kita akan menggunakannya nanti untuk merujuk ke kelas gateway
  4. Nama kontroler tergantung pada implementasi. Di sini, kita menggunakan Apache APISIX.

Perhatikan bahwa GatewayClass memiliki cakupan cluster-wide. Model ini memungkinkan kita untuk mendeklarasikan implementasi Gateway API yang berbeda dan menggunakannya secara paralel dalam cluster yang sama.

Buat Gateway

Dengan Apache APISIX, ini cukup mudah:

apiVersion: gateway.networking.k8s.io/v1alpha2 #1
kind: Gateway #2
metadata:
  name: apisix-gateway
spec:
  gatewayClassName: apisix-gateway-class #3
  listeners: #4
    - name: http
      protocol: HTTP
      port: 80
  1. Namespace yang sama seperti di atas
  2. Objek Gateway
  3. Referensi kelas gateway yang dideklarasikan sebelumnya
  4. Izinkan beberapa batasan pada level ini sehingga operator cluster dapat menghindari penggunaan yang tidak diinginkan

Peringatan: Gateway API menentukan opsi untuk secara dinamis mengubah port di sisi operator. Pada saat penulisan ini, alokasi port Apache APISIX bersifat statis. Rencananya adalah membuatnya dinamis di masa depan. Silakan berlangganan GitHub issue ini untuk mengikuti perkembangannya.

Rute, rute, rute di mana-mana

Sampai sekarang, semuanya adalah infrastruktur; kita akhirnya dapat mengonfigurasi routing.

Saya ingin routing yang sama seperti di posting sebelumnya; cabang /left dan right. Saya akan melewatkan yang terakhir demi singkatnya.

apiVersion: gateway.networking.k8s.io/v1alpha2 #1
kind: HTTPRoute #2
metadata:
  name: left
spec:
  parentRefs:
    - name: apisix-gateway #3
  rules:
    - matches: #4
        - path: #4
            type: PathPrefix #4
            value: /left
      backendRefs: #5
        - name: left #5
          port: 80 #5
  1. Namespace yang sama seperti di atas
  2. Objek HTTPRoute
  3. Referensi Gateway yang dibuat di atas
  4. Aturan pencocokan. Dalam kasus kita, kita mencocokkan berdasarkan awalan path, tetapi banyak aturan yang tersedia. Anda dapat mencocokkan berdasarkan parameter kueri, header, dll.
  5. "Upstream" untuk meneruskan. Kita mendefinisikan Service left di posting blog sebelumnya.

Memeriksa apakah berfungsi

Sekarang kita telah mengonfigurasi rute kita, kita dapat memeriksa apakah itu berfungsi.

curl localhost:30800/left

Ketika kita menginstal Helm chart, kita memberi tahu Apache APISIX untuk membuat layanan NodePort pada port 30800. Oleh karena itu, kita dapat menggunakan port tersebut untuk mengakses layanan dari luar cluster.

left

Kesimpulan

Banyak alternatif yang tersedia untuk mengakses pod dari luar cluster. CNCF menambahkan sebagian besar dari mereka untuk meningkatkan yang sebelumnya.

Gateway API adalah proposal terbaru dalam hal ini. Spesifikasi ini masih dalam proses pengerjaan dan produk berada pada tahap implementasi yang berbeda. Karena alasan ini, terlalu dini untuk memproduksi berdasarkan API ini. Namun, Anda mungkin harus mengikuti perkembangannya karena ini pasti akan menjadi peningkatan yang signifikan dari pendekatan sebelumnya.

Kode sumber lengkap untuk posting ini dapat ditemukan di GitHub.

Untuk lebih lanjut:

Tags:
Kubernetes
Gateway API