Honestly. Give yourself a month to learn it and migrate your home lab and it's actually not too difficult. Yes it takes a lot of debugging initially, but like most things, once you're familiar, it becomes easy.
And that’s an undeniable feature of Kubernetes: people know about it, and smart people use the same (CNCF) building blocks, to keep maximising the probability that your next Kubernetes engineer has also knows about it.
But do you want to turn your software system distributed at the cost of immense complexity?
Only if you’re already cultivating something immensely complex, and you’d be better off with a common language.
If your needs are met by a VM or three then sure, you may not need Kubernetes, although as other comments have pointed out, distributions like k3s can be useful even in those environments. But as you climb the scale and complexity ladder, there soon comes a point where it's very hard to beat Kubernetes, which is why it has become so widespread.
> It isn't about the tooling, it's knowing the business.
The sort of statement I expect to see on LinkedIn. Once you know the business, you decide on appropriate tooling. As I said, as you climb the scale and complexity ladder, Kubernetes starts to make more sense. At that point, the tooling can become very important.
