3.18 Kubernetes Control Plane Extension Points

Kubernetes Control Plane Extension Points is the specific enumeration of locations within the control plane's own request-processing and reconciliation machinery where external code can be inserted, describing admission webhooks, custom schedulers, aggregated API servers, and controller-based CRDs as four structurally distinct points, each intercepting a different stage of control plane operation.

Admission Webhooks as a Pipeline Extension Point

Inserted Within an Existing Request's Journey

Admission webhooks extend the control plane by inserting external logic directly into the admission chain that every request already passes through, intercepting a request already in flight rather than reacting to it after the fact.

Synchronous and Blocking by Nature

Because a webhook is called synchronously as part of the request pipeline, its extension point is architected to block the request until the webhook responds, distinguishing it from extension points that react asynchronously to already-completed changes.

Custom Schedulers as a Parallel Extension Point

Running Alongside, Not Inside, the Default Scheduler

A custom scheduler extends the control plane not by inserting into an existing pipeline but by running as an entirely separate process alongside the default scheduler, handling only the Pods explicitly assigned to it, leaving the default scheduler's own pipeline untouched.

Extension Through Substitution, Not Interception

This extension point works through substitution rather than interception: a Pod opts into being handled by the custom scheduler instead of the default one, rather than the custom logic being inserted into the default scheduler's own decision process.

Aggregated API Servers as a Structural Extension Point

Extending the API Surface Itself

The aggregation layer extends the control plane at the API surface level, allowing an entirely separate API server process to be registered beneath the main server's URL space, extending what resource types and behaviors are reachable through the cluster's single API endpoint.

Beyond What CRDs Alone Enable

This extension point exists specifically for cases requiring serving logic beyond what the generic, schema-driven CRD machinery can express, making it the deepest and least commonly used of the four extension points.

Controllers Watching Custom Resources as a Reactive Extension Point

Reacting After State Has Already Changed

Unlike admission webhooks, which intercept a request before it completes, a controller watching a CRD extends the control plane reactively, observing already-persisted changes and taking subsequent action, placing this extension point downstream of persistence rather than upstream of it.

Extension Point Comparison Diagram