Shulou(Shulou.com)05/31 Report--

This article mainly introduces "how to deploy a webhook". In daily operation, I believe many people have doubts about how to deploy a webhook. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the doubts of "how to deploy a webhook"! Next, please follow the editor to study!

What is the use of External Admission Webhooks working mechanism External Admission Webhooks

When do we need to use External Admission Webhooks? When the cluster administrator needs to force some or all requests to be verified or modified, you can consider using ValidatingAdmissionWebhook or MutatingAdmissionWebhook. The difference between the two is as follows:

MutatingAdmissionWebhook allows you to make mutate modifications to object in webhook

ValidatingAdmissionWebhook (GenericAdmissionWebhook before Kubernetes 1.9) does not allow you to make mutate modifications to Object in webhook, but returns validate as true or false

How to enable External Admission Webhooks

As mentioned earlier, you need to add ValidatingAdmissionWebhook,MutatingAdmissionWebhook in each kube-apiserver instance (taking into account Kubernetes Master HA)-- admission-controll.

In addition, you need to add admissionregistration.k8s.io/v1alpha1 to the-- runtime-config of each kube-apiserver instance. When you disable, also remember to delete it from here.

Considerations for MutatingAdmissionWebhook

Beta in 1.9

It is important to note that the MutatingAdmissionWebhook is executed serially by the matching webhooks, because each webhook may be mutate object.

Similar to the use of Initializers, MutatingAdmissionWebhook configures what kind of request triggers which webhook by creating a MutatingWebhookConfiguration.

Note that apiserver must be authenticated by TLS when calling webhook, so caBundle must be configured in MutatingWebhookConfiguration.

Considerations for ValidatingAdmissionWebhook

Alpha in 1.8,beta in 1.9

It is important to note that ValidatingAdmissionWebhook allows matching webhooks to execute concurrently, because each webhook only performs validate operations, not mutate object.

Similar to the use of Initializers, ValidatingAdmissionWebhook configures what kind of request triggers which webhook by creating a ValidatingWebhookConfiguration.

Note that apiserver must be authenticated by TLS when calling webhook, so caBundle must be configured in ValidatingWebhookConfiguration.

Sample

Let's take ValidatingAdmissionWebhook as an example to see how to play.

Deploy ValidatingWebhook. For example, we simply deploy a webhook with Pod and create a corresponding Service:

ApiVersion: v1kind: Podmetadata: labels: role: webhook name: webhookspec: containers:-name: webhook image: example-webhook:latest imagePullPolicy: IfNotPresent ports:-containerPort: 8000---apiVersion: v1kind: Servicemetadata: labels: role: webhook name: webhookspec: ports:-port: 443 targetPort: 8000 selector: role: webhook

Example-webhook is the project caesarxuchao/example-webhook-admission-controller of github, and the example-webhook image is created through the Dockerfile under the root directory of github repo.

FROM golang:1.8WORKDIR / go/srcRUN mkdir-p github.com/caesarxuchao/example-webhook-admission-controllerCOPY. . / github.com/caesarxuchao/example-webhook-admission-controllerRUN go install github.com/caesarxuchao/example-webhook-admission-controllerCMD ["example-webhook-admission-controller", "--alsologtostderr", "- VIP 4", "2 > & 1"]

Create a ValidatingWebhookConfiguration Object, such as:

ApiVersion: admissionregistration.k8s.io/v1alpha1kind: ValidatingWebhookConfigurationmetadata: name: config1externalAdmissionHooks:-name: podimage.k8s.io rules:-operations:-CREATE apiGroups:-"" apiVersions:-v1 resources:-pods failurePolicy: Ignore clientConfig: caBundle: xxxx service: namespace: default name: webhook- Note failurePolicy can be Ignore or Fail This means that if there is a problem communicating with webhook that causes the call to fail, the decision will be made based on the failurePolicy, whether to ignore the failure (admit) or consider the admission failure (reject). In Kubernetes 1.7, this value is only allowed to be configured as Ignore. -compared with initializerConfiguration,ValidatingWebhookConfiguration and MutatingWebhookConfiguration in the definition of rule, operations field is added. When defining resources, you can specify subresource in the format of resource/subresource.

