Ringkasan health check

Google Cloud menawarkan health check yang dapat dikonfigurasi untuk backend load balancer, backend Cloud Service Mesh, dan autohealing berbasis aplikasi untuk grup instance terkelola.Google Cloud Dokumen ini mencakup konsep pemeriksaan kondisi utama.

Kecuali jika dinyatakan lain, Google Cloud pemeriksaan kondisi diimplementasikan oleh tugas software khusus yang terhubung ke backend sesuai dengan parameter yang ditentukan dalam resource pemeriksaan kondisi. Setiap upaya koneksi disebut pemeriksaan. Google Cloud mencatat keberhasilan atau kegagalan setiap pemeriksaan.

Berdasarkan jumlah pemeriksaan berurutan yang berhasil atau gagal yang dapat dikonfigurasi, status respons keseluruhan dihitung untuk setiap backend. Backend yang berhasil merespons sebanyak jumlah yang dikonfigurasi dianggap responsif. Backend yang gagal merespons dengan berhasil untuk sejumlah kali yang dapat dikonfigurasi secara terpisah dianggap tidak responsif.

Kondisi keseluruhan setiap backend menentukan kelayakan untuk menerima permintaan atau koneksi baru. Anda dapat mengonfigurasi kriteria yang menentukan keberhasilan probe. Hal ini dibahas secara mendetail di bagian Cara kerja health check.

Pemeriksaan kondisi yang diterapkan oleh tugas software khusus menggunakan rute khusus yang tidak ditentukan di jaringan Virtual Private Cloud (VPC) Anda. Untuk mengetahui informasi selengkapnya, lihat Jalur untuk health check.

Kategori, protokol, dan port health check

Health check memiliki kategori dan protokol. Dua kategori tersebut adalah health check dan health check lama, serta protokol yang didukungnya adalah sebagai berikut:

• Health check

  • Regional (gRPC, TCP, SSL, HTTP, HTTPS, atau HTTP/2)
  • gRPC Regional (dengan TLS) (Pratinjau)
  • Global (gRPC, TCP, SSL, HTTP, HTTPS, atau HTTP/2)
  • gRPC Global (dengan TLS) (Pratinjau)

• Health check lama:

  • Global lama (HTTP)
  • Global lama (HTTPS)

Protokol dan port menentukan cara pemeriksaan health check dilakukan. Misalnya, pemeriksaan kondisi dapat menggunakan protokol HTTP di port TCP 80, atau dapat menggunakan protokol TCP untuk port bernama dalam grup instance.

Anda tidak dapat mengonversi health check lama menjadi health check, dan Anda tidak dapat mengonversi health check menjadi health check lama.

Pilih health check

Health check harus kompatibel dengan jenis load balancer (atau Cloud Service Mesh) dan jenis backend. Faktor-faktor yang perlu dipertimbangkan saat Anda memilih pemeriksaan kondisi adalah sebagai berikut:

• Kategori: health check atau health check lama. Hanya Load Balancer Jaringan passthrough eksternal berbasis kumpulan target yang memerlukan health check lama. Untuk semua produk lainnya, Anda akan menggunakan pemeriksaan kondisi normal.
• Protokol: protokol yang digunakan Google Cloud untuk menyelidiki backend. Sebaiknya gunakan health check (atau health check lama) yang protokolnya cocok dengan protokol yang digunakan oleh layanan backend atau kumpulan target load balancer. Namun, protokol health check dan protokol load balancer tidak harus sama.
• Spesifikasi port: port yang Google Cloud menggunakan protokol. Anda harus menentukan port untuk health check. Pemeriksaan kondisi memiliki dua metode spesifikasi port: --port dan --use-serving-port. Untuk health check lama, ada satu metode: --port. Untuk mengetahui informasi selengkapnya tentang persyaratan port health check per load balancer, lihat Flag spesifikasi port.

Bagian berikutnya menjelaskan pilihan health check yang valid untuk setiap jenis load balancer dan backend.

Panduan load balancer

Tabel ini menunjukkan kategori dan cakupan health check yang didukung untuk setiap jenis load balancer.

