Ringkasan health check

Cloud de Confiance by S3NS menawarkan health check yang dapat dikonfigurasi untuk backend Cloud de Confiance load balancer dan autohealing berbasis aplikasi untuk grup instance terkelola. Dokumen ini mencakup konsep pemeriksaan kesehatan utama.

Kecuali jika dinyatakan lain, Cloud de Confiance 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. Cloud de Confiance mencatat keberhasilan atau kegagalan setiap pemeriksaan.

Berdasarkan jumlah pemeriksaan yang berhasil atau gagal secara berurutan 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 kesehatan 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, gRPC (dengan TLS), TCP, SSL, HTTP, HTTPS, atau HTTP/2)
  • Global (gRPC, gRPC (dengan TLS), TCP, SSL, HTTP, HTTPS, atau HTTP/2)

• Health check lama:

  • Global lama (HTTP)

Protokol dan port menentukan cara pemeriksaan health check dilakukan. Misalnya, health check dapat menggunakan protokol HTTP di port TCP 80, atau 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 dan jenis backend. Faktor-faktor yang perlu dipertimbangkan saat Anda memilih pemeriksaan kesehatan adalah sebagai berikut:

• Kategori: health check atau health check lama. Hanya Load Balancer Jaringan passthrough eksternal regional berbasis kumpulan target yang memerlukan health check lama. Untuk semua produk lainnya, Anda akan menggunakan pemeriksaan kondisi normal.
• Protokol: protokol yang digunakan Cloud de Confiance 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 Cloud de Confiance menggunakan protokol. Anda harus menentukan port untuk health check. Pemeriksaan kondisi memiliki dua metode spesifikasi port: --port dan --use-serving-port. Untuk pemeriksaan kondisi 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 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 global	Health check (global)
Load Balancer Jaringan passthrough eksternal regional	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 grup instance backend, NEG zona dengan endpoint GCE_VM_IP, dan NEG zona dengan endpoint GCE_VM_IP_PORT, pemeriksa hanya mencoba terhubung ke instance VM (atau instance VM yang berisi endpoint) jika VM sedang berjalan. Pemeriksa tidak mencoba terhubung ke instance (atau instance VM yang berisi endpoint) jika instance tersebut dihentikan.

• Load Balancer Jaringan passthrough eksternal regional 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 regional berbasis kumpulan target untuk menyeimbangkan traffic TCP, Anda perlu menjalankan layanan HTTP di VM yang di-load balance 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.

Rentang IP probe

Cloud de Confiance mengharuskan Anda membuat aturan firewall masuk allow yang diperlukan untuk mengizinkan traffic dari penguji ke backend atau resource lainnya. Perhatikan hal-hal berikut saat Anda membuat aturan firewall ini:

• Rentang IP probe adalah kumpulan lengkap alamat IP yang mungkin digunakan oleh probeCloud de Confiance . 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. Cloud de Confiance dapat menerapkan prober baru secara otomatis tanpa pemberitahuan.

• Sebagai praktik terbaik, batasi aturan ini hanya pada protokol dan port yang cocok dengan yang digunakan oleh health check Anda.

Jika Anda tidak memiliki aturan firewall allow masuk yang mengizinkan pemeriksa health check terhubung ke backend load balancer, tindakan firewall masuk yang ditolak secara implisit akan memblokir traffic, sehingga menyebabkan backend Anda tidak responsif. Untuk mengetahui informasi selengkapnya, lihat Kebijakan dan aturan firewall.

Rentang IP probe untuk backend load balancer berbasis Envoy terkelola

Load Balancer Aplikasi dan Load Balancer Jaringan proxy yang menggunakan proxy Envoy terkelola adalah:

• Load Balancer Aplikasi eksternal regional

• Load Balancer Aplikasi internal regional

• Load Balancer Jaringan proxy eksternal regional

• Load Balancer Jaringan proxy internal regional

Health check untuk backend load balancer ini berasal dari rentang alamat IP dalam tabel berikut:

