New
How many Kubernetes clusters do you run, and how do you keep upgrades sane?
Fleet size, managed vs self-managed, and the tooling that keeps version upgrades from becoming a quarterly fire drill.
Evaluation guide
How to evaluate Kubernetes platforms
This guide is for platform, infrastructure and DevOps leads choosing a Kubernetes distribution, a managed service or a tool to run many clusters. It suits teams moving from a handful of clusters to a fleet, and teams weighing a move of virtual machine workloads onto Kubernetes.
In short
Use this guide to compare Kubernetes distributions, managed services and cluster management tools on what decides the outcome: how upgrades work, fleet management across environments, security defaults, networking and storage, support for virtual machines and the effort of running it. Then shortlist three to five companies on Techarda and test each on a real upgrade.
What’s changing in Containers & Kubernetes
Before you compare anyone, it helps to know what has shifted in the market, because it changes which questions matter.
Fleets have replaced single clusters
Many organisations now run clusters across several clouds, data centres and edge sites. The hard problem has moved from installing Kubernetes to keeping a fleet consistent, upgraded and secure.
Virtual machines are moving onto Kubernetes
Tools that run virtual machines alongside containers on one platform are getting serious attention from teams reconsidering their virtualisation platform. Maturity varies, especially for networking, storage and backup.
The upstream release cycle sets the pace
Upstream Kubernetes ships several minor releases a year and supports each one for a limited time. Every distribution has to keep up, and so does your team.
Security has moved into the platform
Supply chain checks, admission policies and runtime detection are now expected parts of a platform. Many still come from separate tools, which adds integration work.
What to judge vendors on
Those shifts shape the criteria below. Each one says why it matters and what to ask, so you can take it straight into a vendor call.
| Criterion | Why it matters | What to ask vendors |
|---|---|---|
| 1Upgrades and version support | A platform that makes upgrades painful leaves you on unsupported versions with known vulnerabilities. | “How long do you support each Kubernetes version, how are control plane and node upgrades run, and can we test an upgrade during the trial?” |
| 2Fleet management across environments | Running many clusters by hand does not scale. You need one way to apply policy, configuration and upgrades everywhere you run. | “How do we manage policy, configuration and upgrades across clusters in different clouds and data centres from one place, and what works differently in each?” |
| 3Conformance and lock-in | Distributions that add proprietary APIs make applications harder to move. Certified conformance is a baseline, not the whole answer. | “Which of your features depend on APIs outside upstream Kubernetes, and what would our applications need to change to run on another conformant distribution?” |
| 4Security defaults and policy | Default settings decide how most clusters actually run. Weak defaults spread to every team that copies them. | “Which security settings are on by default, how do you enforce admission policy and image signing, and how quickly do you ship fixes for critical vulnerabilities?” |
| 5Networking and storage | Many production problems in Kubernetes sit in networking and persistent storage rather than in the scheduler. | “Which network and storage plugins do you support and test, how do you handle stateful workloads, and who owns a problem that spans them?” |
| 6Virtual machine support | Virtual machines moved onto the platform bring networking, storage, backup and live migration needs that containers do not. | “How do you run virtual machines on the platform today, which guest operating systems are supported, and how do backup and live migration work?” |
| 7Operating effort and skills | Kubernetes rewards experienced teams and punishes thin ones. The licence is often smaller than the cost of the people who run it. | “What size of team runs a fleet like ours on your platform, what is automated, and what do you take on under support?” |
| 8Pricing as you grow | Pricing by core, node, cluster or management fee changes the bill a great deal as you scale and as node sizes change. | “How is the platform priced as we add clusters and nodes, and what happens to the cost if we move to larger or smaller nodes?” |
Trade-offs to settle early
No vendor does well on every criterion, and some pull against each other. Decide where you stand on these before the demos start, or the demos will decide for you.
Each cloud’s managed service or your own distribution
Managed Kubernetes from a cloud provider removes control plane work in that cloud. A distribution you run everywhere gives one way of working across environments and puts more of the operation on you or your vendor.
Opinionated platform or upstream with add-ons
An opinionated platform ships networking, security and developer tooling chosen and tested together. Assembling upstream components gives more choice and more integration work.
Few large clusters or many small ones
Fewer clusters are easier to upgrade and carry less overhead. More clusters isolate teams and failures better and multiply the management work.
Move virtual machines or leave them where they are
Running virtual machines on Kubernetes can consolidate platforms and skills. It also puts long-lived workloads on newer tooling, so start with systems that can tolerate change.
Commercial support or community support
A commercial agreement gives you patched builds and someone to call. Community distributions cost less and rely on your team’s skill when something breaks.
Red flags
As the answers come back, watch for these. One on its own isn’t a deal breaker, but it deserves a follow-up question in writing.
- No stated version support window, or upgrades that need professional services every time.
- Features described as standard that only work through the vendor’s own APIs.
- Virtual machine support shown only on simple workloads, with no answer on backup or live migration.
- Security fixes that arrive well after upstream releases them, with no stated target.
- Fleet management that works in one cloud and becomes manual everywhere else.
- No reference customer who has run several upgrades on the platform across a fleet.
Build your shortlist
Map where your clusters run and who runs them, then use Techarda to narrow the field to three to five companies.
- List the environments you need clusters in, the number of clusters you expect and whether virtual machines are in scope.
- Keep companies that support all of those environments in production today.
- Compare like with like: distributions against distributions, fleet management tools against each other, security add-ons against each other.
- Read recent stories on Techarda for licence, pricing and ownership changes, which can matter as much as features here.
- Use the practitioner questions below, then run one real upgrade on each finalist before you decide.
Companies to consider in Containers & Kubernetes
Listed by recent activity on Techarda (what people are reading, following and discussing). The order says nothing about quality, market share or fit for your needs.
Latest Containers & Kubernetes stories
Once you have names, recent news is where pricing changes, acquisitions and outages show up first. These are the five newest stories in this category.
What practitioners are asking
News tells you what vendors announced. These open questions show what teams are still trying to work out, with the least-answered first.
New
OpenShift vs managed Kubernetes (EKS/AKS/GKE) for regulated workloads
For teams in financial services, government or healthcare: which did you choose and what tipped it: compliance evidence, support, cost or skills?
Where evidence is thin
A shortlist is only as good as the evidence behind it, and ours is still growing category by category. Here is what’s missing in Containers & Kubernetes right now.
19 of 20 companies have no published reviews
If you’ve run one of these in production, a short review helps the next team decide. Reviews are moderated before they appear.
2 questions with no answers yet
An answer from someone who has made the same decision is often more useful than any guide. Share what worked, what didn’t and what you’d check next time.
Answer a Containers & Kubernetes questionFrequently asked questions
What should I ask Containers & Kubernetes vendors about upgrades and version support?
A platform that makes upgrades painful leaves you on unsupported versions with known vulnerabilities. Ask: How long do you support each Kubernetes version, how are control plane and node upgrades run, and can we test an upgrade during the trial?
What should I ask Containers & Kubernetes vendors about fleet management across environments?
Running many clusters by hand does not scale. You need one way to apply policy, configuration and upgrades everywhere you run. Ask: How do we manage policy, configuration and upgrades across clusters in different clouds and data centres from one place, and what works differently in each?
What should I ask Containers & Kubernetes vendors about conformance and lock-in?
Distributions that add proprietary APIs make applications harder to move. Certified conformance is a baseline, not the whole answer. Ask: Which of your features depend on APIs outside upstream Kubernetes, and what would our applications need to change to run on another conformant distribution?
What should I ask Containers & Kubernetes vendors about security defaults and policy?
Default settings decide how most clusters actually run. Weak defaults spread to every team that copies them. Ask: Which security settings are on by default, how do you enforce admission policy and image signing, and how quickly do you ship fixes for critical vulnerabilities?
New to some of the terms in this guide? The glossary explains Container, Kubernetes, Kubernetes operator and Service mesh.
This guide is written by Techarda editors to our editorial standards. No vendor paid to appear in it or saw it before publication. See our methodology, the trust dashboard or go back to the Containers & Kubernetes hub.