6 ms·

Kubernetes is bad for running databases is a _very_ outdated belief

sgarland 2y ago
As a DBRE, I disagree. See post below [0]. [0]: https://news.ycombinator.com/item?id=41414237 https://news.ycombinator.com/item?id=41414237
otabdeveloper4 2y ago
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.)
- movedx 2y ago
  I couldn't agree more.
  - jauntywundrkind 2y ago
    And yet you both throw incredibly weak & broad non-technical aspersions. Casting such broad unspecific unnuanced nets, denying value blanketly where clearly some people do find value, is trolling.
    - otabdeveloper4 2y ago
      From a technology point of view k8s doesn't do anything better than what Perl scripts used to do 25 years ago. (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.
- throwaway984393 2y ago
  K8s is a fantastic development tool. You can't ask for a better self-service tool to enable developers to ramp up on a platform and develop or test their apps across teams and orgs in a standard, portable, safe way. Its biggest problem arguably is that it's too configurable, and doesn't have enough abstractions to hide the complexity.
- jb_gericke 2y ago
  Can you qualify this statement? It’s 2024, Kubernetes is old tech and bullet proof at that.
  - raverbashing 2y ago
    Does Kubernetes has reliable and predictable cronjobs already?
    - mborch 2y ago
      Yes? https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/ https://kubernetes.io/docs/concepts/workloads/controllers/cr....
      - raverbashing 2y ago
        We've seen a multitude of issues, like jobs failing to start, getting too delayed (also the infamous "if your cronjob fails too much it will stop working forever ") Though it seems they rebuilt the controller to address most of the issues https://kubernetes.io/blog/2021/04/09/kubernetes-release-1.21-cronjob-ga/ https://kubernetes.io/blog/2021/04/09/kubernetes-release-1.2...
- cyberpunk 2y ago
  This is just not true anymore. I went through the pain of using it early and there were times to feel like that, but t brings far more to the table than it costs anymore…
  - anonzzzies 2y ago
    It's fine if you run it at a cloud provider. Setting up a k8s cluster yourself is painful though and at a cloud provider it costs far more than using just bare metal and/or docker (we do not, as it's another thing to manage and very boring). We have auto deploy scripts in Perl since the 90s and never had any needs for any of this stuff; we now host for less than $100/mo, with millions of users and a lot of profit with very little maintenance. I wonder why IT people like burning money so much, especially here on HN. 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.
    - eropple 2y ago
      > It's fine if you run it at a cloud provider. Setting up a k8s cluster yourself is painful though and at a cloud provider it costs far more than using just bare metal 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.
- Haaammaa 2y ago
  [dead]

As a DBRE, I disagree. See post below [0]. [0]: https://news.ycombinator.com/item?id=41414237 https://news.ycombinator.com/item?id=41414237

otabdeveloper4 2y ago

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.)

movedx 2y ago
I couldn't agree more.
- jauntywundrkind 2y ago
  And yet you both throw incredibly weak & broad non-technical aspersions. Casting such broad unspecific unnuanced nets, denying value blanketly where clearly some people do find value, is trolling.
  - otabdeveloper4 2y ago
    From a technology point of view k8s doesn't do anything better than what Perl scripts used to do 25 years ago. (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.
throwaway984393 2y ago
K8s is a fantastic development tool. You can't ask for a better self-service tool to enable developers to ramp up on a platform and develop or test their apps across teams and orgs in a standard, portable, safe way. Its biggest problem arguably is that it's too configurable, and doesn't have enough abstractions to hide the complexity.
jb_gericke 2y ago
Can you qualify this statement? It’s 2024, Kubernetes is old tech and bullet proof at that.
- raverbashing 2y ago
  Does Kubernetes has reliable and predictable cronjobs already?
  - mborch 2y ago
    Yes? https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/ https://kubernetes.io/docs/concepts/workloads/controllers/cr....
    - raverbashing 2y ago
      We've seen a multitude of issues, like jobs failing to start, getting too delayed (also the infamous "if your cronjob fails too much it will stop working forever ") Though it seems they rebuilt the controller to address most of the issues https://kubernetes.io/blog/2021/04/09/kubernetes-release-1.21-cronjob-ga/ https://kubernetes.io/blog/2021/04/09/kubernetes-release-1.2...
cyberpunk 2y ago
This is just not true anymore. I went through the pain of using it early and there were times to feel like that, but t brings far more to the table than it costs anymore…
- anonzzzies 2y ago
  It's fine if you run it at a cloud provider. Setting up a k8s cluster yourself is painful though and at a cloud provider it costs far more than using just bare metal and/or docker (we do not, as it's another thing to manage and very boring). We have auto deploy scripts in Perl since the 90s and never had any needs for any of this stuff; we now host for less than $100/mo, with millions of users and a lot of profit with very little maintenance. I wonder why IT people like burning money so much, especially here on HN. 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.
  - eropple 2y ago
    > It's fine if you run it at a cloud provider. Setting up a k8s cluster yourself is painful though and at a cloud provider it costs far more than using just bare metal 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.
Haaammaa 2y ago
[dead]