• andrew
    link
    fedilink
    English
    7
    edit-2
    1 year ago

    Because dogma. There are tons of places running production postgres, and indeed many other stateful services, in Kubernetes.

    Edit because presumably GP downvoted me for contradicting them, since I’ve personally overseen this in production at Fortune 100 companies and unicorn startups alike:

    https://dok.community/

    https://github.com/zalando/postgres-operator

    And plenty of YouTube videos from various kubecons and CloudNativeCons. Kubernetes is a runtime and provides plenty of primitives for safely running stateful workloads even better than otherwise possible. Anyone who says otherwise hasn’t bothered directly learning enough about the possibilities and is likely citing oft-quoted dogma that dates back to the earliest days of k8s and was questionable even then.

    • @vapeloki
      link
      English
      2
      edit-2
      1 year ago

      No, because of many factors:

      The last 10 years, I managed 700 database Clusters. Anything from a few megs to terrabyte database sizes.

      The main issues are:

      • huge pages. They work an bare metal, not so much in kubernetes ( I am not talking about transparent huge pages…)
      • Core/cache locality.
      • NUMA

      And of course: maintainability. Especially in the PIT recovery.

      Zalando has an open source operator + patroni bases images. They work for many cases, and are a great way if you can’t manage postgresql on bare metal.

      And of course: if you have everything running on k8s, running a few bare metal servers for a db is a pain in the ass, and in such cases it is if course better to just deploy an operator in your cluster and let it handle the heavy lifting like backup and replication.