When creating the Target Pool for Network Load Balance, there is a health check option.
Also there is a property named livenessProbe in the container spec.
A liveness probe checks if the container in which it is configured is still running. If the liveness probe fails, the kubelet kills the container, which will be subjected to its restart policy. Set a liveness check by configuring the template.spec.containers.livenessprobe stanza of a pod configuration.
Is the health check needless when the container is configured with livenessProbe ?
As I understand, if the container is down, POD will be restarted automatically. In this case, no need for health check.
What about the NODE is down? As I understand, kubernetes will start the POD in another NODE, which means the POD will be restarted again.
It seems to me, in any case, health check is needless when livenessProbe is configured.
Health checks for the load balancer and for Kubernetes are separate and you should probably have both.
The load balancer health checks are for the load balancer to know that a particular backend VM can serve traffic. It works on a Compute Engine VM level and will mark specific VMs as healthy or unhealthy. So if a node goes down it will know not to direct traffic at that particular node. It is for traffic before it hit's the Kubernetes cluster. Kubernetes health probes won't help you in the event of a node going down because that only works for traffic that has made it to the cluster. Kubernetes can only handle traffic it can see.
Once the traffic has made it into the cluster Kubernetes will direct traffic to containers it things are healthy. If there is a no health check, this will be containers that are in the running state. Even though your container may be running it might not yet be ready to serve traffic. Liveliness/Readiness probes give Kubernetes a way to know containers are up and ready to serve traffic.