GKE Ingress untuk Load Balancer Aplikasi

Autopilot Standard

Halaman ini memberikan ringkasan umum tentang Ingress Google Kubernetes Engine (GKE) untuk Load Balancer Aplikasi, dan menjelaskan cara pengontrol Ingress menyediakan Load Balancer Aplikasi untuk mengekspos aplikasi ke traffic HTTP(S) dari dalam atau luar jaringan VPC Anda.

Halaman ini berfungsi sebagai titik entri utama untuk memahami cara kerja Ingress GKE. Untuk memeriksa arsitektur jaringan yang mendasarinya, pola perutean traffic, dan penerapan keamanan secara lebih mendetail, lihat Tentang perutean dan keamanan Ingress GKE.

Halaman ini mengasumsikan bahwa Anda sudah mengetahui hal-hal berikut:

Halaman ini ditujukan bagi spesialis Jaringan yang mendesain dan membangun arsitektur jaringan untuk organisasi mereka serta menginstal, mengonfigurasi, dan mendukung peralatan jaringan. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam kontenGoogle Cloud , lihat Peran dan tugas pengguna GKE umum.

Ringkasan

GKE menyediakan pengontrol Ingress bawaan dan terkelola yang disebut GKE Ingress. Saat Anda membuat resource Ingress di GKE, pengontrol akan otomatis mengonfigurasi load balancer HTTPS yang memungkinkan traffic HTTP atau HTTPS mencapai Layanan Anda. Pengontrol Ingress mengonfigurasi load balancer dan merutekan traffic ke aplikasi yang berjalan di cluster Anda berdasarkan aturan yang ditentukan dalam manifes Ingress dan objek Service terkait.

Objek Ingress dikaitkan dengan satu atau beberapa objek Layanan, yang pada gilirannya dikaitkan dengan sekumpulan Pod. Untuk mempelajari lebih lanjut cara Ingress mengekspos aplikasi menggunakan Layanan, lihat Ringkasan jejaring layanan.

Untuk menggunakan Ingress, Anda harus mengaktifkan add-on load balancing HTTP. Cluster GKE mengaktifkan add-on ini secara default; Anda tidak boleh menonaktifkannya.

Perbedaan antara Layanan Kubernetes dan Google Cloud layanan backend

Objek Layanan Kubernetes dan objek Google Cloud backend service memiliki tujuan yang serupa tetapi berbeda. Meskipun sangat terkait, hubungan tersebut tidak selalu bersifat one-to-one.

Pengontrol Ingress GKE bertindak sebagai penerjemah antara dua konsep ini. Saat Anda membuat resource Ingress, pengontrol akan menyediakan load balancerGoogle Cloud . Kemudian, pengontrol membuat layanan backendGoogle Cloud khusus untuk setiap kombinasi (service.name, service.port) unik yang dirujuk dalam manifes Ingress.

Misalnya, manifes Ingress mungkin memiliki nama Layanan Kubernetes yang sama, tetapi mengarah ke service.port yang berbeda untuk dua aturan host atau path yang terpisah. Dalam kasus ini, pengontrol GKE Ingress membuat dua layanan backend terpisah. Oleh karena itu, satu objek Layanan Kubernetes dapat terkait dengan beberapa layanan backend. Google Cloud

Ingress untuk traffic eksternal dan internal

Ada dua jenis resource GKE Ingress:

Ingress untuk Load Balancer Aplikasi eksternal men-deploy Load Balancer Aplikasi klasik. Load balancer yang terhubung ke internet ini di-deploy secara global di seluruh jaringan edge Google sebagai kumpulan resource load balancing yang terkelola dan skalabel. Pelajari cara menyiapkan dan menggunakan Ingress untuk Load Balancer Aplikasi eksternal.
Ingress untuk Load Balancer Aplikasi internal men-deploy Load Balancer Aplikasi internal. Load Balancer Aplikasi internal ini didukung oleh sistem proxy Envoy di luar cluster GKE, tetapi di dalam jaringan VPC Anda. Pelajari cara menyiapkan dan menggunakan Ingress untuk Load Balancer Aplikasi internal.

