Arsitektur referensi load balancing lapisan 7

Referensi arsitektur ini menyediakan solusi load balancing Lapisan 7 yang dikelola pelanggan di Google Distributed Cloud (GDC) dengan air gap. Dengan men-deploy pengontrol open source populer seperti HAProxy Kubernetes Ingress atau NGINX Gateway Fabric di cluster standar GDC, pelanggan dapat merutekan traffic L7 ke lingkungan hybrid dengan lancar. Arsitektur ini menggunakan TLS Termination (Ingress / HTTPRoute) untuk merutekan traffic berdasarkan Server Name Indication (SNI) ke pod dalam container bawaan dan aplikasi yang dihosting di virtual machine eksternal.

Fitur dan kemampuan

  • Pemilihan Rute Lapisan 7 Lanjutan: Mendukung pemilihan rute berbasis host, pemilihan rute berbasis jalur, dan pengelolaan traffic lanjutan seperti pencocokan berbasis header dan pembobotan traffic.
  • Pengelolaan TLS Terpusat: Menyediakan pengelolaan dan penghentian TLS terpusat.
  • Dukungan Lingkungan Hybrid: Merutekan traffic L7 dengan lancar ke pod dalam container bawaan dan aplikasi yang dihosting di virtual machine eksternal.
  • Opsi Pengontrol yang Fleksibel: Menawarkan pilihan antara NGINX Gateway Fabric modern (menggunakan Gateway API) atau HAProxy Ingress Controller yang sudah mapan.
  • Kesiapan Air-Gap: Terintegrasi dengan Harbor Registry untuk menyimpan dan menyajikan image proxy dan aplikasi dalam lingkungan pribadi yang terputus.
  • Pemisahan Traffic yang Kompleks: Memungkinkan strategi distribusi traffic lanjutan untuk pengiriman aplikasi modern.

Prinsip arsitektur

  • Pola Load Balancing Dua Tingkat: Arsitektur ini menggabungkan Load Balancer L4 bawaan GDC (sebagai titik entri) dengan Gateway L7 yang dikelola pelanggan yang di-deploy dalam Kubernetes.
  • Pemisahan Berorientasi Peran: Gateway API mengikuti desain yang memisahkan tanggung jawab antara penyedia infrastruktur, operator cluster, dan developer melalui resource tertentu (seperti GatewayClass, Gateway, dan HTTPRoute, atau Ingress).
  • Transisi ke Standar Modern: Arsitektur ini memprioritaskan Gateway API untuk kemampuan pemilihan rute modern sekaligus mempertahankan dukungan untuk Ingress API lama jika stabilitas untuk pengontrol tertentu diperlukan.
  • Fleksibilitas yang Dikelola Pelanggan: Dengan men-deploy pengontrol yang dikelola sendiri, pelanggan mendapatkan kontrol atas fitur dan konfigurasi L7 yang tidak disediakan secara native oleh load balancer L4 yang dikelola GDC.
  • Abstraksi Lokasi Workload: Arsitektur ini memperlakukan workload dalam container dan berbasis VM secara konsisten melalui abstraksi Service Kubernetes (standar atau headless).

Arsitektur konseptual

Diagram arsitektur konseptual untuk load balancing Lapisan 7 di GDC dengan air gap.

Arsitektur logis

Arsitektur logis terdiri dari beberapa komponen fungsional yang bekerja bersama untuk merutekan traffic eksternal ke backend internal atau eksternal:

  1. Titik Entri Ingress/Gateway: Klien memulai permintaan HTTPS yang pertama kali mencapai Load Balancer L4 GDC. Balancer bawaan ini berfungsi sebagai titik entri dan mendistribusikan traffic TCP/443 ke Load Balancer L7.
  2. Bidang Kontrol: Pengontrol Ingress atau Gateway (operator HAProxy atau NGINX) memantau resource Kubernetes seperti Ingress, Gateway, dan HTTPRoute
  3. Data Plane: Berdasarkan resource yang diamati, pengontrol secara dinamis memperbarui Proxy yang mendasarinya yang melakukan pemilihan rute traffic sebenarnya berdasarkan aturan pemilihan rute host berbasis SNI dan TLS termination.
  4. Layanan Backend:
    • Pod dalam container: Dikelola sebagai Deployment standar dan diekspos dengan Service Kubernetes reguler.
    • VM eksternal: Diintegrasikan ke dalam cluster dengan Service Kubernetes headless dan endpoint kustom (atau EndpointSlice) yang berisi IP langsung VM
  5. Pengelolaan Artefak: Semua image untuk proxy dan aplikasi disajikan dari Harbor Registry lokal untuk memastikan fungsionalitas di lingkungan air-gapped

