Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to opt-out of aggressive probing #10838

Closed
dprotaso opened this issue Feb 23, 2021 · 3 comments
Closed

Unable to opt-out of aggressive probing #10838

dprotaso opened this issue Feb 23, 2021 · 3 comments
Assignees
Labels
area/API API objects and controllers kind/bug Categorizes issue or PR as related to a bug.

Comments

@dprotaso
Copy link
Member

dprotaso commented Feb 23, 2021

/area API

What version of Knative?

All version

Expected Behavior

Setting ReadinessProbe.PeriodSeconds >= 1 should default into K8s style probing.

Actual Behavior

The queue proxy exec probe has a retry tight loop that defaults to the aggressive interval and not the user's defined PeriodSeconds

Steps to Reproduce the Problem

Create an app that fails probing a few times (~3) with the following config

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: default-probe
  namespace: default
spec:
  template:
    spec:
      containers:
      - image: ${RUN_IMAGE}
        readinessProbe:
          httpGet:
            path: /
          periodSeconds: 1
          timeoutSeconds: 1
          failureThreshold: 1

Technically the app should start after ~3s. Instead it behaves the same as periodSeconds is set to zero.

@dprotaso dprotaso added the kind/bug Categorizes issue or PR as related to a bug. label Feb 23, 2021
@dprotaso
Copy link
Member Author

/area API

@knative-prow-robot knative-prow-robot added the area/API API objects and controllers label Feb 23, 2021
@dprotaso
Copy link
Member Author

/assign @dprotaso

@dprotaso
Copy link
Member Author

dprotaso commented Mar 2, 2021

/close

The intent of this issue was to fix the queue proxy probing timing. I've come to realize the activator does it's own aggressive probing (every ~200ms) so it's effectively by-passing the readiness signal to the API server.

I'm going to close this out as a no-fix for now cause I don't think the activator should customize it's probing logic per revision.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/API API objects and controllers kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants