3 ms·
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.co
by 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 agoLook 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 agoYou'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.