Apply default livenessProbe and readinessProbe to the user container

[chizhg]

In what area(s)?

/area test-and-release

Describe the feature

According to the second paragraph of Meta Requests in Knative Runtime Contract, we should apply default livenessProbe and readinessProbe to the user container when they are not specified, and have them the following settings:

• tcpSocket set to the container's port
• initialDelaySeconds set to 0
• periodSeconds set to platform-specific value

@tcnghia @mattmoor @markusthoemmes

[markusthoemmes]

In theory we have this (we don't do liveness probes though) implemented via the queue-proxy, which does this exact probe.

[dgerd]

QueueProxy Probe on Admin Interface:

serving/pkg/reconciler/revision/resources/queue.go

Line 63 in 1b6908c

queueReadinessProbe = &corev1.Probe{

QueueProxyHandler Setup on Admin Interface:

serving/cmd/queue/main.go

Line 201 in 1b6908c

func createAdminHandlers() *http.ServeMux {

Probe Handler:

serving/pkg/reconciler/revision/resources/queue.go

Line 63 in 1b6908c

queueReadinessProbe = &corev1.Probe{

[dgerd]

We do have something here. Some areas where this doesn't match well with the description:

1. LivenessProbe is not configured
2. "Platform-specific value" makes me think this is configuration; however, periodSeconds is hard-coded in the queueProxy
3. "Default" makes me think that user specified probes override this behavior, but instead they are applied concurrently.

I think we could go either way on whether to update the contract, or to update the implementation for each of these things. I do however want to make them consistent.

[dgerd]

After discussion in the API working group meeting, this is my understanding of where we landed. Please correct if I missed something or misunderstood.

On the contract/specification side:

1. LivenessProbe should not be configured by default. This part of the statement should be removed from the runtime contract.

On the implementation side:

1. The default TCP probe behavior should be disabled when a user specifies a custom readinessProbe.
2. The default TCP readinessProbe should be added by the webhook and appear on the Revision spec.
3. Custom readiness probes defined by the user should be translated to health checks that are done BY the queue-proxy against the user-container, and removed from the user container.
4. We should understand if our queue-proxy http server startup time is causing Good gRPC deployment pods frequently fail at least one health check #3308. If it is we should consider using an execProbe on the queue-proxy to perform the healthcheck against the user-container. If it is not, we should take a look at how fast we timeout on health checking the user container.

[joshrider]

/assign @joshrider

[joshrider]

/assign @shashwathi