I'm somewhat sure you could make a similarly complicated looking chart that would entail:
- using ping
- sshing into a box
- using ssh port forwarding
- using ps aux
- understanding system load
- understanding oom killer messages
- is this systemd? use systemctl, otherwise figure it out
- is this systemd? use journalctl, otherwise figure out where an app is logging
- is nginx running? what box is it running on?
- is the nginx config okay?
- what about haproxy? are health checks going through?
Plus dealing with whatever configuration management system you're using, credential store you're using, etc.
Kubernetes, while complex, does take over a huge chunk of responsibilities from existing deployments. As such, a large part of any debugging will be done via kubectl and on a much different level of abstraction than if you were dealing with individual machines and services deployed on them via Ansible.
Yes, there's new things to learn. But for many cases (not even just scale!) it's quite worth it.
TBF a lot of people don't know what any of that is and use Heroku or equivalent. I've worked with people who don't even know how to use find or chmod, much less ps, htop, and other system tools.
Yep, and many of these projects are 10+ years old rock solid code that very rarely breaks and the failure scenarios are well understood (the only real exception is systemd). Can you tell the same about k8s?
Well yes, people who already pay for external cloud providers running k8s for little business value is a meme at this point. If you are creating a cloud provider though then you're very much welcome to use k8s.
I understand that Kubernetes is a complex project, but I struggle to see how this comment adds to the discourse.
For those that do need a solution like Kubernetes, charts like this are helpful, and the knowledge requirements certainly aren't too steep relative to comparable platforms.
What about Kubernetes makes it especially worth going in and commenting that you don't have a use case for it, in a thread dedicated to Kubernetes? Would you make similar comments about other platforms/libraries/technologies that you, for whatever reason, don't have a use case for?
Because echo chambers need their bubble's pierced every so often. Kubernetes is such garbage that no one runs it on their servers and if they do they have an army dedicated to managing it 24/7. Go to any company that's running it and ask them how they feel about it.
Because many people (including managers) take HN seriously and then go and try to implement or push for this being implemented because they read it on HN. Unfortunately they cannot go to HN when a outage explodes in their face, caused by an unknown problem in k8s. There is no clear value proposition for using k8s. It is trading time to figure out what would make the most sense for a project for black box complexity in most cases and that is a very bad deal. You pay the price once for the first one and all the time for the second one. If I do not comment here then you have a nice echo chamber that all fine and dandy with k8s and there is no downside at all using it. Btw. it is not only k8s and HN supposed to be a discussion site not a fanboy club of broken tech. I understand that the latter is much more appealing to many people.
- using ping
- sshing into a box
- using ssh port forwarding
- using ps aux
- understanding system load
- understanding oom killer messages
- is this systemd? use systemctl, otherwise figure it out
- is this systemd? use journalctl, otherwise figure out where an app is logging
- is nginx running? what box is it running on?
- is the nginx config okay?
- what about haproxy? are health checks going through?
Plus dealing with whatever configuration management system you're using, credential store you're using, etc.
Kubernetes, while complex, does take over a huge chunk of responsibilities from existing deployments. As such, a large part of any debugging will be done via kubectl and on a much different level of abstraction than if you were dealing with individual machines and services deployed on them via Ansible.
Yes, there's new things to learn. But for many cases (not even just scale!) it's quite worth it.