Technology
Clusters your teams can ship to without a ticket
Most clusters grow one team and one exception at a time. We set up GitOps, autoscaling, policies and an upgrade routine so the platform stays predictable as more teams move onto it.
- Duration
- 4 to 12 weeks per stage
- Model
- Staged programme
- Output
- GitOps-managed clusters and golden paths
Signs you need this
Each of these can be seen in the cluster, the Git history or the cloud bill.
- Changes reach the cluster through
kubectlfrom a laptop, so production no longer matches Git. - Cluster upgrades are postponed until the version nears end of support, then done in a rush.
- One team’s workload starves others because requests and limits are missing or copied from an old example.
- Pods scale on CPU while the real signal is queue length, and new nodes arrive after the spike has passed.
- Any pod can talk to any other pod, and containers run as root because nobody set a default.
- Each team keeps its own Helm charts and pipelines, and a new service takes a week of copying.
- Nobody can say what a namespace or a team costs, so the cluster bill is argued about rather than managed.
A cluster is not a platform
Kubernetes gives every team the same API and very few defaults. Without shared decisions on tenancy, resource requests, network rules and how changes are applied, each team fills the gaps its own way. The cluster works, but every upgrade, incident and new service costs more than the last.
The obvious fixes are a cluster per team or a new platform built from scratch. The first multiplies upgrades and cost; the second stops delivery for months. We work on the running clusters instead: GitOps with Argo CD or Flux so Git is the only way in, autoscaling on the real signal with HPA, KEDA and Cluster Autoscaler or Karpenter, network policies and Pod Security Standards applied namespace by namespace, and an upgrade routine that makes each minor version a planned event.
Cloud and Platform Engineering builds the wider platform: accounts, networks, infrastructure code and delivery pipelines. This service is about the Kubernetes layer itself and the paths teams use to run on it.
What is included, and what is not
Included
- Cluster topology and tenancy: what shares a cluster, a node pool or a namespace
- GitOps with Argo CD or Flux, with drift detection and promotion between environments
- Autoscaling with HPA, KEDA and Cluster Autoscaler or Karpenter, tuned to the real signal
- Network policies, Pod Security Standards and admission policies as defaults
- Upgrade strategy and a tested runbook for control plane, nodes and add-ons
- Golden paths: a service template, base manifests and a pipeline teams use without help
- Cost visibility per namespace and team, with requests sized from real usage
Not included
- Rewriting applications to run on Kubernetes
- Cloud accounts, networks and landing zones outside the cluster
- Running the clusters on call after handover
- Reselling licences for commercial Kubernetes distributions
How the work runs
- Weeks 1 to 2Read the clusters. With read-only access to clusters, Git repositories and billing data, we record versions, add-ons, tenancy, policies, autoscaling settings and how changes reach production. Findings are ranked by risk.
- Weeks 3 to 6Put Git in charge. Argo CD or Flux takes over deployments namespace by namespace, starting with the least critical. Manual changes show up as drift, then stop.
- Weeks 5 to 10Add guardrails. Pod Security Standards and admission policies start in audit mode and are enforced once reports are clean. Network policies and resource defaults roll out namespace by namespace; autoscaling is tuned with load tests.
- Weeks 8 to 12Pave the path. The patterns become a golden path: a template, base manifests and a pipeline. The first team that ships with it without help marks the end of the stage.
- ThroughoutKeep access narrow. Access is read-only by default. Any write access needed to install tooling is removed when the stage ends.
What you get
All outputs belong to you: code, reports, diagrams and their source files, kept in your repositories.
When this is not the right service
- A single application with steady traffic. A managed container service or a few virtual machines is usually simpler to run.
- Organisations whose main goal is a smaller cloud bill across all services. Cloud Cost Optimisation looks beyond the clusters.
- Organisations that want a provider to run Kubernetes for them. We set up the platform with your team and hand it over.
Frequently asked questions
Which distributions and versions do you work with?
Managed services such as EKS, AKS and GKE, and self-managed upstream Kubernetes. Upgrades follow the three minor releases the upstream project supports and your provider’s own calendar.
Argo CD or Flux?
Both are mature CNCF projects. Argo CD comes with a web interface that many teams find easier to adopt; Flux is lighter and composes well with existing tooling. If you already use one, we keep it.
Will enforcing policies break running workloads?
Not if it is done in order. Policies start in audit or warn mode, the reports show which workloads would fail, and teams fix them before enforcement is switched on, namespace by namespace.
How do monitoring and on-call fit in?
We make sure the cluster exposes the signals that matter, such as saturation, pending pods and failed rollouts. Service level objectives, alerting and incident practice belong to Observability and SRE.
What happens after the stage?
Your team runs the clusters with the runbooks, and write access is removed. For support through your first upgrade alone, an embedded architect can work with the team 2 to 3 days a week.
Start with a short technical conversation
Thirty minutes. You describe your clusters and teams, and the architect who would run the work tells you where we would start.