The State of Kubernetes: Key Challenges and the Role of AI
There have been plenty of articles extolling the virtues of Kubernetes. It’s been a dominant theme in the DevOps universe for years. So let’s just state it simply: Kubernetes won. It’s the de facto way to orchestrate containers and is at the heart of cloud native applications.
So now what?
Well, I think the interesting conversations are happening around the community and the broader ecosystem. How do we provide better support to Kubernetes users? How do we build better tooling? How do we understand and manage these distributed, complex systems?
I wanted to speak with some folks building cutting-edge solutions to complex problems that are arising from the adoption of Kubernetes, and containers/microservices more broadly. I asked questions like: Where is Kubernetes headed? Why is it so complicated? What’s the role of artificial intelligence?
Below are some key takeaways and then the link to the full conversation, for those interested.
Kubernetes is a superpower. It’s not an accident that Kubernetes has taken off, despite its complexity. A single engineer can now deploy containers from their laptop in a way that used to require a team of experts. The ability to containerize applications and orchestrate their deployment means a level of scale and agility that was simply impossible before.
Kubernetes is complicated. As someone once said: There are no solutions, only trade offs! Kubernetes can feel like magic to start with, but teams often find themselves over their heads relatively quickly. Like a broken watch, when things go wrong, it often requires expertise to get under the hood and figure out what’s going wrong.
The Kubernetes community is taking security seriously. By default, Kubernetes comes with the control plane locked down, no privileged containers, encryption between APIs, the ability to limit communication between services and more. It’s also declarative, so you can ensure even more security before deployment — also known as “shift left.” However, there are enough knobs that you can unintentionally make things more insecure. The moment you don’t go through the proper processes, such as directly editing a deployment instead of the manifest, or if you turn off the default security controls to make your life easier in the moment, that security benefit is gone.
Stick with vanilla. Kubernetes is very customizable and the APIs are only getting better. That said, there’s no reason to make things more complicated than necessary. Don’t let the hype pull you into over-architecting your application, which can also introduce unnecessary security issues. Sometimes all you need is a simple app deployed on EC2. Also worth noting that each cloud provider has created a different configuration for Kubernetes — for example, AKS (Azure Kubernetes Service) is not the same as EKS. (Amazon’s Elastic Kubernetes Service). You can practice chaos engineering to understand these systems better and root out potential failure scenarios before they affect customers.
AI is coming, but it’s not here yet. Especially in the Ops world, the idea of AI coming in and remediating problems has been a topic of discussion for years (a.k.a. “AIOps”). We’re actually seeing this conversation shift even further left, with the launch of things like GitHub Copilot. But the fact remains that machines may show you a spike, but you still need a human to assign value to it and take a specific action. Kubernetes is no different. We will see a huge influx of trend data and machine learning baked into products, helping teams troubleshoot Kubernetes and make better decisions, but humans will still remain at the wheel for the time being.
Kubernetes isn’t necessarily for everyone. A point that was hit on a few times throughout the conversation is that Kubernetes isn’t for everyone. Or at least it’s not for everyone all of the time. Understanding where it is necessary, versus where more traditional infrastructure suffices, is something worth thinking through at your organization.
The participants in the Kubernetes Roundtable were:
- Austin Parker – Developer advocate at Lightstep
- Matt Johnson – Developer advocate at Bridgecrew
- Tammy Butow – Principal site reliability engineer at Gremlin
- Liran Haimovitch – CTO and co-founder of Rookout
- Itiel Shwartz – CTO and co-founder of Komodor
Watch the full video below: