Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Subject: Re: Running PostgreSQL in Kubernetes?
From: Scott Ribe <scott_ribe@elevated-dev.com>
In-Reply-To: 
 <CAM+6J97yqWEnBO=GR6QA+-N6JiNFm+XW4H2ZtsnTsD95JfNHBg@mail.gmail.com>
Date: Thu, 29 Jul 2021 06:47:38 -0600
Cc: Victor Sudakov <vas@sibptus.ru>,
 Pgsql-admin <pgsql-admin@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D8F7827F-4132-4B0A-91D0-47C3D1E143BC@elevated-dev.com>
References: <YP6QJja3b+2nZ3z7@admin.sibptus.ru>
 <CAM+6J97yqWEnBO=GR6QA+-N6JiNFm+XW4H2ZtsnTsD95JfNHBg@mail.gmail.com>
To: Vijaykumar Jain <vijaykumarjain.github@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/D8F7827F-4132-4B0A-91D0-47C3D1E143BC%40elevated-dev.com>
Precedence: bulk

> \On Jul 28, 2021, at 11:18 PM, Vijaykumar Jain =
<vijaykumarjain.github@gmail.com> wrote:
>=20
> What was the real need to have postgresql cluster running in =
kubernetes?

When you have everything else running in K8s, it's awkward to keep =
around a cluster of VMs just for your db--and running on dedicated =
hardware has its own tradeoffs.

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

You either have shared network volumes (persistent volume claims in K8s =
terminology), in which case the migrated server re-mounts the same =
volume. Or you can use local storage in which case the servers are bound =
to specific nodes with that storage and don't migrate (you have to =
manage this a bit manually, and it's a tradeoff for likely =
higher-performing storage).

Also, what makes you think the server will "sneeze" often? I cannot =
remember the last time postgres quit unexpectedly.

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

We don't find params to be different, but we are not really =
over-committed.

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

This is not really different than VMs. You either are able to manage =
this reasonably, or you need dedicated hardware.

> 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 ?=20

You needed to fix your services. If your DNS is overloaded because your =
apps are moving so much, then something is terribly, terribly wrong. Any =
way, your postgres instances certainly should not be moving, so stale =
lookups should not be a problem, even in such a circumstance.

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

Shared resources can slow things down, but I have no experience of that =
affecting what the appropriate query plan should be.

> 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?

As discussed above, movement of pods is not the problem you think it is. =
Network volumes, no problem moving; local storage, can't move.