Kubernetes is bad for running anything at all, including databases.
(K8s is second-system effect and job security for sysadmins. From a technical point of view it causes more problems than it solves.)
(K8s is second-system effect and job security for sysadmins. From a technical point of view it causes more problems than it solves.)
Though it seems they rebuilt the controller to address most of the issues https://kubernetes.io/blog/2021/04/09/kubernetes-release-1.2...
There is no need for almost any sites; sure facebook/google, but you are not running those nor is it likely you (not specifically you obviously, me neither) ever will. VPSs are robust these days and have no downtime besides kernel updates. I cannot phantom why you would want to burn humans or money on this kind of complexity. But then again, we like profit (not growth because of growth) and it seems that most here really are not that interested in that. If I cannot be Gates or Musk (and I cannot, nor can you, again, no attack on you; just statistics) then I rather have little work or headache with millions $ of profit/mo coming in instead of 'growth'. Maybe i'm odd, but I am free for the past 30+ years because of these choices (currently; common lisp, apache, perl, php, mysql, haproxy, redis, wireguard; hopefully I get this down to just common lisp + wireguard before I pass). We don't use libraries or tech less than 10 years old unless it's really needed and we contribute to everything we use (so we use very few things otherwise we have to hire and that's a waste of $); I sleep very well at night knowing nothing is going to happen.
I think it's almost exactly the opposite: I'd rather use cloud-specific tooling on clouds but k8s is a Better OpenStack on bare metal. It provides a standardized layer upon which generally-reasonable tools can operate without thinking about it much. There is a cost factor--it doesn't need to be a high one, though, and it's also a forcing function into stuff like "actually thinking about redundancy" ahead of time.
I've deployed in production everything you described and unless I was optimizing, as you are, for cut-to-the-bone opex and personal stress when it breaks bad (which is not a judgment call but it is certainly not the only reasonable decision to make; investing more in operations to have more "bounce" when things goes bad is not a bad thing), a reasonably thought-out k8s environment is going to be easier than shell scripts from the 90s once I need to have anyone who isn't me take over a problem.
God forbid if you had to think and know about your infrastructure and how it worked, and whether it was as minimal and simple as possible whilst delivering results. Best to just use abstractions upon abstractions you don't know well and hope for the best.
I've built systems that exist today both ways. There are reasonable arguments for both. Please don't be weird.
Casting such broad unspecific unnuanced nets, denying value blanketly where clearly some people do find value, is trolling.
(Not that Perl scripts are any good. They're crap technology, but unfortunately so is k8s.)
K8s doesn't solve a technical problem. It solves two contradictory social problems:
a) It gives sysadmins a job creation program, full of expensive and opaque stuff that requires expensive sysadmins. b) It makes sysadmin stuff fungible and replaceable for developers.
Solving both problems is probably an important social issue if you're running a Google scale organization. But it's solving a social and organizational problem, not fulfilling a technological need.