Webhook Configuration Installation

    There are 2 options to install webhook configurations into a cluster:

    • Use the webhook manifests generator to generate webhook configurations.Then install the webhook configurations and deploy the webhook servers.

    Webhook installer is a feature provided by the controller-runtime library.For a ,you can choose to enable the webhook installer.Depending on your ServerOptions,the installer may install ,validatingWebhookConfigurationsand service; it may also update the secret if needed.

    To make the webhook installer work correctly, please ensure the manager's service account hasthe right permissions. For example. it may need permissions:

    • create and update MutatingWebhookConfigurations and ValidatingWebhookConfigurations
    • create and update the Service in the same namespace of the manager
    • update the Secret in the same namespace of the managerThe service fronts the webhook server.So please ensure the service's selectors select your webhook server pods.

    The secret contains

    • the signing CA certificate and its corresponding private keyWebhook installer can be very helpful for

    • faster iteration during development

    • easier deployment in production if policy allowsWebhook installer is on by default. Setto true to turn it off.

    Webhook Manifests Generator

    From cluster administrators perspective, they may want to have the webhook configurationsinstallation to be a separate process from running the webhook server,since permissions to create and update webhook configurations are considered as high privileges.

    Similar to other generators in ,webhook manifest generator is annotation-driven.

    How the webhook manifest generator works1) It parses the annotations to configureWebhook.1) It parses the annotations to configure.1) It uses the library in controller-runtime, which is the same machinery asthe installer, to generate the webhook configuration manifests.

    Comment Group

    For example, the following comments are in one comment group

    The following comments are in 2 comments groups

    Annotations

    Each comment line that starts with +kubebuilder:webhook: will be processed to extract annotations.

    The annotations can be grouped in 2 categories based on what struct they configure.

    The first category is for each individual webhook.They are used to set the fields in Webhook struct.The annotations for the same webhook are allowed to span across multiple lines as long as they are prefixed with+kubebuilder:webhook: and in the same comment group.It is suggested to put this category of annotations in the same file as its corresponding webhook.

    For example, the following is for one single webhook

    groups, versions and resources have the same semantic as the ones used for generating RBAC manifests.They can reference a core type or a CRD type.

    verbs are used to set .It supports create, update, delete, connect and * case-insensitively.

    name is the name of the webhook andis used to set .path is the endpoint that this webhook serves andis used to set .Both name and path do NOT allow , and ;.

    failure-policy is used to set FailurePolicy.It supports fail and ignore case-insensitively.

    The second category is for the webhook server.All of them are used to configuration struct.Each annotation should only be used once.They don't have to be in the same comment group.It is suggested to put this category of annotations in the same file as the webhook server.

    The following is an example using webhook server annotations.

    is the port that the webhook server serves. It is used to set Port.

    service should be formatted as <namespace>:<name>. It is used to set.

    selector should be formatted as key1:value1;key2:value2 and it has 2 usages:

    secret should be formatted as <namespace>:<name>. It is used to set

    mutating-webhook-config-name is used to set MutatingWebhookConfigName.

    is used to set .