Load balancer	Kategori dan cakupan health check
Load Balancer Aplikasi eksternal global Load Balancer Aplikasi Klasik * Load Balancer Jaringan proxy eksternal global Load Balancer Jaringan proxy klasik Load Balancer Aplikasi internal lintas region Load Balancer Jaringan proxy internal lintas region	Health check (global)
Load Balancer Aplikasi eksternal regional Load Balancer Aplikasi internal regional Load Balancer Jaringan proxy internal regional Load Balancer Jaringan proxy eksternal regional	Health check (regional)
Load Balancer Jaringan passthrough eksternal	Load balancer berbasis layanan backend: Health check (regional) Load balancer berbasis kumpulan target: Health check lama (global dengan protokol HTTP)
Load Balancer Jaringan passthrough internal	Health check (global atau regional)

Catatan penggunaan tambahan

• Untuk backend grup instance VM, health check hanya dilakukan pada instance VM yang dimulai. Instance VM yang dihentikan tidak menerima paket health check.

• Untuk Load Balancer Jaringan passthrough internal, Anda hanya dapat menggunakan TCP atau UDP untuk protokol layanan backend. Jika Anda menyalurkan traffic HTTP dari VM di belakang Network Load Balancer passthrough internal, sebaiknya gunakan health check menggunakan protokol HTTP.

• Load Balancer Jaringan passthrough eksternal berbasis kumpulan target harus menggunakan health check HTTP lama. Tidak dapat menggunakan health check HTTPS lama atau health check non-lama. Jika Anda menggunakan Load Balancer Jaringan passthrough eksternal berbasis kumpulan target untuk menyeimbangkan traffic TCP, Anda perlu menjalankan layanan HTTP di VM yang diseimbangkan bebannya agar dapat merespons probe health check.
  
  Untuk hampir semua jenis load balancer lainnya, Anda harus menggunakan health check reguler non-lama dengan protokol yang cocok dengan protokol layanan backend load balancer.

• Untuk layanan backend yang menggunakan protokol gRPC, gunakan hanya pemeriksaan kondisi gRPC atau TCP. Jangan gunakan health check HTTP(S) atau HTTP/2.

• Load balancer berbasis Envoy tertentu yang menggunakan backend NEG hibrida tidak mendukung health check gRPC. Untuk mengetahui informasi selengkapnya, lihat Ringkasan NEG hybrid.

Pemeriksaan kondisi dengan Cloud Service Mesh

Perhatikan perbedaan perilaku berikut saat Anda menggunakan health check dengan Cloud Service Mesh.

• Dengan Cloud Service Mesh, perilaku health check untuk endpoint jaringan jenis INTERNET_FQDN_PORT dan NON_GCP_PRIVATE_IP_PORT berbeda dengan perilaku health check untuk jenis endpoint jaringan lainnya. Daripada menggunakan tugas software khusus, Cloud Service Mesh memprogram proxy Envoy untuk melakukan health check untuk NEG internet (endpoint INTERNET_FQDN_PORT) dan NEG hybrid (endpoint NON_GCP_PRIVATE_IP_PORT).

  Envoy mendukung protokol berikut untuk health check:

  • HTTP
  • HTTPS
  • HTTP/2
  • TCP

• Jika Cloud Service Mesh terintegrasi dengan Service Directory dan Anda mengikat layanan Service Directory ke layanan backend Cloud Service Mesh, Anda tidak dapat menetapkan health check pada layanan backend.

Cara kerja pemeriksaan kesehatan

Bagian berikut menjelaskan cara kerja pemeriksaan kondisi.

Probe

Saat membuat health check atau health check lama, Anda menentukan flag berikut atau menerima nilai defaultnya. Setiap health check atau health check lama yang Anda buat diterapkan oleh beberapa pemeriksaan. Flag ini mengontrol seberapa sering setiap probe mengevaluasi instance dalam grup instance atau endpoint dalam NEG tingkat zona.

