Multi Cluster Ingress

Multi Cluster Ingress adalah pengontrol yang dihosting di cloud untuk cluster Google Kubernetes Engine (GKE). Ini adalah layanan yang dihosting oleh Google dan mendukung deployment resource load balancing bersama di seluruh cluster dan di seluruh region. Untuk men-deploy Multi Cluster Ingress di beberapa cluster, selesaikan Menyiapkan Multi Cluster Ingress, lalu lihat Men-deploy Ingress di beberapa cluster.

Untuk perbandingan mendetail antara Multi Cluster Ingress (MCI), Multi-cluster Gateway (MCG), dan load balancer dengan Grup Endpoint Jaringan Mandiri (LB dan Mandiri NEG), lihat Memilih multi-cluster load balancing API untuk GKE.

Networking multi-cluster

Ada banyak faktor yang mendorong topologi multi-cluster, termasuk jarak kedekatan pengguna terhadap aplikasi, ketersediaan tinggi regional dan cluster, pemisahan organisasi dan keamanan, migrasi cluster, serta lokalitas data. Kasus penggunaan ini jarang diisolasi. Seiring bertambahnya alasan untuk memperbanyak cluster, kebutuhan akan platform multi-cluster formal dan terproduksi menjadi lebih mendesak.

Multi Cluster Ingress dirancang untuk memenuhi kebutuhan load balancing lingkungan multi-cluster dan multi-regional. Multi Cluster Ingress merupakan pengendali load balancer HTTP(S) eksternal guna memberikan ingress untuk traffic yang berasal dari internet di satu atau beberapa cluster.

Dukungan multi-cluster Multi Cluster Ingress memenuhi banyak kasus penggunaan, yang mencakup:

  • Satu IP virtual (VIP) yang konsisten untuk aplikasi, terlepas dari tempat aplikasi di-deploy secara global.
  • Ketersediaan multi-regional dan multi-cluster melalui health check dan failover traffic.
  • Perutean berbasis kedekatan melalui VIP Anycast publik untuk latensi klien yang rendah.
  • Migrasi cluster transparan untuk mengupgrade atau membangun ulang cluster.

Kuota default

Multi Cluster Ingress memiliki kuota default berikut:

  • Untuk mengetahui detail tentang batas anggota untuk fleet, lihat kuota pengelolaan fleet.
  • 100 resource MultiClusterIngress dan 100 resource MultiClusterService per project. Anda dapat membuat hingga 100 resource MultiClusterIngress dan 100 MultiClusterService dalam sebuah cluster konfigurasi untuk sejumlah cluster backend hingga jumlah maksimum cluster per project.

Harga dan uji coba

Untuk mempelajari harga Multi Cluster Ingress, lihat Harga Multi Cluster Ingress.

Cara kerja Multi Cluster Ingress

Multi Cluster Ingress dibangun berdasarkan arsitektur Load Balancer Aplikasi eksternal global. Load Balancer Aplikasi eksternal global adalah load balancer yang didistribusikan secara global dengan proxy yang di-deploy di lebih dari 100 titik kehadiran (PoP) Google di seluruh dunia. Proxy ini, yang disebut Google Front Ends (GFE), berada di edge jaringan Google, yang diposisikan dekat dengan klien. Multi Cluster Ingress membuat Load Balancer Aplikasi eksternal dalam Paket Premium. Load balancer ini menggunakan alamat IP eksternal global yang diiklankan menggunakan anycast. Permintaan disajikan oleh GFE dan cluster yang paling dekat dengan klien. Traffic internet menuju ke PoP Google terdekat dan menggunakan backbone Google untuk mencapai cluster GKE. Konfigurasi load balancing ini menghasilkan latensi yang lebih rendah dari klien ke GFE. Anda juga dapat mengurangi latensi antara menyajikan cluster GKE dan GFE dengan menjalankan cluster GKE di region yang paling dekat dengan klien Anda.

Dengan menghentikan koneksi HTTP dan HTTPS di edge, load balancer Google dapat memutuskan ke mana traffic harus dirutekan dengan menentukan ketersediaan backend sebelum traffic memasuki pusat data atau region. Hal ini memberi traffic jalur yang paling efisien dari klien ke backend sembari mempertimbangkan kondisi dan kapasitas backend.

Multi Cluster Ingress adalah pengontrol Ingress yang memprogram load balancer HTTP(S) eksternal menggunakan grup endpoint jaringan (NEG). Saat Anda membuat resource MultiClusterIngress, GKE men-deploy resource load balancer Compute Engine dan mengonfigurasi Pod yang sesuai di seluruh cluster sebagai backend. NEG digunakan untuk melacak endpoint Pod secara dinamis sehingga load balancer Google memiliki kumpulan backend yang responsif dan tepat.

