4 ms·
I really wish Kubernetes would make it's storage backend pluggable or the k3s folks would push their work to allow a SQL database as the backed upstream. Then y
by meddlepal 7y ago
I really wish Kubernetes would make it's storage backend pluggable or the k3s folks would push their work to allow a SQL database as the backed upstream. Then you could just back Kubernetes with some Cloud SQL offering.
- jacques_chester 7y agoI'd like that too (I trust SQLite more than almost anything), but it would prove difficult in some respects. Kubernetes intimately relies on etcd's watch capability. k3s does this with polling, which works fine, but some consideration would need to be given as to how to most effectively replicate that behaviour (eg. would LISTEN/NOTIFY work well on postgresql? I have no idea). Further out, a case can be made that the whole business of reconciliation is one of event stream processing. My gut feeling for some time has been that the intersection of event stream and bitemporalism[1][2] makes a lot of the problems that motivate consensus protocols approximately moot. Done properly it might be possible to do away with the need for a master for a lot of things, which would improve scalability, failure tolerance and security. [1] or Johnston's tritemporalism, I don't yet feel confident enough in my understanding to say. [2] I am not alone and probably not the first to think so. For an example of a streaming-oriented bitemporal store, see Crux: https://juxt.pro/crux/index.html https://juxt.pro/crux/index.html
- cpuguy83 7y agoAzure is testing an etcd frontend for CosmosDB specifically for the purpose of running Kubernetes. Doc for testing this out: https://github.com/Azure/aks-engine/tree/master/examples/cosmos-etcd https://github.com/Azure/aks-engine/tree/master/examples/cos...