Jenis backend	Rentang IP sumber pemeriksaan health check
Grup instance NEG zona dengan endpoint GCE_VM_IP_PORT	Untuk health check IPv4 ke backend: 177.222.80.0/23 Untuk health check IPv6 ke backend: 2a13:7500:8301:b029:0:2b::/96
NEG dengan konektivitas hybrid (endpoint NON_GCP_PRIVATE_IP_PORT ) NEG internet regional (dengan endpoint INTERNET_IP_PORT atau INTERNET_FQDN_PORT)	Pemeriksaan kondisi Envoy terdistribusi dari alamat IP Proxy-only subnet
NEG tanpa server (endpoint SERVERLESS) Private Service Connect NEG (endpoint PRIVATE_SERVICE_CONNECT)	Tidak berlaku (backend ini tidak mendukung health check)

Rentang IP probe untuk frontend load balancer berbasis Envoy terkelola tertentu

Load Balancer Aplikasi dan Load Balancer Jaringan proxy berikut menggunakan proxy Envoy terkelola dan juga mendukung aturan firewall yang mengontrol akses ke proxy Envoy terkelola itu sendiri:

• Load Balancer Aplikasi internal regional

• Load Balancer Jaringan proxy internal regional

Untuk mengetahui informasi selengkapnya tentang opsi ini, lihat Menggunakan kebijakan firewall jaringan regional untuk melindungi Load Balancer Aplikasi internal dan Load Balancer Jaringan proxy internal.

Jika Anda memilih untuk membuat aturan firewall tolak ingress dan izinkan ingress untuk mengontrol akses ke aturan penerusan salah satu load balancer ini, Anda harus membuat aturan firewall izinkan ingress untuk mengizinkan sistem Google memantau kondisi proxy Envoy terkelola.

Untuk health check IPv4 ke aturan penerusan:

• 177.222.80.0/23

Untuk health check IPv6 ke aturan penerusan:

• 2a13:7500:8301:b029:0:2b::/96

Health check yang digunakan S3NS untuk memantau proxy Envoy terkelola adalah detail penerapan internal, bukan health check yang dapat dikonfigurasi pengguna.

Rentang IP probe untuk backend Load Balancer Jaringan passthrough

Health check untuk backend Load Balancer Jaringan passthrough berasal dari rentang alamat IP dalam tabel berikut:

Jenis load balancer dan backend	Rentang IP sumber pemeriksaan health check
Load Balancer Jaringan passthrough eksternal global yang menggunakan salah satu backend berikut: Grup instance NEG zona dengan endpoint GCE_VM_IP	Untuk health check IPv4 ke backend: 136.124.104.0/22 136.124.108.0/22 Untuk health check IPv6 ke backend: 2600:1904:7::/48 2600:1904:8::/48
Load Balancer Jaringan passthrough eksternal regional yang menggunakan salah satu backend berikut1: Grup instance NEG zona dengan endpoint GCE_VM_IP	Untuk health check IPv4 ke backend: 177.222.87.64/26 177.222.87.0/26 (untuk target pool) Untuk health check IPv6 ke backend: 2a13:7500:241:30::/64
Load Balancer Jaringan passthrough internal menggunakan salah satu backend berikut: Grup instance NEG zona dengan endpoint GCE_VM_IP	Untuk health check IPv4 ke backend: 177.222.80.0/23 Untuk health check IPv6 ke backend: 2a13:7500:8301:b029:0:2b::/96

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 probe. 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 regional 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.

Flag 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 Cloud de Confiance tunggu untuk mendapatkan respons terhadap pemeriksaan. Nilainya harus kurang dari atau sama dengan interval pemeriksaan. Unit dalam hitungan detik.	5s (5 detik)

Pertimbangan keamanan untuk rentang IP probe

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

• Rentang IP probe milik Google. Cloud de Confiance menggunakan rute khusus di luar jaringan VPC Anda, tetapi dalam jaringan produksi Google, untuk berkomunikasi antara pemeriksa health check dan VM backend.

• Rentang IP probe digunakan secara eksklusif dalam jaringan produksi Google untuk pemeriksaan kondisi dan load balancing. Cloud de Confiance dan jaringan produksi Google mencegah rentang IP probe digunakan untuk tujuan lain dengan menerapkan hal berikut:

  • Router edge Google akan membuang paket dari internet jika paket tersebut memalsukan alamat IP sumber dari rentang IP probe.

  • Anda tidak dapat menggunakan rentang IP probe untuk subnet di jaringan VPC. Untuk mengetahui informasi selengkapnya, lihat Rentang subnet IPv4 yang dilarang dan Spesifikasi IPv6.