Konsep dan teknologi inti

Arsitektur ini menggunakan pola load balancing dua tingkat, yang menggabungkan Load Balancer L4 bawaan GDC dengan Gateway L7 yang dikelola pelanggan yang di-deploy di Kubernetes. Komponen utamanya meliputi:

  • Klien: Entity yang memulai permintaan HTTPS untuk berinteraksi dengan aplikasi.
  • Cluster Standar GDC: GDC menyediakan cara bawaan untuk membuat Cluster Vanilla Kubernetes. Dalam solusi ini, cluster akan menghosting LB L7 dan pengontrolnya, beserta workload dan layanan headless untuk VM eksternal
  • Load Balancer L4 GDC: Load balancer L4 bawaan yang berfungsi sebagai titik entri, mendistribusikan traffic TCP/443 langsung ke Pod Kubernetes yang menjalankan pengontrol Ingress atau Gateway.
  • Pengontrol Ingress dan Gateway: Operator HAProxy atau NGINX yang berjalan di Cluster Standard. Untuk Nginx, mereka memantau resource Gateway API (seperti Gateway dan HTTPRoute) dan memperbarui proxy yang mendasarinya secara dinamis. Untuk HAProxy, keduanya memantau resource Ingress dan memperbarui proxy yang mendasarinya secara dinamis.
    • HAProxy Ingress Controller: Pengontrol Ingress untuk Kubernetes yang menggunakan HAProxy sebagai reverse proxy dan load balancer Lapisan 7, yang juga menangani TLS termination.
    • Nginx Gateway Fabric: Implementasi Gateway API menggunakan NGINX sebagai data plane.
  • Ingress dan Gateway (dengan HTTPRoute): Resource Kubernetes standar yang menentukan port pemrosesan fisik (443) dan aturan pemilihan rute host berbasis SNI dengan TLS Termination.
  • Workload dalam Container (Pod): Deployment Kubernetes standar yang diekspos secara internal menggunakan Service Kubernetes reguler.
  • Workload Berbasis VM (Eksternal): Workload yang dihosting di VM eksternal pada jaringan project, yang diekspos ke proxy dengan Service Kubernetes headless dan endpoint kustom yang berisi IP langsung VM.
  • Harbor Registry: Container Registry pribadi yang digunakan untuk menyimpan dan menyajikan image proxy dan aplikasi di lingkungan air-gapped.

Ingress versus Gateway API

Lanskap jaringan Kubernetes sedang beralih dari Ingress API lama ke Gateway API modern. Memahami perbedaan antara keduanya sangat penting untuk memilih arsitektur yang tepat untuk workload Anda.

  • Ingress API: Secara historis, Ingress telah menjadi standar untuk mengelola akses eksternal ke layanan HTTP. Ingress menyediakan perutean berbasis host dan berbasis jalur, tetapi desainnya relatif dasar dan tidak memiliki dukungan bawaan untuk pengelolaan traffic lanjutan (misalnya, pencocokan berbasis header atau pembobotan traffic) tanpa mengandalkan anotasi khusus vendor. Yang penting, Ingress API kini dianggap dibekukan fiturnya oleh komunitas Kubernetes (batasan Ingress dan evolusi jaringan Kubernetes).

  • Gateway API: Sering disebut sebagai V2 Ingress, Gateway API adalah kumpulan Definisi Resource Kustom (CRD) yang menyediakan model yang lebih kuat dan dapat diperluas untuk jaringan layanan. Gateway API dirancang untuk berorientasi pada peran, yang memisahkan tanggung jawab antara penyedia infrastruktur (GatewayClass), operator cluster (Gateway), dan developer (HTTPRoute/TLSRoute) (Gateway API di GKE). Pemisahan ini memungkinkan kontrol yang lebih terperinci dan dukungan multi-tenancy yang lebih baik.

