51–60 of 92 posts
dumb question - where is the storage kept?
dumb question - where is the storage kept?
Me who have never used kubernetes, what if node crash ? Will I lost everything ?
Obviously it's worth doing simulated disaster recovery to ensure you would recover if there is hardware failure. The larger the scale and throughput with parallel writes against the same keys, etc then the more complicated the setup will be. I hope to write more on this topic, but setting up a persistent volume with a NAS is a great way to ensure high durability.
dumb question - where is the storage kept?
The author mentions Longhorn, a storage solution from the people behind the k3s distribution, so I’m assuming the data is stored in pvc provisioned through longhorn.
Earlier quoted context omitted.
I've never been a fan of deploying DBs, either traditional RDBMS or distributed, under containerization/orchestration other than quickly spinning up dev and test environments. Certainly not for production. Databases have been built for high availability for many decades. Sure, maybe RDBMS doesn't scale quite as easily as a node API application, but it's still not really rocket science and you usually have some leeway…
Wouldn't most data driven, disk-IO intensive workloads be a bad fit for k8s? Especially when its not purely read-only.. That seems the crux of it.
So in both situations you have the same IO limits of block storage. The question is does k8s persistent volume api add enough of an IO bottleneck to cause issues, IME that isn't the case.
Now if you want direct attached NVMe drives for higher IO than a network attached block storage will give, then it might be easier with a VM vs k8s, but I can't speak to that much.
Just like with cloud providers, it seems to me like with kubernetes, it is not a matter of if but when orchestration problems will arise. Specially in this case of hosting databases, a composition of provisioning complexities (db operational complexities on top of k8s operational complexities) is really scary. Is there any way to overcome hidden complexity biting your hand other than studying k8s extensively?
In the case of running Postgres on K8s, the problem arises immediately when you try to resize a data volume and you can't because the API doesn't support it. K8s is not really for stateful systems, yet, and systems like Postgres that prefer to manage their own resources, you don't want another layer which doesn't cooperate to get in your way.
What API doesn't support it? k8s has support for resizing PVs and has for a while now. AFAIK all 3 cloud providers (and more) support increasing the PV using their storage class.
> K8s is not really for stateful systems, yet
Is this written somewhere or is it just your opinion?
Earlier quoted context omitted.
Honestly no, it's mostly due to inexperience with operators and not really understanding what the "best" way to find operators is. I did also look at the Crunch Data one (I was having some issues setting that one up), but didn't even find Zalando during my search. OperatorHub is currently the main resource I use, but GitHub stars aren't exposed in the search so I have been looking at the "Capability Level" chart and…
A subtle advantage of cnpg is that it doesn't use statefulsets, instead the operator handles things like mapping storage volumes and stable identities. Regular kubernetes statefulsets have some tricky sharp edges for failure recovery. I don't know if all of these alternatives use statefulsets but I remember several doing so. I've personally found cnpg to be pretty robust, and supports everything you will eventually n…
Is Kubernetes still hard in 2024?
dumb question - where is the storage kept?
OP uses Longhorn which is a whole other thing that I've only read about.
For at home you can use other storage classes like ceph, NFS, etc.
Is Kubernetes still hard in 2024?
If you don't need much orchestration (which is true for a lot of postgres users), the complexity from kubernetes is compounded on top of the complexity from postgres without generating much value.
Earlier quoted context omitted.
A subtle advantage of cnpg is that it doesn't use statefulsets, instead the operator handles things like mapping storage volumes and stable identities. Regular kubernetes statefulsets have some tricky sharp edges for failure recovery. I don't know if all of these alternatives use statefulsets but I remember several doing so. I've personally found cnpg to be pretty robust, and supports everything you will eventually n…
What sharp edges are you referring to with statefulsets?
Statefulsets have their place but are surprisingly inconvenient for database workloads.