3 ms·

Yes, but we're not talking about IP and this misses the point. Kubernetes, as a technology, has support tooling being built around every interface it has. Jus

• throwanem 5y ago
  In full production deployment, sure, but in full production deployment everything is "enshrouded by support tooling" - or had better be, if you want to be able to recognize and respond to incidents in a timely fashion. But if that's not a requirement, there are easier options - my Kubernetes home lab, for example, I set up in about 20 minutes with k3s [1], and it's been ticking happily along for over a year at this point with zero administrative burden. Granted, it'll be a PITA if that ever breaks, but it's a lab and I don't have to care more about downtime than I want to; at worst I'll tear it down, follow my notes from last time to stand it up again, and reapply my manifests out of source control. Meanwhile, as a developer, I find that k8s does simplify a great deal with regard to deploying services and managing them once deployed - this, in turn, makes life easier for our infra folks, who no longer have to spend so much time splitting focus to provide direct dev support for deployment issues. Which is after all one of the reasons to run Kubernetes at all! It's built to simplify things, but not to simplify everything; there is a deal of irreducible complexity involved in the domain k8s addresses, and because it is indeed irreducible, that complexity can at best be managed and abstracted, not removed. That's what k8s intends to do, and in my experience it does that quite well - not without tradeoffs, true enough, but when in our line of work is that ever not the case? [1] I mention this in particular because I used to take a view much like you do here, until an HN commenter pointed out in response to my own such fussing that it didn't have to be as complicated as I had understood it to be, and recommended trying k3s in that wise. It's been a year and I no longer remember who that was, but they were absolutely correct regardless!
  • dolni 5y ago
    If I can summarize your points in short, I'm getting that your view of Kubernetes is that it abstracts complexity that is inherent to our problem domain in an attempt to simplify it as best it can. In particular that is true around deployments. Point taken, and it's a valid one. I'll throw some more of my perspective at you here (from a guy who mainly uses AWS managed services). Let's talk scaling. Scaling is, and has been a solved problem before Kubernetes (see autoscaling groups). Imagine an autoscaling group whose instances launch and run one docker container -- your service (maybe also nginx, if you want). Maybe you even went the extra mile and baked your app's docker container into an AMI so you don't take a runtime dependency on Docker Hub or similar. In an autoscaling group, you define where instances can launch and what type you want. You can get fancy about capacity by leveraging weighted capacities to increase instance type diversity. You set the amount of capacity you want, and it goes. ASG instances register with a target group behind a load balancer, and you're off to the races. Oh and by the way: if any of those things break, it's Amazon's problem, not mine (could be good or bad; I personally think it's good). AWS has scaling figured out. Busy neighbors? Can't say that I have been impacted by that recently. Run out of disk? The impact of that is limited to one node that can be respun independently of everything else. Kubernetes scaling is a similar story with a different interface... except now you have to worry about how services stack up on nodes. For example, suppose you have a node of size "4X" and a service of size "3X" (X can be whatever limiting factor you want - CPU or memory). You now have to deal with the potential issue of 1X being wasted on nodes that the 3X service is deployed to. Maybe there's a 1X service that can slot in there. Maybe the 1X service is not scaled as high as the 3X service, so some nodes just sit there with wasted utilization. You can deploy the 3X service to a correctly sized node group, but that's another thing to manage. You could go the route of oversubscribing resources, which would save money but it's another failure mode for your infrastructure. If you run Kubernetes on AWS, it's probably using autoscaling groups anyway. And then on top it's doing its own orchestration. So to run Kubernetes on AWS, you have to understand both autoscaling AND how Kubernetes works. How about security? The wisdom of the day is: don't colocate sensitive services on the same Kubernetes nodes due to container escape concerns (and probably some others). So now you're looking at running an entirely separate Kubernetes cluster, or at least segregating the sensitive service to a different set of nodes. That's more management that is simply a non-issue running a VM-focused workload. How about load balancing? AWS can manage your load balancer and get you an SSL certificate that renews automatically. In Kubernetes, you can use the managed stuff or roll your own load balancing. If you elect to roll your own, you get the same functionality -- except if it breaks, it's your problem. If you roll with the managed stuff, you now have to understand not only how AWS load balancing works, but also how Kubernetes interacts with it. If the Kube interfaces breaks, it's probably your problem. I could continue here, but I think you get the idea. The central issue of Kubernetes is that you take on more problems than you otherwise have to versus using managed services. Amazon has entire teams working SPECIFICALLY on autoscaling, load balancing, SSL cert provisioning, etc. Any individual or team who thinks they can do better (in addition to their other job duties) probably has a bit of an ego issue.