Platform engineering on upstream Kubernetes: keep the freedom, add the support

Why upstream matters

Most Kubernetes decisions are really decisions about who you will depend on in three years. A commercial distribution can get a cluster running quickly, but it often brings its own resource types, its own installer and an operating system you are expected to keep. Those choices are easy to make and expensive to reverse.

We build platforms from upstream projects that have not been forked. That means the Kubernetes you run is the Kubernetes the community ships, and the tools around it are open source projects your engineers can read, test against and hire for. If you decide to change who supports the platform, you change the support arrangement. You do not rebuild the platform.

Freedom is not the same as being on your own

Open source gives you control, but control without support is a risk for any organization running critical workloads. A bank, a hospital or a public agency cannot wait for a forum thread when a node will not rejoin the cluster at two in the morning.

This is the gap that k8s.ng, our sub-brand for internal developer platforms and cloud native enterprise support, exists to fill. It gives you an accountable engineering team for the projects underneath your platform, covering security hardening, integration and lifecycle management. The scope of cover is agreed with you and written down, so both sides know what is included.

What a dependable platform is made of

A platform is a set of decisions about layers. A typical build looks like this:

• Talos Linux as an immutable operating system, managed through an API instead of by logging in to servers.
• Flux for GitOps, so the cluster follows what is stored in Git.
• Kyverno for policy as code, checking workloads before they are allowed to run.
• FreeIPA for central identity and access control.
• Rook-Ceph for replicated storage, Kafka for streaming and PostgreSQL as a database service.

This is a selection from the CNCF landscape we support, not a fixed bill of materials. If your estate runs something else, we start by asking whether we can support it, not by asking you to replace it.

GitOps as the operating model

The most useful property of this stack is that every change is a commit. A new namespace, a policy update, a version upgrade: each one is proposed, reviewed and merged in Git, and Flux applies it. The history of the platform is the history of the repository.

That gives security and audit teams something they rarely get from infrastructure, a readable record of who changed what and why. It also makes rollback a routine operation rather than an emergency. When something goes wrong, the question is simply which commit to revert.

An internal developer platform on top

A well-run cluster still does not help a development team that has to raise a ticket for every new environment. The other half of k8s.ng is our internal developer platform (IDP), which sits on top of Kubernetes and turns the platform team’s decisions into something engineers can use directly.

In practice that means golden paths for building and shipping a service, self-service environments and platform APIs. Your platform team sets the guardrails once: which images are allowed, which policies apply, how secrets are handled. Developers then move quickly inside those guardrails without waiting for anyone.

A platform is working when the secure way to ship is also the easiest way to ship.

Wherever it needs to run

Because the platform is built on upstream projects, it behaves the same way wherever it is deployed. We build on AWS, Azure and Google Cloud, in your own data centre, or across a hybrid of them. Regulated organizations often keep some workloads on their own hardware and place others in a public cloud, and the same GitOps repository and policies can govern both.

Questions worth asking any platform provider

Before you commit to a platform, whether ours or anyone else’s, ask:

• Is every component upstream and unforked, and can I see the source?
• If I end the support relationship, what do I keep, and does it still run?
• Who do I speak to when something breaks, and are they the engineers who built it?
• How are changes recorded, reviewed and reversed?
• What does the support scope cover, and what does it leave out?

Good answers are specific. Vague ones usually mean the dependency sits somewhere you cannot see it.

Where to start

Start with a conversation about your current estate and what the platform needs to do. We can review an existing cluster, its delivery pipeline and its security posture, then propose an architecture and a plan you can examine before any build work begins.