Docker, Kubernetes, Terraform, and AWS crash course series • Hacker News Board

Re: Docker, Kubernetes, Terraform, and AWS crash course series

#81

Post by bzmrgonz » Wed, Jul 27, 2022, 2:19 PM UTC

bavell wrote: post #64

waynesonfire wrote: post #58

Earlier quoted context omitted.

No, you're way off. Maybe my reaction is extreme, but my problem isn't. What's yucky is that you're trying to convince people that reading five tutorials on k8s will make them productive. No, the problem, and I'll repeat it since you conveniently skipped over it, k8s requires 10+ engineers to maintain and manage, full time. _I_ don't have 10 engineers and thus it's the wrong tool for me and I've decided to not invest…

K8s is certainly a beast and I agree with your posts directionally but just as a counterpoint - as a solopreneur I've been using k8s to run my business workloads (on GKE) for the past 4 or 5 years now. I'm very comfortable with dev and ops and k8s is a force multiplier for me, letting me easily manage much more than I could without it (e.g. due to automation, tooling, community, etc). Building on top of a standardize…

This is a very interesting use-case for k8s. Can you expand on it some more? For instance, why did you you pick this over vhosting? You essentially took TESLA's Electric semi-truck, remove the cab, extend the chasis and slap a school bus body on top of it. I think I like it, but I'm wondering how stable it is. how much of set-it-and-forget-it benefit do you get out of it. Sometimes it's best to over-engineer to sleep good at night, knowing the limits will never be tested. This is why XCP-NG beats PROXMOX, because there's less wet nursing involved. Let me know if you have any write-up on this approach that you can share. I'd be interested in reading it.

Re: Docker, Kubernetes, Terraform, and AWS crash course series

#82

Post by vbezhenar » Wed, Jul 27, 2022, 9:32 PM UTC

thunky wrote: post #79

vbezhenar wrote: post #38

Earlier quoted context omitted.

I'll try to answer, but keep in mind that I'm newbie myself. > 1. Do i still need gluster/ceph or do i use the longhorn thing ? Kubernetes does not care about storage implementation. It contains some abstract ways to request a storage (PersistentVolumeClaim). And then some particular Kubernetes installation will fulfil this request with PersistentVolume. So basically it comes down to your Kubernetes provider. It shou…

> I think that simplest solution is some kind of NFS server. Kubernetes can consume it as well. Isn't this asking for trouble, running MySQL on top of NFS? Also a k-nube.

I don't have experience with that kind of setup, so can't really comment. Kubernetes is not magic, if you're running MySQL in NFS volume, it's just mysql process running in separate cgroup with mounted NFS volume. If you think that's a bad idea, don't do that. When it comes to processes and mounts, Kubernetes just arranges things and rest is done my ordinary Linux APIs. I tried to run Postgres with ceph volume and it works for me. You can configure database to just use local storage. Of course if your server will die, your database will die, so probably you will want some kind of cluster setup or be ready to restore database from backup if that happens. Or you can start with simple setup and migrate to something more complex in the future.

Re: Docker, Kubernetes, Terraform, and AWS crash course series

#83

Post by thunky » Thu, Jul 28, 2022, 1:29 PM UTC

vbezhenar wrote: post #82

thunky wrote: post #79

Earlier quoted context omitted.

> I think that simplest solution is some kind of NFS server. Kubernetes can consume it as well. Isn't this asking for trouble, running MySQL on top of NFS? Also a k-nube.

I don't have experience with that kind of setup, so can't really comment. Kubernetes is not magic, if you're running MySQL in NFS volume, it's just mysql process running in separate cgroup with mounted NFS volume. If you think that's a bad idea, don't do that. When it comes to processes and mounts, Kubernetes just arranges things and rest is done my ordinary Linux APIs. I tried to run Postgres with ceph volume and it…

I hadn't heard about k8s "local storage". IIUC this fixes each pod to a single node, so the potential benefits of k8s can't be fully realized. It seems that clustering could still be achieved by running muliple instances across multiple nodes, each with local storage. I might still prefer this to having to manage NFS and any difficulties that might come from using MySQL with remote disks.

It just seems like k8s is coercing people to do things that they normally wouldn't do: MySQL on NFS, Postgres on Ceph, etc. In this case, OP just wants to "kubernetify my run of the mil lamp app" and is now being pointed towards NFS, Ceph, etc. I can't help but wonder if the juice is worth the sqeeze. Especially for services like databases that for most people probably don't really require dynamic provisioning or orchestration.

Re: Docker, Kubernetes, Terraform, and AWS crash course series

#84

Post by bavell » Mon, Aug 01, 2022, 12:29 AM UTC

bzmrgonz wrote: post #81

bavell wrote: post #64

Earlier quoted context omitted.

K8s is certainly a beast and I agree with your posts directionally but just as a counterpoint - as a solopreneur I've been using k8s to run my business workloads (on GKE) for the past 4 or 5 years now. I'm very comfortable with dev and ops and k8s is a force multiplier for me, letting me easily manage much more than I could without it (e.g. due to automation, tooling, community, etc). Building on top of a standardize…

This is a very interesting use-case for k8s. Can you expand on it some more? For instance, why did you you pick this over vhosting? You essentially took TESLA's Electric semi-truck, remove the cab, extend the chasis and slap a school bus body on top of it. I think I like it, but I'm wondering how stable it is. how much of set-it-and-forget-it benefit do you get out of it. Sometimes it's best to over-engineer to sleep…

I'll consider writing a blog post on it but long story short, it's very stable and hands-off when using a managed service. I started off with some DO droplets when I first launched my business and adopted k8s around v1.6. It was a little rough back then but now I spend maybe a few hours a month max on managing my clusters, mostly just upgrading the nodes and core components (cert-manager, nginx-ingress-controller).

I fell in love with it because of the dev and ops experience. Just the shift of perspective from pets to cattle is a big improvement. Deploying via sftp is simple but k8s really helps me with the other aspects (monitoring, logging, scheduled tasks, TLS cert mgmt, blue/green deploys, multiple environments, etc) of managing apps that my clients use regularly and depend on. It's nice having one API platform that can handle all of this and feels more like assembling Lego blocks instead of bespoke solutions for every project.

Hope that gives you some insight!