Service

Kubernetes Development

Custom operators, charts, controllers and the long maintenance tail.

Engagement

Scope-priced

Engagements priced against scope — operators, charts, retainers and incident support.

Begin an engagement ← All services

When the platform you need does not exist off the shelf, we build it. We write production controllers, operators and Helm distributions, and stay on to maintain them.

What you get

  • Custom Kubernetes operators and controllers
  • Helm chart authoring, refactoring and chart libraries
  • Long-term maintenance, security patching and version migrations
  • On-call and incident support contracts
  • Bahriya Kubernetes Engine integrations and extensions

Ideal for

Engineering teams who need a small, deep partner to extend their platform, rather than contracted headcount.

The engagement

Kubernetes development is a maintenance commitment that begins with some code.

A Kubernetes controller is not a script. It is a process that holds an opinion about the state of a cluster and acts on that opinion continuously, without supervision, including during the incidents it was not designed for. Writing one that behaves during the first week is ordinary work. Writing one that behaves during an etcd degradation, a partial network failure, or a Kubernetes upgrade that removed the API it was compiled against is the part that requires people who have operated clusters and not only written against them.

We write production controllers, operators, admission webhooks and Helm distributions , and then we stay on to maintain them. The second half is not an upsell. Custom Kubernetes code written against one API version and abandoned becomes, within roughly two releases, the reason an organisation cannot upgrade its clusters — and that outcome is worse than never having built it.

The same practice produces the Mamluk Enterprise Helm Charts and the Bahriya Kubernetes Engine, both of which run in production on our own public cloud. Client work is built to the standard we hold our own distribution to, because the people are the same and the on-call rota is the same.

Capability

What we build.

Operators and controllers

Custom resource definitions with a considered API, reconciliation that is idempotent and tolerant of partial failure, status conditions a human can read during an incident, and finalisers that release what they claimed. Written against controller-runtime.

Admission and policy

Validating and mutating webhooks where a policy engine is insufficient, and the operational work around them that is usually forgotten: certificate rotation, failure policy, and what the cluster does when the webhook itself is unavailable.

Helm charts and chart libraries

Chart authoring, the refactoring of a chart estate that has been copied between teams for three years, and library charts that make a consistent deployment the path of least effort. Values schemas so that a bad value fails at install rather than at runtime.

Platform integration

The components that join Kubernetes to the rest of an enterprise: identity and single sign-on, secret management, certificate issuance, ingress and gateway configuration, backup, and the observability stack that has to see all of it.

Internal developer platforms

The tooling that makes the golden path designed during a Kubernetes consulting engagement real: templates, provisioning APIs, environment promotion, and the GitOps machinery underneath.

BKE extensions

Components added to the Bahriya Kubernetes Engine for a specific estate, packaged and versioned with the distribution so that an upgrade carries them forward rather than over them.

Method

How a development engagement is scoped and run.

  1. Step 01

    Establish that code is the answer

    A meaningful proportion of requests for a custom operator are better served by an existing project, a Helm chart and a scheduled job, or a policy in an engine already installed. We look for that first and say so when we find it. Custom software has an unbounded maintenance cost, and the cheapest line of Kubernetes code is the one that turns out to be unnecessary.

  2. Step 02

    Design the API before the implementation

    A custom resource is a public interface. Once workloads depend on it, a field is expensive to rename and impossible to remove quietly. The spec, the status conditions, the validation and the versioning strategy are agreed in writing first, and the reconciliation logic is written against them.

  3. Step 03

    Build against a cluster, and against its failures

    Unit tests against a fake client establish that the logic is correct. They do not establish that the controller survives a resource version conflict, a webhook timeout, or an API server restart mid-reconcile. Integration tests run against a real control plane, and the failure paths are exercised deliberately rather than waited for.

  4. Step 04

    Ship it as something operable

    A signed image, a chart that installs it, metrics that describe reconciliation rather than only process health, structured logs, and a runbook for each way it can fail. Software that works but cannot be diagnosed is an outage waiting for the engineer who wrote it to be reachable.

  5. Step 05

    Carry the maintenance tail

    Kubernetes deprecates and removes API versions on a published schedule, dependencies accrue vulnerabilities, and neither event announces itself to the team that inherited the code. A maintenance retainer covers version migrations, CVE patching and a contracted response for faults, and is the difference between an asset and a liability on the same repository.