After ExternalAdmissionHookConfiguration is created, you need to wait a few seconds, and then through Deployment or directly create Pod, then the request to create Pod will be blocked by apiserver, and call ValidatingAdmissionWebhook to check whether the Admit is passed. For example, the example-webhook above checks whether the container image is prefixed with "gcr.io".

How to develop an Externel Admission Webhook

Admission controller actually sends an admissionReview request to webhook server, and then webhook server obtains object,oldobject,userInfo and other information from admissionReview.spec, mutate or validate, and then sends back an admissionReview as a return, in which the returned admissionReivew.status has an admission decision.

AdmissionReview

Here is the definition of the AdmissionReview structure:

Type AdmissionReview struct {metav1.TypeMeta `json: ", inline" `/ / Request describes the attributes for the admission request. / / + optional Request * AdmissionRequest `json: "request,omitempty" protobuf: "bytes,1,opt,name=request" `/ / Response describes the attributes for the admission response. / / + optional Response * AdmissionResponse `json: "response,omitempty" protobuf: "bytes,2,opt,name=response" `} / / AdmissionRequest describes the admission.Attributes for the admission request.type AdmissionRequest struct {/ / UID is an identifier for the individual request/response. It allows us to distinguish instances of requests which are / / otherwise identical (parallel requests, requests when earlier requests did not modify etc) / / The UID is meant to track the round trip (request/response) between the KAS and the WebHook, not the user request. / / It is suitable for correlating log entries between the webhook and apiserver, for either auditing or debugging. UID types.UID `json: "uid" protobuf: "bytes,1,opt,name=uid" `/ / Kind is the type of object being manipulated. For example: Pod Kind metav1.GroupVersionKind `json: "kind" protobuf: "bytes,2,opt,name=kind" `/ / Resource is the name of the resource being requested. This is not the kind. For example: pods Resource metav1.GroupVersionResource `json: "resource" protobuf: "bytes,3,opt,name=resource" `/ / SubResource is the name of the subresource being requested. This is a different resource, scoped to the parent / / resource, but it may have a different kind. For instance, / pods has the resource "pods" and the kind "Pod", while / pods/foo/status has the resource "pods", the sub resource "status", and the kind "Pod" (because status operates on / / pods). The binding resource for a pod though may be / pods/foo/binding, which has resource "pods", subresource / / "binding", and kind "Binding". / / + optional SubResource string `json: "subResource,omitempty" protobuf: "bytes,4,opt,name=subResource" `/ / Name is the name of the object as presented in the request. On a CREATE operation, the client may omit name and / / rely on the server to generate the name. If that is the case, this method will return the empty string. / / + optional Name string `json: "name,omitempty" protobuf: "bytes,5,opt,name=name" `/ / Namespace is the namespace associated with the request (if any). / / + optional Namespace string `json: "namespace,omitempty" protobuf: "bytes,6,opt,name=namespace" `/ / Operation is the operation being performed Operation Operation `json: "operation" protobuf: "bytes,7,opt,name=operation"` / / UserInfo is information about the requesting user UserInfo authenticationv1.UserInfo `json: "userInfo" protobuf: "bytes,8,opt Name=userInfo "`/ / Object is the object from the incoming request prior to default values being applied / / + optional Object runtime.RawExtension `json:" object,omitempty "protobuf:" bytes,9,opt,name=object "` / / OldObject is the existing object. Only populated for UPDATE requests. / / + optional OldObject runtime.RawExtension `json: "oldObject,omitempty" protobuf: "bytes,10,opt,name=oldObject" `} / / AdmissionResponse describes an admission response.type AdmissionResponse struct {/ / UID is an identifier for the individual request/response. / / This should be copied over from the corresponding AdmissionRequest. UID types.UID `json: "uid" protobuf: "bytes,1,opt,name=uid" `/ / Allowed indicates whether or not the admission request was permitted. Allowed bool `json: "allowed" protobuf: "varint,2,opt,name=allowed" `/ / Result contains extra details into why an admission request was denied. / / This field IS NOT consulted in any way if "Allowed" is "true". / / + optional Result * metav1.Status `json: "status,omitempty" protobuf: "bytes,3,opt,name=status" `/ / The patch body. Currently we only support "JSONPatch" which implements RFC 6902. / / + optional Patch [] byte `json: "patch,omitempty" protobuf: "bytes,4,opt,name=patch" `/ / The type of Patch. Currently we only allow "JSONPatch". / / + optional PatchType * PatchType `json: "patchType,omitempty" protobuf: "bytes,5,opt,name=patchType" `} example-webhook

