4 ms·

Same here. Running ~100 app servers in K8S and the rest (databases & legacy apps) as regular GCE instances with PD drives. But long term going K8S-only is instr

Same here. Running ~100 app servers in K8S and the rest (databases & legacy apps) as regular GCE instances with PD drives. But long term going K8S-only is instrumental for us to prevent vendor lock-in. I really hope that storage for K8S happens this year in a form that is simpler than Gluster/Ceph/etc and preferably integrated. Right now we're using NFS and it's ok for the simple applications but I right now I wouldn't dare deploy my databases in K8S and feel good about it. What gives me hope is the speed the K8S is moving forward and the superb experience we had thus far.

bogomipz 10y ago
Any idea how does GCE handles PD drives underneath your K8? Is it network-attacched storage? Are those NVMe drives I wonder?
- bogomipz 10y ago
  I thought this was a valid question as I am curious how you you able to run databases using K8 on GCE. Why would somebody downvote asking a question?
TheIronYuppie 10y ago
What would it look like to be integrated? Could you just use your existing node solutions and hostpath and be set? Disclosure: I work at Google on Kubernetes
- adictator 10y ago
  I think NFS without its issues (performance & security) would be ideal as an integrated solution.
  - brazzledazzle 10y ago
    If you can solve that elegantly and safely I suggest you build a startup around it.
brazzledazzle 10y ago
Correct me if I'm wrong, but if you have the storage solved for the rest why not just use that same storage mechanism? If you're using local storage on your legacy applications and are essentially bound to the one node why couldn't you tag one node and use hostpath in kubernetes? Since these applications are fundamentally not designed for something like kubernetes what everyone seems to be asking for is Kubernetes to provide network storage that has the good things from NFS but faster. I could be way off base here but asking for a simple and performant solution to this problem from projects like kubernetes just doesn't seem reasonable. Network storage, particularly the type that provides traditional filesystem semantics, is a hard space all on its own. To put it another way, it sounds like people are asking kubernetes to take single node applications dependent on traditional filesystems and provide a magical performant network storage layer to make those failover seamlessly between kubernetes nodes with no (or tunable?) data loss. For those asking for this how would _you_ go about creating such a system? Just thinking through that a little should make it clear that what you're asking for isn't just a solution to a very difficult problem, it's a solution that is, I think, worth quite a lot of money to the person/group that solves it elegantly. I would genuinely love to be proven wrong here so by all means destroy my argument with extreme prejudice.
- icebraining 10y ago
  There's ZREP [1]. It uses the snapshots feature of ZFS, which can send them over the network, to continually (but asynchronously) mirror the local filesystem to a remote machine. It seems to provide exactly the features required (fast local access with failover), at the expense of a window of lost data (since the replication isn't synchronous and confirmed). [1] http://www.bolthole.com/solaris/zrep/ http://www.bolthole.com/solaris/zrep/

bogomipz 10y ago

Any idea how does GCE handles PD drives underneath your K8? Is it network-attacched storage? Are those NVMe drives I wonder?

bogomipz 10y ago
I thought this was a valid question as I am curious how you you able to run databases using K8 on GCE. Why would somebody downvote asking a question?

TheIronYuppie 10y ago

What would it look like to be integrated? Could you just use your existing node solutions and hostpath and be set? Disclosure: I work at Google on Kubernetes

adictator 10y ago
I think NFS without its issues (performance & security) would be ideal as an integrated solution.
- brazzledazzle 10y ago
  If you can solve that elegantly and safely I suggest you build a startup around it.

brazzledazzle 10y ago

Correct me if I'm wrong, but if you have the storage solved for the rest why not just use that same storage mechanism? If you're using local storage on your legacy applications and are essentially bound to the one node why couldn't you tag one node and use hostpath in kubernetes? Since these applications are fundamentally not designed for something like kubernetes what everyone seems to be asking for is Kubernetes to provide network storage that has the good things from NFS but faster. I could be way off base here but asking for a simple and performant solution to this problem from projects like kubernetes just doesn't seem reasonable. Network storage, particularly the type that provides traditional filesystem semantics, is a hard space all on its own. To put it another way, it sounds like people are asking kubernetes to take single node applications dependent on traditional filesystems and provide a magical performant network storage layer to make those failover seamlessly between kubernetes nodes with no (or tunable?) data loss. For those asking for this how would _you_ go about creating such a system? Just thinking through that a little should make it clear that what you're asking for isn't just a solution to a very difficult problem, it's a solution that is, I think, worth quite a lot of money to the person/group that solves it elegantly. I would genuinely love to be proven wrong here so by all means destroy my argument with extreme prejudice.

icebraining 10y ago
There's ZREP [1]. It uses the snapshots feature of ZFS, which can send them over the network, to continually (but asynchronously) mirror the local filesystem to a remote machine. It seems to provide exactly the features required (fast local access with failover), at the expense of a window of lost data (since the replication isn't synchronous and confirmed). [1] http://www.bolthole.com/solaris/zrep/ http://www.bolthole.com/solaris/zrep/