GKE Ingress untuk Load Balancer Aplikasi

Halaman ini memberikan ringkasan umum tentang Ingress untuk Load Balancer Aplikasi eksternal dan cara kerjanya. Google Kubernetes Engine (GKE) menyediakan pengontrol Ingress bawaan dan terkelola yang disebut GKE Ingress. Saat Anda membuat resource Ingress di GKE, pengontrol akan otomatis mengonfigurasi load balancer HTTP(S) yang memungkinkan traffic HTTP atau HTTP(S) menjangkau Layanan Anda.

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

Ringkasan

Di GKE, objek Ingress menentukan aturan untuk pemilihan rute traffic HTTP(S) ke aplikasi yang berjalan di cluster. Objek Ingress dikaitkan dengan satu atau beberapa Objek layanan, yang masing-masing terkait dengan kumpulan Pod. Untuk mempelajari lebih lanjut cara Ingress mengekspos aplikasi menggunakan Layanan, lihat Ringkasan jejaring layanan.

Saat Anda membuat objek Ingress, pengontrol GKE Ingress akan membuat Load Balancer HTTP(S) Google Cloud dan mengonfigurasinya sesuai dengan informasi di Ingress dan Layanan terkait.

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

Ingress untuk traffic eksternal dan internal

Resource GKE Ingress terdiri dari dua jenis:

Perilaku pengontrol GKE Ingress

Untuk cluster yang menjalankan GKE versi 1.18 dan yang lebih baru, baik pengontrol GKE Ingress memproses Ingress atau tidak, Ingress 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.

Untuk cluster yang menjalankan versi GKE lama, pengontrol GKE memproses Ingress apa pun yang tidak memiliki anotasi kubernetes.io/ingress.class, atau yang memiliki anotasi dengan nilai gce atau gce-internal.

Penghentian anotasi kubernetes.io/ingress.class

Meskipun anotasi kubernetes.io/ingress.class tidak digunakan lagi di Kubernetes, GKE terus menggunakan anotasi ini.

Anda tidak dapat menggunakan kolom ingressClassName untuk menentukan GKE Ingress. Anda harus menggunakan anotasi kubernetes.io/ingress.class.

Fitur Load Balancer Aplikasi eksternal

Load Balancer Aplikasi eksternal, yang dikonfigurasi oleh Ingress, menyertakan fitur berikut:

  • Konfigurasi fleksibel untuk Layanan. Ingress menentukan bagaimana traffic mencapai Layanan dan bagaimana traffic dirutekan ke aplikasi Anda. Selain itu, Ingress dapat menyediakan satu alamat IP untuk beberapa Layanan di cluster Anda.
  • Integrasi dengan layanan jaringan Google Cloud
  • Dukungan untuk beberapa sertifikat TLS. Ingress dapat menentukan penggunaan beberapa sertifikat TLS untuk penghentian permintaan.

Untuk daftar lengkap, lihat Konfigurasi Ingress.

Metode load balancing

GKE mendukung load balancing dan grup instance native Container.

Load balancing asal container

Load balancing berbasis container adalah praktik load balancing secara langsung ke endpoint Pod di GKE. Load balancing berbasis container adalah jenis Grup Endpoint Jaringan (NEG).

Dengan NEG, traffic akan di-load balancing dari load balancer langsung ke IP Pod, bukan melintasi IP VM dan jejaring kube-proxy. Selain itu, gate kesiapan Pod diterapkan untuk menentukan kondisi Pod dari perspektif load balancer, bukan hanya pemeriksaan kondisi dalam cluster Kubernetes. Tindakan ini meningkatkan stabilitas traffic secara keseluruhan dengan membuat infrastruktur load balancer mengetahui peristiwa siklus proses seperti startup Pod, kehilangan Pod, atau kehilangan VM. Kemampuan ini mengatasi batasan sebelumnya dan menghasilkan jejaring yang lebih berperforma tinggi dan stabil.

Load balancing berbasis container diaktifkan secara default untuk Layanan saat semua kondisi berikut terpenuhi:

  • Untuk Layanan yang dibuat di cluster GKE 1.17.6-gke.7 dan yang lebih baru
  • Menggunakan cluster VPC native
  • Tidak menggunakan jaringan VPC Bersama
  • Tidak menggunakan Kebijakan Jaringan GKE