Setelan health check tidak dapat dikonfigurasi per backend. Pemeriksaan kondisi terkait dengan seluruh layanan backend. Untuk Load Balancer Jaringan passthrough eksternal berbasis kumpulan target, health check HTTP lama dikaitkan dengan seluruh kumpulan target. Dengan demikian, parameter untuk probe sama untuk semua backend yang dirujuk oleh layanan backend atau kumpulan target tertentu.

Tanda konfigurasi	Tujuan	Nilai default
Interval pemeriksaan check-interval	Interval pemeriksaan adalah jumlah waktu dari awal satu pemeriksaan yang dikeluarkan oleh satu pemeriksa hingga awal pemeriksaan berikutnya yang dikeluarkan oleh pemeriksa yang sama. Unit dalam hitungan detik.	5s (5 detik)
Waktu tunggu timeout	Waktu tunggu adalah jumlah waktu yang Google Cloud tunggu untuk mendapatkan respons terhadap pemeriksaan. Nilainya harus kurang dari atau sama dengan interval pemeriksaan. Unit dalam hitungan detik.	5s (5 detik)

Memeriksa rentang IP dan aturan firewall

Agar health check berfungsi, Anda harus membuat aturan firewall allow ingress sehingga traffic dari pemeriksa Google Cloud dapat terhubung ke backend Anda. Untuk mengetahui petunjuknya, lihat Membuat aturan firewall yang diperlukan.

Tabel berikut menunjukkan rentang IP sumber yang diizinkan untuk setiap load balancer:

Produk	Rentang IP sumber pemeriksaan health check
Load Balancer Aplikasi eksternal global Load Balancer Jaringan proxy eksternal global	35.191.0.0/16 130.211.0.0/22 Agar traffic IPv6 dapat mencapai backend: 2600:2d00:1:b029::/64 2600:2d00:1:1::/64
Load Balancer Aplikasi eksternal regional 1, 2 Load Balancer Aplikasi internal lintas region 1 Load Balancer Aplikasi internal regional 1, 2 Load Balancer Jaringan proxy eksternal regional1, 2 Load Balancer Jaringan proxy internal regional1, 2 Load Balancer Jaringan proxy internal lintas region 1	35.191.0.0/16 130.211.0.0/22 Agar traffic IPv6 dapat mencapai backend: 2600:2d00:1:b029::/64
Load Balancer Jaringan proxy klasik Load Balancer Aplikasi Klasik Cloud Service Mesh, kecuali backend NEG internet dan backend NEG hybrid	35.191.0.0/16 130.211.0.0/22
Load Balancer Jaringan passthrough eksternal 3	Untuk traffic IPv4 ke backend: 35.191.0.0/16 209.85.152.0/22 209.85.204.0/22 Agar traffic IPv6 dapat mencapai backend: 2600:1901:8001::/48
Load Balancer Jaringan passthrough internal	Untuk traffic IPv4 ke backend: 35.191.0.0/16 130.211.0.0/22 Agar traffic IPv6 dapat mencapai backend: 2600:2d00:1:b029::/64
Cloud Service Mesh dengan backend NEG internet dan backend NEG hybrid	Alamat IP VM yang menjalankan software Envoy Untuk contoh konfigurasi, lihat dokumentasi Cloud Service Mesh.

Pentingnya aturan firewall

Google Cloud mengharuskan Anda membuat aturan firewall allow masuk yang diperlukan untuk mengizinkan traffic dari pemeriksa ke backend Anda. Sebagai praktik terbaik, batasi aturan ini hanya pada protokol dan port yang cocok dengan yang digunakan oleh health check Anda. Untuk rentang IP sumber, pastikan untuk menggunakan rentang IP probe yang didokumentasikan dan tercantum di bagian sebelumnya.

Jika Anda tidak memiliki aturan firewall allow ingress yang mengizinkan health check, aturan deny tersirat akan memblokir traffic masuk. Jika penguji tidak dapat menghubungi backend, load balancer akan menganggap backend Anda tidak responsif.

Pertimbangan keamanan untuk rentang IP probe

Pertimbangkan informasi berikut saat merencanakan health check dan aturan firewall yang diperlukan:

• Rentang IP probe adalah milik Google. Google Cloud menggunakan rute khusus di luar jaringan VPC Anda, tetapi dalam jaringan produksi Google untuk memfasilitasi komunikasi dari prober.

