Pertama Kali Melihat Kubernetes Service APIs

Kata Pengantar

Kita tahu bahwa Kubernetes memiliki sejumlah solusi untuk mengekspos layanan di dalam kluster, salah satu yang lebih populer adalah Ingress, yang merupakan standar untuk mengekspos layanan ke dunia luar dan memiliki sejumlah implementasi pihak ketiga, masing-masing dengan teknologi dan dependensi pada gateway yang tidak kompatibel satu sama lain.

Untuk menyatukan berbagai implementasi Ingress dan memfasilitasi manajemen yang seragam di Kubernetes, komunitas SIG-NETWORK telah merilis Kubernetes Service APIs, seperangkat implementasi standar yang disebut Ingress generasi kedua.

Deskripsi Subjek

Artikel ini memberikan pengenalan tentang konsep dasar Kubernetes Service APIs, dimulai dengan beberapa pertanyaan.

Pengenalan

Kubernetes Service APIs disebut sebagai teknologi Ingress generasi kedua, tetapi dalam hal apa mereka lebih baik daripada generasi pertama

Kubernetes Service APIs tidak dirancang untuk dibatasi hanya pada Ingress, melainkan untuk meningkatkan jaringan layanan dengan fokus pada: ekspresivitas, skalabilitas, dan RBAC.

1. Lebih banyak fitur, misalnya mengelola lalu lintas berdasarkan header, bobot.

kind: HTTPRoute
apiVersion: networking.x-k8s.io/v1alpha1
---
matches:
  - path:
      value: "/foo"
    headers:
      values:
        version: "2"
  - path:
      value: "/v2/foo"

2. Meningkatkan skalabilitas, Service APIs memperkenalkan konsep API multi-layer, dengan setiap lapisan mengekspos antarmukanya sendiri, memungkinkan sumber daya kustom lainnya untuk berinteraksi dengan API untuk kontrol yang lebih halus (API-grained).

3. RBAC berorientasi peran: Realisasi API multi-layer, salah satu idenya adalah merancang objek sumber daya dari perspektif pengguna. Sumber daya ini pada akhirnya akan dipetakan dengan peran umum dalam menjalankan aplikasi di Kubernetes.

Objek sumber daya apa yang diabstraksi oleh Kubernetes Service APIs

Berdasarkan peran pengguna, Kubernetes Service APIs akan mendefinisikan sumber daya berikut:

GatewayClass, Gateway, Route

1. GatewayClass mendefinisikan sekumpulan tipe gateway dengan konfigurasi dan perilaku yang sama:

• Hubungan dengan Gateway, mirip dengan anotasi ingess.class di ingress;
• Sebuah GatewayClass mendefinisikan sekelompok gateway yang berbagi konfigurasi dan perilaku yang sama. Setiap GatewayClass akan ditangani oleh satu controller, dengan controller memiliki hubungan satu-ke-banyak dengan GatewayClass;
• GatewayClass adalah sumber daya kluster. Setidaknya satu GatewayClass harus didefinisikan untuk memiliki gateway yang berfungsi.

2. Gateway meminta titik di mana lalu lintas dapat dikonversi ke layanan di dalam kluster:

• Apa yang dilakukannya: membawa lalu lintas dari luar kluster ke dalam kluster. Ini adalah entitas ingress yang sebenarnya;
• Ini mendefinisikan permintaan untuk konfigurasi LB tertentu yang juga merupakan implementasi dari konfigurasi dan perilaku GatewayClass;
• Sumber daya Gateway dapat dibuat langsung oleh operator atau oleh controller yang menangani GatewayClass;
• Gateway dan Route memiliki hubungan banyak-ke-banyak.

3. Route menjelaskan bagaimana lalu lintas yang melewati gateway dipetakan ke layanan.

Selain itu, Kubernetes Service APIs mendefinisikan objek sumber daya BackendPolicy untuk memungkinkan konfigurasi yang fleksibel dari layanan backend.

Objek BackendPolicy memungkinkan Anda untuk mengonfigurasi TLS, pemeriksaan kesehatan, dan menentukan jenis layanan backend, seperti service atau pod.

Perubahan apa yang akan dibawa oleh pengenalan Kubernetes Service APIs

Kubernetes Service APIs, sebagai standar implementasi, membawa perubahan berikut.