Pentingnya aturan firewall

Cloud de Confiance mengharuskan Anda membuat aturan firewall allow masuk yang diperlukan untuk mengizinkan traffic dari pemeriksa ke backend Anda:

• Rentang IP probe adalah kumpulan lengkap alamat IP yang mungkin digunakan oleh probeCloud de Confiance . 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. Cloud de Confiance dapat menerapkan prober baru secara otomatis tanpa pemberitahuan.

• Sebagai praktik terbaik, batasi aturan ini hanya pada protokol dan port yang cocok dengan yang digunakan oleh health check Anda.

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

Beberapa pemeriksaan dan frekuensi

Cloud de Confiance mengirimkan pemeriksaan health check dari beberapa sistem redundan yang disebut penguji. Pemeriksa menggunakan rentang IP sumber tertentu. Cloud de Confiance 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 pemeriksa gagal, Cloud de Confiance terus melacak status responsivitas 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 Cloud de Confiance 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 pemeriksaan. Frekuensi dasar layanan backend dikalikan dengan jumlah penguji serentak yang digunakan Cloud de Confiance . Jumlah ini dapat bervariasi, tetapi umumnya antara 5 dan 10.

• Beberapa aturan penerusan untuk Load Balancer Jaringan passthrough. Jika Anda telah mengonfigurasi beberapa aturan penerusan (dengan alamat IP yang berbeda) yang memiliki grup instance atau NEG zonal yang sama sebagai backend, Cloud de Confiance menggunakan beberapa pemeriksa untuk memeriksa kondisi setiap alamat IP di backend. Frekuensi pemeriksaan pada setiap backend instance atau endpoint dikalikan dengan jumlah alamat IP aturan penerusan unik yang dilayaninya. Contoh:

  • Jika Anda membuat dua aturan penerusan Load Balancer Jaringan passthrough eksternal regional dengan alamat IP yang berbeda yang mengarah ke layanan backend yang sama, frekuensi pemeriksaan pada setiap backend instance atau endpoint layanan backend dikalikan dengan 2.

  • Jika Anda membuat satu Load Balancer Jaringan passthrough eksternal global, satu Load Balancer Jaringan passthrough eksternal regional, dan satu aturan penerusan Load Balancer Jaringan passthrough internal yang menggunakan grup instance yang sama sebagai backend, frekuensi probe pada setiap instance backend grup instance tersebut dikalikan 4. Hal ini karena aturan penerusan Load Balancer Jaringan passthrough eksternal global diberi dua alamat IP dan, oleh karena itu, frekuensi pemeriksaan instance atau endpoint backend-nya selalu dua kali lipat dari frekuensi health check yang dikonfigurasi.

• Beberapa proxy target untuk Load Balancer Aplikasi eksternal. Jika Anda memiliki beberapa proxy target yang mengarahkan traffic ke peta URL yang sama, Cloud de Confiance 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,Cloud de Confiance 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 health check setiap layanan backend.

  Dengan backend NEG zonal, akan lebih sulit untuk menentukan jumlah persis pemeriksaan health check. Misalnya, endpoint yang sama dapat berada di beberapa NEG zonal. NEG zonal tersebut tidak selalu memiliki kumpulan 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, 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 regional Load Balancer Aplikasi internal regional Load Balancer Jaringan proxy eksternal regional Load Balancer Jaringan proxy internal regional	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 zona dengan NON_GCP_PRIVATE_IP_PORT endpoint, 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) 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 regional	Untuk backend grup instance, antarmuka jaringan utama (nic0). Untuk backend NEG zonal dengan endpoint GCE_VM_IP, antarmuka jaringan di subnetwork VPC yang terkait dengan NEG.	Alamat IP yang terkait dengan aturan penerusan. Jika Anda mengonfigurasi beberapa aturan penerusan (dengan alamat IP yang berbeda) yang memiliki grup instance atau NEG zonal yang sama sebagai backend, Cloud de Confiance menggunakan beberapa pemeriksa untuk memeriksa kondisi setiap alamat IP, sehingga meningkatkan frekuensi pemeriksaan pada setiap instance backend atau endpoint backend. Untuk mengetahui detailnya, lihat Beberapa pemeriksaan dan frekuensi.