Alur traffic Multi Cluster Ingress

Saat Anda men-deploy aplikasi di berbagai cluster di GKE, Multi Cluster Ingress memastikan bahwa load balancer sinkron dengan peristiwa yang terjadi di cluster:

  • Deployment dibuat dengan label pencocokan yang tepat.
  • Proses Pod dihentikan dan digagalkan health check-nya.
  • Cluster dihapus dari kumpulan backend.

Multi Cluster Ingress memperbarui load balancer, sehingga tetap konsisten dengan lingkungan dan status resource Kubernetes yang diinginkan.

Arsitektur Multi Cluster Ingress

Multi Cluster Ingress menggunakan server Kubernetes API terpusat untuk men-deploy Ingress di beberapa cluster. Server API terpusat ini disebut cluster konfigurasi. Setiap cluster GKE dapat bertindak sebagai cluster konfigurasi. Cluster konfigurasi menggunakan dua jenis resource kustom: MultiClusterIngress dan MultiClusterService. Dengan men-deploy resource ini pada cluster konfigurasi, pengontrol Multi Cluster Ingress men-deploy load balancer di beberapa cluster.

Konsep dan komponen berikut membentuk Multi Cluster Ingress:

  • Pengontrol Multi Cluster Ingress - Ini adalah bidang kontrol yang terdistribusi secara global yang berjalan sebagai layanan di luar cluster Anda. Hal ini memungkinkan siklus proses dan operasi pengontrol tidak bergantung pada cluster GKE.

  • Cluster konfigurasi - Ini adalah cluster GKE pilihan yang berjalan di Google Cloud, tempat resource MultiClusterIngress dan MultiClusterService di-deploy. Ini adalah titik kontrol terpusat untuk resource multi-cluster ini. Resource multi-cluster ini tersedia dan dapat diakses dari satu API logis untuk mempertahankan konsistensi di semua cluster. Pengontrol Ingress mengawasi cluster konfigurasi dan merekonsiliasi infrastruktur load balancing.

  • Dengan fleet, Anda dapat mengelompokkan dan menormalisasi cluster GKE secara logis, sehingga mempermudah administrasi infrastruktur dan memungkinkan penggunaan fitur multi-cluster seperti Multi Cluster Ingress. Anda dapat mempelajari lebih lanjut manfaat fleet dan cara membuatnya di dokumentasi pengelolaan fleet. Sebuah cluster hanya dapat menjadi anggota dari satu fleet.

  • Cluster anggota - Cluster yang terdaftar ke suatu fleet disebut cluster anggota. Cluster anggota dalam fleet terdiri dari cakupan penuh backend yang diketahui oleh Multi Cluster Ingress. Tampilan pengelolaan cluster Google Kubernetes Engine menyediakan konsol aman untuk melihat status semua cluster yang terdaftar.

Arsitektur Multi Cluster Ingress

Alur kerja deployment

Langkah-langkah berikut menggambarkan alur kerja tingkat tinggi untuk menggunakan Multi Cluster Ingress di beberapa cluster.

  1. Daftarkan cluster GKE ke fleet dalam project pilihan Anda.

  2. Konfigurasikan cluster GKE sebagai cluster konfigurasi pusat. Cluster ini dapat berupa bidang kontrol khusus, atau yang dapat menjalankan workload lain.

  3. Deploy aplikasi ke cluster GKE tempat aplikasi tersebut perlu dijalankan.

  4. Deploy satu atau beberapa resource MultiClusterService di cluster konfigurasi dengan kecocokan label dan cluster untuk memilih cluster, namespace, dan Pod yang dianggap sebagai backend untuk Layanan tertentu. Tindakan ini akan menghasilkan NEG di Compute Engine, yang mulai mendaftarkan dan mengelola endpoint layanan.

  5. Deploy resource MultiClusterIngress di cluster konfigurasi yang merujuk satu atau beberapa resource MultiClusterService sebagai backend untuk load balancer. Tindakan ini akan men-deploy resource load balancer eksternal Compute Engine dan mengekspos endpoint di seluruh cluster melalui satu VIP load balancer.

Konsep Ingress

Multi Cluster Ingress menggunakan server Kubernetes API terpusat untuk men-deploy Ingress di beberapa cluster. Bagian berikut menjelaskan model resource Multi Cluster Ingress, cara men-deploy Ingress, dan konsep penting untuk mengelola bidang kontrol jaringan dengan ketersediaan tinggi ini.

