failureThreshold and timeoutSeconds parameter should be optional as per k8s doc

[savitaashture]

In what area(s)?

/area API
/kind good-first-issue

/area autoscale
/area build
/area monitoring
/area networking
/area test-and-release

Describe the feature

Currently when create a service with below provided info

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: hello
spec:
  template:
    metadata:
      name: hello-test
      annotations:
    spec:
      containers:
      - image: savita3020/helloworld
        readinessProbe:
          exec:
            command:
            - cat
            - /tmp/healthy
          initialDelaySeconds: 5
          periodSeconds: 5

Actual Output:

Error from server (BadRequest): error when creating "vol.yaml": admission webhook "resource.webhook.serving.knative.dev" denied the request: mutation failed: expected 1 <= 0 <= 2147483647: spec.template.spec.containers[0].readinessProbe.failureThreshold, spec.template.spec.containers[0].readinessProbe.timeoutSeconds

Expected Output:
Should create service successfully because failureThreshold and timeoutSeconds are optional fields if don't specify should take the default values as per doc

But in k8s_validation.go because check its failing.

Implementation:
Should provide a default values for failureThreshold and timeoutSeconds same like SuccessThreshold

So even if we don't specify failureThreshold and timeoutSeconds in service yaml it should create successfully

[danielqsj]

/assign

[dgerd]

This seems to be coming up more often recently so we can potentially revisit the decision here, but this is purposeful. Knative Serving does not necessarily follow K8s defaults or validation.

We have chosen to deviate here to enable sub-second probing by default. K8s does not allow for setting a granularity less than 1 second, but we needed to go lower and we wanted this experience by default as cold-start is critical for serverless workloads. Because we deviated here defaulting and validation logic also needed to change.

See #4780 (comment) and kubernetes/kubernetes#76951

[knative-housekeeping-robot]

Issues go stale after 90 days of inactivity.
Mark the issue as fresh by adding the comment /remove-lifecycle stale.
Stale issues rot after an additional 30 days of inactivity and eventually close.
If this issue is safe to close now please do so by adding the comment /close.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/lifecycle stale

[dgerd]

/remove-lifecycle stale
as there is an open PR referencing this issue.

[ahmetb]

/lifecycle frozen
as it's needed.