Tentang pemilihan rute dan keamanan GKE Ingress

Autopilot Standard

Halaman ini menjelaskan kemampuan inti dan arsitektur jaringan GKE Ingress, khususnya mengamankan koneksi dari klien ke load balancer dan hingga ke Pod aplikasi, mengelola perutean yang kompleks di beberapa layanan backend, dan memahami cara pemeriksaan kondisi load balancer diatur dalam cluster.

Halaman ini dibangun berdasarkan konsep dasar yang dijelaskan dalam Ringkasan Ingress GKE. Untuk petunjuk langkah demi langkah dan contoh penerapan menggunakan resource kustom seperti FrontendConfig dan BackendConfig, lihat Mengonfigurasi fitur Ingress untuk aplikasi GKE.

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.

Mengamankan Ingress dengan HTTPS

GKE Ingress mengamankan traffic antara klien dan Load Balancer Aplikasi, serta dari load balancer ke Pod aplikasi.

Mengonfigurasi TLS antara klien dan load balancer

Load balancer HTTP(S) bertindak sebagai proxy antara klien dan aplikasi Anda. Jika Anda ingin menerima permintaan HTTPS dari klien, load balancer harus memiliki sertifikat agar dapat membuktikan identitasnya kepada klien Anda. Load balancer juga harus memiliki kunci pribadi untuk menyelesaikan handshake HTTPS.

Saat load balancer menerima permintaan HTTPS dari klien, traffic antara klien dan load balancer dienkripsi menggunakan TLS. Namun, load balancer menghentikan enkripsi TLS dan meneruskan permintaan tanpa enkripsi ke aplikasi. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi enkripsi antara load balancer dan aplikasi Anda.

Metode untuk menyediakan Sertifikat SSL

Catatan: Untuk menggunakan sertifikat yang dikelola oleh Certificate Manager, sebaiknya Anda menggunakan Gateway API. GKE Ingress tidak mendukung sertifikat yang dikelola oleh Certificate Manager.

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

• Sertifikat yang dikelola Google: Ini adalah sertifikat Validasi Domain (DV) yang disediakan, diperpanjang, dan dikelola Google untuk nama domain Anda. Sertifikat ini tidak menunjukkan identitas Anda atau organisasi Anda. Sertifikat yang dikelola Google mendukung hingga 100 domain non-karakter pengganti. Untuk mengetahui informasi selengkapnya, lihat Menggunakan sertifikat yang dikelola Google.

• Sertifikat yang dikelola sendiri yang dibagikan dengan Google Cloud: Anda dapat menyediakan sertifikat SSL Anda sendiri dan membuat resource sertifikat di project Google Cloud Anda. Kemudian, Anda mencantumkan resource sertifikat dalam anotasi di Ingress untuk membuat load balancer HTTP(S) yang menggunakan sertifikat tersebut. Untuk mengetahui informasi selengkapnya, lihat Menggunakan sertifikat yang dibagikan sebelumnya.

• Sertifikat yang dikelola sendiri yang menggunakan Secret Kubernetes: Anda dapat menyediakan sertifikat SSL Anda sendiri dan membuat Secret untuk menyimpannya. Anda kemudian dapat merujuk ke Secret ini di kolom tls pada manifes Ingress untuk membuat load balancer HTTP(S). Untuk informasi selengkapnya, lihat Menggunakan Secret Kubernetes.

Menyalurkan traffic HTTPS dengan beberapa sertifikat

Anda dapat mengonfigurasi Load Balancer Aplikasi untuk memberikan hingga 15 sertifikat TLS kepada klien. Penggunaan beberapa sertifikat sangat penting saat Anda perlu menayangkan konten dari beberapa nama host, yang masing-masing memerlukan sertifikat yang berbeda (misalnya, sertifikat terpisah untuk your-store.example dan your-experimental-store.example). Anda menentukan beberapa sertifikat ini dalam manifes Ingress.

Pemilihan dan prioritas sertifikat

Untuk menentukan sertifikat yang akan ditampilkan kepada klien, load balancer menggunakan Server Name Indication (SNI).

• Jika klien menggunakan SNI, atau menggunakan nama domain yang cocok dengan Nama Umum (CN) di salah satu sertifikat yang tersedia, load balancer akan menggunakan sertifikat yang CN-nya paling cocok dengan nama host yang diminta oleh klien.

