Among growing container trends, here’s an important one: As containers go, so goes container orchestration. That’s because most organizations quickly realize that managing containers in production can get complicated in a hurry. Orchestration solves that problem, and while there are multiple options, Kubernetes has become the de facto leader.
[ Want to help others understand Kubernetes? Check out our related article, How to explain Kubernetes in plain English. ]
Kubernetes’ star appeal does lead to some misunderstandings and outright myths, though. We asked a range of IT leaders and container experts to identify the biggest misconceptions about Kubernetes – and the realities behind each of them – to help people who are just getting going with the technology. Here are five important ones to know before you get your hands dirty.
Misunderstanding #1: Kubernetes is only for public cloud
Reality: Kubernetes is commonly referred to as a cloud-native technology, and for good reason. The project, which was first developed by a team at Google, currently calls the Cloud Native Computing Foundation home. (Red Hat, one of the first companies to work with Google on Kubernetes, has become the second-leading contributor to Kubernetes upstream project.)
“Kubernetes is cloud-native in the sense that it has been designed to take advantage of cloud computing architecture [and] to support scale and resilience for distributed applications,” says Raghu Kishore Vempati, principal systems engineer at Aricent.
Just remember that “cloud-native” is not wholly synonymous with “public cloud.”
“Kubernetes can run on different platforms, be it a personal laptop, VM, rack of bare-metal servers, public/private cloud environment, et cetera,” Vempati says.
Notes Red Hat technology evangelist Gordon Haff, “You can cluster together groups of hosts running Linux containers, and Kubernetes helps you easily and efficiently manage those clusters. These clusters can span hosts across public, private, and hybrid clouds.”
Misunderstanding #2: Kubernetes is a finished product
Reality: Kubernetes isn’t really a product at all, much less a finished one.
“Kubernetes is an open source project, not a product,” says Murli Thirumale, co-founder and CEO at Portworx. (Portworx co-founder and VP of product management Eric Han was the first Kubernetes product manager while at Google.)
New users should understand a fundamental reality here: The Kubernetes ecosystem moves very quickly. It’s even been dubbed the fastest-moving project in open source history.
“Take your eyes off of it for only one moment, and everything changes,” Frank Reno, senior technical product manager at Sumo Logic. “It is a fast-paced, highly active community that develops Kubernetes and the related projects. As it changes, it also changes the way you need to look at and develop things. It’s all for the better, but still, much to keep up on.”
Misunderstanding #3: Kubernetes is simple to run out of the box
Reality: It may be “easy” to get it up and running on a local machine, but it can quickly get more complicated from there. “For those new to Kubernetes, there’s often an ‘aha’ moment as they realize it’s not that easy to do right,” says Amir Jerbi, co-founder and CTO at Aqua Security.
Jerbi notes that this is a key reason for the growth of commercial Kubernetes platforms on top of the open source project, as well as managed services and consultancies. “Setting up and managing K8s correctly requires time, knowledge, and skills, and the skill gap should not be underestimated,” Jerbi says.
Some organizations are still going to learn that the hard way, drawn in by the considerable potential of Kubernetes and the table-stakes necessity of a using container management or orchestration tool for running containers at scale in a production environment.
“Kubernetes is a very popular and very powerful platform,” says Wei Lien Dang, VP of products at StackRox. “Given the DIY mindset that comes along with open source software, users often think they should be working directly in the Kubernetes system itself. But this understanding is misguided.”
Dang points to needs such as supporting high availability and resilience. Both, he says, become easier when using abstraction layers on top of the core Kubernetes platform, such as a UX layer to enable various end users to get the most value out of the technology.
“One of the major benefits of open source software is that it can be downloaded and used with no license cost – but very often, making this community software usable in a corporate environment will require a significant investment in technical effort to integrate [or] bundle with other technologies,” says Andy Kennedy, managing director at Tier 2 Consulting. “For example, in order to provide a full set of orchestrated services, Kubernetes relies on other services provided by open source projects, such as registry, security, telemetry, networking, and automation.”
Complete container application platforms, such as Red Hat OpenShift, eliminate the need to assemble those pieces yourself.
This gets back to the difference between the Kubernetes project and the maturing Kubernetes platforms built on top of that project.
“Do-it-yourself Kubernetes can work with some dedicated resources, but consider a more productized and supported [platform],” says Portworx’s Thirumale. “These will help you go to production faster.”