Our offerings
What Day Two Actually Costs
A short session, open to anyone
The work a cluster needs once it is live, and the failures we see most often in our support work, with a one-page health check of your own cluster to take away.
- Recording coming soon
- Live on request
- Nothing to install
Modular training for your team
Four one-day modules, each sold on its own
Running, upgrading, protecting, and right-sizing your cluster. Each is a full, hands-on day on your non-production cluster, so your team leaves with the work committed to its repositories.
- One day per module
- On site or remote
- On your own cluster
Our engineers alongside yours
For teams that would rather not do it alone
Once the team is trained, our engineers can work alongside it on the same day-two work: upgrades, restore tests, and failure drills, using the runbooks the modules produce.
- Alongside your team
- Upgrades and drills
- Your own runbooks
The free session in detail
What Day Two Actually Costs
What running a cluster involves once it is live, and where yours stands.
- Format
- Recording coming soon, live on request
- Level
- Intermediate
- Your cluster
- No
- Price
- Free
A Kubernetes cluster keeps costing effort long after it is built. There is a new version every few months, backups nobody has restored, alerts nobody answers, and resource requests nobody set. None of it shows on the day the cluster goes live, and most of it shows during the first serious incident. In this session, the engineers who do that work for our clients every week walk you through it. We cover ten questions about running a cluster, which you take away as a one-page health check to fill in for your own. Then we go through the failures we see most often in our own support work, and where each one starts. A talk-through rather than a workshop, with demos shown as videos, open to managers as well as engineers.
You will be able to
Say where your cluster stands on ten questions about running it, and which answers you are least sure of
Name the failures that most often catch teams out once a cluster is live, and the early sign of each
Decide what to fix first, from your health check
Setting it up
Nothing at all, not even an install
The free session, coming soon
Tell us where to send it and we will email it to you as soon as it is ready. If you would rather have the session given live, to your team or at your event, then let us know and we will arrange a date.
The modules in detail
| Module | Length | Where | Your cluster | Who it is for | Price |
|---|---|---|---|---|---|
Operations Running Your Cluster | 1 day | On site / remote | Yes | Teams running a cluster they did not all build | On request |
Upgrades Upgrading Your Cluster | 1 day | On site / remote | Yes | Teams with an upgrade due or overdue | On request |
Resilience Protecting Your Workloads | 1 day | On site / remote | Yes | Teams putting workloads with data into production | On request |
Cost Capacity and Cost | 1 day | On site / remote | Yes | Teams whose cluster bill has grown faster than the work on it | On request |
The free session is the starting point, and is open to anyone who runs a cluster, or is about to. The four modules can be taken in any order, and each assumes everyday kubectl use; the tutorials in the Kubernetes documentation cover the basics for anyone less sure. vSphere teams new to Kubernetes should start with vSphere to Kubernetes Skills Transfer.
Running Your Cluster
Know what runs on your cluster, who can touch it, and where to look when it breaks.
- Length
- 1 day
- Format
- On site / remote
- Hands-on
- 4.5 hrs
- Level
- Intermediate
- Your cluster
- Yes
- Price
- On request
Most clusters have been changed by more people than have ever mapped them. Workloads arrive through Helm, through a GitOps controller, and by hand; bindings outlive the people they were made for; and a database sits on a volume that is deleted along with its claim. None of it shows until an incident, and an incident starts with the same two questions: what is this, and who owns it? On your non-production cluster, we map what is running and who owns it, find who can do what, and find every volume that would lose its data if the wrong thing were deleted. Then the team practises a triage order on faults we seed in our sandbox, and turns it into a runbook for your cluster, built from your recent incidents.
You will be able to
Produce a map of what runs on your cluster, who owns it, and what deploys it, and regenerate it whenever you need to
Say who holds cluster-admin and which service accounts can read secrets, and remove a permission nobody needs
Find every volume that would lose its data if its claim were deleted, and decide what to do about each one
Work out why something is not running, in a fixed order, whatever an assistant suggests
Use a triage runbook written for your cluster in the next incident
Setting it up
A non-production cluster that resembles production, with read access for each attendee
A repository to commit the day's work to
Upgrading Your Cluster
Find what the next upgrade will break, fix it, rehearse it, and write down how to do it in production.
- Length
- 1 day
- Format
- On site / remote
- Hands-on
- 3.5 hrs
- Level
- Intermediate
- Your cluster
- Yes
- Price
- On request
Kubernetes releases a new minor version about three times a year, and supports each for about fourteen months, so a cluster nobody upgrades falls out of support within a year or so. Teams put upgrades off because the last one broke something: an API that had been removed, an add-on that no longer fitted, or a node drain stuck behind a disruption budget. Every version skipped makes the next upgrade bigger, because the control plane moves one minor version at a time. On your repositories and non-production cluster, we find what the next upgrade will break and fix it, work out what a drain will do to each workload, and upgrade the cluster by one minor version end to end. The day finishes with the runbook for doing the same in production.
You will be able to
Say when each of your clusters falls out of support, and what that costs on your provider
Find every deprecated and removed API in your repositories and your live cluster, and fix them before they block an upgrade
Put your add-ons in an upgrade order that keeps each one compatible at every step
Predict what a node drain will do to each workload, and fix what would stop it or cause an outage
Upgrade a cluster by one minor version, and run the runbook you wrote for production
Setting it up
A non-production cluster that can be upgraded by one minor version on the day
The repositories that hold its manifests, charts, and cluster code
Protecting Your Workloads
Back it up, watch it, and know what happens when a node goes, before production finds out for you.
- Length
- 1 day
- Format
- On site / remote
- Hands-on
- 4 hrs
- Level
- Intermediate
- Your cluster
- Yes
- Price
- On request
A cluster runs workloads perfectly well with no backups, no alerts, and nobody knowing what happens when a node goes. None of those come with a cluster, whoever built it, so a lot of teams have some of each and have tested none of them. On your non-production cluster, we back up one of your own workloads off the cluster, delete it, and restore it, then check the application rather than the status. We read its performance from your metrics, build an alert with somewhere to go and a runbook behind it, and take a node away to see what recovers on its own and what needs a person. Then the team turns the day into the routine it runs from then on.
You will be able to
Back up one of your workloads and its volumes off the cluster, and restore it after deleting it, checking the application rather than the status
Explain why a snapshot is not a backup, and what quiescing the application adds to one
Read a workload's performance from your metrics, and the queries behind each chart
Turn a condition into an alarm with somewhere to go and a runbook behind it
Say what recovers on its own when a node is lost, how long it takes, and what needs a person
Plan your team's routine for backups, alerts, and failure drills
Setting it up
A non-production cluster with workloads that hold data, and agreement to take one of its nodes away
Object storage for backups, or your own backup product
Capacity and Cost
Find what your cluster pays for and does not use, prove it can go, and show each team its share.
- Length
- 1 day
- Format
- On site / remote
- Hands-on
- 4 hrs
- Level
- Intermediate
- Your cluster
- Yes
- Price
- On request
Most clusters cost more than the work on them needs. Requests are set once, copied from a template, or never set at all. The scheduler reserves whatever is requested, so nodes fill up on paper while they sit half idle, and the node autoscaler adds nodes for requests rather than for use. From your own metrics, we compare what each workload requests with what it uses, and put a price on the gap. Then the team right-sizes a handful of workloads in non-production with the evidence that nothing suffered, autoscales one on load, finds what stops the nodes scaling down, and builds a cost per namespace so each team can see its share.
You will be able to
Explain how requests and limits decide scheduling, throttling, out-of-memory kills, and the bill
Find the workloads that request most above what they use, from your metrics, and put a price on the gap
Change requests with evidence, and show that nothing was throttled or ran out of memory
Autoscale a workload on load, and find what stops your nodes scaling down
Show what each namespace costs, and keep it accurate with labels
Setting it up
A week or more of usage metrics, read-only on production
A non-production cluster where requests and autoscaling can be changed
The price of each node type, or the cloud bill
Once the cluster is live
Once a cluster is live, most of the work is in running it: a new Kubernetes version about three times a year, backups that have never been restored, alerts that reach nobody, and resource requests that nobody set but which decide the size of the bill. Self-paced courses cover how Kubernetes works. This training is about your cluster, such as finding the API your next upgrade removes, or the volume that would lose its data if the wrong claim were deleted.
Teams we have trained
We have run Kubernetes training for engineering teams at companies including Maersk, JCDecaux, AJ Bell, Vonage, and Numatic. At Leaseweb, a five-day bootcamp prepared 25 engineers to support its new managed Kubernetes service product.
Our work with Siemens began with Kubernetes training at Mentor Graphics, now part of Siemens. Siemens Digital Industries went on to run its core infrastructure on a multi-cloud Kubernetes platform which we designed and built, then supported for six years, by which point it had grown to 200+ clusters across AWS, Azure, and VMware on premises.
Does this sound like your team?
Platform teams running Kubernetes day to day
On EKS, AKS, GKE, or a cluster you built yourselves, with little time to do more than keep it running
Teams that inherited a cluster
From a contractor, a consultancy, or a previous team, with more running on it than anyone has documented
Teams with an upgrade due
Approaching the end of standard support, or still recovering from the last upgrade
Teams putting data into production
About to run stateful workloads, with backups and alerts that nobody has tested
Teams asking what the cluster costs
Watching the bill grow faster than the work on it, with no way to show what each team uses
How the modules run
Six to ten engineers from one team per module, so everybody works at their own keyboard
Your own laptop, with your normal toolchain and kubectl
A non-production cluster that resembles production, agreed on a short call before the day
Nothing runs against production; Capacity and Cost reads production's metrics, read-only
The modules are designed for teams already using kubectl day to day. Start with the free session if you are not sure where your cluster stands
Talk to a specialist
Interested in running Kubernetes in Production with your team? Book a quick chat with one of our team to find out more.
Talk to a specialist