This article is based on reporting originally published by TechTarget (August 2018). Quotes and case studies are attributed to the original source.
The Kubernetes Distribution Decision
By mid-2018, Kubernetes had established itself as the dominant container orchestration platform, and a crowded vendor ecosystem had grown up around it. Red Hat, Docker, Heptio, Mesosphere, Rancher, Platform9, Pivotal, Google, Microsoft, IBM, and Cisco were among the vendors offering prepackaged Kubernetes implementations for private and hybrid cloud environments. Products such as Red Hat OpenShift Container Platform, Docker Enterprise Edition, and Rancher layered enterprise security, management tooling, and support contracts on top of the upstream Kubernetes codebase.
Despite this vendor activity, many enterprise IT teams continued to download Kubernetes directly from GitHub and run it without a commercial distribution. The debate between these two approaches — upstream Kubernetes versus a packaged implementation — reflects genuine trade-offs around cost, control, portability, and operational complexity.
The Case for Pure Upstream Kubernetes
Avoiding Licensing Costs and Vendor Lock-In
IT consulting firm Indellient Inc. reported in 2018 that a growing number of its clients were choosing upstream Kubernetes over commercial distributions such as Docker Enterprise Edition and Red Hat OpenShift. According to Damith Karunaratne, director of client solutions at Indellient:
“Those platforms may help with management out of the gate, but software license costs are always a consideration, and companies are confident in their technical teams’ expertise.”
Rosetta Stone: A Late Adopter’s Perspective
Language learning software company Rosetta Stone had used Docker containers in its DevOps pipeline for years but had not deployed a container orchestration tool in production as of mid-2018. In August 2017, the company evaluated Docker Swarm as a simpler alternative to Kubernetes. A year later, however, it planned to move upstream Kubernetes into production, citing the platform’s growing maturity and industry ubiquity.
Kevin Burnett, DevOps lead at Rosetta Stone, noted that concerns about Kubernetes management complexity had diminished significantly as the platform matured:
“We’re a late adopter, but we have the benefit of more maturity in the platform. We also wanted to avoid [licensing] costs, and we already have servers. Eventually, we may embrace a cloud service like Google Kubernetes Engine more fully, but not yet.”
Burnett’s team preferred hand-rolling its own configurations of open source tools and was explicitly concerned that adopting vendor-specific features could compromise cloud portability down the line.
The Fork Problem and Long-Term Management Complexity
Several practitioners raised concerns about vendor distributions that diverge — or could diverge — from upstream Kubernetes. A DevOps transformation leader at an insurance company, speaking anonymously, framed the problem bluntly:
“Container sprawl combined with a forked Kubernetes runtime in the hands of traditional IT ops is a management nightmare. Why invite that mess when you already have your hands full with a number of packaged containers that you’re going to have to develop security patching processes for?”
His company was evaluating OpenShift due to an existing Red Hat relationship, but he expressed concern that adding a new orchestration layer and managing multiple control planes for both VMs and containers would increase operational burden, particularly for security patching workflows.
The Case for Packaged Kubernetes Distributions
Enterprise Support and Security as Top Priorities
Early adopters of vendor Kubernetes distributions generally ranked enterprise support and integrated security features above concerns about upstream conformance. For regulated industries or organizations without large platform engineering teams, a commercial distribution often represents the only practical path to production.
Surya Suravarapu, assistant vice president of product development at healthcare IT company Change Healthcare, captured this perspective directly:
“We’re a healthcare IT company. We can’t just go with a raw tool without 24/7 enterprise-level support.”
Change Healthcare used multiple third-party Kubernetes tools as of mid-2018. Suravarapu cited multi-tenancy support and integrated DevOps tooling — specifically, the ability to convert code to container images with a single CLI command or button click — as the primary drivers for choosing a vendor platform. Built-in compliance and security policy management for all product teams was an additional consideration.
Amadeus: OpenShift in a Multi-Cloud World
Global travel technology company Amadeus was an early OpenShift adopter and had deployed it across Microsoft Azure, Google Cloud, AWS, and on-premises data centers. Dietmar Fauser, vice president of core platforms and middleware at Amadeus, said that Red Hat’s track record in maintaining open source distributions made the fork concern largely theoretical:
“Red Hat is very good at maintaining open source software distributions, patching is consistent and easy to maintain, and I trust them to maintain a portable version of Kubernetes. Some upstream Kubernetes APIs come and go, but Red Hat’s approach offers stability.”
Fauser also acknowledged a residual strategic risk: any dominant vendor in the Kubernetes ecosystem has the potential to restrict third-party plugin access or otherwise limit the surrounding ecosystem. As of 2018, Red Hat had not done this, but Fauser noted the risk was real and worth monitoring.
Key Trade-Offs at a Glance
| Consideration | Upstream Kubernetes | Packaged Distribution |
|---|---|---|
| Licensing cost | None (open source) | Vendor subscription fee |
| Initial setup complexity | Higher — requires in-house expertise | Lower — vendor tooling and documentation |
| Long-term management | Full team control; no vendor dependency | Vendor handles patches and updates |
| Enterprise support | Community support only | 24/7 commercial SLA available |
| Cloud portability | Maximum — no vendor-specific APIs | Varies by vendor; most target portability |
| Security tooling | Must integrate separately | Often bundled (RBAC, network policy, image scanning) |
| Upstream conformance risk | None | Low to moderate depending on vendor |
What Has Changed Since 2018
The original debate was captured in mid-2018, when Kubernetes was still rapidly evolving and enterprise adoption was accelerating. Several factors have shifted the landscape since then:
- Managed cloud services (Amazon EKS, Google GKE, Azure AKS) have become a third mainstream option, reducing the operational burden of running upstream Kubernetes without requiring a full commercial distribution.
- CNCF conformance certification provides a clearer signal that a given vendor distribution does not diverge materially from upstream Kubernetes behavior.
- Red Hat’s acquisition by IBM (completed in 2019) changed the strategic context for OpenShift customers evaluating vendor ecosystem risk.
- Kubernetes API stability has improved, with the project adopting a more rigorous deprecation policy, reducing the churn that concerned early adopters.
The core tension — control and portability versus operational simplicity and support — remains relevant for any team evaluating Kubernetes today. The right answer still depends on in-house engineering capacity, regulatory requirements, budget, and long-term cloud strategy.
Summary
Enterprises choosing between upstream and packaged Kubernetes implementations face a genuine engineering and business trade-off, not simply a technical one. Teams with strong platform engineering capabilities and concerns about vendor lock-in have good reasons to run upstream Kubernetes. Organizations in regulated industries, those without dedicated infrastructure teams, or those requiring integrated security tooling and commercial support have equally good reasons to adopt a vendor distribution. Evaluating both paths against your team’s actual operational capacity is more useful than defaulting to either extreme.