Arsitektur referensi load balancing lapisan 7

Arsitektur referensi ini menyediakan solusi load balancing Layer 7 yang dikelola pelanggan di Google Distributed Cloud (GDC) yang terisolasi. Dengan men-deploy pengontrol open source populer seperti HAProxy Kubernetes Ingress atau NGINX Gateway Fabric di cluster standar GDC, pelanggan dapat merutekan traffic L7 dengan lancar ke lingkungan hybrid. 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

  • Perutean Layer 7 Lanjutan: Mendukung perutean berbasis host, perutean 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 secara lancar ke pod dan aplikasi yang di-container bawaan serta 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 Lingkungan Tanpa Koneksi Internet: Terintegrasi dengan Harbor Registry untuk menyimpan dan menayangkan image aplikasi dan proxy dalam lingkungan pribadi yang terputus.
  • Pemisahan Traffic yang Kompleks: Memungkinkan strategi distribusi traffic lanjutan untuk penayangan 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: 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 perutean modern sekaligus mempertahankan dukungan untuk Ingress API lama jika diperlukan stabilitas untuk pengontrol tertentu.
  • 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 berbasis VM dan yang di-container secara konsisten melalui abstraksi Layanan 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 sama untuk merutekan traffic eksternal ke backend internal atau eksternal:

  1. Titik Entri Ingress/Gateway: Klien memulai permintaan HTTPS yang pertama-tama mencapai Load Balancer L4 GDC. Load 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. Bidang Data: Berdasarkan resource yang diamati, pengontrol memperbarui Proxy yang mendasarinya secara dinamis, yang melakukan pemilihan rute traffic sebenarnya berdasarkan aturan pemilihan rute host berbasis SNI dan Penghentian TLS.
  4. Layanan Backend:
    • Pod dalam Container: Dikelola sebagai Deployment standar dan diekspos dengan Layanan Kubernetes reguler.
    • VM eksternal: Terintegrasi 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 ditayangkan dari Harbor Registry lokal untuk memastikan fungsi di lingkungan yang terisolasi

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: Entitas yang memulai permintaan HTTPS untuk berinteraksi dengan aplikasi.
  • Cluster Standard GDC: GDC menyediakan cara bawaan untuk membuat Cluster Vanilla Kubernetes. Dalam solusi ini, cluster akan menghosting L7 LB dan pengontrolnya, beserta workload dan layanan tanpa head 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 Standar. Untuk Nginx, mereka memantau resource Gateway API (seperti Gateway dan HTTPRoute) dan memperbarui proxy yang mendasarinya secara dinamis. Untuk HAProxy, mereka memantau resource Ingress dan memperbarui proxy yang mendasarinya secara dinamis.
    • Pengontrol Ingress HAProxy: Pengontrol Ingress untuk Kubernetes yang menggunakan HAProxy sebagai proxy terbalik dan load balancer Layer 7, serta menangani penghentian TLS.
    • Nginx Gateway Fabric: Penerapan Gateway API menggunakan NGINX sebagai bidang data.
  • Ingress dan Gateway (dengan HTTPRoute): Resource Kubernetes standar yang menentukan port pendengar fisik (443) dan aturan perutean host berbasis SNI dengan Penghentian TLS.
  • 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 di jaringan project, diekspos ke proxy dengan Kubernetes tanpa antarmuka Service dan endpoint kustom yang berisi IP langsung VM.
  • Harbor Registry: Container registry pribadi yang digunakan untuk menyimpan dan menayangkan image proxy dan aplikasi di lingkungan yang terisolasi.

API Ingress versus Gateway

Lingkungan jaringan Kubernetes bertransisi dari Ingress API lama ke Gateway API modern. Memahami perbedaan antara keduanya sangat penting untuk memilih arsitektur yang tepat bagi beban kerja Anda.

  • Ingress API: Secara historis, Ingress telah menjadi standar untuk mengelola akses eksternal ke layanan HTTP. Layanan ini menyediakan perutean berbasis host dan berbasis jalur, tetapi desainnya relatif sederhana 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 feature-frozen 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 jaringan layanan yang lebih andal dan dapat di-extend. Dirancang agar berorientasi pada peran, 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 penerapan NGINX, kami menggunakan NGINX Gateway Fabric, yang merupakan penerapan Gateway API bawaan yang matang. Dengan memanfaatkan Gateway API untuk NGINX, pelanggan dapat memperoleh manfaat dari standar modern dan kemampuan pemilihan rute lanjutan (seperti HTTPRoute) yang sudah ada di 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 tidak dianggap matang. Dengan menggunakan Pengontrol Ingress HAProxy yang sudah mapan, kami memastikan solusi L7 yang stabil dan andal bagi pelanggan yang lebih memilih HAProxy, sekaligus tetap 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 telah dikonfigurasi dengan benar untuk menyimpan dan menyajikan image proxy dan aplikasi di lingkungan air gap.
  • Titik Entri Native: Traffic diasumsikan pertama-tama mencapai Load Balancer L4 GDC bawaan, 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 Standar: 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 ke 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.
  • Community Edition: Arsitektur ini dirancang untuk edisi komunitas open source Nginx dan HAProxy. Enterprise Edition mungkin berfungsi, tetapi belum diuji secara eksplisit.
  • Kepemilikan Operasional: Pelanggan harus mengelola penskalaan, ketersediaan tinggi, dan patch mereka sendiri untuk pengontrol pihak ketiga.
  • Batas Dukungan: Dukungan Google hanya mencakup infrastruktur GDC yang mendasarinya; masalah pada software HAProxy atau NGINX itu sendiri adalah tanggung jawab pelanggan atau vendor.
  • Penghentian Penggunaan API: Ingress API (yang digunakan untuk HAProxy) tidak akan lagi dikembangkan oleh komunitas Kubernetes, yang dapat membatasi kemampuan perutean di masa mendatang.

Pemberian Lisensi

  • Edisi Komunitas: Arsitektur ini dirancang untuk edisi komunitas open source (biasanya Apache 2.0 atau yang serupa), yang gratis digunakan tetapi dikelola pelanggan.
  • Pengadaan Perusahaan: Pengadaan dan pengelolaan lisensi komersial, seperti NGINX Plus atau HAProxy Enterprise, adalah tanggung jawab pelanggan sepenuhnya.

Materi tambahan