4 ms·

Let's say a new Kubernetes version comes out in April. In November, as everything works perfectly well, you decide to install a Postgres operator on it. Bummer,

Let's say a new Kubernetes version comes out in April. In November, as everything works perfectly well, you decide to install a Postgres operator on it. Bummer, it doesn't work. It's not a huge issue, you just wait until the bug is resolved (already done[0]), but it's just one of these tiny things that I don't get when running Postrges natively. And I'm saying this as a big fan of Crunchy Data running some production loads on it without a failure for quite some time now. [0] https://github.com/CrunchyData/postgres-operator/issues/3476 https://github.com/CrunchyData/postgres-operator/issues/3476

thunky 4y ago
And that repo you linked to has 1846 issues, 161 open. Which doesn't seem extraordinary based on my limited exposure to k8s. Another example: https://github.com/zalando/postgres-operator/issues https://github.com/zalando/postgres-operator/issues with 445 open issues. Why? Maybe I'm wrong and this is all a good sign of progress, but my impression is that the entire k8s ecosystem is held together with reused duct tape.
- Too 4y ago
  Look at the feature-list of that repo. Half of it are actually deficiencies in postgres that warrants the external complexities, not something induced by kubernetes. Sure, a lot of it is nice-to-haves but some are absolutely essential for even a basic postgres deployment even if you used VMs... Like, why is replication so difficult, why do i need all these extensions and why do i need to deploy a bouncer as a separate service in 2023?!
  - thunky 4y ago
    You're probably right and I'm probably being unfair. My opinion is colored by seeing HA postgres deployed on k8s for no good reason, then having to deal with the consequences. It just seems like once you're in the k8s world, the likelihood that your system will be massively over-engineered goes way up. This isn't the fault of the operators, or k8s itself, it's more of a cultural problem I think. And resume driven development is real.

thunky 4y ago

And that repo you linked to has 1846 issues, 161 open. Which doesn't seem extraordinary based on my limited exposure to k8s. Another example: https://github.com/zalando/postgres-operator/issues https://github.com/zalando/postgres-operator/issues with 445 open issues. Why? Maybe I'm wrong and this is all a good sign of progress, but my impression is that the entire k8s ecosystem is held together with reused duct tape.

Too 4y ago
Look at the feature-list of that repo. Half of it are actually deficiencies in postgres that warrants the external complexities, not something induced by kubernetes. Sure, a lot of it is nice-to-haves but some are absolutely essential for even a basic postgres deployment even if you used VMs... Like, why is replication so difficult, why do i need all these extensions and why do i need to deploy a bouncer as a separate service in 2023?!
- thunky 4y ago
  You're probably right and I'm probably being unfair. My opinion is colored by seeing HA postgres deployed on k8s for no good reason, then having to deal with the consequences. It just seems like once you're in the k8s world, the likelihood that your system will be massively over-engineered goes way up. This isn't the fault of the operators, or k8s itself, it's more of a cultural problem I think. And resume driven development is real.