• Jika klien tidak mendukung SNI, atau nama domain yang diminta tidak cocok dengan CN sertifikat yang tersedia, load balancer akan menggunakan sertifikat pertama yang tercantum dalam manifes Ingress sebagai default. Load balancer memilih sertifikat ini sesuai dengan aturan berikut:

  • Untuk Secret yang tercantum dalam blok tls: sertifikat utama adalah Secret pertama dalam blok tls.
  • Untuk sertifikat yang dibagikan sebelumnya dalam anotasi pre-shared-cert: sertifikat utama adalah sertifikat pertama yang tercantum dalam anotasi.
  • untuk sertifikat yang dikelola Google dalam anotasi managed-certificates: semua sertifikat yang dikelola diurutkan berdasarkan nama dalam urutan abjad. Sertifikat utama adalah sertifikat yang muncul pertama dalam daftar abjad ini. Untuk menetapkan sertifikat tertentu sebagai sertifikat utama, Anda harus memberi nama objek ManagedCertificate dengan tepat untuk mengontrol urutan pengurutan. Misalnya, untuk menjadikan my-default-cert sebagai yang utama daripada another-cert, Anda dapat menamainya 0-my-default-cert dan 1-another-cert.

Saat load balancer menampilkan beberapa sertifikat melalui berbagai metode GKE, sertifikat yang dibagikan sebelumnya akan lebih diprioritaskan daripada Secret yang tercantum dalam blok tls Ingress.

Diagram berikut menunjukkan load balancer yang mengirimkan traffic ke backend yang berbeda, bergantung pada nama domain yang digunakan dalam permintaan:

Praktik terbaik rotasi sertifikat

Jika Anda ingin merotasi konten Secret atau sertifikat yang dibagikan sebelumnya, berikut beberapa praktik terbaik:

• Buat Secret baru atau sertifikat yang dibagikan sebelumnya dengan nama berbeda yang berisi data sertifikat baru. Perbarui Ingress Anda untuk menggunakan resource sertifikat baru.
• Jika tidak keberatan mengganggu traffic, Anda dapat menghapus resource lama dari Ingress, menyediakan resource baru dengan nama yang sama, tetapi dengan konten yang berbeda, lalu melampirkannya kembali ke Ingress.

Agar tidak perlu mengelola rotasi sertifikat sendiri, gunakan sertifikat SSL yang dikelola Google.

Menerapkan traffic khusus HTTPS

Jika Anda ingin semua traffic antara klien dan load balancer HTTP(S) menggunakan HTTPS, Anda dapat menonaktifkan HTTP dengan menyertakan anotasi kubernetes.io/ingress.allow-http dalam manifes Ingress dan menyetel nilai ke "false". Untuk mengetahui informasi selengkapnya, lihat Menonaktifkan HTTP.

Perhatian: Penonaktifan HTTP tidak didukung untuk Multi Cluster Ingress.

Mengonfigurasi enkripsi antara load balancer dan aplikasi Anda

Bagian ini menjelaskan cara mengamankan koneksi dari load balancer ke Pod aplikasi.

Mengaktifkan Protokol Backend HTTPS atau HTTP/2

Load Balancer Aplikasi eksternal bertindak sebagai proxy antara klien dan aplikasi GKE Anda. Meskipun klien dapat terhubung ke load balancer menggunakan HTTPS (untuk enkripsi) dan berbagai protokol (HTTP/1.1 atau HTTP/2), koneksi dari load balancer ke Pod backend Anda secara default menggunakan HTTP/1.1 yang tidak terenkripsi.

Jika aplikasi Anda mampu menangani konfigurasi yang lebih canggih, Anda dapat memperbarui Load Balancer Aplikasi eksternal secara manual untuk menggunakan:

• HTTP/2: untuk mengoptimalkan performa jika Pod Anda mendukungnya.
• HTTPS (TLS): untuk menerapkan enkripsi end-to-end untuk traffic antara proxy load balancer dan Pod Anda.

Anda mengontrol protokol (HTTP atau HTTPS) dan versi HTTP (HTTP/1.1 atau HTTP/2) yang digunakan untuk koneksi backend dengan menggunakan anotasi cloud.google.com/app-protocols dalam manifes Layanan Kubernetes. Manifes Service ini harus menyertakan type: NodePort kecuali jika Anda menggunakan load balancing berbasis container. Jika Anda menggunakan load balancing berbasis container, gunakan type: ClusterIP.

Alamat IP statis untuk load balancer HTTPS

Saat membuat objek Ingress untuk Load Balancer Aplikasi eksternal, Anda akan mendapatkan alamat IP eksternal yang stabil yang dapat digunakan klien untuk mengakses Layanan Anda, yang kemudian menjadi container yang sedang berjalan. Alamat IP stabil dalam arti berlaku selama masa aktif objek Ingress. Jika menghapus Ingress dan membuat Ingress baru dari file manifes yang sama, Anda tidak dijamin akan mendapatkan alamat IP eksternal yang sama.