Resource MultiClusterService

MultiClusterService adalah resource kustom yang digunakan oleh Multi Cluster Ingress untuk merepresentasikan layanan berbagi di seluruh cluster. Resource MultiClusterService memilih Pod, mirip seperti resource Layanan, tetapi MultiClusterService juga dapat memilih label dan cluster. Kumpulan cluster yang dipilih MultiClusterService disebut cluster anggota. Semua cluster yang terdaftar dalam fleet adalah cluster anggota.

MultiClusterService hanya ada di cluster konfigurasi dan tidak merutekan apa pun seperti yang dilakukan oleh Layanan ClusterIP, LoadBalancer, atau NodePort. Sebagai gantinya, layanan ini memungkinkan pengontrol Multi Cluster Ingress merujuk pada resource terdistribusi tunggal.

Contoh manifes berikut menjelaskan MultiClusterService untuk aplikasi bernama foo:

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: foo
  namespace: blue
spec:
  template:
    spec:
      selector:
        app: foo
      ports:
      - name: web
        protocol: TCP
        port: 80
        targetPort: 80

Manifes ini men-deploy Layanan di semua cluster anggota dengan pemilih app: foo. Jika Pod app: foo ada di cluster tersebut, alamat IP Pod tersebut akan ditambahkan sebagai backend untuk MultiClusterIngress.

mci-zone1-svc-j726y6p1lilewtu7 berikut adalah Layanan turunan yang dihasilkan dalam salah satu cluster target. Layanan ini membuat NEG yang melacak endpoint Pod untuk semua pod yang cocok dengan pemilih label yang ditentukan dalam cluster ini. Layanan dan NEG turunan akan ada di setiap cluster target untuk setiap MultiClusterService (kecuali jika menggunakan pemilih cluster). Jika tidak ada Pod yang cocok di cluster target, Layanan dan NEG akan kosong. Layanan turunan dikelola sepenuhnya oleh MultiClusterService dan tidak dikelola oleh pengguna secara langsung.

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports":{"8080":{}}}'
    cloud.google.com/neg-status: '{"network_endpoint_groups":{"8080":"k8s1-a6b112b6-default-mci-zone1-svc-j726y6p1lilewt-808-e86163b5"},"zones":["us-central1-a"]}'
    networking.gke.io/multiclusterservice-parent: '{"Namespace":"default","Name":"zone1"}'
  name: mci-zone1-svc-j726y6p1lilewtu7
  namespace: blue
spec:
  selector:
    app: foo
  ports:
  - name: web
    protocol: TCP
    port: 80
    targetPort: 80

Beberapa catatan tentang Layanan turunan:

  • Fungsinya adalah sebagai pengelompokan endpoint yang logis seperti backend untuk Multi Cluster Ingress.
  • Layanan ini mengelola siklus proses NEG untuk cluster dan aplikasi tertentu.
  • Dibuat sebagai Layanan headless. Perhatikan bahwa hanya kolom Selector dan Ports yang akan dipindahkan dari MultiClusterService ke layanan turunan.
  • Pengontrol Ingress mengelola siklus prosesnya.

Resource MultiClusterIngress

Resource MultiClusterIngress memiliki perilaku yang identik dengan resource Ingress inti. Keduanya memiliki spesifikasi yang sama untuk menentukan host, jalur, penghentian protokol, dan backend.

Manifes berikut menjelaskan MultiClusterIngress yang merutekan traffic ke backend foo dan bar, bergantung pada header host HTTP:

apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  name: foobar-ingress
  namespace: blue
spec:
  template:
    spec:
      backend:
        serviceName: default-backend
        servicePort: 80
      rules:
      - host: foo.example.com
        backend:
          serviceName: foo
          servicePort: 80
      - host: bar.example.com
        backend:
          serviceName: bar
          servicePort: 80

Resource MultiClusterIngress ini mencocokkan traffic dengan alamat IP virtual pada foo.example.com dan bar.example.com dengan mengirimkan traffic ini ke resource MultiClusterService bernama foo dan bar. MultiClusterIngress ini memiliki backend default yang cocok dengan semua traffic lain dan mengirimkan traffic tersebut ke MultiClusterService backend default.

Diagram berikut menunjukkan bagaimana traffic diarahkan dari Ingress ke cluster:

Dalam diagram, ada dua cluster, gke-us dan gke-eu. Traffic diarahkan dari foo.example.com ke Pod yang memiliki label app:foo di kedua cluster. Dari bar.example.com, traffic diarahkan ke Pod yang memiliki label app:bar di kedua cluster.

