3 ms·

> If you don't need storage cluster with any other solution, then you don't need it with kubernetes. That is only half of the truth. If your application needs

> If you don't need storage cluster with any other solution, then you don't need it with kubernetes. That is only half of the truth. If your application needs a database, and which application doesn't, you have to store its data somewhere. So you either need a storage cluster, or you open the can of warms called local volumes and (anti-)affinity rules. For smaller application deployments, hosting a separate kubernetes cluster is extremely expensive in terms of time spend to debug infrastructure issues. k8s introduces orders of magnitudes of additional complexity to networking, dns, storage, routing, logging, etc. All in the name of making these exact same things easier for the developer. This can be a good separation of work, if you are large enough to afford a dedicated k8s maintenance team. But often it is not.

figassis 3y ago
Keep your db outside the cluster. Use a managed db or just host it on its own server. You should be doing that even if not using k8s anyway. Don’t share memory and cpu with your db. Regarding storage, try to build stateless apps that only need temporary storage that don’t need to outlive a request (like uploads). For long lived unchanging assets, you can try including in the container (ie. defaults.json, countries.json, samples.json, etc). For assets that need to be fresh, try to have the app generate at startup (eg. Email vírus definitions) or via init container. I think this will cover most use cases. This won’t work with apps that depend on shared storage like Wordpress, but Wordpress is horrible and I can’t support you running it :-)
vbezhenar 3y ago
I'm not sure I follow you about local volumes and affinity rules. I followed instructions on kubernetes website to create local volume and pod which uses this local volume was scheduled on the proper node every time. I think it works with volumeBindingMode: WaitForFirstConsumer option. So if you think that you need storage cluster either way, go ahead and deploy it. If you think that you're OK with single unreplicated database, just use local volume, it works. At least I've yet encounter any worm with this thing. For me it just worked. Another option is to use local volumes and replicated database setup. So you can run, say, two database instances in a replicated mode on two servers, but storage will be simple local volume. It provides some reliability and availability benefits without complex storage cluster solutions. I used cloudnative pg operator for this and it worked for me. I guess one can configure ordinary postgres replication without any operator, I just don't have experience with that. My opinion is that even single-node kubernetes cluster is worth it. That's because I have some experience and won't need time to learn basics. If someone does not have that experience, then I agree. Deploying kubernetes requires learning curve and that time might be spent for other things. At least it's hard for me to imagine any kubernetes complication that won't arise with, say, docker. At the same time, kubernetes provides lots of polished software line ingress-nginx, cert-manager, cloudnative-pg which could save some time. And, most importantly, using kubernetes from the start, provides very easy option for moving into cloud, for scaling, for zero-downtime deployments. Those things are valuable by almost everyone.

figassis 3y ago

Keep your db outside the cluster. Use a managed db or just host it on its own server. You should be doing that even if not using k8s anyway. Don’t share memory and cpu with your db. Regarding storage, try to build stateless apps that only need temporary storage that don’t need to outlive a request (like uploads). For long lived unchanging assets, you can try including in the container (ie. defaults.json, countries.json, samples.json, etc). For assets that need to be fresh, try to have the app generate at startup (eg. Email vírus definitions) or via init container. I think this will cover most use cases. This won’t work with apps that depend on shared storage like Wordpress, but Wordpress is horrible and I can’t support you running it :-)

vbezhenar 3y ago

I'm not sure I follow you about local volumes and affinity rules. I followed instructions on kubernetes website to create local volume and pod which uses this local volume was scheduled on the proper node every time. I think it works with volumeBindingMode: WaitForFirstConsumer option. So if you think that you need storage cluster either way, go ahead and deploy it. If you think that you're OK with single unreplicated database, just use local volume, it works. At least I've yet encounter any worm with this thing. For me it just worked. Another option is to use local volumes and replicated database setup. So you can run, say, two database instances in a replicated mode on two servers, but storage will be simple local volume. It provides some reliability and availability benefits without complex storage cluster solutions. I used cloudnative pg operator for this and it worked for me. I guess one can configure ordinary postgres replication without any operator, I just don't have experience with that. My opinion is that even single-node kubernetes cluster is worth it. That's because I have some experience and won't need time to learn basics. If someone does not have that experience, then I agree. Deploying kubernetes requires learning curve and that time might be spent for other things. At least it's hard for me to imagine any kubernetes complication that won't arise with, say, docker. At the same time, kubernetes provides lots of polished software line ingress-nginx, cert-manager, cloudnative-pg which could save some time. And, most importantly, using kubernetes from the start, provides very easy option for moving into cloud, for scaling, for zero-downtime deployments. Those things are valuable by almost everyone.