Kubernetes is hard. This is especially true for those new to Kubernetes who want to run their applications on it. Or, even those who are seasoned and still don’t know how everything works. There are more people like that than care to admit it. We have a problem.
The first step is usually to admit there is a problem. A problem needs to be admitted to prior to having people willing to work on it. That’s what this post is. An admittance that we have a problem.
As one of the co-leads of Kubernetes SIG Apps, that deals with building apps for and operating apps in Kubernetes, I feel I need to state this out loud. If you’ve been silent and not wanted to talk about it too publicly please don’t hesitate to hold back. But, I ask that instead of complaining you focus on positive steps that you can take or ways you can encourage others to take positive steps.
Why Admitting The Problem Is Important
Many of us live in a culture where we don’t admit wrongs, failures, or shortcomings. To do so would mean we didn’t live up to some expectation. And, in many work contexts admitting wrongs has the perception it can hurt career growth.
But, there are two big benefits to admitting these.
- Far too many people feel the pain of dealing with the hard. Admitting there is a problem tells them their feelings are justified.
- It helps to provide a list of actionable steps to make the situation better.
Some of The Problems
To help I’d like to start admitting some of the problems. Specifically. And, talking about some of the efforts to improve on this.
Lack Of Appropriate Documentation
Kubernetes has a lot to know. For example, you’re application needs a controller such as a Deployment, StatefulSet, or one of the many other options. But, which one should you choose and what is the best way to get started?
The current documentation is rather technical and assumes you know a lot about how Kubernetes works and names things. It assumes a lot of tribal knowledge. I’m sorry it is in this state.
There is work going on to restructure the Kubernetes documentation to make it better for application operators. This is a good first start.
The next step is we need well written documentation targeted application operators rather than community members. I find it worth remembering that most application operators will not join in as active members of the community.
Verbose Hard To GROK Configuration
Have you ever tried to write RBAC configuration for Kubernetes? I’ve had numerous people tell me it makes them uncomfortable. Someone even created tooling to read logs and turn them into configuration. The idea is you could use this in development. This is just one example of hard.
Application operators are often used to a far simpler experience.
What might take me a few lines (maybe a dozen) of configuration for Heroku or Cloud Foundry might take me hundreds of lines of configuration for Kubernetes. This is across numerous configuration objects; each with their own schema. Oh, and there’s a fair amount of duplication. I’m sorry this is so hard.
While we can look at this as a debate between a container manager (Kubernetes) and a Platform as a Service, I see this as a place we can do better without needing that debate. And, some are working on it. There are two practical things that come to immediate mind.
- Tools like Kedge and Psykube are working to make the generation of Kubernetes objects easier.
- Better documentation. This goes back to the first point. We need more appropriate documentation.
Difficulty Finding Tools
There are a lot of tools to help with developing Kubernetes configuration and to help operate applications. Do you know how to find them? Did you know there are multiple Kubernetes configuration linters? Did you know there were even linters? This is just one category.
Discovering tools is hard. Search engines don’t do it justice. I’m sorry this isn’t easier.
Some of us are trying to build a place to make discovery of tools in the Kubernetes ecosystem easier.
Want To Help?
There are a couple practical things many people can do to help. Even those who aren’t active in the Kubernetes community.
- Share stories of where you ran into pain points. And, if you came up with a way to overcome them share that, too.
- Consider contributing to a better experience. You can do that by joining us in SIG Apps and discovering where you can help or you can find me and I’m happy to help point you in the right direction.