Resource Ingress di seluruh cluster

Cluster konfigurasi adalah satu-satunya cluster yang dapat memiliki resource MultiClusterIngress dan MultiClusterService. Setiap cluster target yang memiliki Pod yang cocok dengan pemilih label MultiClusterService juga memiliki Layanan turunan yang sesuai dan dijadwalkan pada cluster tersebut. Jika sebuah cluster secara eksplisit tidak dipilih oleh MultiClusterService, Layanan turunan yang sesuai tidak akan dibuat di cluster tersebut.

Kesamaan namespace

Kesamaan namespace adalah properti cluster Kubernetes tempat namespace diperluas ke seluruh cluster dan dianggap sebagai namespace yang sama.

Dalam diagram berikut, namespace blue ada di seluruh cluster GKE gke-cfg, gke-eu, dan gke-us. Kesamaan namespace menganggap blue namespace sama di semua cluster. Ini berarti pengguna memiliki hak istimewa yang sama atas resource dalam namespace blue di setiap cluster. Kesamaan namespace juga berarti bahwa resource Layanan dengan nama yang sama di beberapa cluster dalam blue namespace dianggap sebagai Layanan yang sama.

Gateway menganggap Layanan sebagai satu kumpulan endpoint di ketiga cluster. Karena Rute dan resource MultiClusterIngress hanya dapat dirutekan ke Layanan dalam namespace yang sama, hal ini akan memberikan multi-tenancy yang konsisten untuk konfigurasi di semua cluster dalam fleet. Fleet memberikan tingkat portabilitas yang tinggi karena resource dapat di-deploy atau dipindahkan di berbagai cluster tanpa perubahan pada konfigurasinya. Deployment ke dalam namespace fleet yang sama akan memberikan konsistensi di seluruh cluster.

Pertimbangkan prinsip desain berikut untuk kesamaan Namespace:

  • Namespace untuk tujuan yang berbeda tidak boleh memiliki nama yang sama di seluruh cluster.
  • Namespace harus direservasi secara eksplisit, dengan mengalokasikan namespace, atau secara implisit, melalui kebijakan out-of-band, untuk tim dan cluster dalam suatu fleet.
  • Namespace untuk tujuan yang sama di seluruh cluster harus memiliki nama yang sama.
  • Izin pengguna untuk Namespace di seluruh cluster harus dikontrol secara ketat guna mencegah akses yang tidak sah.
  • Anda tidak boleh menggunakan Namespace default atau Namespace generik seperti "prod" atau "dev" untuk deployment aplikasi normal. Sangat mudah bagi pengguna untuk men-deploy resource ke Namespace default secara tidak sengaja dan melanggar prinsip segmentasi Namespace.
  • Namespace yang sama harus dibuat di berbagai cluster, dan di mana pun tim atau grup pengguna tertentu harus men-deploy resource.

Desain cluster konfigurasi

Cluster konfigurasi Multi Cluster Ingress adalah cluster GKE tunggal yang menghosting resource MultiClusterIngress dan MultiClusterService serta berfungsi sebagai titik kontrol tunggal untuk Ingress di seluruh fleet cluster GKE target. Anda harus memilih cluster konfigurasi saat mengaktifkan Multi Cluster Ingress. Anda dapat memilih cluster GKE sebagai cluster konfigurasi dan mengubah cluster konfigurasi kapan saja.

Ketersediaan cluster konfigurasi

Karena cluster konfigurasi adalah satu titik kontrol, resource Multi Cluster Ingress tidak dapat dibuat atau diperbarui jika API cluster konfigurasi tidak tersedia. Load balancer dan traffic yang disajikan oleh keduanya tidak akan terpengaruh oleh pemadaman cluster konfigurasi, tetapi perubahan pada resource MultiClusterIngress dan MultiClusterService tidak akan direkonsiliasi oleh pengontrol hingga tersedia lagi.

