Written down once,
kept that way
We set up and look after Kubernetes clusters, with every change made one reviewed way, limits on what each workload can use and reach, and upgrades on a schedule, so what runs is what you wrote down.
Thanks, we’ll be in touch soon.
{{ heroStatus }}
You’re in good company
A few of the companies we’ve worked with.
When the cluster is changed from more than one place
A Kubernetes cluster is a group of machines that run your software together. It works from what it’s told: written descriptions of what should run and how, such as which version of a service to run and how many copies of it to keep, each copy a running instance on one of the machines. Whatever runs there, a service, a job or a website, is a workload.
Those descriptions can be changed in more than one way: a command typed by hand, a file applied from someone’s laptop, or a pipeline that applies the files kept in the repository. The project’s documentation advises managing each object, each thing the cluster keeps, with one technique only, and warns that mixing them “results in undefined behavior”.
So a change made by hand can sit in the cluster with no file that says so. Depending on how the files are applied, the next change from the repository may undo it or leave it in place: a copy count changed by hand, for one, is put back the next time its file is applied.
None of this stops a cluster from running. What helps is one reviewed way in for every change, and a clear view of what’s running set against what’s written down.
What we build
Each cluster is set up for the work it holds, with its files in the repository and every change reviewed and checked in CI before it’s applied.
Clusters set up for what you run
Clusters on a cloud’s managed service or on your own machines, laid out for the workloads they hold and defined in code, so each one can be built again the same way.
Services moved across, one at a time
Each service moved onto the cluster on its own, tried on a copy of the cluster first, with the old setup answering until the new one does the work.
One way in for every change
The cluster’s files kept in the repository, reviewed, checked in CI and applied the same way every time, from one place.
New versions, a few copies at a time
Each new copy counts as available only once it’s ready, the old copies stay until enough new ones are, and a version that never gets there stops rolling out, so it can be rolled back.
What each workload may use and reach
Requests and limits for what each workload may use, network policies for what it may reach, and the Pod Security Standards for how it may run, each set for that workload and checked in review.
Upgrades on a schedule
Each minor release in turn, the APIs it removes found in the files first, and the add-ons, the parts that do jobs beside the cluster such as routing traffic in, kept current too.
Watched once it’s running
Logs, metrics and alerts that show what restarted and why, read with the team that runs each service.
Room and costs that match what runs
Requests set from measured use, machines sized to fit, and each team’s workloads labeled with its name, so the costs have owners.
AI where it helps
Changes drafted by AI coding assistants, to a service or to the cluster’s files, tested and reviewed by a person before they reach a cluster.
- Clusters on a cloud’s managed service, built on AWS:Software development
- On the Microsoft Azure cloud:Software development
- With Google Cloud services:Software development
- The pipelines and operations around the clusters:Cloud, DevOps & Security
- Internal platforms and the templates your teams share:Platform Engineering
- A security review of the services you run:Application Security
- The code that sets your clusters up:Infrastructure as code
- Engineers in your own team:Engineers for your team
What you write down, it keeps
You write down what should run, and how many copies of it, and the cluster works to keep it that way. In the project’s terms, you describe the state you want, and the cluster changes what’s running to match it, at a controlled rate.
When a copy stops, for whatever reason, the cluster starts another to bring the count back to what’s written, on a machine with room for it, and not always the one the old copy was on.
So what’s written down matters most: the cluster keeps a missing limit or an old setting as faithfully as a good one.
So we review what’s written before it reaches the cluster, and check the cluster against it.
Press a copy to stop it, and watch the cluster start another to match.
Color matcher at Pemberton Paints
Written down
Color matcher
Copies: three
Each copy: a small share of one machine
Machine
{{ kpLine }}
{{ kpSay }}
Moved up a release at a time, the parts around it too
The Kubernetes project publishes new minor releases a few times a year and patches each one for a set period, with every end-of-life date published ahead on its releases page.
An upgrade can remove APIs, the versions of each kind of object a cluster accepts, that older files still use. The project’s Deprecated API Migration Guide lists them release by release, with the newer version to move each file to.
The add-ons around a cluster have lives of their own. The Ingress NGINX controller, one way of routing traffic into a cluster, was retired in March 2026 and gets no further fixes. Existing installs keep working, and the project recommends Gateway API, which it calls the modern replacement for Ingress, or another Ingress controller; as its committees say, none of the alternatives is a direct drop-in replacement.
A cloud’s managed service follows its own calendar for each release, so its dates can differ from the project’s.
So we upgrade one minor release at a time, as the project’s version policy requires of the parts that run a cluster, on a copy of the cluster first, with every file checked for removed APIs before each step.
Start with what’s running, and what’s written down
The review covers the releases in use: the parts that run the cluster, the machines, and each add-on; how changes reach the cluster today, who applies what, and from where; the files in the repository, set against what’s running, and anything changed by hand; requests and limits, and which workloads have none; network policies, and whether the cluster’s network plugin enforces them; the Pod Security Standards set for each team’s part of the cluster; who holds rights across the whole cluster; how the passwords and keys your services use are kept, and whether the cluster encrypts them at rest, which it doesn’t by default; the Ingress controller in use, and whether it’s Ingress NGINX; the APIs the next release removes that the files still use; what’s saved of the cluster’s state, and how it would be rebuilt; logs, metrics and alerts; and room and costs, with requests set against measured use.
The first step is one of these, each tried on a copy of the cluster first: one service’s files moved into the repository and applied only from CI; requests and limits set from measured use for one team’s part of the cluster; network policies for one team’s part, starting from what it needs; a replacement for Ingress NGINX tried for one route; or the next minor upgrade, with the files checked for removed APIs first.
What you receive is a written review and a proposal for that first step.
Questions worth asking
Do we need clusters like these at all?
Not always. For a few services, a simpler way to run them often does the job, and we’ll say so. Kubernetes clusters help most when many services, teams or environments share one way of running.
A cloud’s managed service, or our own machines?
We decide it with you, one system at a time. A cloud’s managed service runs the parts that run the cluster for you, to an extent that varies by service, and follows its own calendar for each release; your own machines suit work that has to stay on them.
Can you take over a cluster someone else set up?
Yes. We start with the review above, then change one part at a time, each change tried on a copy of the cluster first.
How often do we need to upgrade?
The Kubernetes project publishes new minor releases a few times a year and patches each one for a set period, with each end-of-life date published ahead. A cloud’s managed service follows its own calendar, so we plan upgrades around both.
We still use Ingress NGINX. What now?
The project retired it in March 2026: it gets no further fixes, and existing installs keep working. We map what each route does, try Gateway API or another Ingress controller on a copy of the cluster, and move the routes over one at a time.
What will it cost us to run?
That depends on what runs and how much room it asks for. We set each workload’s requests from measured use, size the machines to fit, and label each team’s workloads, so the costs have owners.
What does it cost to work with you?
That depends on the work, and on where you’d like to start. Before any work starts, you get a written proposal with the scope, the price or rate, and how you pay.
Can AI assistants help with our cluster’s files?
Yes, as one of the ways code gets written here. Every change an assistant drafts, to a service or to the cluster’s files, is tested and reviewed by a person before it reaches a cluster.
Can we hire engineers for our own team?
Yes. Within 48 hours of your request, we introduce engineers for Kubernetes clusters who work in your time zone, and you meet them before choosing who joins.
Kubernetes is a registered trademark of LF Projects, LLC in the United States and/or other countries. AWS is a trademark of Amazon.com, Inc. or its affiliates, Microsoft and Azure are trademarks of the Microsoft group of companies, and Google Cloud is a trademark of Google LLC. Webair is independent of LF Projects, LLC, The Linux Foundation and the Kubernetes project, and isn’t sponsored by, endorsed by or affiliated with any of them.
Let’s build it better
Tell us how your clusters are run today and what’s been changed by hand, and we’ll suggest where to begin, in a short call.
Thanks, we’ll be in touch soon.
{{ ctaStatus }}