Dalam kondisi tersebut, Layanan akan dianotasi secara otomatis dengan cloud.google.com/neg: '{"ingress": true}' yang menunjukkan bahwa NEG harus dibuat untuk mencerminkan IP Pod dalam Layanan. Dengan NEG, load balancer Compute Engine dapat berkomunikasi langsung dengan Pod. Perlu diperhatikan bahwa Layanan yang dibuat sebelum GKE 1.17.6-gke.7 tidak akan otomatis dianotasi oleh pengontrol Layanan.

Untuk GKE 1.17.6-gke.7 dan yang lebih lama, dengan anotasi NEG otomatis, Anda dapat menonaktifkan NEG dan memaksa load balancer eksternal Compute Engine untuk menggunakan grup instance sebagai backend jika diperlukan. Hal ini dapat dilakukan dengan menganotasi Layanan secara eksplisit dengan cloud.google.com/neg: '{"ingress": false}'. NEG tidak dapat dinonaktifkan dengan Ingress untuk Load Balancer Aplikasi internal.

Untuk cluster di mana NEG bukan default, sangat direkomendasikan untuk menggunakan load balancing berbasis container, tetapi harus diaktifkan secara eksplisit per Layanan. Anotasi harus diterapkan ke Layanan dengan cara berikut:

kind: Service
...
  annotations:
    cloud.google.com/neg: '{"ingress": true}'
...

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.

VPC Bersama

Resource Ingress dan MultiClusterIngress didukung di VPC Bersama, tetapi memerlukan persiapan tambahan.

Pengontrol Ingress berjalan di bidang kontrol GKE dan melakukan panggilan API ke Google Cloud menggunakan akun layanan GKE dari project cluster. Secara default, saat sebuah cluster yang terletak dalam project layanan VPC Bersama menggunakan jaringan VPC Bersama, pengontrol Ingress tidak dapat menggunakan akun layanan GKE project layanan untuk membuat dan memperbarui aturan firewall dalam project host.

Anda dapat memberikan izin akun layanan GKE pada project layanan untuk membuat dan mengelola aturan firewall VPC di project host. Dengan memberikan izin ini, GKE membuat aturan firewall izinkan traffic masuk untuk yang berikut ini:

  • Proxy Google Front End (GFE) dan sistem health check yang digunakan oleh Load Balancer Aplikasi eksternal untuk Ingress eksternal. Untuk informasi selengkapnya, lihat Ringkasan Load Balancer Aplikasi Eksternal.

  • Health check sistem untuk Load Balancer Aplikasi internal yang digunakan oleh Ingress internal.

Menyediakan aturan firewall secara manual dari project host

Jika kebijakan keamanan Anda hanya mengizinkan pengelolaan firewall dari project host, Anda dapat menyediakan aturan firewall ini secara manual. Saat men-deploy Ingress di VPC Bersama, peristiwa resource Ingress menyediakan aturan firewall tertentu yang perlu Anda tambahkan untuk memberikan akses.

Untuk menyediakan aturan secara manual:

  1. Lihat peristiwa resource Ingress:

    kubectl describe ingress INGRESS_NAME

    Ganti INGRESS_NAME dengan nama Ingress Anda.

    Anda akan melihat output yang mirip dengan contoh berikut ini:

    Events:
Type    Reason  Age                    From                     Message
----    ------  ----                   ----                     -------
Normal  Sync    9m34s (x237 over 38h)  loadbalancer-controller  Firewall change required by security admin: `gcloud compute firewall-rules update k8s-fw-l7--6048d433d4280f11 --description "GCE L7 firewall rule" --allow tcp:30000-32767,tcp:8080 --source-ranges 130.211.0.0/22,35.191.0.0/16 --target-tags gke-l7-ilb-test-b3a7e0e5-node --project <project>`

    Aturan firewall wajib yang disarankan akan muncul di kolom Message.

  2. Salin dan terapkan aturan firewall yang disarankan dari project host. Dengan menerapkan aturan, Anda akan memiliki akses ke Pod dari load balancer dan health checker Google Cloud.

