You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 22, 2023. It is now read-only.
As cluster-admin I want to run the webhook server in its own pod
So that** that crashloops of the operator doesn't affect the ability to edit instances.
Context
Currently (v0.1.1) both operator and webhook are in the same container and pod.
If the controller encounters an unrecoverable error (such as a panic) then the chances are high that the container ends up in a crashloop. This means that the webhook server also gets constantly restarted.
Consider this scenario:
Instance object is in a broken state
Operator tries to reconcile instance, but panics and crashloops
A user tries to fix the instance by editing the broken spec -> user can't do this since kubernetes can't reach the webhook server
Out of Scope
No response
Further links
No response
Acceptance Criteria
No response
Implementation Ideas
Run the webhook part as a separate CLI subcommand in its own deployment
Adapt the helm chart accordingly
The text was updated successfully, but these errors were encountered:
Summary
As cluster-admin
I want to run the webhook server in its own pod
So that** that crashloops of the operator doesn't affect the ability to edit instances.
Context
Currently (
v0.1.1
) both operator and webhook are in the same container and pod.If the controller encounters an unrecoverable error (such as a panic) then the chances are high that the container ends up in a crashloop. This means that the webhook server also gets constantly restarted.
Consider this scenario:
Out of Scope
No response
Further links
No response
Acceptance Criteria
No response
Implementation Ideas
The text was updated successfully, but these errors were encountered: