Top 5 Ways to Tame Kubernetes Complexity
Like many other application platform technologies, what accelerates development and deployment creates complexity and management gaps for IT Operations and/or DevOps.
Join the DZone community and get the full member experience.Join For Free
Kevin Fulton recently authored an interesting article over at The New Stack. Compiling commentary on conversations that happened at KubeCon Copenhagen a weeks ago. The article title is both simple and bold: "Has Kubernetes Already Become Too Unnecessarily Complex for Enterprise IT? "
Instana was a KubeCon sponsor, which allowed me to also speak with attendees, many of whom were already using Kubernetes (often abbreviated to K8s) or exploring details on how they could use it in their environment (as you would expect at a K8s-focused conference). Complexity was part of the conversation, but most (if not all) were/are going to be using K8s as part of their production stack in the very near future.
If we're all going to use it, what's the problem?
One of the most important concepts from the article is the following ... "Kubernetes was designed by systems engineers, for systems engineers," stated Kate Kuchin, an engineer with Heptio, during the last KubeCon. "Which is great, if you're a systems engineer. For the rest of us, Kubernetes is really, really intimidating. With the exception of those people who created Kubernetes who were there at the very, very beginning, everyone in this room was probably a new Kubernetes user at some point, or is a new Kubernetes user now, or will be a new Kubernetes user next week. So you all already know that it can be pretty daunting."
The reality is that there is very limited expertise in K8s at this point. I recently wrote an article that discusses the concept of technology advancements outpacing our ability to develop expertise.
What's really important?
In his article, Kevin does a nice job explaining various perspectives on how and why K8s is complex. To be clear, K8s is complex - but it's to be complex. To borrow a phrase from an old movie - it's the complexity that makes it great!
The question to ask isn't if K8s is too complex, but why so many organizations are choosing and using K8s, given the complexity.
Yes, it's complex, but it appears to be a lot less complex than years of built up Chef recipes, Puppet templates, or - gasp - shell scripts. Since most companies are going to end up using K8s anyway, the question I always get is "How can we tame Kubernetes' complexity and derive the most value possible?"
Taming Kubernetes Complexity
Like many other application platform technologies, what accelerates development and deployment creates complexity and management gaps for IT Operations and/or DevOps. But new tools do come along to help monitor and manage the new technologies. As those tools emerge, here are 5 ways they can help optimize K8s and applications running on K8s:
- Identify and show the relationship between clusters, nodes, deployments, pods, etc.
- Provide an understanding of the health of K8s AND the managed services
- Visually map the service configuration and deployments resulting from all of that YAML declaration
- Identify, monitor and visualize contextual relationship data between infrastructure, application, and K8s
- Provide curated expertise while your team builds its own knowledge level
You can see these benefits of tooling demonstrated in the following content:
- Video: Instana Kubernetes Monitoring Demo
- Blog Post: Monitoring Kubernetes so you actually know what it’s doing
- Blog Post: Insights into Kubernetes-Powered Applications
- Blog Post: Using real-time Kubernetes monitoring to accelerate application delivery
Yes, K8s is complex but that is not going to stop most companies from using it. The complexity doesn't have to translate into a painful management experience. Take advantage of the tooling that exists and build your K8s knowledge and experience.
Published at DZone with permission of Jim Hirschauer, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.