Lingkungan jaringan yang diperlukan untuk Load Balancer Aplikasi eksternal

Load Balancer Aplikasi eksternal adalah sistem terkelola yang didistribusikan secara global yang menggunakan proxy Google Front End (GFE) yang di-deploy di seluruh jaringan edge Google. Proxy ini tidak berada dalam jaringan VPC Anda. Saat klien mengirim permintaan ke alamat IP eksternal load balancer, permintaan akan dirutekan menggunakan jaringan anycast Google ke GFE terdekat. GFE menghentikan traffic pengguna (termasuk TLS, jika dikonfigurasi), lalu meneruskan traffic ke Pod backend di cluster GKE Anda.

Agar alur ini berfungsi, pengontrol Ingress GKE secara otomatis membuat aturan firewall untuk mengizinkan traffic dari GFE dan dari sistem health checkGoogle Clouduntuk menjangkau Pod Anda. Aturan ini mengizinkan traffic dari rentang alamat IP Google yang diketahui (130.211.0.0/22 dan 35.191.0.0/16).

Berikut cara kerja Load Balancer Aplikasi eksternal:

Klien mengirimkan permintaan ke alamat IP dan port aturan penerusan load balancer.
Permintaan dirutekan ke proxy Google Front End (GFE) di jaringan global Google. Proxy ini menghentikan koneksi jaringan klien.
Proxy GFE meneruskan permintaan ke endpoint Pod backend yang sesuai di cluster GKE Anda, seperti yang ditentukan oleh peta URL dan layanan backend load balancer.

Tidak seperti Load Balancer Aplikasi internal, tidak ada persyaratan untuk mengonfigurasi subnet khusus proxy di jaringan VPC Anda untuk Load Balancer Aplikasi eksternal.

Lingkungan jaringan yang diperlukan untuk Load Balancer Aplikasi internal

Load Balancer Aplikasi internal menyediakan kumpulan proxy untuk jaringan Anda. Proxy mengevaluasi tempat setiap permintaan HTTP(S) harus diarahkan berdasarkan faktor-faktor seperti peta URL, afinitas sesi BackendService, dan mode penyeimbangan setiap NEG backend.

Load Balancer Aplikasi internal suatu region menggunakan subnet khusus proxy untuk region tersebut dalam jaringan VPC Anda guna menetapkan alamat IP internal ke setiap proxy yang dibuat oleh Google Cloud.

Secara default, alamat IP yang ditetapkan ke aturan penerusan load balancer berasal dari rentang subnet node yang ditetapkan oleh GKE, bukan dari subnet khusus proxy. Anda juga dapat menentukan alamat IP secara manual untuk aturan penerusan dari subnet mana pun saat membuat aturan.

Diagram berikut memberikan ringkasan alur traffic untuk Load Balancer Aplikasi internal, seperti yang dijelaskan di paragraf sebelumnya.

gambar

Berikut cara kerja Load Balancer Aplikasi internal:

Klien membuat koneksi ke alamat IP dan port aturan penerusan load balancer.
Proxy menerima dan menghentikan koneksi jaringan klien.
Proxy ini membuat koneksi ke endpoint (Pod) yang sesuai dalam NEG, seperti yang ditentukan oleh peta URL load balancer dan layanan backend.

Setiap proxy memproses alamat IP dan port yang ditentukan oleh aturan penerusan load balancer yang sesuai. Alamat IP sumber setiap paket yang dikirim dari proxy ke endpoint adalah alamat IP internal yang ditetapkan ke proxy tersebut dari subnet khusus proxy.

Perilaku pengontrol GKE Ingress

Apakah pengontrol Ingress GKE memproses Ingress atau tidak, bergantung pada nilai anotasi kubernetes.io/ingress.class:

