What Kubernetes customization services involve for your cluster
Kubernetes customization services cover the design, build, testing and hand-over of extensions that make your cluster do something its upstream API cannot do on its own. Most platform teams keep the design decisions in-house, meaning which objects the platform exposes, which rules it enforces and who owns each one, and outsource the build, testing and hand-over work. The typical situation is a platform team that needs a new object type, an automated workflow, a policy gate, or a storage or network plugin that the default install does not provide, and needs it working in production without adding a long-term skills gap.
Three triggers account for most of this work. The first is a new internal platform API, usually implemented as a CustomResourceDefinition with a controller that reconciles the objects it defines. The second is a compliance-driven admission rule, implemented as a validating or mutating admission webhook or a policy engine that accepts, rejects or changes requests before they are stored. The third is a vendor operator that must be integrated, which means its custom resources, service accounts and cluster roles must fit your namespace model and identity setup. Before scoping, list each requested extension, its trigger and the team that will request changes to it.
Each extension becomes code that you must maintain across upgrades. A CRD may add a new served version, a webhook depends on the admission API version your cluster runs, and a controller depends on the client libraries it was built with. Ask who owns the source repository, the container images, the test suite and the runbook after hand-over. Confirm the failure policy and timeout on every webhook, because an unavailable webhook can block all matching requests. For vendor operators, confirm the supported Kubernetes versions in the vendor's compatibility statement before you pick a target minor release. Upgrade procedure, deprecated API checks and add-on compatibility are covered in Kubernetes upgrades and support.
When you request a quote, the written scope should name each extension, the acceptance tests it must pass, the documentation delivered and the post-hand-over support model. Build effort is typically one-time, while testing against each new Kubernetes minor release, dependency updates and vendor operator changes recur for as long as the extension runs. The cost of ownership, distribution choice and the platform team you need afterwards are covered in Kubernetes cost of ownership and editions and Kubernetes implementation plan and cost. Access control for extensions and the admission rules that protect them are covered in Kubernetes security hardening and Kubernetes RBAC and multi-tenancy.
Kubernetes customization deliverables you receive
A Kubernetes extension is only as useful as the material that lets your team build it, test it, upgrade it and hand it over. The cards below describe the work packages a written scope can include and the artifacts you keep at the end of each one. Scope, deliverables and timelines are agreed in writing before work starts, and DeployOpen does not issue audit reports or certifications for the extensions it builds.
Custom resource definitions and versioning
A custom resource definition (CRD) adds a new API type to your clusters, and every consumer of that type depends on its schema. The deliverable is a versioned CRD set with OpenAPI schemas, a conversion strategy for any second API version, and a note on which fields are safe to change. Check how existing objects will be migrated when the schema moves, and who owns the API group after handover.
Operator or controller source and build
An operator or controller watches custom resources and reconciles real cluster state, so its bugs show up as drift in production workloads. The deliverable is the source repository, reconciliation logic, container build definition and release process, with the controller's RBAC permissions documented and kept to the minimum it needs. Ask how the controller behaves when the API server is unavailable and how it recovers from a restart partway through a change.
Validating and mutating admission components
Admission webhooks can accept, reject or rewrite requests before objects reach etcd, which makes them a common cause of cluster-wide outages. The deliverable includes the webhook service, its failure policy, certificate handling, namespace exclusions and rules that show the policy decisions in one place. Confirm the failure policy for each webhook and the procedure for disabling one during an incident.
CNI and CSI plugin selection and configuration
Network and storage plugins determine pod connectivity, network policy enforcement and how volumes are provisioned, and they are hard to replace once workloads depend on them. The deliverable is a written selection record, the plugin configuration as manifests or Helm values, and the settings for storage classes, snapshots and reclaim behavior. Confirm which plugin versions your chosen Kubernetes minor releases support before you commit to one.
Test suite and upgrade notes
Extensions break quietly when a Kubernetes minor version changes an API they depend on, so tests must run against each supported release. The deliverable is a test suite covering unit, integration and end-to-end paths, a version matrix, and upgrade notes that list the APIs, add-on versions and skew limits to check before each cluster upgrade. Ask which test environments are included and whether the suite runs in your own pipeline.
Operator runbook and handover
Custom components become your team's responsibility after handover, so the runbook matters as much as the code. The deliverable is a runbook covering install, rollback, alerting, common failure modes, certificate rotation and the steps to remove an extension safely. Agree in writing who receives the repository, signing keys and access, and which of your staff will be trained to run the extension.
What drives Kubernetes customization cost and duration
This table lists the factors that move the effort of a Kubernetes extension project, why each one matters, and what to do to keep it contained. Read each row as a question to answer before asking for a quote, since most cost comes from the number and type of extensions rather than from any single component. The main takeaway is that a small number of custom resource types, reconciliation logic kept inside one operator, and early agreement on target clusters usually do more to control cost than any choice of tooling.
| Driver | Why it moves effort | How to keep it down |
|---|---|---|
| Custom resource types and versions | Each new kind needs schema design, validation, versioning, conversion between versions and documentation. Every extra version multiplies testing and upgrade work. | Limit new kinds to real domain objects, start with one served version, and agree a deprecation rule before the first release. |
| Operator reconciliation versus admission enforcement | A reconciling operator owns ongoing state, retries, finalizers and failure recovery. Admission webhooks run on every matching request, so they add latency, failure modes and certificate management. | Use admission only for accept or reject decisions. Put stateful or long-running logic in one operator and test its failure paths explicitly. |
| External systems called by the extension | Each call to a CMDB, secrets vault, ticketing system or cloud API adds credentials, network paths, error handling, rate limits and test doubles. | Prefer one integration point with a clear owner. Cache reads where the source allows it and confirm the API contract with each system owner in writing. |
| Number of clusters and environments | Every cluster and tier (development, staging, production) needs its own install, configuration, and verification. Drift between them is a common source of rework. | Package the extension as a versioned Helm chart or equivalent, keep per-environment values in one place, and automate promotion. |
| Air-gapped or regulated cluster | Offline clusters need images, charts and dependencies mirrored to a private registry. Regulated environments add change records, evidence capture and approval steps. | Confirm mirroring and approval workflows before design starts. Keep dependency lists short and pin versions so the mirror stays small. |
| Plugins replaced versus added | Replacing an existing networking, storage or admission plugin means migrating live workloads and policies. Adding a new one mostly means install and test. Replacement usually costs more. | Use existing extension points where possible. Where replacement is required, plan a parallel run and a rollback path before scheduling cutover. |
| Upgrade path of the extension | Each Kubernetes minor release can change APIs, admission behavior or controller-runtime dependencies. Effort recurs with every upgrade the platform takes. | Check deprecated API usage before each upgrade, keep a staging cluster on the target version, and ask any partner to state the upgrade work covered by its support terms. |
How a Kubernetes customization project runs, phase by phase
The sequence moves each custom resource, operator, admission policy and networking or storage plugin from an idea to a supported production component, with the upgrade path proven before release. Each phase ends in a named artifact the client keeps and can operate without the partner.
Inventory every extension and its owner
The partner and your platform team list each planned custom resource, operator, admission policy, CNI or CSI plugin and webhook, along with the workloads that depend on it, the team that will own it and the cluster it runs in. Each item is checked for an upstream maintenance status and for the Kubernetes API versions it relies on. The step is complete when the client holds a written extension inventory that names an owner and a retirement condition for every item.
Design schemas and failure behavior
The team defines the schema of each custom resource, the validation rules of each admission policy, and what happens when a webhook or operator is unavailable. Decisions cover whether admission fails open or closed, how controllers recover after restarts, and which resources are protected from deletion. The output is a design record with schema definitions, failure-mode decisions and the reasons for each, reviewed and signed off by your platform and security leads.
Build in a development cluster
Engineers implement the extensions in a development cluster that matches your distribution and networking setup as closely as practical. They write the controllers, policies and plugin configuration, apply least-privilege RBAC to each component's service account, and keep all code and manifests in version control. The step closes with a working build, a deployment manifest set, and a short note listing every cluster-scoped permission the extension requests.
Test against each target Kubernetes minor version
Automated tests run the extensions against every Kubernetes minor version the client will operate during the planned support window, using the version list in the written plan. Tests cover schema validation, admission behavior on valid and invalid objects, controller reconciliation after restarts, and removal of deprecated API versions. The output is a test report per version and a compatibility matrix that the client can rerun before each upgrade.
Roll out to staging and rehearse an upgrade
The extensions are deployed to a staging cluster that mirrors production, then the team rehearses a control plane and node upgrade with the extensions present, moving one minor version at a time in line with the version skew rules. Engineers record which add-ons break, how long the webhooks block the API server during the rehearsal, and what rollback looks like. The step is complete when the rehearsal log and a list of required fixes are accepted by the client.
Release to production under change control
The partner and your change board release the extensions to production using the rollout steps proven in staging, with a documented rollback path and a named on-call contact for the window. Admission policies are introduced in audit or warn mode first where the design calls for it, then enforced. The release is complete when production shows the expected behavior, the change record is closed and the client confirms the extensions are running under its monitoring.
Hand over runbooks and ownership
Engineers walk your platform team through the architecture, the upgrade procedure, the failure-mode decisions and the recovery steps for each extension, then support staff run one supervised upgrade rehearsal themselves. The client receives the runbooks, the test suite, the extension inventory with owners and the compatibility matrix. The hand-over is complete when your team has performed the rehearsal without partner assistance. Ask the partner to state in the written plan how many handover sessions and rehearsals are included, and whether ongoing support is a separate retainer.
Which Kubernetes extension work stays in-house and which to outsource
This table compares six kinds of Kubernetes extension work and shows where ownership usually stays with the client and where a partner is commonly brought in. Read each row for the decision it encodes, the skills it needs and the point where outside help is most often justified. The main takeaway is that schema and ownership decisions carry your internal policy and should remain yours, while build speed and specialist controller experience are the usual reasons to bring in a partner.
| Work area | Usually kept in-house | Usually outsourced | Skills required |
|---|---|---|---|
| Extension ownership and API design | Custom resource schemas, naming, ownership boundaries and which teams may create each resource type | Workshops to draft options and review trade-offs against upstream API conventions | Platform architecture, API design, internal policy knowledge |
| Operator or webhook build | Final design sign-off, acceptance criteria and code review of controller logic | Initial controller or admission webhook implementation, tests and packaging | Go or similar, controller-runtime patterns, reconciliation and failure handling |
| Plugin evaluation and configuration | Choice of CNI, CSI or policy plugins against your requirements and approval of defaults | Side-by-side evaluations, configuration baselines and documentation of trade-offs | Networking and storage fundamentals, familiarity with each plugin's operating model |
| Test automation against new Kubernetes minor versions | Ownership of the test suite, pass criteria and release gating decisions | Building conformance-style and end-to-end tests that run in CI against candidate versions | CI pipelines, Kubernetes test tooling, scripting and cluster provisioning |
| Upgrade compatibility checks | Decision to upgrade, risk acceptance and scheduling within change windows | Deprecated API scans, add-on version matrix checks and staging rehearsals | Version skew rules, deprecation policy knowledge, cluster operations experience |
| Ongoing on-call for controllers | Escalation ownership, service-level targets and incident review for business-critical extensions | Shared or retainer on-call for controller failures, reconciliation loops and webhook outages | Controller debugging, log and metric analysis, runbook writing, after-hours coverage |
What goes wrong with Kubernetes extensions and how to prevent it
Kubernetes maintains only the three most recent minor releases, and each patch line gets about one year of support, so the cluster must be upgraded roughly once a year, one minor version at a time. As of September 2026 the supported minors were 1.35, 1.36 and 1.37. Every operator, webhook and plugin must be retested against each of those upgrades, and the five risks below show where that recurring work usually fails.
Webhook blocks API requests
An admission webhook or operator that intercepts API calls can stop the cluster from accepting changes when its pods are down or unreachable. If the webhook uses a failure policy of Fail, every matching create or update returns an error until it recovers, including the calls needed to repair it. Check each webhook's failure policy, limit its scope with namespace and object selectors, and run it with multiple replicas spread across nodes before production use.
Custom resource versions left unmanaged
A custom resource definition can serve several API versions, and its conversion strategy decides how stored objects move between them. When an operator ships a new version without a conversion path or migration plan, objects written under the old version can become unreadable to the new controller. Before upgrading an operator, list the served and stored versions of each CRD, confirm the conversion strategy, and record which team owns each version.
Extensions built on removed APIs
An extension built against a Kubernetes API that a newer minor release removes will fail after the control plane upgrade, even if it worked before. Controllers, Helm charts and admission policies that reference old API groups often break without any warning, because nothing in the cluster flags a stale manifest. Scan every manifest and client library against the target minor release, and rehearse the upgrade in staging on that same release before production.
Plugins tied to one distribution
A storage, networking or ingress plugin may support only certain Kubernetes versions or the single distribution it was tested on. CNCF conformance confirms that a distribution supports the required APIs, but it does not confirm that a third-party plugin works on that distribution. Ask each plugin vendor for the minor releases and distributions it lists as tested, and keep that compatibility matrix with your change records.
Extensions with no owner
Extensions often outlive the team that installed them. After a handover, operators, CRDs and webhooks may have no named owner, so nobody tracks their patch releases, certificate rotation or upgrade path. Before handover, record each extension's owner, source, version, dependencies and upgrade trigger in a register, and assign a named reviewer who checks the register against each supported minor release.
How Kubernetes customization differs by starting point
On a new cluster, extensions are designed together with the platform, so custom resources, admission policies, and storage and network plugins are chosen before workloads depend on them. The main risk is scope creep. Every extension added early becomes part of every future upgrade.
- Inventory first: list the custom resources, operators, webhooks, and CNI or CSI plugins the platform needs before installing anything.
- Decide ownership: name who builds, tests, and patches each operator and webhook.
- Set admission policy early: define Pod Security Standards levels and validating policies per namespace so later workloads inherit them.
- Plan the upgrade path: test each extension against the minor versions that will be supported when the cluster goes live.
Confirm with your distribution or installer which extension points it reserves and which API versions your chosen plugins support.
An existing cluster usually carries ad hoc scripts, manual kubectl changes, and webhooks that no one documented. The work is to find what exists, convert the important parts into declarative manifests or operators, and retire the rest in a controlled way. Changes made by hand often run in production with no clear owner, so discovery takes as much care as the build.
- Find drift: compare live objects with version control and list resources created outside the deployment pipeline.
- Map scripts to operators: decide which repeated steps become custom resources with a controller and which become plain manifests.
- Rehearse conversions: test each change in a staging cluster built from the same versions before touching production.
- Document owners and rollback: record who runs each script today and how each change is reversed.
Confirm with your distribution whether it allows the cluster-level changes you plan, and whether manual edits to control plane components will be overwritten during an upgrade.
A vendor distribution already supplies some extension points, such as a bundled ingress, storage class, monitoring stack, or admission policies. The work shifts from building those components to deciding which to keep, which to replace, and how your extensions sit alongside the vendor's. Vendor components also follow their own release cadence, which can differ from upstream.
- Map bundled components: list each supplied extension and mark it as required, optional, or replaceable.
- Check overlap: confirm that your custom admission policies do not conflict with vendor-supplied ones.
- Separate support boundaries: note which issues the vendor supports and which fall to your team.
- Track version pairing: tie each custom operator to the Kubernetes versions the vendor supports.
Ask the vendor which extension points are documented as supported, which customizations fall outside support, and whether a given change could affect your support agreement.
In a managed cluster the provider runs the control plane, so extension points that touch it are limited or unavailable. Most customization happens through the API: custom resources, operators, admission webhooks, and the CNI or CSI plugins the provider allows. Your options depend on the provider's configuration model, and some settings can only be changed through its console or API.
- Confirm control plane access: list which admission, authentication, and API server settings the provider exposes to you.
- Check plugin support: verify which networking and storage plugins the provider certifies or permits.
- Plan for provider upgrades: provider-driven control plane upgrades can change behavior that your operators depend on.
- Account for node pools: node-level customization, such as custom runtimes, may require provider-specific node images.
Ask the provider for its documented list of supported extension points, its upgrade notice process, and any restrictions on webhooks or privileged workloads.
In an air-gapped cluster, every extension image, chart, package, and dependency must be mirrored into a private registry or repository before it can be installed. A plugin that pulls content at startup or fetches a schema from the internet will fail. The work includes building an inventory of artifacts, verifying them, and keeping the mirror in step with each upgrade.
- Inventory artifacts: list every container image, Helm chart, CRD bundle, and binary each extension needs, including sidecars and init containers.
- Mirror and verify: copy artifacts into the private registry and confirm their digests against the source.
- Remove runtime fetches: check that operators do not download CRDs, licenses, or telemetry configuration at runtime.
- Plan offline upgrades: each new extension version requires a new mirror cycle and a rehearsal in a disconnected staging environment.
Confirm with your distribution and each extension vendor which artifacts they publish for offline use, and how they handle certificates and signature verification without internet access.
What Kubernetes customization adds to upgrade and run costs
Every custom resource definition, operator, admission policy, network plugin or storage driver you add to a cluster creates work that continues long after the build is finished. The one-time build cost covers design, code, tests, the first deployment, documentation and hand-over training. The recurring cost covers keeping each extension working as Kubernetes and its surrounding components change. Budget for both, and ask for them to be shown as separate lines in any quote so that the run cost is visible before the build starts.
The recurring work has a predictable pattern. Each extension needs to be tested against every supported minor release, and deprecated API usage in its manifests and controller code needs to be reviewed before each cluster upgrade. Operator, plugin and driver versions must be updated when their upstream projects publish fixes or drop support for an older Kubernetes release. Base images and language dependencies need patching. Controllers and admission webhooks also need staff on call, because a failing webhook can block API requests across the cluster. Finally, someone must remain who understands the code well enough to change it.
The supported minor release window sets the minimum cadence for checking each extension. The Kubernetes project maintains the three most recent minor releases, and as of September 2026 these were 1.37, 1.36 and 1.35, with end-of-life dates of October 28, 2027, June 28, 2027 and February 28, 2027 respectively. Releases arrive roughly three times a year on a cycle of about 14 weeks. Cost rises with the number of extensions and the number of clusters, because every extension must be checked on every cluster at every minor version in use. As an illustrative example, ten extensions across five clusters on two minor versions means one hundred combinations to verify before each change window.
When requesting a quote, ask who maintains each extension after hand-over. Name the owner for every operator, webhook, CRD and plugin, and state whether that owner is your platform team, DeployOpen under a retainer, or an upstream vendor. Ask whether deprecated API reviews and version testing for each supported minor release are included in the retainer or billed separately, how many clusters and minor versions the testing covers, what on-call coverage is included, and what happens if an upstream operator stops being maintained. For the wider picture of licensing, support, platform tooling and staffing, read the Kubernetes cost of ownership and editions topic, and for the upgrade sequence itself, read the Kubernetes upgrades and support topic.
What you need to provide before customization starts
Customization work moves quickly only when the client has decided who owns each extension, what it must do, and where it will be tested. The cards below cover the inputs that DeployOpen needs in writing before scoping starts, and what usually goes wrong when one of them is missing.
A named owner for each extension
Every custom resource definition, operator, admission policy and networking or storage plugin needs one accountable person or team on the client side. That owner approves design choices, signs off on upgrades and answers for the extension when a Kubernetes minor version changes its APIs. Without a named owner, extensions pile up with no one to decide whether they are still needed, and upgrades stall while nobody can approve the fix.
Desired behaviors and enforced policies
List what each extension must do in plain terms, such as which workloads must carry a label, which image registries are allowed, or which resources a team may request. Add the policies that must be enforced and the ones that should only warn. Vague goals lead to admission rules that block legitimate deployments or let non-compliant workloads through, and the rework is usually discovered during testing rather than in the design.
Non-production cluster on matching versions
Provide access to a non-production cluster that uses the same distribution and Kubernetes version as production, with comparable add-ons and security settings. Extensions that behave correctly on a different distribution or minor version can fail on production because of API differences, webhook timing or default settings. Confirm the cluster's distribution, version and installed add-ons in writing before the first build.
Source control and CI access
Grant access to the repositories that hold cluster manifests, Helm values and existing policies, along with the pipeline that deploys them. Customization is delivered as code that must pass the same review and promotion path as the rest of the platform. Without this access, changes end up applied by hand to a cluster, and the next reconciliation or upgrade quietly reverts them.
External systems and credentials handling
List every external system an extension calls, such as a ticketing API, a secrets manager, a policy service or a cloud provider, and state how it authenticates. Agree where credentials will live, who rotates them and how they reach pods. Kubernetes stores Secrets unencrypted in etcd by default, so a credential placed in a manifest or a hook without this decision is exposed to anyone who can read it and to any backup that captures it.
Target Kubernetes minor version
Decide which Kubernetes minor version the extensions must support before design begins. The project maintains only the three most recent minor releases, so a target chosen late can already be near end of life, and an extension that depends on a deprecated API will need rework during the next upgrade. Record the target and the planned upgrade path in the scope so the build is tested against the version that will actually run.
Questions buyers ask about Kubernetes customization services
How much effort does a custom resource or operator take to build?
Effort depends on what the extension must do, not on the Kubernetes API alone. A custom resource definition that only stores configuration is a small job. An operator that reconciles state, handles failures, supports upgrades and cleans up safely is a software project in its own right. A useful estimate breaks the work into schema design, controller logic, tests against a real cluster, RBAC and packaging, documentation and handover. Ask for each line as hours or fixed deliverables in the written scope, along with the Kubernetes minor versions the work targets and whether ongoing changes are included or priced separately.
How long does a first Kubernetes extension take to deliver?
The timeline is set by scope and access, more than by code volume. The main drivers are the number of resources and controllers, how many teams must approve the design, whether a staging cluster matches production, how long security review and change windows take, and whether the extension depends on identity, storage or network work that is not yet finished. Delays often come from waiting for access or decisions rather than from building. Ask the written scope for milestones with dependencies named, the client inputs each milestone needs, and the acceptance tests that close each phase.
Can our internal team build Kubernetes extensions without outside help?
Many teams can build a first extension in house if they have a strong programming skill, prior experience with controllers, and time to own the code after handover. The harder gap is usually operational. Teams must test controllers against API changes, review RBAC and admission behavior, and plan each extension into upgrades across the three most recent minor releases. Before deciding, check who will be on call for the extension, who reviews changes, and whether the same people can rebuild it after a Kubernetes upgrade. Those answers usually decide whether a partner adds value.
What does our side need to provide before a customization project starts?
Most of the input comes from your side because the work runs in your infrastructure. Expect to provide access to a non-production cluster that matches production as closely as possible, the Kubernetes version and distribution in use, an inventory of existing custom resources, admission controllers and add-ons, and written requirements from the teams that own each workload. You will also need named approvers, your change process, access to source control and the container registry, and a decision on who receives and maintains the code. Confirm each item in the scope before work begins.
How do Kubernetes upgrades change the maintenance load of custom extensions?
Each extension adds a maintenance point at every upgrade because it depends on API versions and controller libraries that can change. Kubernetes releases come about three times a year, and the project maintains the three most recent minor releases, so an extension will be retested several times over its life. Upgrades must move one minor version at a time, with the kube-apiserver first, and kubelets may lag behind by up to three minor versions. Ask the scope to include deprecated API checks, a rehearsal in staging for each extension, image rebuilds and a named owner for each upgrade step.
Is an admission webhook safe to use in a regulated environment?
It can be, when the webhook is designed and operated as critical control-plane software. An admission webhook sits in the request path, so a failing or slow webhook can block deployments across the cluster. Plan the failure policy, timeouts, replicas, certificate rotation, exclusions for system namespaces and logging of every decision. Check first whether the built-in Pod Security Admission controller already covers the need, since it enforces the Pod Security Standards per namespace. DeployOpen prepares the controls and evidence, but independent assessors decide whether the design meets your obligations, so confirm their expectations early.
Does the written scope include support after an extension goes live?
It should be stated explicitly, because build work and ongoing support are priced differently. A fixed-scope build ends at the agreed deliverables, while support, upgrades and continuous testing can be covered by a retainer. Ask the quote to separate one-time build effort from recurring items such as upgrade rehearsals, incident response hours, dependency updates and documentation changes. Also ask who owns the source code, how releases are versioned, and how the handover will be tested. Those terms determine what your team must still carry after the first delivery.
How DeployOpen works on this
DeployOpen plans, builds, tests, documents and supports Kubernetes customizations inside your own infrastructure, whether that is your cloud accounts, data centers or air-gapped networks. Every extension is treated as a long-term maintenance commitment, so the work is scoped against the upgrade path and handed over with the evidence your team needs to run it.
How we scope
- Inventory the cluster's distribution, Kubernetes minor version and the extensions already installed before proposing changes.
- Define each custom resource, operator, admission policy, network or storage plugin, with its owner and the workloads it affects.
- Agree the written, fixed scope with deliverables and timelines before any work starts, including what is excluded.
How we build
- Build extensions in a staging cluster that matches production, with the same Kubernetes version and add-on set.
- Test admission policies and operators against the Pod Security Standards and RBAC rules your cluster already enforces.
- Check each extension's API versions against the upstream version skew rules and deprecated API lists before promotion.
How we hand over
- Deliver manifests, Helm or Kustomize sources and configuration in version control, with a documented deployment order.
- Provide runbooks for upgrading each extension alongside the control plane, including rollback steps and known version dependencies.
- Hand over test scripts and verification checks so your team can confirm each extension still works after an upgrade.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope build is delivered.
- Review extension compatibility each time your cluster moves to a new supported minor release.
- Confirm with your team which support tasks sit in the retainer and which remain with your platform engineers.