• Google menggunakan rentang IP probe untuk mengirim probe health check bagi Load Balancer Aplikasi eksternal dan Load Balancer Jaringan proxy eksternal. Jika paket diterima dari internet dan alamat IP sumber paket berada dalam rentang IP probe, Google akan menghentikan paket tersebut. Hal ini mencakup alamat IP eksternal instance Compute Engine atau node Google Kubernetes Engine (GKE).

• Rentang IP probe adalah kumpulan lengkap alamat IP yang mungkin digunakan oleh probeGoogle Cloud . Jika Anda menggunakan tcpdump atau alat serupa, Anda mungkin tidak mengamati traffic dari semua alamat IP di semua rentang IP probe. Sebagai praktik terbaik, buat aturan firewall ingress yang mengizinkan semua rentang IP probe sebagai sumber. Google Cloud dapat menerapkan prober baru secara otomatis tanpa pemberitahuan.

Beberapa pemeriksaan dan frekuensi

Google Cloud mengirimkan pemeriksaan health check dari beberapa sistem redundan yang disebut penguji. Pemeriksa menggunakan rentang IP sumber tertentu. Google Cloud tidak hanya mengandalkan satu pemeriksa untuk menerapkan health check—beberapa pemeriksa secara bersamaan mengevaluasi instance di backend grup instance atau endpoint di backend NEG zonal. Jika satu penguji gagal,Google Cloud akan terus melacak status kesehatan backend.

Setelan interval dan waktu tunggu yang Anda konfigurasi untuk health check diterapkan ke setiap pemeriksa. Untuk backend tertentu, log akses software dan tcpdump menunjukkan pemeriksaan yang lebih sering daripada setelan yang Anda konfigurasi.

Ini adalah perilaku yang diharapkan, dan Anda tidak dapat mengonfigurasi jumlah pemeriksa yang digunakan Google Cloud untuk pemeriksaan kesehatan. Namun, Anda dapat memperkirakan efek beberapa pemeriksaan serentak dengan mempertimbangkan faktor-faktor berikut.

• Untuk memperkirakan frekuensi pemeriksaan per layanan backend, pertimbangkan hal berikut:

  • Frekuensi dasar per layanan backend. Setiap health check memiliki frekuensi pemeriksaan terkait, yang berbanding terbalik dengan interval pemeriksaan yang dikonfigurasi:

    ¹⁄_{(interval pemeriksaan)}

    Saat mengaitkan health check dengan layanan backend, Anda menetapkan frekuensi dasar yang digunakan oleh setiap pemeriksa untuk backend pada layanan backend tersebut.

  • Faktor skala probe. Frekuensi dasar layanan backend dikalikan dengan jumlah penguji serentak yang digunakan Google Cloud . Jumlah ini dapat bervariasi, tetapi umumnya antara 5 dan 10.

• Beberapa aturan penerusan untuk Load Balancer Jaringan passthrough internal. Jika Anda telah mengonfigurasi beberapa aturan penerusan internal (masing-masing memiliki alamat IP yang berbeda) yang mengarah ke layanan backend internal regional yang sama,Google Cloud menggunakan beberapa pemeriksa untuk memeriksa setiap alamat IP. Frekuensi probe per layanan backend dikalikan dengan jumlah aturan penerusan yang dikonfigurasi.

• Beberapa aturan penerusan untuk Load Balancer Jaringan passthrough eksternal. Jika Anda telah mengonfigurasi beberapa aturan penerusan yang mengarah ke layanan backend atau kumpulan target yang sama, Google Cloud menggunakan beberapa pemeriksa untuk memeriksa setiap alamat IP. Frekuensi pemeriksaan per VM backend dikalikan dengan jumlah aturan penerusan yang dikonfigurasi.

• Beberapa proxy target untuk Load Balancer Aplikasi eksternal. Jika Anda memiliki beberapa proxy target yang mengarahkan traffic ke peta URL yang sama, Google Cloud menggunakan beberapa pemeriksa untuk memeriksa alamat IP yang terkait dengan setiap proxy target. Frekuensi pemeriksaan per layanan backend dikalikan dengan jumlah proxy target yang dikonfigurasi.

