Skip to content

Latest commit

 

History

History
41 lines (23 loc) · 2.79 KB

lifecycle.md

File metadata and controls

41 lines (23 loc) · 2.79 KB

Kubernetes Request internal lifecycle

Kubernetes API serves as the foundation for the declarative configuration schema for the system, among others. Kubernetes itself is decomposed into multiple components, which interact through its API.

Any request made to K8s API is affected by a timeout; by default 60 seconds (see source code).

Mutating Webhook

The injection of New Relic APM Metadata is implemented as an Admission Webhook (MutatingAdmissionWebhook) using Kubernetes Admission Controllers.

Admission Controllers run as part of the Kubernetes API Request Lifecycle.

An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized.

--- https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#what-are-they

The default request timeout between the Kubernetes API and any Admission Webhook is 30 seconds (the value is being forced. See source code).

Response

Kubernetes API expects that successful calls return a 200 OK HTTP code including a ReviewResponse in the body.

Response schema

Please refer to our Open Api 3.0 spec file in order to know more about the shape of the response body.

K8s API Error Handling

Please find here a flow diagram of the internal Kubernetes API Lifecycle. Pay special attention to the failurePolicy config value and how it determines the final behaviour.

As an alternative, you can see the source code of the Dispatcher that executes the Mutating Webhook.

Non-intrusive commitment

We are committed to keep the webhook as a non-intrusive mechanism for injecting the required env vars into the containers. In order to achieve this we took the following design decisions:

  1. The failurePolicy is set to Ignore. Any response from our webhook with a non success HTTP Status Code will be then skipped, so the Kubernetes API will continue the execution of the request lifecycle.
  2. Any 200 OK response coming from the webhook contains allowed: true within the response included in the body. This tells the Kubernetes API that the creation of such workload is allowed, letting then to continue the execution of the request lifecycle.