Dalam solusi GDC dengan air gap ini, kami sengaja memilih API yang berbeda untuk dua pengontrol unggulan:

  • NGINX (Gateway API): Untuk implementasi NGINX, kami menggunakan NGINX Gateway Fabric, yang merupakan implementasi Gateway API yang matang dan bawaan. Dengan memanfaatkan Gateway API untuk NGINX, pelanggan dapat memperoleh manfaat dari standar modern dan kemampuan pemilihan rute lanjutan (seperti HTTPRoute) yang disertakan dalam API.
  • HAProxy (Ingress API): Meskipun Gateway API adalah arah strategis, kami telah memilih Ingress API untuk HAProxy dalam panduan ini. Hal ini karena integrasi Gateway API HAProxy belum dianggap matang. Dengan menggunakan HAProxy Ingress Controller yang sudah mapan, kami memastikan solusi L7 yang stabil dan andal bagi pelanggan yang lebih memilih HAProxy, sekaligus menyediakan jalur menuju kemampuan L7 modern.

Asumsi dan batasan

Asumsi

  • Kesiapan Infrastruktur: Deployment mengasumsikan ketersediaan Cluster Standar GDC dengan air gap 1.15.x.
  • Registry Lokal: Diasumsikan bahwa Harbor Registry lokal dikonfigurasi dengan benar untuk menyimpan dan menyajikan image proxy dan aplikasi di lingkungan air-gap.
  • Titik Entri Native: Traffic diasumsikan akan mencapai Load Balancer L4 GDC bawaan terlebih dahulu, yang kemudian mendistribusikan traffic ke proxy L7.

Batasan

  • Solusi yang Dikelola Pelanggan: Tidak ada layanan L7 yang dikelola dan didukung SLA di GDC; implementasi ini sepenuhnya dikelola sendiri oleh pelanggan.
  • Khusus Cluster Standard: Cluster Pengguna Bersama tidak termasuk dalam cakupan karena hak istimewa tinggi yang diperlukan untuk deployment Ingress dan Gateway Controller.
  • Kematangan API: Meskipun NGINX menggunakan Gateway API modern, HAProxy dibatasi pada Ingress API karena integrasi Gateway API-nya belum dianggap matang.
  • Pemeliharaan Air-Gapped: Semua image container harus dipromosikan dan dikelola secara manual dalam registry Harbor lokal.
  • Edisi Komunitas: Arsitektur ini dirancang untuk edisi komunitas open source Nginx dan HAProxy. Edisi Enterprise mungkin berfungsi, tetapi belum diuji secara eksplisit.
  • Kepemilikan Operasional: Pelanggan harus mengelola penskalaan, ketersediaan tinggi, dan patching mereka sendiri untuk pengontrol pihak ketiga.
  • Batas Dukungan: Dukungan Google hanya mencakup infrastruktur GDC yang mendasarinya; masalah pada software HAProxy atau NGINX itu sendiri merupakan tanggung jawab pelanggan atau vendor.
  • API yang Tidak Digunakan Lagi: Ingress API (digunakan untuk HAProxy) telah dibekukan fiturnya oleh komunitas Kubernetes, yang dapat membatasi kemampuan pemilihan rute di masa mendatang.

Pemberian Lisensi

  • Community Edition: Arsitektur ini dirancang untuk edisi komunitas open source (biasanya Apache 2.0 atau yang serupa), yang dapat digunakan secara gratis, tetapi dikelola oleh pelanggan.
  • Pengadaan Enterprise: Pengadaan dan pengelolaan lisensi komersial, seperti NGINX Plus atau HAProxy Enterprise, sepenuhnya menjadi tanggung jawab pelanggan.

Materi tambahan