Jika menginginkan alamat IP permanen yang tetap sama saat menghapus Ingress dan membuat yang baru, Anda harus mencadangkan alamat IP eksternal statis global. Kemudian, dalam manifes Ingress, sertakan anotasi yang memberikan nama alamat IP statis yang dicadangkan. Jika Anda mengubah Ingress yang ada untuk menggunakan alamat IP statis, bukan alamat IP sementara, GKE dapat mengubah alamat IP load balancer saat GKE membuat ulang aturan penerusan load balancer.

Merutekan Traffic

Ingress GKE menggunakan peta URL untuk menentukan cara permintaan masuk dirutekan ke layanan backend tertentu. Anda dapat mengonfigurasi aturan perutean berdasarkan nama host, jalur URL, atau kombinasi keduanya untuk mengelola traffic beberapa aplikasi melalui satu load balancer.

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
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-products
            port:
              number: 60000
      - path: /discounted
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-discounted-products
            port:
              number: 80

Catatan: Untuk menggunakan Ingress, Anda harus mengaktifkan add-on Load Balancer Aplikasi eksternal. Cluster GKE memiliki Load Balancer Aplikasi eksternal yang diaktifkan secara default; Anda tidak boleh menonaktifkannya.

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/products, permintaan tersebut dirutekan ke Layanan Kubernetes bernama my-products pada port 60000. Kemudian, saat klien mengirimkan permintaan ke your-store.example/discounted, 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

Perhatikan hal berikut dalam manifes sebelumnya:

• Kolom spec.type bergantung pada metode load balancing yang Anda gunakan:

  • Jika Anda menggunakan load balancing berbasis container, gunakan type: ClusterIP.
  • Jika Anda menggunakan grup instance, gunakan type: NodePort.

• Kolom selector menyatakan setiap Pod yang memiliki label app: products dan label department: sales adalah anggota Service 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

Perhatikan hal berikut dalam manifes sebelumnya:

• 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. Hal 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 di 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 kustom, lihat GKE Ingress dengan backend default kustom.

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 Google Cloud health check. 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 Anda 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 container 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 Ingress GKE Enterprise dan pengontrol Ingress GKE 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 Ingress GKE hanya bisa membuat health check menggunakan nilai default.

Catatan: Kolom containerPort harus ditentukan di bagian spesifikasi pod dan kolom targetPort harus ditentukan di bagian spesifikasi layanan untuk health check untuk menyimpulkan parameter yang ditentukan di pemeriksaan kesiapan. Jika tidak ditentukan, health check untuk layanan backend akan ditetapkan secara default ke jalur "/" meskipun parameter ditentukan dalam pemeriksaan kesiapan.

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 berbasis container: alamat IP Pod untuk grup instance: alamat IP node	sama seperti default: untuk Load balancing berbasis container: alamat IP Pod untuk grup instance: alamat IP node

Catatan: Pemeriksaan kesiapan Kubernetes yang valid mendukung penyetelan beberapa header HTTP di readinessProbe.httpGet. Jika readinessProbe.httpGet.httpHeaders menentukan lebih dari sekadar header Host, parameter health check load balancer disetel ke nilai default, bukan nilai yang disimpulkan dari pemeriksaan kesiapan. Batasan ini ada karena health check hanya mendukung penyetelan header Host.

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.

Peringatan: Jika parameter health check layanan backend disimpulkan dari pemeriksaan kesiapan Pod penayangan, GKE tidak mempertahankan sinkronisasi pemeriksaan kesiapan dan health check:

• Jika Anda mengubah pemeriksaan kesiapan untuk Pod penayangan Layanan yang dirujuk oleh Ingress setelah GKE membuat Load Balancer Aplikasi eksternal atau Load Balancer Aplikasi internal untuk Ingress tersebut, perubahan yang Anda buat untuk pemeriksaan kesiapan tidak akan disalin ke health check untuk layanan backend yang terkait di load balancer.
• Sebaliknya, jika Anda membuat perubahan pada health check yang digunakan oleh layanan backend load balancer yang dibuat atas nama Ingress, GKE tidak akan memperbarui pemeriksaan kesiapan apa pun, begitu juga GKE tidak akan mengembalikan perubahan apa pun yang Anda buat di health check.

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.

Kesiapan Pod

Setelah health check load balancer dikonfigurasi menggunakan salah satu metode sebelumnya, pengontrol GKE Ingress akan menggunakan status responsif endpoint backend untuk menentukan kesiapan Pod, yang sangat penting untuk mengelola update bertahap dan stabilitas traffic secara keseluruhan.