Nilai `kubernetes.io/ingress.class`	Nilai `ingressClassName`	Perilaku pengontrol GKE Ingress
Belum disetel	Belum disetel	Proses manifes Ingress dan buat Load Balancer Aplikasi eksternal.
Belum disetel	Semua nilai	Tidak memerlukan tindakan apa pun. Manifes Ingress dapat diproses oleh pengontrol Ingress pihak ketiga jika ada yang sudah di-deploy.
`gce`	Semua nilai. Kolom ini diabaikan.	Proses manifes Ingress dan buat Load Balancer Aplikasi eksternal.
`gce-internal`	Semua nilai. Kolom ini diabaikan.	Proses manifes Ingress dan buat Load Balancer Aplikasi internal.
Tetapkan ke nilai selain `gce` atau `gce-internal`	Semua nilai	Tidak memerlukan tindakan apa pun. Manifes Ingress dapat diproses oleh pengontrol Ingress pihak ketiga jika ada yang sudah di-deploy.

Penghentian anotasi `kubernetes.io/ingress.class`

Meskipun anotasi kubernetes.io/ingress.class tidak digunakan lagi di Kubernetes, GKE terus menggunakan anotasi ini. Anda harus menggunakan anotasi ini untuk mengidentifikasi class Ingress.

Saat menerapkan konfigurasi, Anda mungkin akan melihat peringatan penghentian penggunaan. Peringatan ini mencatat bahwa anotasi tidak digunakan lagi dan menginstruksikan Anda untuk menggunakan kolom ingressClassName. Anda dapat mengabaikan peringatan ini dengan aman karena GKE Ingress terus mengandalkan secara eksklusif anotasi kubernetes.io/ingress.class.

Ingress ke pemetaan resource Compute Engine

Pengontrol GKE Ingress men-deploy dan mengelola resource load balancer Compute Engine berdasarkan resource Ingress yang di-deploy dalam cluster. Pemetaan resource Compute Engine bergantung pada struktur resource Ingress.

Manifes berikut menjelaskan Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-products
            port:
              number: 60000
      - path: /discounted
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-discounted-products
            port:
              number: 80

Manifes Ingress ini meminta GKE untuk membuat resource Compute Engine berikut:

