Challenge
Your business probably does not sell Kubernetes, but once it is in production, running it becomes a steady stream of smaller jobs: alerts, failed deployments, CVE patches, access requests, and a new Kubernetes version every four months. That work competes with your product roadmap, and it tends to land on the one or two people who know the platform best.
Alerts nobody acts on
The alerts set up at launch now fire so often that people mute them, so the one which matters gets missed until a customer reports the problem.
One person who knows how
Fixes and changes wait for the one engineer who has done them before, and stall when that person is on holiday or leaves.
Incidents without a lasting fix
When something breaks, whoever is free picks it up, the fix is rarely written down, and the same failure comes back a few weeks later.
Extended support or forced upgrades
Once a cluster falls behind, EKS, AKS, and GKE charge six times the standard price for extended support, or upgrade the cluster themselves, even if your workloads still use APIs the new version removes.
Approach
You look after your applications, and we look after the Kubernetes layer underneath them: clusters and node pools, cluster networking, add-ons, and the cloud resources and pipelines around them. Our engineers handle incidents and requests during UK working hours, with response times agreed in your contract, and keep the platform patched and on a supported version.
Nobody on your side has to plan or assign the work: alerts and requests come to us, and every change we make still goes through your repositories and change process. Behind our engineers is the rest of our team, so your platform gets the experience of many production platforms, as opposed to one new hire’s.
Support starts with a review of your platform, so that both sides know what is being supported before we agree the scope and response times.
It suits a production platform with no platform team, or with a team too small to run it day to day. If your team runs the platform and needs help with one piece of work, such as an upgrade which has fallen behind, we deliver that as a defined project under Kubernetes Consulting. If you want engineers working through your own backlog, see Engineers in Your Team.
- 11+ Years
- running production container platforms
- 1 hour
- Intro call
What does managed Kubernetes support cover?
Support covers the day-two work which keeps a platform running:
Incidents
When a node, workload, or deployment fails during working hours, our engineers investigate and fix it, then write up the cause and what stops it happening again.
Alerts and runbooks
Alerts tuned so that each one needs action, backups with tested restores, and a runbook for each alert, so your own team can handle anything that happens out of hours.
Patching
Node images and add-ons patched when a CVE affects them, through your change process, without waiting for the next version upgrade.
Requests and small changes
New namespaces, access changes, and quota increases, handled as tickets, so your engineers can stay on product work.
Version upgrades
The control plane, node pools, and add-ons upgraded in the right order, with your manifests and Helm charts checked for removed APIs before each step.
The platform around your clusters
A cluster cannot be supported on its own, so support also covers the cloud networking and IAM it depends on, your Terraform, the CI / CD pipelines which deploy to it, and your monitoring stack.
What changes for your team?
Your engineers spend their time on your product, as opposed to alerts and access requests. Fixes and changes no longer wait for the one person who knows the platform, and the platform stays patched and on a supported version, before an extended support bill or a forced upgrade arrives.
Managed Kubernetes Support Roadmap
Support starts with an intro call and a review of your platform, then runs during UK working hours, Monday to Friday.
Talk
What happens:
- Talk through your clusters
- Tell us what you need covered
- Hear whether we can help
What you leave with:
- Whether support is the right fit
Review
What happens:
- Review your clusters and the platform around them
- Agree the scope and response times
- Put both in a statement of work
What you leave with:
- Agreed support scope
- Response times in your contract
Run
What happens:
- Fix incidents and handle requests
- Patch and upgrade the platform
- Keep alerts and runbooks current
What you leave with:
- Current, patched clusters
- Incidents written up
- Runbooks for out of hours
Hand back
What happens:
- Everything already in your repositories
- Runbooks kept up to date
- Your team takes the platform back
What you leave with:
- Your team runs the platform
Case studies
Managed Kubernetes Support FAQ
Ben Carter, Engineering Manager
Our cloud provider already manages Kubernetes. Why would we need support?
LiveWyer
They manage the control plane
EKS, AKS, and GKE run the Kubernetes control plane for you. Most of what sits on top is still yours to look after: node pools, add-ons such as the CNI and ingress controller, the APIs your manifests use, and your workloads, along with deciding when each upgrade happens. That is the part we support.
Priya Nair, Head of Platform
Do you provide 24/7 support?
LiveWyer
No, support runs during UK working hours
Our engineers handle incidents and requests during UK working hours, Monday to Friday, with response times agreed in your contract. We do not run an out-of-hours rota, so if you need 24/7 cover, your own on-call engineers keep it, using the alerts and runbooks we set up with them.
Sophie Turner, Head of Engineering
Do we still need our own platform engineers?
LiveWyer
Not for the day-to-day work
Someone on your side should still own decisions about the platform, such as which clusters to run and what to spend on them, and cover anything which happens out of hours. We handle the rest.
Mark Ellis, Head of Cloud Operations
Do you support platforms which do not run Kubernetes?
LiveWyer
Yes, on the same terms
We also support platforms built on Amazon ECS, serverless services, or virtual machines, during the same working hours. For Red Bee Media, we supported a serverless file delivery service on AWS Lambda, DynamoDB, and SQS for three years, then handed it to their in-house team with the documentation to run and extend it themselves.
Rachel Price, Director of Engineering
How do we buy it?
LiveWyer
Through a statement of work or G-Cloud
We agree the scope and response times in a statement of work. Public bodies can also buy through G-Cloud 15 and Digital Outcomes and Specialists 7.
Helen Murray, VP of Engineering
Can our team take support back later?
LiveWyer
Yes, everything stays yours
We work in your repositories and ticketing system, and keep the runbooks up to date, so your team can take the platform back whenever it is ready.
Book an intro call
Book an intro call of up to an hour with one of our senior engineers to talk through your clusters and what you need covered, and we will tell you whether we can help.
Book an intro call