Re: Running PostgreSQL in Kubernetes?

From: Vijaykumar Jain <vijaykumarjain(dot)github(at)gmail(dot)com>
To: Victor Sudakov <vas(at)sibptus(dot)ru>
Cc: Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org>
Subject: Re: Running PostgreSQL in Kubernetes?
Date: 2021-07-29 05:18:08
Message-ID: CAM+6J97yqWEnBO=GR6QA+-N6JiNFm+XW4H2ZtsnTsD95JfNHBg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

I am just asking in a different thread so as to not derail the original
conversation.
What was the real need to have postgresql cluster running in kubernetes?
I have experience in apache mesos, and did some beginner tutorial in
kubernetes, but in my case those were good for stateless services.
For dbs, we used to have dedicated vms for postgresql clusters on lvm and
vmware. It was very rare that we lost a physical server beyond recovery,
else most of the time, a reboot of the physical server would resolve the
issue. If we were able to figure out the problem with the physical server,
we would just vmotion(live migrate) the vm from one server to another and
survive fine.
so a large tb sized db, did not really require a resync on server problems.

Now with k8s, every time the server sneezes, the pods would get spawned
onto different servers that would result in a full resync unless volumes
could be moved.
Since containers are now in a shared environment, and if it is mostly over
committed, then tuning of various params of a instance would be totally
different compared to what was it on a dedicated vm.

Noisy neighbour's, a typical heavy activity like a bot attack on some
services, which do not touch the db that is on the same server will have a
serious impact due to shortage of resources.

in our case dns was under huge stress due to constant bouncing of services
and discovery compared to original monoliths but were not tuned to handle
that amount of changes and suffered stale cache lookups. For apps it would
be OK, as they implement circuit breakers , but intra pg setup for barman
or logical replication or pgbackrest would suffer a longer outage ?

Lastly, shared resources resulting in a poor query plan, like slow
vacuuming may degrade the db.

Now, I have 0 exp in kubernetes, but I tried to understand the basics and
found most of then similar to apache mesos. My use case was dbs grow and
they grow really fast so they cannot be the same as immutable containers ,
but idk. Like when in need of a increased memory, it was OK to have do that
for a vm and reboot, but for a pod, there is a risk of deployment and
moving the instance on another server ? Or else all the pods that server
would get bounced?

The point of these queries is just to have a conversation and understanding
the need to put dbs on k8s, not about making it about right or wrong.

Maybe just like ssd, hdd, postgresql community would come up with a cost
param to generate plans if run on k8s vs dedicated servers :).

Feel free to ignore, it's perfectly fine.

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Mukesh Rajpurohit 2021-07-29 05:50:34 Re: Multiple refcursor as INOUT parameter in procedure
Previous Message Stephen Frost 2021-07-28 20:34:51 Re: Running PostgreSQL in Kubernetes?