Aturan penerusan dan alamat IP.
Aturan firewall Compute Engine yang mengizinkan traffic untuk health check load balancer dan traffic aplikasi dari Google Front Ends atau proxy Envoy.
Proxy HTTP target dan proxy HTTPS target, jika Anda mengonfigurasi TLS.
Peta URL yang dengan aturan host tunggal yang mereferensikan satu pencocok jalur. Pencocok jalur memiliki dua aturan jalur, satu untuk /* dan satu lagi untuk /discounted. Setiap aturan jalur dipetakan ke layanan backend unik.
NEG yang menyimpan daftar alamat IP Pod dari setiap Layanan sebagai endpoint. Ini dibuat sebagai hasil dari Layanan my-discounted-products dan my-products.

Metode load balancing

GKE mendukung load balancing berbasis container dan grup instance.

Load balancing asal container

Load balancing berbasis container adalah praktik load balancing secara langsung ke endpoint Pod di GKE. Load balancing berbasis container menggunakan Network Endpoint Groups (NEG) berjenis GCE_VM_IP_PORT, dengan endpoint berupa alamat IP Pod.

Load balancing berbasis container selalu digunakan untuk Ingress GKE internal dan bersifat opsional untuk Ingress eksternal. Pengontrol Ingress akan membuat load balancer, termasuk alamat IP virtual, aturan penerusan, health check, dan aturan firewall.

Load balancing berbasis container mendukung afinitas sesi berbasis Pod.

GKE otomatis mengaktifkan load balancing berbasis container jika semua kondisi berikut terpenuhi:

Cluster bersifat VPC native.
Cluster tidak menggunakan jaringan VPC Bersama.
Cluster tidak menggunakan Kebijakan Jaringan GKE.
Cluster telah mengaktifkan add-on HttpLoadBalancing. Add-on HttpLoadBalancing diaktifkan secara default di cluster GKE; Anda tidak boleh menonaktifkannya.

Saat GKE mengaktifkan load balancing berbasis container, Service akan dianotasi secara otomatis dengan cloud.google.com/neg: '{"ingress": true}'. Anotasi ini memicu pembuatan NEG yang mencerminkan IP Pod, sehingga load balancer Compute Engine dapat berkomunikasi langsung dengan Pod.

Untuk cluster di mana NEG bukan default, sangat direkomendasikan untuk menggunakan load balancing berbasis container, tetapi harus diaktifkan secara eksplisit per Layanan.

Untuk fleksibilitas yang lebih besar, Anda juga dapat membuat NEG mandiri. Dalam hal ini, Anda bertanggung jawab untuk membuat dan mengelola semua aspek load balancer.

Manfaat

Dengan menggunakan NEG, load balancing berbasis container menawarkan jaringan yang lebih berperforma tinggi dan stabil:

Peningkatan performa jaringan: tanpa load balancing berbasis container, traffic berpindah ke grup instance node, lalu mengandalkan aturan iptables yang dikonfigurasi oleh kube-proxy untuk merutekan ke Pod target. Dengan load balancing berbasis container, traffic akan di-load balance langsung ke Pod, sehingga tidak perlu merutekan melalui IP VM dan jaringan kube-proxy di node. Alur ini menghilangkan hop jaringan tambahan, serta meningkatkan latensi dan throughput.

Pemeriksaan Kondisi yang Ditingkatkan: Gerbang kesiapan Pod diimplementasikan untuk menentukan kondisi Pod dari perspektif load balancer, bukan hanya mengandalkan pemeriksaan kondisi dalam cluster. Fitur penting ini membuat load balancer mengetahui peristiwa siklus proses Pod (startup, kehilangan, dll.), dan meningkatkan stabilitas traffic. Untuk mempelajari lebih lanjut cara penggunaan gate kesiapan Pod untuk menentukan kesehatan Pod, lihat Kesiapan Pod.

Peningkatan visibilitas: dengan load balancing berbasis container, Anda memiliki visibilitas ke latensi dari Load Balancer Aplikasi langsung ke setiap Pod. Karena latensi tidak lagi diagregasi di tingkat IP node, pemecahan masalah Layanan Anda di tingkat NEG menjadi lebih mudah.

Dukungan untuk Cloud Service Mesh: model data NEG diperlukan untuk menggunakan Cloud Service Mesh, yaitu bidang kontrol traffic yang terkelola sepenuhnya dari Google Clouduntuk mesh layanan.

Batasan load balancer berbasis container

Load balancer berbasis container melalui Ingress di GKE memiliki batasan berikut:

Load balancer berbasis container tidak mendukung Load Balancer Jaringan passthrough eksternal.
Anda tidak boleh secara manual mengubah atau memperbarui konfigurasi Load Balancer Aplikasi yang dibuat GKE. Setiap perubahan yang Anda buat akan ditimpa oleh GKE.

Harga untuk load balancer berbasis container

Anda akan dikenai biaya atas Load Balancer Aplikasi yang disediakan oleh Ingress yang Anda buat dalam panduan ini. Untuk mengetahui informasi harga load balancer, lihat Aturan penerusan dan load balancing di halaman harga VPC.

Grup instance

Saat menggunakan grup instance, load balancer Compute Engine mengirimkan traffic ke alamat IP VM sebagai backend. Saat menjalankan container pada VM, dengan container yang memiliki antarmuka host yang sama, tindakan ini menimbulkan batasan berikut:

Proses ini menimbulkan dua hop load balancing - satu hop dari load balancer ke VM NodePort dan hop lainnya melalui pemilihan rute kube-proxy ke alamat IP Pod (yang mungkin berada di VM yang berbeda).
Hop tambahan menambah latensi dan membuat jalur traffic lebih kompleks.
Load balancer Compute Engine tidak memiliki visibilitas langsung ke Pod sehingga menghasilkan balancing traffic yang kurang optimal.
Peristiwa lingkungan seperti kehilangan VM atau Pod lebih cenderung menyebabkan hilangnya traffic yang terputus-putus karena hop traffic ganda.

Cluster berbasis rute dan Ingress Eksternal

Jika Anda menggunakan cluster berbasis rute dengan Ingress eksternal, pengontrol GKE Ingress tidak dapat menggunakan load balancing berbasis container menggunakan grup endpoint jaringan (NEG) GCE_VM_IP_PORT. Sebagai gantinya, pengontrol Ingress menggunakan backend grup instance tidak terkelola yang mencakup semua node di semua node pool. Jika grup instance tidak terkelola ini juga digunakan oleh Layanan LoadBalancer, hal itu dapat menyebabkan masalah terkait Batasan grup load balanced instance tunggal.

Beberapa objek Ingress eksternal lama yang dibuat di cluster VPC native mungkin menggunakan backend grup instance pada layanan backend setiap Load Balancer Aplikasi eksternal yang dibuat. Hal ini tidak relevan dengan Ingress internal karena resource Ingress internal selalu menggunakan NEG GCE_VM_IP_PORT dan memerlukan cluster VPC native.

Untuk mempelajari cara memecahkan masalah error 502 terkait Ingress eksternal, lihat Ingress Eksternal menghasilkan error HTTP 502.

Batasan pengontrol GKE Ingress

GKE Ingress tidak mendukung sertifikat yang dikelola oleh Certificate Manager. Untuk menggunakan sertifikat yang dikelola oleh Certificate Manager, gunakan Gateway API.
Pada cluster yang menggunakan NEG, waktu rekonsiliasi masuk dapat dipengaruhi oleh jumlah traffic masuk. Misalnya, cluster dengan 20 traffic masuk, masing-masing berisi 20 backend NEG yang berbeda, dapat menyebabkan latensi lebih dari 30 menit agar perubahan traffic masuk dapat direkonsiliasi. Hal ini terutama berdampak pada klaster regional karena meningkatnya jumlah NEG yang diperlukan.
Kuota untuk peta URL berlaku.
Kuota untuk resource Compute Engine berlaku.
Jika Anda tidak menggunakan NEG dengan pengontrol traffic masuk GKE,cluster GKE memiliki batas 1.000 node. Jika layanan di-deploy dengan NEG, tidak ada batas node GKE. Layanan non-NEG yang diekspos melalui Ingress tidak berfungsi dengan benar pada cluster yang memiliki lebih dari 1.000 node.
Agar pengontrol GKE Ingress dapat menggunakan readinessProbes Anda sebagai health check, Pod untuk Ingress harus ada pada saat pembuatan Ingress. Jika replika diskalakan ke 0, health check default akan berlaku. Untuk mengetahui informasi selengkapnya, lihat komentar masalah GitHub tentang health check.
Perubahan pada readinessProbe Pod tidak memengaruhi Ingress setelah dibuat.
Load Balancer Aplikasi eksternal menghentikan TLS di lokasi yang didistribusikan secara global, untuk meminimalkan latensi antara klien dan load balancer. Jika memerlukan kontrol geografis atas tempat TLS dihentikan, Anda harus menggunakanpengontrol ingress kustom yang diekspos melalui Layanan GKE jenis LoadBalancer sebagai gantinya, dan menghentikan TLS di backend yang berada di region yang sesuai dengan kebutuhan Anda.
Menggabungkan beberapa resource Ingress ke dalam satu load balancer Google Cloud tidak didukung.
Anda harus menonaktifkan TLS bersama di aplikasi Anda karena tidak didukung untuk Load Balancer Aplikasi eksternal.
Ingress hanya dapat mengekspos port HTTP 80 dan 443 untuk frontend-nya.