What's included
Every component, named. And what BKE deliberately leaves out.
A distribution is a set of promises about which versions work together. This page is the list of what BKE promises about, and — just as plainly — what it does not.
The base
Upstream Kubernetes, and the fabric under it.
Every cluster gets upstream Kubernetes — no fork, no proprietary CRDs — with Calico as the network fabric, WireGuard encryption for pod traffic, and containerd as the runtime, each pinned to an exact patch tested together. These are the two decisions BKE makes, fixed for the life of the cluster.
Which exact versions a release pins is stated in that release's notes, in the console.
The components
Seven components, each opt-in, one line each.
Kubernetes alone runs containers. It does not give you storage, a way in for outside traffic, certificates, logs or monitoring. BKE installs those as components — each a well-known open-source project, pinned to versions tested together, enabled per cluster in one file. Enable what you need and leave out what you do not.
| Component | What it does for you |
|---|---|
| Longhorn | Replicated block storage — persistent volumes for applications that keep data, with backups to an object store you name. |
| Kong | Ingress and API gateway — routes HTTP traffic from outside the cluster, with rate limiting, caching and access control as declared plugins. |
| cert-manager | Obtains and renews TLS certificates. |
| Kuma | Service mesh — optional traffic control between applications; installing it changes nothing until a namespace opts in. |
| Fluent Bit | Collects logs from every node and ships them to a destination you choose. |
| Netdata | Per-node monitoring with per-second resolution — metrics and dashboards. |
| metrics-server | Resource figures — makes kubectl top and autoscaling work. |
There are no editions and no feature flags. The licence gates BKE, not parts of it — there is no per-component entitlement anywhere in the product, and no upsell waiting behind a setting.
Security controls
The controls an auditor asks for, on by default, each a switch.
Security frameworks and regulators ask the same things of a Kubernetes platform. BKE applies them to every new cluster, and each can be turned off in config.yaml where your own tooling already provides it.
| Control | What it does for you |
|---|---|
| Secret encryption | Secrets are encrypted before they are written to etcd, so a disk, snapshot or backup does not carry them. The key is generated on your cluster and never sent to us, and it can be rotated. |
| Audit logging | Every control-plane node records who did what through the Kubernetes API, without writing the contents of a Secret, ready to forward to your SIEM. |
| Pod Security | A new cluster enforces the baseline standard and warns at restricted, so a workload asking for host access is refused unless its namespace is exempted. |
| Hardening | TLS 1.2 or later with modern ciphers on the API server and every kubelet, profiling off, and anonymous requests limited to the health checks. |
| Signed images | Every image BKE installs is signed, and the public key is published, so you can verify each one or require signatures in an admission policy. |
| Host firewall | Calico enforces a firewall on every node and filters who may reach NodePorts. It is off until you turn it on, because it must name your own networks. |
| A record for auditors | A ConfigMap in the cluster records which controls are configured and which are observed in force, for a compliance tool or an auditor to read. |
Compliance and hardening and Encryption at rest describe each control, and how to turn one on or off on a cluster that already exists.
Interfaces
A terminal interface on the control plane, and web interfaces for storage and monitoring.
k9s, on every control-plane node.
A terminal interface to the whole cluster: workloads, logs, events and every resource, browsed and acted on from one screen. BKE installs it on each control-plane node, where it reads the administrator kubeconfig that BKE places there.
Longhorn and Netdata, in the browser.
Longhorn's web interface shows volumes, replicas and backups; Netdata's shows per-second metrics from every node. Both are reachable only from inside the cluster until you choose to publish them, because an administrative interface should not be on a network by default. The docs show how to open Longhorn's and Netdata's.
A desktop client, if you want one.
BKE does not include a graphical desktop console. Teams that want one can download Lens, a desktop application from its own vendor and under that vendor's terms, and connect it with the same kubeconfig they use for kubectl. BKE is upstream Kubernetes, so any Kubernetes client works with it.
Deliberately not included
Three things BKE will not decide for you.
Your load balancer.
The addresses in front of a cluster are your infrastructure. The reference architecture gives working configurations to start from.
Your certificate issuer.
An issuer names things that are yours — your domains, your DNS provider, your registration email. You create one once; the docs show how.
Your log destination.
BKE decides what is collected; you decide where it goes. Until you do, nothing is shipped. Worked examples cover OpenSearch, Loki and object stores.