What does a Kubernetes support contract cost?

Support is quoted per cluster per year against three variables: the tier, the number of clusters, and whether the estate is production. It is not quoted per node, per core or per seat, for the same reason the BKE licence is not — a support commitment does not become harder to keep because a cluster grew.

Do you support Kubernetes distributions other than BKE?

Yes. We support any upstream-compliant Kubernetes, which includes kubeadm-built clusters, k3s, RKE2, Rancher, and the managed control planes EKS, AKS and GKE. OpenShift is supported at the Kubernetes layer; we do not hold Red Hat's subscription on your behalf and will say so plainly rather than resell it back to you.

Is the response time a time to resolution?

No, and no honest support contract states otherwise for infrastructure it does not exclusively operate. The commitment is that a named engineer who can act is engaged with the incident within the stated time. Resolution depends on the fault, and on access we may not hold. What we do commit to is that the engineer who responds is the engineer who works it — there is no first line and no script.

Do you need standing access to our clusters?

No. Many clients grant read-only access so that an incident does not begin with a screen-sharing session, and that shortens a response materially. Where policy forbids it, support proceeds over a shared session with your engineer at the keyboard. Either arrangement is written into the contract rather than settled during the first outage.

What counts as a critical incident?

Loss of the control plane, loss of a production workload with no remaining replica, loss of persistent data, or a failure that prevents deployment of a fix to a live fault. Severity is agreed in the contract against your own service definitions, not asserted by us during the incident, which is the point at which the two parties are least likely to agree.

Can a support contract be added to a cluster you did not build?

Yes, after an assessment. We will not commit a response time to an estate we have not read, because the commitment would not be one we could keep. The assessment is a short Kubernetes consulting engagement, typically five days, and its findings are yours whether or not a support contract follows.

Kubernetes Support — Support contracts, response times and CVE patching

Engagement

On request

Quoted per cluster per year against the tier and the number of clusters. Never per node, per core or per seat.

Begin an engagement ← All services

Kubernetes support for a cluster your own engineers operate. You keep the credentials and the controls; we are the engineers you call when a cluster misbehaves, when a CVE has to be assessed, or when an upgrade needs a second pair of hands. There is no first-line script and no ticket triage queue — the person who answers is the person who fixes it.

What you get

Named support engineers, reachable by e-mail, ticket or telephone
Defined response times by severity, agreed in the contract and measured
Incident response for control plane, networking, storage and workload failures
CVE assessment against your actual cluster, with a patch path for each finding
Upgrade planning and supervised execution, including Kubernetes version migrations
Support for the Bahriya Kubernetes Engine and for upstream-compliant distributions

Ideal for

Teams who operate their own Kubernetes clusters and need senior engineers behind them, without handing over control.

The contract

Support that is an engineer, not a queue.

Most enterprise Kubernetes support is sold as a subscription entitlement. A ticket is raised, a first-line agent acknowledges it inside the stated time, and the engineer capable of reading a controller log is reached somewhere in the third handoff. The response time was met. The cluster was down throughout.

A Mamluk support contract names the engineers. The person who answers is the person who works the fault, and there is no tier of triage between your team and them. That is possible because we are a small firm that accepts support contracts against real capacity, and it is the reason we will decline one rather than oversubscribe the rota.

The contract covers the platform, not the applications on it. We will determine that a workload is failing because of a misconfigured pod disruption budget, and say so; we will not debug your Java. Where the boundary is genuinely unclear during an incident, we work the problem first and settle the boundary afterwards.

Tiers

Three levels of cover, and what each one commits to.

Every figure below is a time to engagement by a named engineer, measured from the point the incident is raised. It is not a time to resolution. Severity is agreed in the contract against your own service definitions.

	Standard	Extended	Critical
Cover	Sunday to Thursday, 09:00 to 18:00 Gulf Standard Time	Sunday to Saturday, 07:00 to 22:00 Gulf Standard Time	24 hours a day, every day of the year
Critical incident	4 business hours	1 hour	30 minutes
High severity	8 business hours	4 hours	2 hours
Normal request	2 business days	1 business day	1 business day
Channels	E-mail and ticket	E-mail, ticket and telephone	E-mail, ticket, telephone and a named escalation contact
Architecture review	Annual	Semi-annual	Quarterly
Suited to	A non-production estate, or a production estate whose own team covers its out-of-hours.	A production estate that runs beyond office hours but tolerates an overnight queue.	An estate where an outage is a regulatory or revenue event.

Support is quoted per cluster per year, and not per node, per core or per seat. A cluster that grows does not make the commitment harder to keep, so it does not change the price.

Inclusions

What the support contract covers.

Incident response

Control-plane failures, etcd degradation, node and kubelet faults, CNI and ingress failures, storage and CSI faults, certificate expiry, and the class of workload failure that is a platform failure wearing an application's error message.

CVE assessment

A published vulnerability in a component you run is assessed against your cluster rather than forwarded to you as a bulletin. The output states whether the affected code path is reachable in your configuration, what the exposure is if it is, and the patch path — including whether a version bump introduces an incompatibility elsewhere.

Upgrades

The version path from where you are to where you intend to be, the deprecated API surface your manifests still use, the order of operations, and an engineer present while it is executed. Kubernetes upgrades fail on removed APIs far more often than on the control plane itself.

Configuration review

A standing invitation to put a change in front of us before it reaches production. A network policy, a storage class, a resource quota or an admission policy is far cheaper to discuss in advance than to diagnose at the point it removes a service from the network.

Architecture review

Held annually, semi-annually or quarterly by tier. It examines what the estate has become rather than what it was designed to be, and produces a short written record of the drift, the risks it introduced, and what to do about each one.

Escalation to the people who build it

Where the fault is in the Bahriya Kubernetes Engine or in the Mamluk Enterprise Helm Charts, the escalation path ends with the engineers who wrote them. There is no upstream vendor between your incident and a fix.

Choosing

Support, or a managed service.

The two engagements are often confused during procurement, and the difference is a single question: who is on call by default. It is worth settling early, because it determines which party a regulator holds accountable for an outage.