Kubernetes your teams can run without fear
Build or repair Kubernetes platforms on EKS, AKS, GKE or self-managed clusters, with multi-tenancy, policy, safe upgrades and the add-ons your teams depend on.
Overview
Many Kubernetes clusters were set up quickly and then left alone. Upgrades get skipped because nobody is sure what will break, add-ons are several versions behind, and every team has admin rights because tenancy was never designed.
We build new clusters or take over existing ones and make them dependable. That means a clear tenancy model, admission policies, ingress and certificates that renew themselves, autoscaling that matches your workloads, and an upgrade process your team has practised. Managed or self-managed, the design is written down and the clusters are built from code.
Signs you need this
- A cluster upgrade has been postponed more than once
- Developers use cluster-admin because there is no other working role
- Pods are evicted or nodes run out of memory under normal load
- Ingress, DNS and certificate setup differ between clusters
What you get
- Cluster design
- Node pools, networking, tenancy, storage classes and add-ons, documented with the reason for each choice.
- Clusters in code
- EKS, AKS, GKE or self-managed clusters built with Terraform and bootstrapped with GitOps, so a new cluster comes up the same way.
- Tenancy and access
- Namespaces, RBAC roles mapped to your identity provider, resource quotas and network policies per team or customer.
- Policy enforcement
- Kyverno or OPA Gatekeeper rules for image sources, resource limits, privileged pods and required labels.
- Upgrade runbook
- A tested process for control plane, node and add-on upgrades, including deprecated API checks before each one.
- Autoscaling setup
- Karpenter or Cluster Autoscaler plus pod autoscaling tuned to your workloads and their real resource use.
How the work runs
- 1
Review
1 to 2 weeks
Inspect existing clusters or requirements, check versions and deprecated APIs, and agree the target design.
- 2
Build or rebuild
3 to 6 weeks
Create clusters from code, install core add-ons through GitOps, and set up tenancy and policy.
- 3
Workload onboarding
2 to 4 weeks
Move or adjust workloads to the new setup, fix resource requests and probes, and check behaviour under load.
- 4
Upgrade drill and handover
1 to 2 weeks
Run a real upgrade with your team following the runbook, then hand over ownership.
Timings depend on the size of your estate. The assessment fixes them before any build starts.
What you can check afterwards
- Clusters run a Kubernetes version within upstream or provider support
- Each team has scoped access with no shared cluster-admin accounts
- Admission policies reject non-compliant workloads at deploy time
- Your team has completed one upgrade using the written runbook
Tools we work with
- Amazon EKS
- Azure Kubernetes Service
- Google Kubernetes Engine
- kubeadm
- Talos Linux
- Cilium
- Karpenter
- Kyverno
- cert-manager
- ingress-nginx
- External Secrets Operator
- Helm
From our work
North American clients, delivered by the OpsBreak team
Running self-hosted platforms for clients
Self-hosted platforms kept running, patched and monitored
Questions buyers ask
- Should we use managed Kubernetes or run our own?
- Managed is the right default for most teams. Self-managed makes sense when you need a provider without a managed offering, specific hardware, or strict control of the control plane.
- Will the upgrade cause downtime?
- Not if workloads have proper disruption budgets and replicas. We check those first and fix them before the upgrade, which is most of the risk.
- What access do you need?
- Admin access to the clusters and cloud account, plus your infrastructure and deployment repositories. Changes go through pull requests your team can review.
- What happens after the engagement?
- Your team owns the clusters with the runbooks and code we leave. We can continue with business-hours support or scheduled upgrade help if you want it.
Talk to us about Kubernetes platform engineering.
Tell us what you run and where. We reply within one business day with questions or a quote.