Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The future of Kubernetes is virtual machines

tech.paulcz.net

Post reply on HN
Print view View original

31–40 of 128 posts

Re: The future of Kubernetes is virtual machines

#31

Post by lykr0n »

serverascode wrote: post #29
lykr0n wrote: post #18

Earlier quoted context omitted.

OpenStack's failure is that it's an extremely complex system that looks to be nearly impossible to deploy by yourself. You have to use a Distro that does everything for you- their way. Kubernetes is simple enough to setup yourself. They have well documented tooling, and a solid do it yourself guide. OpenStack has none of that (that I can find). You select RedHat Openstack (RDO) or Canonical OpenStack (MAAS), and you…

You don't have to use a distro. There are well tested puppet modules, which you could make into your own "distro", as well as openstack-ansible and kolla, and openstack-helm which uses helm to deploy openstack. There is also StarlingX. There is no kubeadm like system however, though I'm not sure how many people will really use kubeadm in prod. Is it complex? Yes. Is it more complex than k8s? Probably. However, are th…

True. My only experience is with VMware OpenStack, and my quick googling didn't turn up much info. I think Kubernetes will fall to the same fate as OpenStack is sliding into. Growing complexity with promises of the world. Time will tell.

You seem to know more than I do, so I got to ask. Why does openstack-helm exist? Why would anyone want to deploy OpenStack on top of kubernetes? Is it so you can have the OpenStack API run in Kubernetes that manages physical boxes?

Re: The future of Kubernetes is virtual machines

#32

Post by dehrmann »

orliesaurus wrote: post #8

This feels like an infinite russian doll problem, putting k8s inside a bunch of vms I mean.. but I am glad that while everyone is still trying to learn how to properly do k8s these folks are thinking of the next thing

And running a Java services in the JVM. It's not real infrastructure unless you have at least four layers of VMs.

Re: The future of Kubernetes is virtual machines

#33

Post by mcguire »

As someone who has been a sysadmin and system programmer for 25 years and a crusty rat bastard for almost that long, I have to wonder how long it is going to be until someone realizes that a piece of hardware doing a task is more efficient than 27 layers of virtual machines and a long pair of tongs.

Re: The future of Kubernetes is virtual machines

#34

Post by davidmr »

amscanne wrote: post #6

An important element of Kubernetes is that it standardizes the infrastructure control plane, and allows different pieces to be plugged in (for networking, storage, etc.). The "virtual kubelet" essentially throws that all that away and keeps Kubernetes "in API only". For example, with virtual kubelets, scheduling is meaningless and networking and storage are restricted to whatever the virtual kubelet target supports (…

I agree, but I think I’ve put less thought into it than you have. Just because I tend to focus on research and low-latency infrastructure, I’ve been really happy with the container-first approach. I really like being able to deal with these processes at the Linux level instead of the VM level and being able to tweak that stuff (cpu placement and isolation, accelerators and rdma network devices, etc.) There’s a reason VMs never really took off in HPC, but I think CRI-O is really poised to change the HPC paradigm, and k8s can be really beneficial in some business applications of HPC.

I definitely understand and agree that multitenancy is super important, but it would be a shame to agree that the bare metal performance is an okay sacrifice.

Re: The future of Kubernetes is virtual machines

#35

Post by elsonrodriguez »

The future of Kubernetes (for some interesting use cases), is virtual machines. For the rest of us the virtual kubelet project represents a bridge between Kubernetes and Serverless.

I'd much rather pay my cloud provider to run my k8s workloads (billed by pod requests/limits) than pay for a control plane and three nodes just to run my workloads.

Re: The future of Kubernetes is virtual machines

#36

Post by nimbius »

mcguire wrote: post #33

As someone who has been a sysadmin and system programmer for 25 years and a crusty rat bastard for almost that long, I have to wonder how long it is going to be until someone realizes that a piece of hardware doing a task is more efficient than 27 layers of virtual machines and a long pair of tongs.

amen. At first i figured containers were a good way to run code with difficult dependencies and weird operating environments, but that still doesnt make sense.

- systemd and uwsgi for example play well when run as a single user per wsgi application under a single nginx/lb.

- php-fpm already handles a ton of overhead from php apps.

- ansible deployments called from gitlab-ci can roll out apps just as well as deploying from the registry.

then i figured maybe they were on to something with the autoscaling thing...but that seems like a meaningless feature. Every good project already has metrics and forecasting...it would be absurd to think a final product like imgur.com or twitter does not know (down to the byte) how much storage theyll need in 4 months and the potential drivers.

auto-scaling infrastructure just betrays the fact that most developers throw resources at load problems instead of waiting for ops to figure out the actual issue.

Re: The future of Kubernetes is virtual machines

#37

Post by state_less »

While the use of namespaces seemed a bit discounted in the article, I think part of the problem is that it's an underutilized and poorly conveyed feature, but maybe that's just me? I'd like to see a better out-of-the-box vanilla K8S user management interface in the dashboard. Maybe the default UX on cluster creation is a user/service account that isn't cluster admin that is limited to 1 or more namespaces. There should be a better dashboard to configure and create users that is front and center when you first create a cluster. You have to work a bit to get something you can use to authenticate as cluster admin like role. This should help direct people towards creating more users and isolated namespaces.

Re: The future of Kubernetes is virtual machines

#38

Post by justicezyx »

state_less wrote: post #37

While the use of namespaces seemed a bit discounted in the article, I think part of the problem is that it's an underutilized and poorly conveyed feature, but maybe that's just me? I'd like to see a better out-of-the-box vanilla K8S user management interface in the dashboard. Maybe the default UX on cluster creation is a user/service account that isn't cluster admin that is limited to 1 or more namespaces. There shou…

Also gVisor.

Re: The future of Kubernetes is virtual machines

#39

Post by la6470 »

mcguire wrote: post #33

As someone who has been a sysadmin and system programmer for 25 years and a crusty rat bastard for almost that long, I have to wonder how long it is going to be until someone realizes that a piece of hardware doing a task is more efficient than 27 layers of virtual machines and a long pair of tongs.

Spot on mate! I still don’t understand why we are still reinventing the wheel .. we have been through Solaris zones and VMware and Fargate yet here we are talking about hypervisor again. How is kubernetes any different that VMWare orchestrator except the terminologies are different and it is free (you pay in terms of engineering costs). Now Kubernetes and the ecosystem may seem very interesting to many engineers but in terms of its cost to the business what is it really buying the business? For long timers like us it seems like old wine in new bottle.

Re: The future of Kubernetes is virtual machines

#40

Post by lightedman »

Can't handle real machines, so let's virtualize everything despite the fact we don't have the physical machines fixed or sussed-out, yet.

Bravo. Now I see why we've got the problems that intel, AMD, and ARM suffer from. Nobody's bothering to fix a single thing and are just passing the buck like typical lazy developers.

Post reply on HN