Pertimbangkan prinsip desain berikut untuk cluster konfigurasi:

  • Cluster konfigurasi harus dipilih sedemikian rupa sehingga memiliki ketersediaan tinggi. Cluster regional lebih diutamakan daripada cluster zona.
  • Untuk mengaktifkan Multi Cluster Ingress, cluster konfigurasi tidak harus berupa cluster khusus. Cluster konfigurasi dapat menghosting workload administratif atau bahkan aplikasi, meskipun Anda harus memastikan bahwa aplikasi yang dihosting tidak memengaruhi ketersediaan server API cluster konfigurasi. Cluster konfigurasi dapat berupa cluster target yang menghosting backend untuk resource MultiClusterService, meskipun tindakan pencegahan tambahan diperlukan, cluster konfigurasi juga dapat dikecualikan sebagai backend melalui pemilihan cluster.
  • Cluster konfigurasi harus memiliki semua Namespace yang digunakan oleh backend cluster target. Resource MultiClusterService hanya dapat mereferensikan Pod di Namespace yang sama di seluruh cluster sehingga Namespace tersebut harus ada di cluster konfigurasi.
  • Pengguna yang men-deploy Ingress di beberapa cluster harus memiliki akses ke cluster konfigurasi untuk men-deploy resource MultiClusterIngress dan MultiClusterService. Namun, pengguna hanya boleh memiliki akses ke Namespace yang diizinkan untuk digunakan.

Memilih dan memigrasikan cluster konfigurasi

Anda harus memilih cluster konfigurasi saat mengaktifkan Multi Cluster Ingress. Setiap cluster anggota fleet dapat dipilih sebagai cluster konfigurasi. Anda dapat memperbarui cluster konfigurasi kapan saja, tetapi Anda harus berhati-hati untuk memastikan bahwa cluster tidak akan menyebabkan gangguan. Pengontrol Ingress akan merekonsiliasi resource apa pun yang ada di cluster konfigurasi. Saat memigrasikan cluster konfigurasi dari cluster saat ini ke cluster berikutnya, resource MultiClusterIngress dan MultiClusterService harus identik. Jika resource tidak identik, Load Balancer Compute Engine mungkin diperbarui atau dihancurkan setelah cluster konfigurasi diperbarui.

Diagram berikut menunjukkan cara sistem CI/CD terpusat menerapkan resource MultiClusterIngress dan MultiClusterService ke server GKE API untuk cluster konfigurasi (gke-us) dan cluster cadangan (gke-eu) setiap saat sehingga resource identik di kedua cluster. Anda dapat mengubah cluster konfigurasi untuk keadaan darurat atau periode nonaktif yang direncanakan kapan saja tanpa dampak apa pun karena resource MultiClusterIngress dan MultiClusterService identik.

Pemilihan cluster

Resource MultiClusterService dapat dipilih di seluruh cluster. Secara default, pengontrol menjadwalkan Layanan turunan di setiap cluster target. Jika tidak ingin Layanan turunan ada di setiap cluster target, Anda dapat menentukan daftar cluster menggunakan kolom spec.clusters dalam manifes MultiClusterService.

Anda mungkin harus menentukan daftar cluster jika Anda perlu:

  • Memisahkan cluster konfigurasi agar resource MultiClusterService tidak memilih seluruh cluster konfigurasi.
  • Mengontrol traffic antar-cluster untuk migrasi aplikasi.
  • Melakukan perutean ke backend aplikasi yang hanya ada di subset cluster.
  • Menggunakan satu alamat IP virtual HTTP(S) untuk memilih rute ke backend yang berada di cluster berbeda.

Anda harus memastikan bahwa cluster anggota dalam fleet dan region yang sama memiliki nama unik untuk mencegah konflik penamaan.

Untuk mempelajari cara mengonfigurasi pemilihan cluster, lihat Menyiapkan Multi Cluster Ingress.

Manifes berikut menjelaskan MultiClusterService yang memiliki kolom clusters yang mereferensikan europe-west1-c/gke-eu dan asia-northeast1-a/gke-asia:

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: foo
  namespace: blue
spec:
  template:
    spec:
      selector:
        app: foo
      ports:
      - name: web
        protocol: TCP
        port: 80
        targetPort: 80
  clusters:
  - link: "europe-west1-c/gke-eu"
  - link: "asia-northeast1-a/gke-asia-1"

Manifes ini menentukan bahwa Pod dengan label yang cocok di cluster gke-asia dan gke-eu dapat disertakan sebagai backend untuk MultiClusterIngress. Cluster lainnya akan dikecualikan meskipun memiliki Pod dengan label app: foo.

Diagram berikut menunjukkan contoh konfigurasi MultiClusterService menggunakan manifes sebelumnya:

Dalam diagram, ada tiga cluster: gke-eu, gke-asia-1, dan gke-asia-2. Cluster gke-asia-2 tidak disertakan sebagai backend, meskipun ada Pod dengan label yang cocok, karena cluster tersebut tidak disertakan dalam daftar spec.clusters manifes. Cluster tidak menerima traffic untuk pemeliharaan atau operasi lainnya.

Langkah berikutnya