Kubernetes for Small Projects

I'll add my opinion as a DevOps engineer, not a startup, so take it with a grain of salt.* Kubernetes is great for a lot of things, and I think there's many use cases for it where it's the best option bar none* Particularly once you start piling on requirements - we need logging, we need metrics, we need rolling redeployments, we need HTTPS, we need a reverse proxy, we need a load balancer, we need healthchecks. Many (not all!) of these things are what mature services want,

If your application doesn't need and likely won't need to scale to large clusters, or multiple clusters, then there's nothing wrong per se. with your solution. I don't think k8s is that hard but there are a lot of moving pieces and there's a bit to learn. Finding someone with experience to help you can make a ton of difference.Questions worth asking:- Do you need a load balancer?- TLS certs and rotation?- Horizontal scalability.- HA/DR- dev/s

Kubernetes scales down pretty well. I don't use network layers or crazy ingress setups. I keep it simple and Kubernetes works great.What's wonderful is that when I work on multiple clouds, my knowledge transfers just fine. I don't think of the AWS solution or the GCS solution, I use the same kubectl to check out both, view logs, inspect and fix.Even when I got tired of waiting for GKE to spin up a node, running Github actions on a self-hosted microk8s meant instant pod start

Kubernetes is a solution for 90% of the effort and services needed for distributed apps running and interacting with each other over a cluster of servers. Those accessory services aren't abstracted, I never used that word. They are instead provided out of the box by K8S, leading to fewer individual components to run, maintain and monitor yourself. You can switch out components at any level, from a single container running your favorite webserver, to a full service mesh, to your own custom c

Digital Ocean's managed Kubernetes offering has been great for me.There's lots of potential complexity to K8s, but if you're not managing the cluster and you have simple workloads the ratio of "stuff you have to learn" to "benefits you get" is pretty high. You can deploy anything that runs in a container, so it's really good for experimenting and not being tied down to one language or platform.I can add a new service by copying and pasting a yaml fil

I think it's easier to run a small k8s cluster than it is to attempt to recreate a lot of the functionality provided manually, especially if you're running in a cloud where the control plane is handled for you.It provides unified secrets management, automatic service discovery and traffic routing, controllable deployments, resource quotas, incredibly easy monitoring (with something like a prometheus operator).Being able to have your entire prod environment defined in declarative

my advice is use k8s if you know it, don't if you don't

"Nowadays, everybody insists on putting stuff on K8s regardless of how large or small it is."But if you already have the tooling, experience and support for k8s, why wouldn't you use it?I can fire up a k8s cluster on any major cloud provider in minutes (or bare metal in slightly longer), and deploy almost any web app using a standard interface that has extremely wide adoption.K8s supports a ton of things, but you don't have to use them. It can be complicated, but usu

Yeah if you study over it instead of copy pasting stuff from the internet, I find k8s the best thing for my small projects. I only have to setup a simple dockerfile and helm chart and I can run a new service in my cluster on DO, for which they offer free control plane, and not be billed for a completely new app and have to setup all my deps and env vars in a clunky UI. I can setup scaling, ingress easily, the Datadog agent is going to pick it up automatically, I can have services communicating v

I lean conservative in my tech choices but I just don't see the big issue with Kubernetes. If you use a managed service like GKE it is really a breeze. I have seen teams with no prior experience set up simple deployments in a day or two and operate them without issues. Sure, it is often better to avoid the "inner platform" of K8s and run your application using a container service + managed SQL offering. But the difference isn't huge and the IaC ends up being about as complex