Kubernetes - Webhook
Webhooks may run as containers in k8s; webhooks can be used to extend admission control. e.g. istio / linkerd has registered admission hooks: user submits normal yaml configs, and "Mutating Admission" stage will add the sidecar container to it.
Webhooks
- one per
Kind
that is reconciled. - provides methods to build and bootstrap a webhook server.
- same as controllers, a Webhook Server is a
Runable
(https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Runnable) (i.e. both controller and webhook server implementStart(ctx context.Context)
) which needs to be registered to a manager. Arbitrary number ofRunable
s can be registered to a manager, so a webhook server can run with other controllers in the same manager. They will share the same dependencies provided by the manager. For example, shared cache, client, scheme, etc. - Admission Webhooks: the API server will send
AdmissionRequest
s to Webhook, Admission Webhooks require Handler(s) to be provided to process the receivedAdmissionReview
requests. - Conversion Webhooks: When API clients, like
kubectl
or your controller, request a particular version of your resource, the Kubernetes API server needs to return a result that’s of that version. However, that version might not match the version stored by the API server. In that case, the API server needs to know how to convert between the desired version and the stored version. Since the conversions aren’t built in for CRDs, the Kubernetes API server calls out to a webhook to do the conversion instead. For Kubebuilder, this webhook is implemented bycontroller-runtime
, and performs the hub-and-spoke conversions.
Webhook Server
Webhook server will start a httpserver
(sigs.k8s.io/controller-runtime/pkg/internal/httpserver
) it is similar to a controller in that it also implements Runnable
interface.
The business logic for a Webhook exists in a Handler. A Handler implements the admission.Handler
interface, which contains a single Handle
method.
hookServer.Register()
: register a handler.
It is recommended to put webhook server together for following benefits:
- Less resource overhead (fewer pod, ip usage and sometimes client cache).
- If webhook and controller are separate deployments, then when webhook is running but controller is down, custom resources will be accepted by API server but not reconciled, this behavior is confusing.
3 kinds of webhooks
- admission webhook. 2 types of admission webhook: mutating and validating admission webhook.
- authorization webhook.
- CRD conversion webhook.
Webhook vs Binary Plugin
- Webhook model: Kubernetes makes a network request to a remote service.
- Binary Plugin model: Kubernetes executes a binary (program). Binary plugins are used by the
kubelet
and bykubectl
.
Gatekeeper
Gatekeeper deploys one Validating webhook and one Mutating webhook that watches all kinds in all apigroups.
It’s basically one big webhook that checks all constraints created via Gatekeeper yamls.
We cannot use Gatekeeper when the validation logic requires queries to the APIServer. For those more complicated policies, we need to write our own webhook.
How to delete Webhooks
Delete the Webhook Configurations:
$ kubectl delete mutatingwebhookconfigurations --all
$ kubectl delete validatingwebhookconfigurations --all