Untuk Pod yang relevan, pengontrol Ingress yang terkait mengelola gate kesiapan berjenis cloud.google.com/load-balancer-neg-ready. Pengontrol Ingress memeriksa status health check load balancer, yang mencakup kesehatan semua endpoint di NEG. Jika status health check load balancer menunjukkan bahwa endpoint yang sesuai dengan Pod tertentu itu responsif, pengontrol Ingress akan menetapkan nilai gate kesiapan Pod ke True. Kubelet yang berjalan di setiap node kemudian menghitung kesiapan efektif Pod, dengan mempertimbangkan nilai gate kesiapan ini dan, jika ditentukan, pemeriksaan kesiapan Pod.

Gerbang kesiapan Pod diaktifkan secara otomatis saat menggunakan load balancing berbasis container melalui Ingress.

Gate kesiapan akan mengontrol tingkat update berkelanjutan. Saat Anda memulai update berkelanjutan, seiring GKE membuat Pod baru, endpoint untuk setiap Pod baru akan ditambahkan ke NEG. Jika endpoint responsif dari perspektif load balancer, pengontrol Ingress akan menetapkan gate kesiapan ke True. Pod yang baru dibuat harus setidaknya lulus gate kesiapannya sebelum GKE menghapus Pod lama. Hal ini memastikan bahwa endpoint yang sesuai untuk Pod telah lulus health check load balancer dan kapasitas backend dipertahankan.

Jika gate kesiapan Pod tidak pernah menunjukkan bahwa Pod sudah siap, karena image container yang buruk atau health check load balancer yang salah dikonfigurasi, load balancer tidak akan mengarahkan traffic ke Pod baru. Jika kegagalan tersebut terjadi saat meluncurkan Deployment yang diupdate, peluncuran akan terhenti setelah mencoba membuat satu Pod baru karena gate kesiapan Pod tersebut tidak pernah Benar. Lihat bagian pemecahan masalah untuk mendapatkan informasi tentang cara mendeteksi dan memperbaiki situasi ini.

Tanpa load balancing dan gate kesiapan berbasis container, GKE tidak dapat mendeteksi apakah endpoint load balancer responsif atau tidak sebelum menandai Pod sebagai siap. Pada versi Kubernetes sebelumnya, kontrol jumlah Pod yang dihapus dan diganti dengan menentukan periode penundaan (minReadySeconds dalam spesifikasi Deployment).

GKE akan menetapkan nilai cloud.google.com/load-balancer-neg-ready untuk Pod ke True jika salah satu kondisi berikut terpenuhi:

• Tidak satu pun alamat IP Pod yang merupakan endpoint dalam GCE_VM_IP_PORT NEG yang dikelola oleh bidang kontrol GKE.
• Satu atau beberapa alamat IP Pod adalah endpoint dalam NEG GCE_VM_IP_PORT yang dikelola oleh bidang kontrol GKE. NEG akan dipasang ke layanan backend. Layanan backend memiliki health check load balancer yang berhasil.
• Satu atau beberapa alamat IP Pod adalah endpoint dalam NEG GCE_VM_IP_PORT yang dikelola oleh bidang kontrol GKE. NEG akan dipasang ke layanan backend. Waktu health check load balancer untuk layanan backend telah habis.
• Satu atau beberapa alamat IP Pod adalah endpoint di satu atau beberapa NEG GCE_VM_IP_PORT. Tidak ada NEG yang disertakan ke layanan backend. Tidak ada data health check load balancer yang tersedia.

Dukungan untuk WebSocket

Dengan Load Balancer Aplikasi eksternal, protokol WebSocket berfungsi tanpa konfigurasi apa pun.

Jika ingin menggunakan protokol WebSocket, sebaiknya gunakan nilai waktu tunggu yang lebih besar dari default 30 detik. Untuk traffic WebSocket yang dikirim melalui Load Balancer Aplikasi eksternalGoogle Cloud , waktu tunggu layanan backend diinterpretasikan sebagai jumlah waktu maksimum koneksi WebSocket dapat tetap terbuka, baik saat ada ataupun tidak ada aktivitas.

Untuk menetapkan nilai waktu tunggu untuk layanan backend, lihat Waktu tunggu respons backend.

Skenario jaringan lanjutan