• Beberapa proxy target untuk Load Balancer Jaringan proxy eksternal dan Load Balancer Jaringan proxy internal regional. Jika Anda telah mengonfigurasi beberapa proxy target yang mengarahkan traffic ke layanan backend yang sama,Google Cloud menggunakan beberapa pemeriksa untuk memeriksa alamat IP yang terkait dengan setiap proxy target. Frekuensi pemeriksaan per layanan backend dikalikan dengan jumlah proxy target yang dikonfigurasi.

• Jumlahkan layanan backend. Jika backend digunakan oleh beberapa layanan backend, instance backend dihubungi sesering jumlah frekuensi untuk health check setiap layanan backend.

  Dengan backend NEG zonal, akan lebih sulit untuk menentukan jumlah persis probe pemeriksaan kesehatan. Misalnya, endpoint yang sama dapat berada di beberapa NEG zonal. NEG zonal tersebut tidak selalu memiliki set endpoint yang sama, dan endpoint yang berbeda dapat mengarah ke backend yang sama.

Tujuan untuk paket probe

Tabel berikut menunjukkan alamat IP tujuan dan antarmuka jaringan yang digunakan oleh penguji health check untuk mengirim paket, bergantung pada jenis load balancer.

Untuk Load Balancer Jaringan passthrough eksternal dan Load Balancer Jaringan passthrough internal, aplikasi harus terikat ke alamat IP load balancer (atau alamat IP 0.0.0.0).

Load balancer	Antarmuka jaringan tujuan	Alamat IP tujuan
Load Balancer Aplikasi eksternal global Load Balancer Jaringan proxy eksternal global	Untuk backend grup instance, antarmuka jaringan utama (nic0). Untuk backend NEG zonal dengan endpoint GCE_VM_IP_PORT, antarmuka jaringan di jaringan VPC yang terkait dengan NEG. Untuk backend NEG zonal dengan endpoint NON_GCP_PRIVATE_IP_PORT, endpoint harus merepresentasikan antarmuka resource lokal yang dapat dijangkau melalui rute di jaringan VPC yang terkait dengan NEG dan di region yang berisi NEG.	Untuk backend grup instance, alamat IPv4 atau IPv6 internal utama yang terkait dengan antarmuka jaringan utama (nic0) setiap instance. Untuk backend NEG zonal dengan endpoint GCE_VM_IP_PORT, alamat IP endpoint: baik alamat IPv4 atau IPv6 internal utama dari antarmuka jaringan atau alamat IPv4 atau IPv6 internal dari rentang IP alias antarmuka jaringan. Untuk backend NEG zonal dengan endpoint NON_GCP_PRIVATE_IP_PORT, alamat IP endpoint.
Load Balancer Aplikasi Klasik Load Balancer Aplikasi eksternal regional Load Balancer Aplikasi internal lintas region Load Balancer Aplikasi internal regional Load Balancer Jaringan proxy klasik Load Balancer Jaringan proxy eksternal regional Load Balancer Jaringan proxy internal lintas region 1 Load Balancer Jaringan proxy internal regional Mesh Layanan Cloud	Untuk backend grup instance, antarmuka jaringan utama (nic0). Untuk backend NEG zonal dengan endpoint GCE_VM_IP_PORT, antarmuka jaringan di jaringan VPC yang terkait dengan NEG. Untuk backend NEG zonal dengan endpoint NON_GCP_PRIVATE_IP_PORT, endpoint harus merepresentasikan antarmuka resource lokal yang dapat dijangkau melalui rute di jaringan VPC yang terkait dengan NEG dan di region yang berisi NEG.	Untuk backend grup instance, alamat IPv4 internal utama yang terkait dengan antarmuka jaringan utama (nic0) dari setiap instance. Untuk backend NEG zonal dengan endpoint GCE_VM_IP_PORT, alamat IP endpoint: baik alamat IPv4 internal utama antarmuka jaringan atau alamat IPv4 internal dari rentang IP alias antarmuka jaringan. Untuk backend NEG zonal dengan endpoint NON_GCP_PRIVATE_IP_PORT, alamat IP endpoint.
Load Balancer Jaringan passthrough eksternal	Antarmuka jaringan utama (nic0)	Alamat IP aturan penerusan eksternal. Jika beberapa aturan penerusan mengarah ke layanan backend yang sama (untuk Load Balancer Jaringan passthrough eksternal berbasis kumpulan target, kumpulan target yang sama), Google Cloud mengirimkan probe ke alamat IP setiap aturan penerusan. Hal ini dapat menyebabkan peningkatan jumlah pemeriksaan.
Load Balancer Jaringan passthrough internal	Untuk backend grup instance dan backend NEG zonal dengan endpoint GCE_VM_IP, antarmuka jaringan yang digunakan bergantung pada cara layanan backend dikonfigurasi. Untuk mengetahui detailnya, lihat Layanan backend dan antarmuka jaringan.	Alamat IP aturan penerusan internal. Jika beberapa aturan penerusan mengarah ke layanan backend yang sama, Google Cloud mengirimkan probe ke alamat IP setiap aturan penerusan. Hal ini dapat menyebabkan peningkatan jumlah pemeriksaan.

