Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork606
feat: Add Knative Service support to Reloader#969
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:master
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
- Add Knative serving client to kube clients- Implement CRUD operations for Knative services- Add rolling upgrade support for Knative services- Update RBAC permissions for serving.knative.dev/services- Add comprehensive test coverage for Knative functionality- Update documentation with Knative service support- Support both env-var and annotation reload strategies- Add patch template support for Knative servicesResolves the need for automatic reload of Knative services whenConfigMaps or Secrets change, extending Reloader's capabilitiesto serverless workloads.
Uh oh!
There was an error while loading.Please reload this page.
- Restored all original documentation sections that were accidentally removed- Added KnativeService to the Mermaid workflow diagram- Maintained all contributing guidelines, license info, and help sections- Safe for open source repository
| verbs: | ||
| -create | ||
| -patch | ||
| {{- if .Values.reloader.enableHA }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
@yg1996 what is this change about?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
@rasheedamir This change isn't needed for Knative support specifically - it's just for better service reliability.
The {{ if .Values.reloader.enableHA }} condition adds RBAC permissions for leader election when running multiple Reloader replicas in High Availability mode. This is completely separate from the Knative functionality.
What it does:
Grants permissions to manage Kubernetes leases for leader election
Only when enableHA: true is set
Allows running multiple Reloader instances without conflicts
Why it's separate from Knative:
Knative support works fine with single replica (default setup)
HA is purely for operational reliability/redundancy
The actual Knative integration uses different RBAC permissions (serving.knative.dev/services)
So you can use Knative support without enabling HA - this is just an optional enhancement for production environments that want multiple Reloader instances for better availability.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
@rasheedamir Still waiting for approval
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
@yg1996 thanks for the patience; team is pretty occupied and we will look into it asap
mhazem-ui commentedSep 22, 2025
I am currently facing the same issue and would really benefit from having Reloader work with Knative Services. Is there any update on the status of this PR or plans for merging it? |
Hi@yg1996 Thank you for generous work. Loved the PR. We're discussing the right way to incorporate the PR into work and will take sometime. Appreciated your support. Meanwhile, please have a look a upgrade.go file for merge conflict resolution. Upon its cleanup, we can run tests on it via pipeline to have a good confidence. |
Felix-Stakater commentedOct 2, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
@yg1996 Hi! We have discussed this internally and came to the conclusion that by implementing individual workload types, such as the knative service, we open ourselves up to a lot of maintenance (keeping up to date with upstream) and also by making implementations tied to the specific workload CRD we have to implement each new workload resource in isolation. A more desirable approach would be to come up with a more flexible solution which allows the user to define the receipt for how the reloader should handle a specific CRD. So some kind of CRD which specifies:
I have some ideas for how we could design this, but it would need some discussion and PoC-ing, if you are up for it: Please ping me in Slack here:https://slack.stakater.com/ |
Uh oh!
There was an error while loading.Please reload this page.
Resolves the need for automatic reload of Knative services when ConfigMaps or Secrets change, extending Reloader's capabilities to serverless workloads.
Closes#493