Article
Kubernetes built from parts: what a composable distribution gives the enterprise
An organisation that buys a Kubernetes distribution is usually buying more than Kubernetes. It is buying a set of decisions that someone else has already made: which network, which ingress, which storage, which monitoring, how users log in, how images are built, and how all of it is upgraded. In most distributions those decisions are integrated into the product, and the product is sold as a whole.
The Bahriya Kubernetes Engine (BKE) is built on a different principle. It is a fixed base and a set of standard parts. The organisation chooses which parts each cluster carries, and every part it does not choose is absent. This article sets out what that means precisely, how it differs from the other distributions in common use, and why the difference matters to the people who are accountable for an estate: the enterprise architect, the CIO, and the functions that assess risk.
What “built from parts” means
The phrase is used loosely in the industry, so it is worth stating the three properties it has in BKE.
Each part is independent. BKE makes two decisions for every cluster: the
network fabric, which is Calico with WireGuard encryption between nodes, and
the Kubernetes version, pinned to the exact patch. Above that base there are
seven components, and each is enabled or left out by one line in the cluster’s
config.yaml. A component that is not enabled is not installed, and it adds
nothing to the cluster’s API, its patch schedule or its audit.
Each part is standard. Every component is an upstream project, installed from its own chart at a version BKE has tested, and mirrored so that the same version always installs the same artefact. There is no fork of Kubernetes, no proprietary resource definition, and no management plane of ours in the path of the cluster’s traffic. Two clusters installed at the same BKE version are the same cluster.
Each part can be replaced by one the organisation already owns. BKE does not assume that a component is required because the product includes it. An organisation with an enterprise log platform keeps it. An organisation with its own certificate authority keeps it. An organisation whose load balancers are already standardised keeps those too, because BKE places none of its own in front of the cluster.
| Part | BKE’s component | What can take its place |
|---|---|---|
| Network fabric and network policy | Calico, always installed | Nothing. This is one of the two decisions BKE makes |
| Ingress and API gateway | Kong | Any ingress controller the organisation prefers |
| Certificates | cert-manager | An existing certificate authority, through cert-manager or without it |
| Persistent storage | Longhorn | An existing storage array, through its CSI driver |
| Service mesh | Kuma, one namespace at a time | Istio or none |
| Log shipping | Fluent Bit | An existing logging agent |
| Monitoring | netdata, which also collects Prometheus-format metrics | An existing Prometheus or monitoring platform |
| Resource metrics | metrics-server | Any implementation of the metrics API |
| Login | OIDC against the organisation’s identity provider | Nothing is installed. The API server trusts the provider directly |
| Load balancers in front of the cluster | None | The organisation’s own |
A component that the organisation already runs can also be brought under BKE in place. Each component accepts the name of an existing Helm release, and BKE then takes over that release rather than installing a second copy beside it.
How other distributions are assembled
Every distribution in common enterprise use sits somewhere between two positions: a finished platform in which the vendor has made every decision, and a bare base in which the organisation makes all of them.
OpenShift is the clearest example of the first. A cluster is run by roughly thirty cluster operators covering authentication, the console, the image registry, monitoring, the router, machine configuration and the operator marketplace, among others. A limited set of capabilities can be left out at installation. The core cannot: the router, the Machine Config Operator and OpenShift’s own APIs, including Routes and SecurityContextConstraints, are present on every cluster. The integration is the product, and it is comprehensive. It also means that an estate gradually adopts OpenShift’s own objects, and the cost of later changing any one decision grows with each year the estate remains.
Tanzu integrates in a different direction. Its workload clusters are close to upstream Kubernetes, but their storage, load balancers, networking and identity are provided through vSphere and its surrounding products, and its additional services are delivered as Tanzu packages. The decisions are bound to the virtualisation estate, so the choice of Kubernetes platform and the choice of hypervisor become one choice.
Rancher is closer to upstream. RKE2 installs standard Kubernetes, and many of its components are recognisable upstream projects. Rancher itself, however, is a management plane that authenticates users and passes their requests to the cluster, and its projects, catalogue and continuous delivery tooling are Rancher’s own constructs above the cluster.
Managed cloud services such as EKS, AKS and GKE make their decisions through the provider’s own integrations: its load balancers, its storage classes and its identity service. Those integrations are well engineered, and they are specific to the provider.
Minimal distributions, such as plain kubeadm, k3s or Talos, take the second position. They install Kubernetes and very little else. Nothing is imposed, and equally nothing is provided: storage, ingress, certificates, logging, monitoring and their upgrades are the organisation’s own engineering work, cluster by cluster.
BKE occupies a deliberate middle position. It provides the parts that an enterprise cluster needs, and it installs, pins and upgrades them together, so that the organisation does not assemble and test the combination itself. It imposes none of them, so that the organisation’s architecture remains its own.
What it gives the enterprise architect
An architecture function exists to make decisions about the estate and to see that they are applied consistently. An integrated platform makes many of those decisions in advance, and the architecture function’s role is then largely to accept them. A composable distribution returns them to the function that is accountable for them.
The reference architecture becomes a file. A cluster’s composition is
stated entirely in its config.yaml and in the values file for each
component, all of which the organisation owns and keeps in source control. The
architecture function can write the standard once and apply it to every
cluster, and an auditor can read what a cluster carries without logging in to
it.
Different clusters can carry different parts. A cluster in a demilitarised zone, an internal cluster holding regulated data and a development cluster have different requirements. With BKE they are built from the same product with different compositions, rather than from one platform configured to suppress what each does not need.
The existing estate is respected. Enterprise architecture is rarely a blank sheet. Most organisations already operate an identity provider, load balancers, a certificate authority, a log platform and a registry, each with its own contracts, skills and controls. BKE is designed to sit inside that estate and use what is there. It does not require a second instance of a service the organisation has already decided on.
Decisions can be revisited one at a time. Because each part is independent, replacing the monitoring platform or adopting a service mesh is a change to one component, planned on its own timetable. It does not require a new platform, a new contract or a migration of everything else.
What it gives the CIO
A CIO is accountable for what the estate costs, the risk it carries, and the organisation’s ability to change it. Composability bears directly on all three.
Cost follows the decision, not the edition. BKE is licensed at a flat fee per cluster. It has no editions and no feature flags, so leaving a component out does not change the price, and enabling one later does not require a new contract. The organisation does not pay for parts it has chosen not to run, and it is never given a commercial reason to run parts it does not need.
Skills transfer. Every part is an upstream project with its own public documentation, community and pool of practitioners. Engineers who have operated Kong, Longhorn or cert-manager elsewhere can operate them on BKE, and engineers trained on BKE are trained on those projects. The organisation is not building expertise that is valid only for one vendor’s product.
Change is visible before it is made. Upgrades are classified by their effect: a patch release does not drain a node, and a jump across non-adjacent versions is refused. Before any change is applied, BKE reports which versions move, whether any node drains, whether the change can be rolled back, and what changes in each of the organisation’s own values files. Nothing is applied until the report has been read and the command is run again to commit it. This is the form a change advisory board can approve.
The cost of leaving is low. A BKE cluster is upstream Kubernetes running upstream components. If the licence lapses, the cluster continues to serve its workloads; the licence governs installation and upgrade only. An organisation that leaves BKE keeps its clusters and takes over their upgrades with the same upstream tools. A supplier that can be left at low cost must justify its renewal on its merits each year, and that is the arrangement we intend.
What it gives the risk and security functions
Every installed component is software that must be assessed, patched and evidenced. A component that is installed and unused still has a version, still receives security advisories, and still appears in a penetration test. The attack surface of a cluster is therefore not only a property of what it runs, but of what it carries.
A BKE cluster carries the upstream Kubernetes API, Calico, and the components the organisation has chosen. Each is named and pinned to an exact version, so the security function can state precisely what is installed on every cluster and assess each part against its own advisories. Credentials are held on the cluster’s own nodes and never leave the cluster. The parts the organisation already operates under its own controls, such as its identity provider and its certificate authority, remain under those controls.
The same principle above the cluster
A cluster is not yet a platform. Applications need databases, caches, message brokers, a container registry and a CI system, each with replication, backups and an upgrade path decided. The Mamluk Enterprise Helm Charts provide these on the same principle: each is a separate chart for an upstream project, the organisation installs only the charts its applications use, in the clusters that need them, and the data each service holds remains in that project’s own format. Together, BKE and the charts provide the ground an integrated platform occupies, assembled from parts the organisation can name, version and keep.
What the approach asks of the organisation
Composability is not without cost, and an organisation should weigh it before choosing BKE.
Someone must make the decisions. A finished platform relieves the organisation of choices that BKE leaves with it. An organisation without an architecture function, or without the time to exercise one, may prefer a platform whose decisions are already made. Support from Mamluk can be purchased with consulting time for this purpose, but the decisions remain the organisation’s.
Some services are deliberately outside the product. BKE provides no developer console, no build system within the cluster and no load balancer in front of it. The servers and their operating system, Debian, are the organisation’s own. These are omissions by design, and each is a service the organisation must provide or obtain.
An organisation already committed to one vendor may reasonably stay. An estate standardised on a single vendor for every layer, including the operating system, gains less from composability, because it has already chosen to make those decisions together.
For an organisation that wants its Kubernetes estate to reflect its own architecture, the case is direct: BKE provides the parts, tests them together and upgrades them predictably, and leaves the design of each cluster to the people accountable for it. The BKE website sets out each component and the documentation in full, the migration guides describe how an existing estate moves, and a 14-day trial is self-service at console.maml.uk.