1. Generalitas: dapat ada banyak implementasi, sama seperti ada banyak implementasi ingress. ingress controller dapat dikustomisasi sesuai dengan karakteristik gateway, tetapi semuanya memiliki struktur konfigurasi yang konsisten. Satu struktur data dapat digunakan untuk mengonfigurasi banyak ingress controller.
2. Konsep kelas: GatewayClasses memungkinkan untuk mengonfigurasi berbagai jenis implementasi load balancing. Kelas-kelas ini memungkinkan pengguna untuk dengan mudah dan eksplisit memahami fungsi apa yang dapat digunakan sebagai model sumber daya itu sendiri.
3. Gateway bersama: Dengan memungkinkan sumber daya routing independen HTTPRoute untuk diikat ke GatewayClass yang sama, mereka dapat berbagi load balancer dan VIP. Dilapisi oleh pengguna, ini memungkinkan tim untuk berbagi infrastruktur dengan aman tanpa harus peduli dengan implementasi spesifik dari Gateway tingkat bawah.
4. Referensi backend dengan tipe: Dengan referensi backend dengan tipe, rute dapat merujuk ke Kubernetes Services, atau jenis sumber daya Kubernetes apa pun yang dirancang sebagai backend gateway, seperti pod, atau statefulset seperti DB, atau bahkan sumber daya eksternal kluster yang dapat diakses.
5. Referensi lintas namespace: Rute lintas namespace yang berbeda dapat diikat ke Gateway, memungkinkan akses satu sama lain lintas namespace. Juga dimungkinkan untuk membatasi rentang namespace yang dapat diakses oleh Rute di bawah Gateway.

Implementasi Ingress apa dari Kubernetes Service APIs yang saat ini tersedia

Ingress yang diketahui mendukung objek sumber daya Kubernetes Service APIs pada tingkat kode adalah Contour, ingress-gce.

Bagaimana Kubernetes Service APIs mengelola izin baca dan tulis sumber daya

Kubernetes Service APIs dibagi menjadi 3 peran berdasarkan dimensi pengguna:

1. penyedia infrastruktur GatewayClass;
2. operator kluster Gateway;
3. pengembang aplikasi Route.

RBAC (Role Based Access Control) adalah standar yang digunakan untuk otorisasi Kubernetes. Ini memungkinkan pengguna untuk mengonfigurasi siapa yang dapat melakukan operasi pada rentang sumber daya tertentu. RBAC dapat digunakan untuk mengaktifkan setiap peran yang didefinisikan di atas.

Dalam kebanyakan kasus, diharapkan semua peran akan dapat membaca semua sumber daya.

Model tiga lapis memiliki izin tulis berikut.

Apa titik ekstensi untuk Kubernetes Service APIs

Persyaratan untuk gateway sangat kaya, dan ada banyak cara untuk mengimplementasikan skenario yang sama, masing-masing dengan kelebihan dan kekurangannya sendiri. Kubernetes Service APIs telah mengekstrak objek sumber daya multi-layer, dan juga menyisakan beberapa titik ekstensi.

Kubernetes Service APIs saat ini fokus pada Route:

• RouteMatch memperluas aturan pencocokan Route.
• tentukan Backend memperluas jenis layanan backend tertentu, seperti sistem file, ekspresi fungsi, dll., selain sumber daya Kubernetes yang disebutkan di atas.
• Filter Route menambahkan ekstensi ke siklus hidup Route untuk menangani permintaan/respons.
• Jika tidak ada ekstensi di atas yang dapat dipenuhi oleh Route Kustom, Route dapat sepenuhnya dikustomisasi.

Ringkasan

Artikel ini telah memberikan pengenalan dasar tentang Kubernetes Service APIs dengan mengajukan pertanyaan. Secara keseluruhan, Kubernetes Service APIs menyempurnakan banyak praktik terbaik dari ingress, seperti peningkatan ekspresivitas, yang sebenarnya memperluas kemampuan Route, dan objek BackendPolicy, yang dapat menentukan hampir semua sumber daya backend Kubernetes untuk upstream. Kubernetes Service APIs saat ini menentukan objek sumber daya pada tingkat yang luas, tetapi masih banyak detail dalam objek sumber daya yang perlu didiskusikan sebelum dapat didefinisikan untuk mencegah skenario konflik yang mungkin terjadi, dan ada variabel tertentu dalam strukturnya.