Below is the main file for example-webhook mentioned earlier, which you can use to develop your own AdmissionWebhook.

/ / only allow pods to pull images from specific registry.func admit (data [] byte) * v1alpha1.AdmissionReviewStatus {ar: = v1alpha1.AdmissionReview {} if err: = json.Unmarshal (data, & ar); err! = nil {glog.Error (err) return nil} / / The externalAdmissionHookConfiguration registered via selfRegistration / / asks the kube-apiserver only sends admission request regarding pods. PodResource: = metav1.GroupVersionResource {Group: ", Version:" v1 ", Resource:" pods "} if ar.Spec.Resource! = podResource {glog.Errorf (" expect resource to be% s ", podResource) return nil} raw: = ar.Spec.Object.Raw pod: = v1.Pod {} if err: = json.Unmarshal (raw, & pod) Err! = nil {glog.Error (err) return nil} reviewStatus: = v1alpha1.AdmissionReviewStatus {} for _, container: = range pod.Spec.Containers {/ / gcr.io is just an example. If! strings.Contains (container.Image, "gcr.io") {reviewStatus.Allowed = false reviewStatus.Result = & metav1.Status {Reason: "can only pull image from grc.io" } return & reviewStatus}} reviewStatus.Allowed = true return & reviewStatus} func serve (w http.ResponseWriter, r * http.Request) {var body [] byte if r.Body! = nil {if data, err: = ioutil.ReadAll (r.Body) Err = = nil {body = data}} / / verify the content type is accurate contentType: = r.Header.Get ("Content-Type") if contentType! = "application/json" {glog.Errorf ("contentType=%s, expect application/json" ContentType) return} reviewStatus: = admit (body) ar: = v1alpha1.AdmissionReview {Status: * reviewStatus,} resp, err: = json.Marshal (ar) if err! = nil {glog.Error (err)} if _, err: = w.Write (resp) Err! = nil {glog.Error (err)}} func main () {flag.Parse () http.HandleFunc ("/", serve) clientset: = getClient () server: = & http.Server {Addr: ": 8000", TLSConfig: configTLS (clientset),} go selfRegistration (clientset) CaCert) server.ListenAndServeTLS (",")} thinking

We found that the purpose of MutatingAdmissionWebhook is the same as that of Initializers. They both modify object, but they are implemented in different ways. Then why do the two coexist? In-depth Analysis of Kubernetes dynamic admission Control Initializers mentions that Initializers has the following shortcomings:

If the Initializers Controllers you deploy does not work properly or the performance is very low, a large number of related objects will stay in the uninitialized state in high concurrency scenarios and cannot be scheduled later. This may affect your business, for example, if you use HPA to flexibly expand the relevant Deployment objects, when the load comes up, your Initializers Controllers will not work properly, which will cause your application not to scale flexibly, and the consequences can be imagined!

So my personal understanding is that MutatingAdmissionWebhook is a more elegant and better performance implementation of mutate object than Initializers. And from the point of view of the release of Kubernetes 1.9, MutatingAdmissionWebhook is Beta, while Initializers is still in Alpha, and the official recommended adminssion-control configuration in Kubernetes 1.9 mentioned earlier is MutatingAdmissionWebhook, not Initializers. So I think the community actually wants to replace Initializers with MutatingAdmissionWebhook.

At this point, the study on "how to deploy a webhook" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.