Load Balancer Jaringan passthrough internal	Antarmuka jaringan di jaringan VPC yang cocok dengan Spesifikasi jaringan layanan backend.	Alamat IP yang terkait dengan aturan penerusan. Jika Anda mengonfigurasi beberapa aturan penerusan (dengan alamat IP yang berbeda) yang memiliki grup instance atau NEG zonal yang sama sebagai backend, Cloud de Confiance menggunakan beberapa pemeriksa untuk memeriksa kondisi setiap alamat IP, sehingga meningkatkan frekuensi pemeriksaan pada setiap instance backend atau endpoint backend. Untuk mengetahui detailnya, lihat Beberapa pemeriksaan dan frekuensi.

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 harus hanya terdiri dari karakter ASCII byte tunggal 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.	Hanya 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.	Hanya kode respons HTTP 200 (OK).

Kriteria keberhasilan untuk SSL dan TCP

Health check TCP dan SSL memiliki kriteria keberhasilan dasar berikut:

• Untuk pemeriksaan kondisi TCP, pemeriksa kondisi harus berhasil membuka koneksi TCP ke backend sebelum waktu tunggu pemeriksaan kondisi habis.

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

• Untuk pemeriksaan kesehatan 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 mengirimkan paket TCP RST, pemeriksaan mungkin dianggap tidak berhasil jika pemeriksa health check telah mengirimkan paket FIN.

Tabel berikut mencantumkan kombinasi valid dari tanda permintaan dan respons yang tersedia untuk health check TCP dan SSL. Flag permintaan dan respons hanya boleh terdiri dari karakter ASCII byte tunggal 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 pemeriksa 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 Cloud de Confiance , dan Cloud Service Mesh. Cloud de Confiance mendukung dua jenis health check gRPC:

• Health check grpc_with_tls digunakan untuk melakukan health check pada backend gRPC dengan TLS yang diaktifkan. Health check 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. Load balancer 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

Cloud de Confiance menggunakan tanda konfigurasi nilai minimum dan maksimum yang berfungsi baik dan tidak berfungsi baik berikut untuk menentukan status kondisi keseluruhan setiap backend yang menjadi tujuan load balancing traffic.

Flag konfigurasi	Tujuan	Nilai default
Healthy threshold healthy-threshold	Nilai minimum responsif menentukan jumlah hasil pemeriksaan berhasil berurutan agar backend yang sebelumnya tidak responsif1 dianggap responsif. Backend yang sebelumnya tidak responsif dapat menjadi responsif jika backend tersebut dapat memenuhi kembali nilai minimum responsif. Cloud de Confiance menganggap backend responsif setelah memenuhi batas responsif ini. Backend yang responsif memenuhi syarat untuk menerima koneksi baru. Backend yang baru ditambahkan mungkin dianggap responsif setelah satu pemeriksaan berhasil.	Ambang batas 2 probe.
Unhealthy threshold unhealthy-threshold	Nilai minimum tidak responsif menentukan jumlah hasil pemeriksaan gagal berurutan agar backend yang sebelumnya responsif2 dianggap tidak responsif. Cloud de Confiance menganggap backend tidak responsif jika batas tidak responsif telah terpenuhi. Backend yang tidak sehat tidak memenuhi syarat untuk menerima koneksi baru; namun, koneksi yang ada *tidak* langsung dihentikan. Sebagai gantinya, koneksi akan tetap terbuka hingga waktu tunggu habis atau hingga traffic dihentikan.	Ambang batas 2 probe.

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 Cloud de Confiance.

Sertifikat dan health check

Pemeriksa health checkCloud de Confiance 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 HTTP Host menggunakan tanda --host.

Jika Anda menggunakan header permintaan kustom, perhatikan bahwa load balancer hanya menambahkan header ini 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
• Ambang batas 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 pemeriksa 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 pemeriksaan A.
2. t=5: Hentikan probe A.
3. t=30: Mulai pemeriksaan B.
4. t=35: Hentikan probe B.
5. t=60: Mulai pemeriksaan C.
6. t=65: Hentikan pemeriksaan C.

Langkah berikutnya

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