| ▲ | AtlasBarfed 12 hours ago | ||||||||||||||||||||||||||||
So you don't run any databases in those thousands of clusters? To your point, and I have not used k8s I just started to research it when my former company was thinking about shoehorning cassandra into k8s... But there was dogma around not allowing access to VM command exec via kubectl, while I basically needed it in the basic mode for certain one-off diagnosis needs and nodetool stuff... And yes, some of the floated stuff was "use sidecars" which also seemed to architect complexity for dogma's sake. | |||||||||||||||||||||||||||||
| ▲ | voidfunc 12 hours ago | parent | next [-] | ||||||||||||||||||||||||||||
> So you don't run any databases in those thousands of clusters? We do, but not of the SQL variety (that I am aware of). We have persistent key-value and document store databases hosted in these clusters. SQL databases are off-loaded to managed offering's in the cloud. Admittedly, this does simplify a lot of problems for us. | |||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||
| ▲ | pas 8 hours ago | parent | prev [-] | ||||||||||||||||||||||||||||
postgresql operators are pretty nice, so it makes sense to run stateful stuff on k8s (ie. for CI, testing, staging, dev, etc.. and probably even for prod if there's a need to orchestrate shards) > exec kubectl exec is good, and it's possible to audit access (ie. get kubectl exec events with arguments logged) and I guess and admissions webhook can filter the allowed commands but IMHO it's shouldn't be necessary, the bastion host where the "kubectl exec" is run from should be accessible only through an SSH session recorder | |||||||||||||||||||||||||||||