> What problem is k8s even trying to solve?<p>> Say you want to deploy two Python servers. One of them needs Python 3.4 and the other needs Python 3.5.<p>Honestly hilarious. The core value prop example is if you want to run two minor version different programming languages on one machine. In order to do that, you get to deploy and configure hundreds to thousands of lines of yaml, learn about at least 20 different abstraction jargon terms, and continue to spend all your time supporting this mess of infrastructure forever.<p>How many engineering teams adopt kubernetes because it's what everyone's doing, versus out of genuine well-specified need? I have no idea.<p>I use k8s at work, i know it has benefits, but it too often feels like using a bazooka to butter your toast. We don't deploy to millions of users around the globe, and we're all on one python version (for library compatibility, amongst other things). Docker is an annoying curse more than it's a boon. How much of this complexity is because python virtualenvs are confusing? How much would be solved if instead of "containers" we deployed static binaries (that were a couple hundred mb's larger apiece because they contained all their dependencies statically linked in... but who's counting). Idk. Autoscheduling can be nice, but can also be a footgun. To boot, k8s does not have sane defaults, everything's a potential footgun.<p>In 10 years we're going to have either paved over all of the complexity, and k8s will be as invisible to us then as linux (mostly) is today. Or, we'll have realized this is insanity, and have ditched k8s for some other thing that solves a similar niche.<p>edit: I realize this is a salty post. I don't mean to make anyone feel bad if they love to think about and use k8s. I appreciate and benefit from tutorial articles like this just as much as the next dev. It's just the nature of the beast at this point, I think.
Although most of the articles focus on the benefits of Kubernetes for work, where you usually have more options (e.g. AWS Fargate), I've found it extremely helpful in the case where you want to self-host stuff personally/"at home", but you also want above average resilience so you use multiple nodes (e.g. 3 raspberry pi).<p>You can probably DIY something or always run all the things on all 3 nodes to achieve the same effect, but the first time I saw a node going down and Kubernetes automatically deployed the affected pods to a healthy node, it felt like having AWS on-prem.<p>Also, doing things in a standard way each time means it's really easy to bootstrap new things, not always reinventing the wheel. Especially cron jobs, I always lost track of those before. Now it's really easy to get an overview. Secrets as well, having it built-in just saves so much "how should I do this again".<p>Plus base OS upgrades are now really uneventful, since besides k3s (single-binary Kubernetes distribution), there's nothing else installed on the host.<p>The complexity is of course higher, you need a load balancer to point to all your cluster IPs since we don't get one "for free" from the cloud, shared storage is still something I'm looking into what's the best way to do (NAS with NFS, minio, ...), you most likely need a private registry, and probably others I'm missing.<p>Nonetheless, since migrating from manually run docker images, I find it a lot more comfortable and even with less downtime (taking down a single node is a non-event now versus "everything is down").
I still believe Kubernetes is one of the best tools out there to build scalable systems. But I wish it was more opinionated and less leaky.<p>Every project I build feels like a Frankenetes made of many subsystems provided by different vendors that struggle to talk to each other.<p>The day Kubernetes provides curated bundles for common architectures that I can spin up with a few commands, I will be in love with it. For now I have a love/hate relationship with it.
For a startup, I'm still trying to figure out why you would use k8s instead of Google App Engine or other managed PaaS. You never worry about the problems listed in this article. You focus on writing code, deploying it with minimal config and let Google handle all these problems. Can anyone explain?
The biggest problem I see is that the headline is ambiguous: it can be interpreted as "how to use Kubernetes to solve common problems," or alternately "how to solve problems commonly encountered in Kubernetes".
> Setting up an IngressController is probably the job of a specialized Platform team who maintain your k8s cluster, or by the cloud platform you're using.<p>What? I thought this was a solution solving problems, not making ones which you should not solve...