การตรวจสอบสุขภาพและโพรบความพร้อมใช้งาน

An orchestrator must know whether a service instance can handle requests. Sending traffic to a starting, overloaded, or broken instance causes errors.

The gRPC health checking protocol answers: is this service healthy?

gRPC defines grpc.health.v1.Health with two methods:

• Check — a one-shot status query
• Watch — a stream of status updates

Status is SERVING, NOT_SERVING, or UNKNOWN.

A health request names a service. An empty name asks about the whole server; a specific name asks about one service, so you can report each independently.

The health package provides a ready implementation you register on your server.

Update status as your service transitions. Mark NOT_SERVING during startup or shutdown, then SERVING when ready.

Two distinct ideas:

• Liveness: is the process alive? Restart if not.
• Readiness: can it serve now? Remove from rotation if not, but do not restart.

Health status maps cleanly to readiness.

Kubernetes supports native gRPC probes. Point them at your health service.

The grpc_health_probe binary lets you check health from a shell or older Kubernetes versions.

Smart load balancers use Watch to receive a stream of status changes, reacting instantly when an instance flips to NOT_SERVING instead of polling.

Before stopping, set status to NOT_SERVING and wait. Load balancers drain you out, in-flight requests finish, and clients avoid hitting a dying instance.

Report NOT_SERVING when a critical dependency (database, cache) is unreachable, so traffic routes only to instances that can actually do work.

Test your health-check knowledge.

You learned gRPC health checking:

• The standard Health service offers Check and Watch
• Status is per-service: SERVING, NOT_SERVING, UNKNOWN
• Map health to readiness; pair with liveness probes
• Kubernetes and grpc_health_probe consume it
• Flip to NOT_SERVING for graceful drain and failed dependencies