Memberikan izin pengontrol GKE Ingress untuk mengelola aturan firewall project host

Jika Anda ingin cluster GKE dalam project layanan membuat dan mengelola resource firewall di project host Anda, akun layanan GKE project layanan harus diberi izin IAM yang sesuai menggunakan salah satu strategi berikut:

  • Beri akun layanan GKE project layanan peran Compute Security Admin ke project host. Contoh berikut menunjukkan strategi ini.

  • Untuk pendekatan yang lebih mendetail, buat peran IAM kustom yang hanya mencakup izin berikut: compute.networks.updatePolicy, compute.firewalls.list, compute.firewalls.get, compute.firewalls.create, compute.firewalls.update, compute.firewalls.delete, dan compute.subnetworks.list. Beri akun layanan GKE project layanan peran khusus ke project host.

Jika memiliki cluster di lebih dari satu project layanan, Anda harus memilih salah satu strategi dan mengulanginya untuk setiap akun layanan GKE project layanan.

gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
  --member=serviceAccount:service-SERVICE_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
  --role=roles/compute.securityAdmin

Ganti yang berikut ini:

Beberapa layanan backend

Setiap Load Balancer Aplikasi eksternal atau Load Balancer Aplikasi internal menggunakan satu peta URL, yang mereferensikan satu atau beberapa layanan backend. Satu layanan backend terkait ke setiap Layanan yang dirujuk oleh Ingress.

Misalnya, Anda dapat mengonfigurasi load balancer untuk merutekan permintaan ke layanan backend yang berbeda, bergantung pada jalur URL. Permintaan yang dikirimkan ke your-store.example dapat dirutekan ke layanan backend yang menampilkan item dengan harga penuh, dan permintaan yang dikirimkan ke your-store.example/discounted dapat dirutekan ke layanan backend yang menampilkan item diskon.

Anda juga dapat mengonfigurasi load balancer untuk merutekan permintaan sesuai dengan nama host. Permintaan yang dikirim ke your-store.example dapat mengarah ke satu layanan backend, dan permintaan yang dikirim ke your-experimental-store.example dapat dikirim ke layanan backend lain.

Dalam cluster GKE, Anda dapat membuat dan mengonfigurasi load balancer HTTP(S) dengan membuat objek Ingress Kubernetes. Objek Ingress harus dikaitkan dengan satu atau beberapa objek Layanan, yang masing-masing terkait dengan sekumpulan Pod.

Jika ingin mengonfigurasi GKE Ingress dengan beberapa backend untuk host yang sama, Anda harus memiliki satu aturan dengan satu host dan beberapa jalur. Jika tidak, pengontrol ingress GKE hanya menyediakan satu layanan backend

Berikut adalah manifes untuk Ingress yang disebut my-ingress:

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

Saat Anda membuat Ingress, pengontrol GKE Ingress akan membuat dan mengonfigurasi Load Balancer Aplikasi eksternal atau Load Balancer Aplikasi internal sesuai dengan informasi di Ingress dan Layanan terkait. Selain itu, load balancer diberi alamat IP stabil yang dapat Anda kaitkan dengan nama domain.

Pada contoh sebelumnya, anggap Anda telah mengaitkan alamat IP load balancer dengan nama domain your-store.example. Saat klien mengirimkan permintaan ke your-store.example, permintaan tersebut dirutekan ke Layanan Kubernetes bernama my-products pada port 60000. Kemudian, saat klien mengirimkan permintaan ke your-store.example/discount, permintaan tersebut akan dirutekan ke Layanan Kubernetes bernama my-discounted-products pada port 80.

Satu-satunya karakter pengganti yang didukung untuk kolom path pada Ingress adalah karakter *. Karakter * harus mengikuti garis miring (/) dan harus merupakan karakter terakhir dalam pola. Misalnya, /*, /foo/*, dan /foo/bar/* adalah pola yang valid, tetapi *, /foo/bar*, dan /foo/*/bar itu tidak.

