feat: Add Knative Service support to Reloader #969
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 services Resolves the need for automatic reload of Knative services when ConfigMaps or Secrets change, extending Reloader's capabilities to serverless workloads.
yg1996
changed the title
yg1996
changed the title
- 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.
@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.
@yg1996 thanks for the patience; team is pretty occupied and we will look into it asap
|
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. |
|
@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/ |
5 participants
Resolves the need for automatic reload of Knative services when ConfigMaps or Secrets change, extending Reloader's capabilities to serverless workloads.
Closes #493