Evidence

We ship this software for ourselves first.

The Bahriya Kubernetes Engine is an enterprise Kubernetes distribution we develop, license and support. The Mamluk Enterprise Helm Charts are the artefacts running the managed services on our own public cloud. Both are maintained under the same version discipline and the same on-call rota that a client engagement is offered under, and our own production estate is the first thing a mistake in either of them reaches.

Six of our projects are open source and in production. A prospective client can read how we write Kubernetes software before commissioning any.

See what we have built Discuss a build

Stack

Language
Go
Controllers
controller-runtime, Kubebuilder
Packaging
Helm, OCI registries
Delivery
GitOps, signed images
Testing
Against a real control plane
Ownership
Yours, on payment

Questions

Common questions about Kubernetes development.

How is Kubernetes development priced?
Against scope, not by the day. A controller with a defined API and a defined reconciliation behaviour can be estimated honestly; a day rate on the same work transfers the estimating risk to you and gives us no reason to be efficient. The estimate is broken into deliverables with acceptance criteria, and a change to the scope is a change to the estimate rather than a change order.
Who owns the code you write?
You do, on payment, including the repository history and the build pipeline. We ask for one exception, and only when it applies: where a piece of the work is a general-purpose component with no relationship to your business, we may ask to keep it open source and contribute it upstream. That is a request, not a clause, and the engagement proceeds either way.
What language do you write operators in?
Go, using controller-runtime and Kubebuilder, because that is what the ecosystem is written in and what your next engineer will expect to read. We will write a controller in another language where an existing codebase makes it the right answer, and we will say plainly that it narrows the pool of people who can maintain it.
Do we need an operator, or will a Helm chart do?
A Helm chart installs software. An operator operates it — it acts on events after installation, which is worth building only when something must happen in response to cluster state without a human present. If the answer to "what does it do on Tuesday at 3am" is "nothing", a chart and a well-written job are the cheaper and more maintainable answer, and we will say so before quoting.
Will you maintain what you build?
Yes, and we would rather. A Kubernetes controller written against one API version and left alone becomes an obstacle to upgrading the cluster within about two releases. Maintenance is contracted as a retainer covering dependency and Kubernetes version migrations, CVE patching, and a defined response for faults in the code we wrote.
Can you extend the Bahriya Kubernetes Engine?
Yes. BKE integrations and extensions are part of this service — additional components, custom operators packaged for the distribution, and modifications to the chart set. Because we build BKE itself, an extension can be designed against its internals rather than around them.
Do you take over an operator someone else wrote?
Frequently. It begins with a short assessment of the code, its test coverage, its API compatibility and its dependency position, and an estimate of the work to bring it to a maintainable state. We will not put a support commitment behind code we have not read, and occasionally the assessment concludes that a rewrite is cheaper than a rescue.

The rest of the practice

Development is one of five ways to engage us.

The same engineers deliver all five. Most engagements begin as one of them and become another once the estate is understood.

Enterprise Architecture as a Service

A senior architect on call, paid for by the day.

Read the engagement model →

Kubernetes Consulting

Strategy, architecture and platform design for Kubernetes done properly.

Read the engagement model →

Kubernetes Support

A Kubernetes support contract with named engineers and a defined response time.

Read the engagement model →

Managed Kubernetes on Premise

A fully managed Kubernetes practice running inside your own data centre, on BKE.

Read the engagement model →

Small teams. Plain contracts. Real architects.

Talk to us Back to services