crossplane / crossplane/crossplane
Run multiple webhook deployments by default
- Dominant language
- Go
- Stars
- 12.1k
- Forks
- 1.3k
- Avg merge
- 1d 6h
- Merged PRs (30d)
- 46
Description
### What problem are you facing?
Currently Crossplane uses webhooks to validate API objects like XRDs and Compositions. In future we think we'll use them for a bunch more things (e.g. converting between API versions). At the moment these webhooks are started by the `crossplane core start` command - i.e. as part of the same binary that runs the core Crossplane controllers.
One issue with this approach is that Kubernetes controllers and webhooks have different scaling properties.
Controller managers are single-leader. If you run more than one replica they will use leader-election - one pod will become leader and the others will do nothing until the leader fails and a new one is elected. This is because controllers operate on API server state, and we don't want many controllers racing to operate on the same state. For this reason we currently default to deploying only a single replica of Crossplane.
Webhooks on the other hand scale horizontally - we can run as many webhooks as we like and spread requests across them. Unfortunately if we're only deploying a single Crossplane replica by default requests to the API server could fail (or not leverage the webhook) if that pod is offline.
### How could Crossplane help solve your problem?
I can see two options here:
1. Break webhooks out into a separate binary and run them as a separate deployment with more replicas than core Crossplane.
2. Run Crossplane with more replicas (say 3) by default. All three would always serve webhooks, but only one would run controllers.
Contributor guide
Assessment
This issue has not been assessed yet.