181–190 of 681 posts
Do you guys think k8s is doing a job which previously the jvm did in enterprise? i.e. if everything is on the jvm, building distributed systems doesn't require a network of containers. Can k8s success be explained partly due to the need for a more polyglot stack?
Is it as easy as two simple commands?
Earlier quoted context omitted.
IaaS is not "the cloud". it was in 2008 when all we had was EC2 and RDS. Today Kubernetes is the antithesis of the cloud - Instead of consuming resources on demand you're launching VMs that need to run 24/7 and have specific roles and names like "master-1". Might as well rent bare-metal servers. It will cost you less.
> Might as well rent bare-metal servers In light of this statement, what do you make of the fact that billions of dollars are spent on EC2? And of the people who spend that money?
Earlier quoted context omitted.
I use Swarm in production and am learning k8s as fast as possible because of how bad Swarm is: 1. Swarm is dead in the water. No big releases/development afaik recently 2. Swarm for me has been a disaster because after a couple of days some of my nodes slowly start failing (although they’re perfectly normal) and I have to manually remove each node from the swarm, join them, and start everything up again. I think this…
To add another side, I use Swarm in production and continue to do so because of how good it is. I've had clusters running for years without issue. I've even used it for packaging B2B software, where customers use it both in cloud and on-prem - no issues whatsoever. I've looked at k8s a few times, but it's vastly more complex than Swarm (which is basically Docker Compose with cluster support), and would add nothing fo…
If K8s supported compose scripts out of the box (not Kompose) that'd basically make Swarm unnecessary (at least for me)
Earlier quoted context omitted.
I think the point is that there are people that claim that k8s adds a ton of complexity to your environment. But if you compare k8s alone with managing your infrastructure using (non-k8s) AWS or GCP primitives, you'll find that the complexity is similar.
While that's true on the managing instances side, you also need to actually deploy the infrastructure to manage them (If you're not using some PaaS offering). You don't need to do this for other IaaS. Honestly the last time I looked at k8s was like 5 years ago, but back then it looked like a pretty big pita to admin.
It is a completely different world that stretches far beyond Kubernetes, though I attribute much of the change to what has happened from / around k8s -> cncf
It's so easy, I can launch production level clusters is 15 minutes with four keystrokes and make backups and restore to new ephemeral clusters with a few more simple commands
https://github.com/hofstadter-io/jumpfiles
(I'll be pushing these updates this weekend, haven't slept in 24 hours as reworked everything to be powered by https://cuelang.org )
I dont want do memory management-> gc
I dont want to do packaging -> Docker
I dont want to do autoscaling -> Kubernetes
Earlier quoted context omitted.
IaaS is not "the cloud". it was in 2008 when all we had was EC2 and RDS. Today Kubernetes is the antithesis of the cloud - Instead of consuming resources on demand you're launching VMs that need to run 24/7 and have specific roles and names like "master-1". Might as well rent bare-metal servers. It will cost you less.
Doesn't kubernetes also have autoscaling capabilities? https://kubernetes.io/blog/2016/07/autoscaling-in-kubernetes...
Although, managed kubernetes clusters let you auto-scale the cluster itself, so i think the GP is wrong.
That being said, I will also be the first one to recognize that PLENTY of workloads are not made to run on Kubernetes. Sometimes it is way more efficient to spawn an EC2/GCE instance and run a single docker container on it. It really depends on your use-case.
If I had to run a relatively simple app in prod I would never use Kubernetes to start with. Kubernetes starts to pay itself off once you have a critical mass of services on it.
I completely understand the use case for Kubernetes when you're dealing with languages that require a lot of environment config, like Python. I've never really thought it was that useful for (for example) nodejs, where you can just npm install your whole environment and deps, and off you go.
- Automatic scaling of pods and cluster VMs to meet demand.
- Flexible automated process monitoring via liveness/readiness probes.
- Simple log streaming across horizontally scaled pods running the same app/serving the same function using stern.
- Easy and low cost metrics aggregation with Prometheus and Grafana.
- Injecting secrets into services.
I'd imagine there are other things can offer the same, but I find it convenient to have them all in the same place.
Earlier quoted context omitted.
IaaS is not "the cloud". it was in 2008 when all we had was EC2 and RDS. Today Kubernetes is the antithesis of the cloud - Instead of consuming resources on demand you're launching VMs that need to run 24/7 and have specific roles and names like "master-1". Might as well rent bare-metal servers. It will cost you less.
If that is your definition of "cloud" then most stuff running on AWS and other "cloud" providers isn't. I agree that Kubernetes and even containers aren't the end all. I think they are a stepping stone to true on demand where you have the abstraction of just sandboxed processes compiled to WASM or something run wherever. But as of where we are now, it is a good abstraction to get there. It provides a lot of stuff lik…
For me, and many others: infrastructure as code. Kubernetes is very complex and took a long time to learn properly. And there have been fires among the way. I plan to write extensively on my blog about it. But at the end of the day: having my entire application stack as YAML files, fully reproducible [1] is invaluable. Even cron jobs. Note: I don't use micro services, service meshes, or any fancy stuff. Just a plain…