Kubernetes for Enterprises

Kubernetes is a platform, not a deployment target

Most enterprises adopt Kubernetes for the wrong reason: a team wanted container orchestration and a vendor sold them a control plane. Eighteen months later they own a distributed operating system they never staffed for, with seventeen Helm charts nobody can read and a cluster upgrade everyone is afraid to run. The technology is sound. The adoption model was wrong. Kubernetes is not where you deploy applications; it is the substrate on which you build an internal platform, and that distinction decides whether it pays off.

At Baalvion we run the Baalvion Operating System — a multi-tenant trade infrastructure spanning commerce, finance, compliance, logistics, and intelligence — across 198 markets and 180+ jurisdictions. Kubernetes underpins large parts of that estate, but only because we treat it as an internal platform with a dedicated owner, a paved road, and explicit guardrails. The lessons below come from operating it under real regulatory load, not from a greenfield demo. They apply whether you are consolidating ten legacy VMs or, like us, orchestrating a cloud-native infrastructure that has to satisfy SOC 2 Type II and ISO 27001 auditors.

The platform team is the prerequisite, not the optimization

The single strongest predictor of whether Kubernetes succeeds in an enterprise is whether there is a platform team that owns it as a product. Not a rotation. Not a tiger team that disbands after go-live. A standing team with a roadmap, an on-call rotation, and internal customers — your application engineers — whose experience they are accountable for.

The anti-pattern is making every product team learn Kubernetes. That spreads a steep, slow-moving operational discipline across people whose job is shipping business features. The result is inconsistent manifests, copy-pasted RBAC, and a security posture that varies by team. The platform-engineering model inverts this: the platform team builds a paved road — opinionated defaults, golden Helm or Kustomize bases, a CI/CD pipeline, and a thin self-service interface (often Backstage or an internal portal) — so that a product engineer deploys by filling in a handful of well-understood fields, never by hand-authoring a 400-line YAML file.

If you cannot fund this team, you are not ready for Kubernetes. A managed PaaS or serverless platform will give a small organisation more leverage per engineer than a self-managed control plane ever will.

Multi-tenancy: namespaces, node pools, or clusters

Multi-tenancy is where most enterprise Kubernetes designs quietly fail, because the obvious choice — one big cluster with a namespace per team — is the weakest isolation boundary Kubernetes offers. Namespaces partition names and apply quotas and network policies, but they share one API server, one set of nodes, one kernel, and one control plane. A noisy neighbour, a CRD that crashes the scheduler, or a container escape is a blast radius across every tenant.

We think about isolation as a spectrum and match it to the trust and regulatory profile of the workload. Soft multi-tenancy — namespaces with strict ResourceQuotas, LimitRanges, NetworkPolicies, and per-namespace RBAC — is fine for internal teams that already trust each other. Harder isolation puts hostile or regulated tenants on dedicated node pools (taints and tolerations, or a tool like Karpenter provisioning per-tenant capacity), and the hardest tier gives a tenant a dedicated cluster entirely.

For BOS this maps directly onto data-residency obligations: a tenant whose data must remain inside a specific jurisdiction does not get a namespace, it gets infrastructure that is provably regional. This is the same isolation discipline that underpins our multi-tenant identity platform, where the cost of a cross-tenant leak is not an outage but a compliance breach. The rule we apply: namespaces isolate by convention and policy; clusters isolate by physics. Choose physics when the downside is regulatory.

Security: the cluster is an attack surface

A default Kubernetes install is not secure, and the gap between the demo and a defensible production cluster is the work most teams underestimate. The control plane, the container runtime, the supply chain, and the network are four distinct surfaces, and a compliance-first posture has to address all of them.

Every BOS workload encrypts data in transit and at rest with AES-256, and admission policy refuses anything that would weaken that baseline. The discipline that makes this scale is the same one we apply to our enterprise software generally: security is a property of the platform, enforced by automation at the API boundary, not a checklist a developer is asked to remember. If a non-compliant workload can be applied successfully, the policy has already failed.

Cost: the bill that grows in the dark

Kubernetes makes provisioning frictionless, which is exactly why it is expensive. Frictionless provisioning plus unbounded resource requests plus the human habit of padding limits produces clusters that run at fifteen percent utilisation while the invoice climbs. The orchestrator is not the cost driver; the absence of feedback is.

The first lever is right-sizing. Most teams set resource requests by guessing high and never revisiting them, which means the scheduler reserves capacity that is never used. The Vertical Pod Autoscaler in recommendation mode, or a tool like Goldilocks, surfaces the gap between requested and actual consumption — and the savings are routinely 30 to 50 percent. The Horizontal Pod Autoscaler then scales replicas to real demand, and a node autoscaler (Cluster Autoscaler or Karpenter) scales the underlying machines so you are not paying for idle nodes overnight.

The cultural point matters more than any tool: cost has to be a number a team sees next to its own services. Until spend is attributed, every optimisation is somebody else's problem. We treat FinOps as part of DevOps, not a quarterly finance exercise, because the decisions that drive the bill are made in pull requests.

When not to use Kubernetes

The most senior engineering judgement is knowing when the answer is no. Kubernetes is a powerful, general-purpose abstraction, and general-purpose abstractions carry fixed overhead that small or simple systems never amortise.

Kubernetes earns its complexity when you have many services, multiple teams shipping independently, real elasticity requirements, and the organisational maturity to run a platform. It is the right foundation for systems like ours that must scale across jurisdictions while staying auditable. It is the wrong foundation for a system that would run happily on three servers. Choosing it well is an exercise in technology consulting honesty: match the tool to the problem, not the problem to the tool you wanted to learn.

The Baalvion view

Kubernetes is neither a silver bullet nor a trap. It is infrastructure-grade machinery that rewards a platform mindset and punishes a deployment-target one. Fund the platform team, enforce isolation by physics where regulation demands it, push security to the API boundary, attribute cost to the teams that create it, and keep the discipline to say no when a simpler tool wins. Do that, and Kubernetes becomes what it should be: an invisible substrate your engineers build on without thinking about it — exactly the standard we hold ourselves to across the BOS platform.