Pola yang lebih spesifik lebih diutamakan daripada pola yang kurang spesifik. Jika Anda memiliki /foo/* dan /foo/bar/*, /foo/bar/bat akan diambil untuk mencocokkan /foo/bar/*.

Untuk informasi selengkapnya tentang batasan jalur dan pencocokan pola, lihat dokumentasi Maps URL.

Manifes untuk Layanan my-products mungkin terlihat seperti ini:

apiVersion: v1
kind: Service
metadata:
  name: my-products
spec:
  type: NodePort
  selector:
    app: products
    department: sales
  ports:
  - protocol: TCP
    port: 60000
    targetPort: 50000

Dalam manifes Layanan, Anda harus menggunakan type: NodePort kecuali jika menggunakan load balancing berbasis container. Jika menggunakan load balancing berbasis container, gunakan type: ClusterIP.

Dalam manifes Layanan, kolom selector menyatakan setiap Pod yang memiliki label app: products dan label department: sales adalah anggota Layanan ini.

Saat permintaan masuk ke Layanan di port 60000, permintaan tersebut akan dirutekan ke salah satu Pod anggota pada port TCP 50000.

Setiap Pod anggota harus memiliki container yang memproses port TCP 50000.

Manifes untuk Layanan my-discounted-products mungkin terlihat seperti ini:

apiVersion: v1
kind: Service
metadata:
  name: my-discounted-products
spec:
  type: NodePort
  selector:
    app: discounted-products
    department: sales
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Dalam manifes Layanan, kolom selector menyatakan setiap Pod yang memiliki label app: discounted-products dan label department: sales adalah anggota Layanan ini.

Saat masuk ke Layanan di port 80, permintaan akan dirutekan ke salah satu Pod anggota di port TCP 8080.

Setiap Pod anggota harus memiliki container yang memproses port TCP 8080.

Backend default

Anda dapat menentukan backend default untuk Ingress dengan menyediakan kolom spec.defaultBackend dalam manifes Ingress. Tindakan ini akan menangani permintaan apa pun yang tidak cocok dengan jalur yang ditentukan di kolom rules. Misalnya, dalam Ingress berikut, permintaan apa pun yang tidak cocok dengan /discounted akan dikirim ke layanan bernama my-products pada port 60001.

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

Jika Anda tidak menentukan backend default, GKE akan menyediakan backend default yang menampilkan 404. Objek ini dibuat sebagai layanan NodePort default-http-backend pada cluster dalam namespace kube-system.

Respons HTTP 404 mirip dengan yang berikut ini:

response 404 (backend NotFound), service rules for the path non-existent

Untuk menyiapkan GKE Ingress dengan backend default pelanggan, lihat GKE Ingress dengan backend default kustom.

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.

Opsi untuk menyediakan sertifikat SSL

Anda dapat memberikan sertifikat SSL ke load balancer HTTP(S) menggunakan metode berikut:

Sertifikat yang dikelola Google
Sertifikat SSL yang dikelola Google disediakan, di-deploy, diperpanjang, dan dikelola untuk domain Anda. Sertifikat yang dikelola tidak mendukung domain karakter pengganti.
Sertifikat yang dikelola sendiri yang digunakan bersama dengan Google Cloud
Anda dapat menyediakan sertifikat SSL Anda sendiri dan membuat resource sertifikat di project Google Cloud. Anda kemudian dapat mencantumkan resource sertifikat dalam anotasi di Ingress untuk membuat load balancer HTTP(S) yang menggunakan sertifikat tersebut. Lihat petunjuk untuk sertifikat yang dibagikan sebelumnya untuk informasi selengkapnya.
Sertifikat yang dikelola sendiri sebagai resource Secret
Anda dapat menyediakan sertifikat SSL Anda sendiri dan membuat Secret untuk menyimpannya. Anda kemudian dapat merujuk ke Secret ini dalam spesifikasi Ingress untuk membuat load balancer HTTP(S) yang menggunakan sertifikat tersebut. Lihat petunjuk untuk menggunakan sertifikat di Secret untuk informasi selengkapnya.

Health check

Saat Anda mengekspos satu atau beberapa Layanan melalui Ingress menggunakan pengontrol Ingress default, GKE akan membuat Load Balancer Aplikasi klasik atau Load Balancer Aplikasi internal. Kedua load balancer ini mendukung beberapa layanan backend di satu peta URL. Setiap layanan backend terkait dengan Layanan Kubernetes, dan setiap layanan backend harus merujuk ke health check Google Cloud. Health check ini berbeda dengan pemeriksaan keaktifan atau kesiapan Kubernetes karena health check diterapkan di luar cluster.

Health check load balancer ditentukan per layanan backend. Meskipun Anda dapat menggunakan health check yang sama untuk semua layanan backend load balancer, referensi health check tidak ditentukan untuk seluruh load balancer (di objek Ingress itu sendiri).

GKE membuat health check berdasarkan salah satu metode berikut:

  • CRD BackendConfig: Definisi resource kustom (CRD) yang memberi Anda kontrol yang tepat atas cara Layanan berinteraksi dengan load balancer. CRD BackendConfig memungkinkan Anda menentukan setelan kustom untuk health check yang terkait dengan layanan backend yang sesuai. Setelan kustom ini memberikan fleksibilitas dan kontrol yang lebih besar atas health check untuk Load Balancer Aplikasi klasik dan Load Balancer Aplikasi internal yang dibuat oleh Ingress.
  • Pemeriksaan kesiapan: Pemeriksaan diagnostik yang menentukan apakah penampung dalam Pod siap menyalurkan traffic. Pengontrol GKE Ingress membuat health check untuk layanan backend Layanan berdasarkan pemeriksaan kesiapan yang digunakan oleh Pod penayangan Layanan tersebut. Anda dapat memperoleh parameter health check seperti jalur, port, dan protokol dari definisi pemeriksaan kesiapan.
  • Nilai default: Parameter yang digunakan saat Anda tidak mengonfigurasi CRD BackendConfig atau menentukan atribut untuk pemeriksaan kesiapan.
Praktik terbaik:

Gunakan CRD BackendConfig untuk memiliki kontrol paling besar atas setelan health check load balancer.

GKE menggunakan prosedur berikut untuk membuat health check bagi setiap layanan backend yang terkait dengan Layanan Kubernetes:

  • Jika Layanan mereferensikan CRD BackendConfig dengan informasi healthCheck, GKE akan menggunakannya untuk membuat health check. Pengontrol GKE Enterprise Ingress dan pengontrol GKE Ingress mendukung pembuatan health check dengan cara ini.

  • Jika Layanan tidak merujuk CRD BackendConfig:

    • GKE dapat menyimpulkan beberapa atau semua parameter untuk health check apakah Pod Penayangan menggunakan template Pod dengan container yang pemeriksaan kesiapannya memiliki atribut yang dapat ditafsirkan sebagai parameter health check. Lihat Parameter dari pemeriksaan kesiapan untuk detail implementasi serta Parameter default dan yang ditentukan untuk daftar atribut yang dapat digunakan untuk membuat parameter health check. Hanya pengontrol GKE Ingress yang mendukung inferensi parameter dari pemeriksaan kesiapan.

    • Jika template Pod untuk Pod penayangan Layanan tidak memiliki container dengan pemeriksaan kesiapan yang atributnya dapat ditafsirkan sebagai parameter health check, nilai default akan digunakan untuk membuat health check. Pengontrol Ingress GKE Enterprise dan pengontrol GKE Ingress hanya dapat membuat health check menggunakan nilai default.

Parameter default dan yang disimpulkan

Parameter berikut digunakan saat Anda tidak menentukan parameter health check untuk Layanan terkait menggunakan CRD BackendConfig.

Parameter health check Nilai default Nilai yang dapat disimpulkan
Protokol HTTP jika ada dalam cloud.google.com/app-protocols anotasi Layanan
Jalur permintaan / jika ada dalam spec Pod penayangan:
containers[].readinessProbe.httpGet.path
Minta header Host Host: backend-ip-address jika ada dalam spec Pod penayangan:
containers[].readinessProbe.httpGet.httpHeaders
Respons yang seharusnya HTTP 200 (OK) HTTP 200 (OK)
tidak dapat diubah
Interval pemeriksaan
  • untuk Load balancing berbasis container: 15 detik
  • untuk grup instance: 60 detik
 jika ada dalam spec Pod penayangan:
  • untuk Load balancing berbasis container:
    containers[].readinessProbe.periodSeconds
  • untuk grup instance:
    containers[].readinessProbe.periodSeconds + 60 seconds
Waktu tunggu pemeriksaan 5 detik jika ada dalam spec Pod penayangan:
containers[].readinessProbe.timeoutSeconds
Batas responsif 1 1
tidak dapat diubah
Batas tidak responsif
  • untuk Load balancing berbasis container: 2
  • untuk grup instance: 10
 sama seperti default:
  • untuk Load balancing berbasis container: 2
  • untuk grup instance: 10
Spesifikasi port
  • untuk Load balancing berbasis container: port Layanan
  • untuk grup instance: nodePort Layanan
 Pemeriksaan health check dikirim ke nomor port yang ditentukan oleh spec.containers[].readinessProbe.httpGet.port, selama semua yang berikut ini juga berlaku:
  • Nomor port pemeriksaan kesiapan harus cocok dengan containers[].spec.ports.containerPort Pod penayangan
  • containerPort Pod penayangan cocok dengan targetPort Layanan
  • Spesifikasi port backend layanan Ingress mereferensikan port yang valid dari spec.ports[] Layanan. Hal ini dapat dilakukan dengan salah satu dari dua cara berikut:
    • spec.rules[].http.paths[].backend.service.port.name di Ingress cocok dengan spec.ports[].name yang ditentukan di Layanan terkait
    • spec.rules[].http.paths[].backend.service.port.number di Ingress cocok dengan spec.ports[].port yang ditentukan di Layanan terkait
Alamat IP tujuan
  • untuk Load balancing native container: alamat IP Pod
  • untuk grup instance: alamat IP node
 sama seperti default:
  • untuk Load balancing native container: alamat IP Pod
  • untuk grup instance: alamat IP node

Parameter dari pemeriksaan kesiapan

Saat GKE membuat health check untuk layanan backend Layanan, GKE dapat menyalin parameter tertentu dari pemeriksaan kesiapan satu container yang digunakan oleh Pod penayangan Layanan tersebut. Opsi ini hanya didukung oleh pengontrol GKE Ingress.

Atribut pemeriksaan kesiapan yang didukung yang dapat ditafsirkan sebagai parameter health check dicantumkan bersama dengan nilai default dalam Parameter default dan yang disimpulkan. Nilai default digunakan untuk atribut apa pun yang tidak ditentukan dalam pemeriksaan kesiapan atau jika Anda tidak menentukan pemeriksaan kesiapan sama sekali.

Jika penayangan Pod untuk Layanan Anda berisi beberapa container, atau jika Anda menggunakan pengontrol GKE Enterprise Ingress, Anda harus menggunakan CRD BackendConfig untuk menentukan parameter health check. Untuk informasi selengkapnya, lihat Kapan harus menggunakan CRD BackendConfig.

Kapan harus menggunakan CRD BackendConfig

Alih-alih mengandalkan parameter dari pemeriksaan kesiapan Pod, Anda harus secara eksplisit menentukan parameter health check untuk layanan backend dengan membuat CRD BackendConfig untuk Layanan dalam situasi berikut:

  • Jika Anda menggunakan GKE Enterprise: Pengontrol GKE Enterprise Ingress tidak mendukung perolehan parameter health check dari pemeriksaan kesiapan Pod penayangan. Alat ini hanya dapat membuat health check menggunakan parameter implisit atau seperti yang ditentukan dalam CRD BackendConfig.

  • Jika Anda memiliki lebih dari satu container di Pod penayangan: GKE tidak memiliki cara untuk memilih pemeriksaan kesiapan container tertentu untuk digunakan menyimpulkan parameter health check. Karena setiap container dapat memiliki pemeriksaan kesiapannya sendiri, dan karena pemeriksaan kesiapan bukan parameter yang diperlukan untuk sebuah container, Anda harus menentukan health check untuk layanan backend terkait dengan mereferensikan CRD BackendConfig di Layanan yang sesuai.

  • Jika Anda memerlukan kontrol atas port yang digunakan untuk health check load balancer: GKE hanya menggunakan containers[].readinessProbe.httpGet.port pemeriksaan kesiapan untuk health check layanan backend jika port tersebut cocok dengan port layanan untuk Layanan yang direferensikan dalam spec.rules[].http.paths[].backend.servicePort Ingress.

Parameter dari CRD BackendConfig

Anda dapat menentukan parameter health check layanan backend menggunakan parameter healthCheck dari CRD BackendConfig yang direferensikan oleh Layanan terkait. Hal ini memberi Anda lebih banyak fleksibilitas dan kontrol atas health check untuk Load Balancer Aplikasi klasik atau Load Balancer Aplikasi internal yang dibuat oleh Ingress. Lihat Konfigurasi Ingress untuk kompatibilitas versi GKE.

Contoh CRD BackendConfig ini menentukan protokol (jenis) health check, jalur permintaan, port, dan interval pemeriksaan dalam atribut spec.healthCheck-nya:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: http-hc-config
spec:
  healthCheck:
    checkIntervalSec: 15
    port: 15020
    type: HTTPS
    requestPath: /healthz

Untuk mengonfigurasi semua kolom yang tersedia saat mengonfigurasi health check BackendConfig, gunakan contoh konfigurasi health check kustom.

Untuk menyiapkan GKE Ingress dengan health check HTTP kustom, lihat GKE Ingress dengan health check HTTP kustom.

Menggunakan beberapa sertifikat TLS

Misalnya Anda menginginkan load balancer HTTP(S) untuk menayangkan konten dari dua nama host: your-store.example dan your-experimental-store.example. Selain itu, Anda ingin agar load balancer menggunakan satu sertifikat untuk your-store.example dan sertifikat yang berbeda untuk your-experimental-store.example.

Anda dapat melakukannya dengan menentukan beberapa sertifikat dalam manifes Ingress. Load balancer akan memilih sertifikat jika Nama Umum (CN) dalam sertifikat cocok dengan nama host yang digunakan dalam permintaan. Untuk informasi mendetail tentang cara mengonfigurasi beberapa sertifikat, lihat Menggunakan beberapa sertifikat SSL di Load Balancing HTTPS dengan Ingress.

Layanan Kubernetes dibandingkan dengan layanan backend Google Cloud

Layanan Kubernetes dan layanan backend Google Cloud itu tidaklah sama. Ada hubungan yang kuat di antara keduanya, tetapi hubungan tersebut tidak selalu one-to-one. Pengontrol GKE Ingress membuat layanan backend Google Cloud untuk setiap pasangan (service.name, service.port) dalam manifes Ingress. Jadi, ada kemungkinan satu objek Layanan Kubernetes terkait dengan beberapa layanan backend Google Cloud.

Batasan

  • Dalam cluster yang menggunakan versi lebih lama dari 1.16, panjang total namespace dan nama Ingress tidak boleh lebih dari 40 karakter. Ketidakpatuhan terhadap pedoman ini dapat menyebabkan pengontrol GKE Ingress berperilaku tidak normal. Untuk mengetahui informasi selengkapnya, lihat masalah GitHub tentang nama panjang.

  • 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 di atas 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 menggunakan pengontrol 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.

Detail implementasi

  • Pengontrol Ingress melakukan pemeriksaan izin akun layanan secara berkala dengan mengambil resource pengujian dari project Google Cloud Anda. Anda akan melihat ini sebagai GET dari BackendService global (yang tidak ada) dengan nama k8s-ingress-svc-acct-permission-check-probe. Karena resource ini biasanya tidak ada, permintaan GET akan menampilkan "not found". Hal ini wajar; pengontrol memeriksa bahwa panggilan API tidak ditolak karena masalah otorisasi. Jika Anda membuat BackendService dengan nama yang sama, maka GET akan berhasil, alih-alih menampilkan "not found".

Template untuk konfigurasi Ingress

Langkah berikutnya