(liveness and readiness probes) is what's keeping your applications available
while you're sleeping. They detect unresponsive pods, mark them unhealthy, and
cause these pods to be restarted or rescheduled.
Kubernetes [does not
support](https://github.com/kubernetes/kubernetes/issues/21493) gRPC health
checks natively. This leaves the gRPC developers with the following three
approaches when they deploy to Kubernetes:
[](/images/blog/2019-09-30-health-checking-grpc/options.png)
1.**httpGet probe:** Cannot be natively used with gRPC. You need to refactor
your app to serve both gRPC and HTTP/1.1 protocols (on different port
numbers).
2.**tcpSocket probe:** Opening a socket to gRPC server is not meaningful,
since it cannot read the response body.
3.**exec probe:** This invokes a program in a container's ecosystem
periodically. In the case of gRPC, this means you implement a health RPC
yourself, then write and ship a client tool with your container.
Can we do better? Absolutely.
## Introducing “grpc-health-probe”
To standardize the "exec probe" approach mentioned above, we need:
- a **standard** health check "protocol" that can be implemented in any gRPC
server easily.
- a **standard** health check "tool" that can query the health protocol easily.
Thankfully, gRPC has a [standard health checking
protocol](https://github.com/grpc/grpc/blob/v1.15.0/doc/health-checking.md). It
can be used easily from any language. Generated code and the utilities for
setting the health status are shipped in nearly all language implementations of