Kriteria keberhasilan untuk HTTP, HTTPS, dan HTTP/2

Health check HTTP, HTTPS, dan HTTP/2 selalu memerlukan kode respons HTTP 200 (OK) untuk diterima sebelum waktu tunggu health check. Semua kode respons HTTP lainnya, termasuk kode respons pengalihan seperti 301 dan 302, dianggap tidak sehat.

Selain mewajibkan kode respons HTTP 200 (OK), Anda dapat:

• Konfigurasi setiap pemeriksa health check untuk mengirim permintaan HTTP ke jalur permintaan tertentu, bukan jalur permintaan default, /.

• Konfigurasi setiap pemeriksa health check untuk memeriksa keberadaan string respons yang diharapkan dalam isi respons HTTP. String respons yang diharapkan hanya boleh terdiri dari karakter ASCII satu byte yang dapat dicetak, yang berada dalam 1.024 byte pertama isi respons HTTP.

Tabel berikut mencantumkan kombinasi jalur permintaan dan tanda respons yang valid yang tersedia untuk health check HTTP, HTTPS, dan HTTP/2.

Flag konfigurasi	Perilaku pemeriksa	Kriteria sukses
--request-path maupun --response tidak ditentukan	Prober menggunakan / sebagai jalur permintaan.	Khusus kode respons HTTP 200 (OK).
--request-path dan --response ditentukan	Prober menggunakan jalur permintaan yang dikonfigurasi.	Kode respons HTTP 200 (OK) dan hingga 1.024 karakter ASCII pertama dari isi respons HTTP harus cocok dengan string respons yang diharapkan.
Hanya --response yang ditentukan	Prober menggunakan / sebagai jalur permintaan.	Kode respons HTTP 200 (OK) dan hingga 1.024 karakter ASCII pertama dari isi respons HTTP harus cocok dengan string respons yang diharapkan.
Hanya --request-path yang ditentukan	Prober menggunakan jalur permintaan yang dikonfigurasi.	Khusus kode respons HTTP 200 (OK).

Kriteria keberhasilan untuk SSL dan TCP

Health check TCP dan SSL memiliki kriteria keberhasilan dasar berikut:

• Untuk health check TCP, pemeriksa health check harus berhasil membuka koneksi TCP ke backend sebelum waktu tunggu health check berakhir.

• Untuk pemeriksaan kondisi SSL, pemeriksa kondisi harus berhasil membuka koneksi TCP ke backend dan menyelesaikan handshake TLS/SSL sebelum waktu tunggu pemeriksaan kondisi.

• Untuk pemeriksaan kondisi TCP, koneksi TCP harus ditutup dengan salah satu cara berikut:

  • Dengan penguji health check yang mengirimkan paket FIN atau RST (reset), atau
  • Dengan backend mengirimkan paket FIN. Jika backend mengirim paket TCP RST, probe mungkin dianggap tidak berhasil jika prober health check telah mengirim paket FIN.

