Setting up for failure
I am not happy with Kubernetes. No, that is too soft but hating Kubernetes is too strong. It is one below hate. I dislike working with it and I advise others to take caution in wanting to use it.
I was contemplating for a couple of days why I was so against it. I wrote already about something in the Golang community making it so they have vague documentation and undocumented steps. That was part of what was bothering me. The real reason I will state after a quick sidestep into self reflection.
Your self
It is important to get to know your self and yourself. This can be only be done by self reflecting a lot. I was having internal conversations putting reasons to my self for disliking kubernetes and seeing if that was really what it was or not. For me the trigger is a simple feeling of yes or no. No other way to explain it then just a sensation that either belongs to yes or not to yes.
Putting reasons to your own self is almost like an Artificial Intelligence playing against itself and learning in the process.
I highly recommend you doing this for subjects that you do not have answer to the question of but why? Again that question that is asked by kids where we go nuts because a lot of things we don't know why is the most important question and instead of parents stopping them from asking this question it should be encouraged.
Back to why I have negative feelings towards kubernetes and the reason why.
My self found an answer
The answer my self found for not having fuzzy warm feelings about kubernetes is the fact that it sets you up for failure. You start at step 1 and then at step 4 you realise you missed something at step 2. Then you have to go back start again from step 2. The fact that you missed it is because they don't tell you aforehand but only at a later step is the suddenly required mandatory prerequisite shown to you.
If you need labels for almost anything in kubernetes why allow one to create anything without them being present?
Example of a company that sets you up for success would be AWS. It is very difficult to not get something to work via the Web Console they provide and also via the cli tooling. In Cloudformation you can miss something but there they also give you good guidance in the documentation as well as provide fully functional examples that you can use as a template. Everything is designed to make it work for you at the end. You want to give the user success.
How to achieve this
In order to achieve this setting up for success it is greatly linked to making things monkey proof, or idiot proof or anything similar sounding ending in proof.
You want to close off all the avenues that lead to failure. It should not feel like playing a Sierra adventure game where you suddenly die and you forgot to save and you died because you did not execute the correct prerequisites. Don't get me wrong I love playing those games. I love them because I play them for the challenge in my downtime.
Tools that should improve my productivity should not be designed to allow for more ways to be less productive than improve it.
So keep in mind to close off the avenues that lead to Sierra states and your users will be all the more happy for it.