/sig api-machinery

Hi @vivekbagade

Enhancements Lead here. Can you please confirm that you will be working towards alpha in 1.20?

Also could you please update the link in the description to link directly to the merged kep: https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/1872-manifest-based-admission-webhooks

Thanks!
Kirsten

Hi @vivekbagade

Any updates on whether this will be included in 1.20?

Enhancements Freeze is October 6th and by that time we require:

The KEP must be merged in an implementable state
The KEP must have test plans
The KEP must have graduation criteria
The KEP must have an issue in the milestone

Thanks
Kirsten

@deads2k @liggitt

@lavalamp had expressed concerns on manifest based webhooks in #2074 (comment)

I strongly feel that this mechanism as proposed helps administrators solve the problems mentioned in the KEP. Only current solution to which is having compiled in admission controllers. That said, the concerns Daniel mentions are apt to discuss.

We need to make a call on this. I intend to target 1.21 with a complete implementation for this.

(Current status: Vivek is going to explore bootstrapping objects from a file (and loading them into the cluster) in a future KEP.)

@vivekbagade are you coming back to this? People are interested in the replacement :)

I'd like to add another use case for this: staged rollout of admission changes to HA clusters. In other words, I'd like to be able to update the admission configuration for 1 api-server instance at a time to catch errors without bringing down the whole cluster. We could of course address this with an enhancement to the regular (dynamic) webhooks, but I think the static file approach would address it by default.

I'd like to be able to update the admission configuration for 1 api-server instance at a time to catch errors without bringing down the whole cluster

Regular admission webhooks have this problem. I would definitely not want to solve it for only certain webhooks. Additionally, breaking "only" 1/Nth of the cluster traffic is actually a bad solution to this problem:

• reentrant calls (webhooks) mean a request may effectively make more than one request, giving more chances to hit the broken apiserver
• In most clusters, some apiserver ends up with the majority of traffic, due to a few different reasons. This means a policy change on one apiserver is either mostly not tested or mostly affects the whole cluster.

Anyway, the replacements to this approach at the moment are:

• #101815
• #101762

@lavalamp I agree that solving this in a general way makes sense. I filed kubernetes/kubernetes#102019 to capture the feature request.

This issue can be closed based on #2822