Tabel berikut mencantumkan kombinasi valid flag permintaan dan respons yang tersedia untuk health check TCP dan SSL. Flag permintaan dan respons hanya boleh terdiri dari karakter ASCII satu byte yang dapat dicetak, dengan setiap string tidak boleh lebih dari 1.024 karakter.

Flag konfigurasi	Perilaku pemeriksa	Kriteria sukses
--request dan --response tidak ditentukan	Prober tidak mengirimkan string permintaan apa pun.	Hanya kriteria keberhasilan dasar.
--request dan --response ditentukan	Prober mengirimkan string permintaan yang dikonfigurasi.	Kriteria keberhasilan dasar dan string respons yang diterima oleh prober harus sama persis dengan string respons yang diharapkan.
Hanya --response yang ditentukan	Prober tidak mengirimkan string permintaan apa pun.	Kriteria keberhasilan dasar dan string respons yang diterima oleh prober harus sama persis dengan string respons yang diharapkan.
Hanya --request yang ditentukan	Prober mengirimkan string permintaan yang dikonfigurasi.	Hanya kriteria keberhasilan dasar (string respons apa pun tidak diperiksa).

Kriteria keberhasilan untuk gRPC

Health check gRPC hanya digunakan dengan aplikasi gRPC,load balancer, dan Cloud Service Mesh. Google Cloud mendukung dua jenis health check gRPC: Google Cloud

• Pemeriksaan kondisi GRPC_WITH_TLS (Pratinjau) digunakan untuk memeriksa kondisi backend gRPC dengan TLS yang diaktifkan. Server ini mendukung enkripsi TLS yang tidak diautentikasi, yang berarti bahwa health check tidak memverifikasi identitas server.
• Health check GRPC digunakan untuk melakukan health check pada backend gRPC yang tidak aman. Backend ini tidak mendukung autentikasi dan enkripsi, sehingga tidak dapat digunakan untuk backend gRPC dengan TLS yang diaktifkan.

Jika Anda menggunakan health check gRPC (dengan atau tanpa TLS), pastikan layanan gRPC mengirimkan respons RPC dengan status OK dan kolom status ditetapkan ke SERVING atau NOT_SERVING.

Untuk informasi selengkapnya, lihat referensi berikut:

• Flag tambahan untuk pemeriksaan kondisi gRPC
• Dokumentasi gRPC untuk health check

Kriteria keberhasilan untuk health check lama

Jika respons yang diterima oleh pemeriksaan health check lama adalah HTTP 200 OK, pemeriksaan dianggap berhasil. Semua kode respons HTTP lainnya, termasuk pengalihan (301, 302), dianggap tidak sehat.

Status kesehatan

Google Cloud menggunakan tanda konfigurasi berikut untuk menentukan status kondisi keseluruhan setiap backend yang trafficnya di-load balance.

Tanda konfigurasi	Tujuan	Nilai default
Ambang batas responsif healthy-threshold	Batas responsif menentukan jumlah hasil pemeriksaan berhasil berurutan agar backend yang sebelumnya tidak responsif dianggap responsif.	Ambang batas 2 probe.
Unhealthy threshold unhealthy-threshold	Nilai minimum tidak responsif menentukan jumlah hasil pemeriksaan gagal berurutan agar backend yang sebelumnya responsif dianggap tidak responsif.	Ambang batas 2 probe.

Google Cloud menganggap backend responsif setelah memenuhi nilai minimum responsif ini. Backend yang responsif memenuhi syarat untuk menerima koneksi baru.

Google Cloud menganggap backend tidak responsif jika batas tidak responsif telah terpenuhi. Backend yang tidak responsif tidak memenuhi syarat untuk menerima koneksi baru; namun, koneksi yang ada tidak segera dihentikan. Sebagai gantinya, koneksi akan tetap terbuka hingga waktu tunggu habis atau hingga traffic dihentikan.

Koneksi yang ada mungkin gagal menampilkan respons, bergantung pada penyebab kegagalan probe. Backend yang tidak responsif dapat menjadi responsif jika dapat memenuhi batas responsif lagi.