Ingress GKE mendukung konfigurasi jaringan lanjutan seperti berbagi resource jaringan di seluruh project dan menggunakan pengontrol Ingress kustom.

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.

  Catatan: Terlepas dari apakah Anda menggunakan VPC Bersama atau tidak, jika cluster Anda menggunakan Ingress internal, Anda harus secara manual buat aturan izinkan firewall masuk untuk mengizinkan traffic dari subnet khusus proxy di jaringan VPC dan region cluster. Pembuatan aturan ini secara manual diperlukan karena pengontrol GKE Ingress tidak dapat membuat aturan izinkan firewall traffic masuk untuk mengizinkan traffic bagi subnet khusus proxy Load Balancer Aplikasi internal. Untuk informasi selengkapnya, lihat Lingkungan jejaring yang diperlukan di Ingress untuk Load Balancer Aplikasi 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 Anda men-deploy Ingress di VPC Bersama, peristiwa resource Ingress menyediakan aturan firewall tertentu yang diperlukan 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 checkerGoogle Cloud .

   Catatan: Jenis Ingress yang berbeda memerlukan aturan yang berbeda. GKE mungkin menampilkan peringatan aturan firewall meskipun Anda memiliki aturan firewall traffic masuk kustom Anda sendiri untuk mengizinkan traffic. Dalam kasus ini, Anda dapat mengabaikan peringatan tersebut.

Catatan: Untuk Multi Cluster Ingress, langkah penyediaan manual ini adalah satu-satunya cara yang didukung untuk menginstal aturan firewall di project host. Perubahan izin akun layanan untuk penyediaan otomatis tidak didukung.

Memberikan izin pengontrol 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:[e-mail] \
  --role=roles/compute.securityAdmin

Ganti yang berikut ini:

• HOST_PROJECT_ID adalah project ID dari project host VPC Bersama.
• SERVICE_PROJECT_NUMBER: nomor project dari project layanan yang berisi cluster Anda.

Menggunakan pengontrol Ingress kustom

Anda dapat menjalankan pengontrol Ingress kustom dengan menonaktifkan add-on HttpLoadBalancing. Tindakan ini mencegah pengontrol Ingress GKE memproses resource Ingress.

Jika Anda ingin menjalankan pengontrol Ingress kustom dengan add-on HttpLoadBalancing diaktifkan, misalnya untuk menggunakan fitur seperti subsetelan dan Private Service Connect, Anda dapat menggunakan salah satu pendekatan berikut:

• Dalam manifes Ingress, tetapkan anotasi kubernetes.io/ingress.class. Konfigurasi ini didukung untuk cluster yang menjalankan semua versi GKE.
• Konfigurasikan kolom ingressClassName.
• Konfigurasi class Ingress default.

Anda harus memastikan bahwa spec.ingressClassName tidak ditimpa secara tidak sengaja oleh proses apa pun. Operasi update yang mengubah spec.IngressClassName dari nilai yang valid menjadi string kosong ("") akan menyebabkan pengontrol Ingress GKE memproses Ingress.

Mengonfigurasi kolom ingressClassName

Anda dapat menggunakan pengontrol Ingress kustom dengan menetapkan kolom ingressClassName dalam manifes Ingress. Manifes berikut menjelaskan Ingress yang menentukan pengontrol Ingress cilium:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: cafe-ingress
spec:
 ingressClassName: cilium
 tls:
 - hosts:
   - cafe.example.com
   secretName: cafe-secret
 rules:
 - host: cafe.example.com

Catatan: Jika Ingress memiliki spec.ingressClassName kosong atau spec.ingressClassName tidak ada, dan Ingress tidak memiliki anotasi kubernetes.io/ingress.class, pengontrol Ingress GKE memproses Ingress.

Mengonfigurasi class Ingress default

Anda dapat mengonfigurasi class Ingress default untuk semua resource Ingress dalam cluster dengan membuat resource IngressClass dengan ingressclass.kubernetes.io/is-default-class anotasi yang disetel ke true:

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: gce
  annotations:
    ingressclass.kubernetes.io/is-default-class: "true"
spec:
  controller: k8s.io/ingress-gce

Catatan: Pengontrol penerimaan mengisi kolom spec.ingressClassName untuk resource Ingress baru dalam cluster, tetapi tidak mengubah resource Ingress yang ada.

Ringkasan perilaku pengontrol Ingress GKE

Untuk cluster yang menjalankan GKE versi 1.18 dan yang lebih baru, baik pengontrol Ingress GKE memproses Ingress atau tidak, bergantung pada nilai anotasi kubernetes.io/ingress.class dan kolom ingressClassName dalam manifes Ingress. Untuk informasi selengkapnya, lihat Perilaku pengontrol Ingress GKE.

Template untuk konfigurasi Ingress

• Di GKE Networking Recipes, Anda dapat menemukan template yang disediakan oleh GKE pada berbagai penggunaan Ingress umum di bagian Ingress.