Perilaku spesifik saat semua backend tidak responsif berbeda-beda, bergantung pada jenis load balancer yang Anda gunakan:

Catatan tambahan

Bagian berikut menyertakan beberapa catatan lainnya tentang penggunaan pemeriksaan kondisi di Google Cloud.

Sertifikat dan health check

Pemeriksa health checkGoogle Cloud tidak melakukan validasi sertifikat, bahkan untuk protokol yang mengharuskan backend Anda menggunakan sertifikat (SSL, HTTPS, dan HTTP/2)—misalnya:

• Anda dapat menggunakan sertifikat yang ditandatangani sendiri atau sertifikat yang ditandatangani oleh certificate authority (CA) mana pun.
• Sertifikat yang masa berlakunya telah habis atau yang belum valid dapat diterima.
• Atribut CN maupun subjectAlternativeName tidak perlu cocok dengan header Host atau data PTR DNS.

Header

Health check yang menggunakan protokol apa pun, tetapi bukan health check lama, memungkinkan Anda menetapkan header proxy menggunakan tanda --proxy-header.

Health check yang menggunakan protokol HTTP, HTTPS, atau HTTP/2 dan health check lama memungkinkan Anda menentukan header Host HTTP dengan menggunakan tanda --host.

Jika Anda menggunakan header permintaan kustom, perhatikan bahwa load balancer menambahkan header ini hanya ke permintaan klien, bukan ke pemeriksaan health check. Jika backend Anda memerlukan header tertentu untuk otorisasi yang tidak ada dalam paket health check, health check mungkin gagal.

Contoh health check

Misalkan Anda menyiapkan health check dengan setelan berikut:

• Interval: 30 detik
• Waktu tunggu: 5 detik
• Protokol: HTTP
• Nilai minimum tidak responsif: 2 (default)
• Ambang batas responsif: 2 (default)

Dengan setelan ini, health check berperilaku sebagai berikut:

1. Beberapa sistem redundan dikonfigurasi secara bersamaan dengan parameter health check. Setelan interval dan waktu tunggu diterapkan ke setiap sistem. Untuk mengetahui informasi selengkapnya, lihat Beberapa pemeriksaan dan frekuensi.

2. Setiap penguji health check melakukan hal berikut:

   1. Memulai koneksi HTTP dari salah satu alamat IP sumber ke instance backend setiap 30 detik.
   2. Menunggu hingga lima detik untuk kode status HTTP 200 (OK) (kriteria keberhasilan untuk protokol HTTP, HTTPS, dan HTTP/2).

3. Backend dianggap tidak responsif jika setidaknya satu sistem probe health check melakukan hal berikut:

   1. Tidak menerima kode respons HTTP 200 (OK) untuk dua probe berturut-turut. Misalnya, koneksi mungkin ditolak, atau mungkin ada waktu tunggu koneksi atau soket.
   2. Menerima dua respons berturut-turut yang tidak cocok dengan kriteria keberhasilan khusus protokol.

4. Backend dianggap responsif jika setidaknya satu sistem probe health check menerima dua respons berturut-turut yang cocok dengan kriteria keberhasilan spesifik per protokol.

Dalam contoh ini, setiap pemeriksa memulai koneksi setiap 30 detik. Tiga puluh detik berlalu di antara upaya koneksi prober, terlepas dari durasi waktu tunggu (apakah koneksi mengalami waktu tunggu atau tidak). Dengan kata lain, waktu tunggu harus selalu kurang dari atau sama dengan interval, dan waktu tunggu tidak pernah menambah interval.

Dalam contoh ini, pengaturan waktu setiap pemeriksa terlihat seperti berikut, dalam detik:

1. t=0: Mulai probe A.
2. t=5: Hentikan probe A.
3. t=30: Mulai penyelidikan B.
4. t=35: Hentikan probe B.
5. t=60: Mulai probe C.
6. t=65: Hentikan probe C.

Langkah berikutnya

• Untuk membuat, mengubah, dan menggunakan health check, lihat Menggunakan health check.
• Untuk memecahkan masalah health check, aktifkan logging health check.