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

101–110 of 128 posts

Re: The future of Kubernetes is virtual machines

#101

Post by dcow »

davidopp__ wrote: post #80
jacques_chester wrote: post #65

Earlier quoted context omitted.

> I don't think multi-tenancy has been "retrofitted" onto Kubernetes. Kubernetes was designed with multi-tenancy in mind from the very early releases -- namespaces, authn/authz (initially ABAC, later RBAC), ResourceQuota, PodSecurityPolicy, etc. My complaint is that these require assembly and are in many cases opt-in (making RBAC opt-out was a massive leap forward). Namespaces are the lynchpin, but are globally visib…

> The biggest is going to be utilisation. Combining workloads pools variance, meaning you can safely run at a higher baseline load. Utilization is arguably the biggest benefit (fewer nodes if you can share nodes among users/workloads, fewer masters if you can share the control plane among users/workloads), but I wouldn't under-estimate the manageability benefit of having fewer clusters to run. Also, for applications…

Are multiple disclosures in the same thread really necessary?

Re: The future of Kubernetes is virtual machines

#102

Post by romeisendcoming »

de_watcher wrote: post #93
clagio wrote: post #42

Earlier quoted context omitted.

I agree with you, being in the same position. I wonder if the DevOps trend started because of the constant friction between devs and ops. While devs main concern and job is to deliver new features, ops main concern and job is to keep things stable. These different goals caused ops to be seen as an obstacle to dev job. Being the devs close to the business was easy to predict that we would be taken out or at least requ…

It has become manageable to do both for one person.

Using recipes, pre-built images, automation, and mostly opaque system controllers that abstract away all the underlying detail. That isn't a reliable/secure system and only salesmen and those who have a stake in that model push it. Unfortunately this is the new normal, fait accompli.

Re: The future of Kubernetes is virtual machines

#103

Post by romeisendcoming »

pbalau wrote: post #81
clagio wrote: post #45

Earlier quoted context omitted.

Not directly, but cost usually it is. Being able to serve the same number of customers with less computational power means reducing your cost.

That's a very simplistic view on the issue. Most businesses do not have a constant workload 24/7, which means the ability to scale up and down will save more money than reducing the overhead of not running directly on metal. There is also the cost of having to care about hardware to begin with. Also, in the big picture, having 100 companies doing their own bare metal deployments is not terrible efficient, compared to…

This sounds like classic devops/cloud snake oil. I wonder what industry pays your bills?

* The most businesses/always on reasoning appeals to executive decision makers and rolls down hill to the technical people who are best educated to make the decision. Many people who believe that you can cut cost by sizing workloads end up racing their own models when it doesn't scale financially or computationally over time.

* What is so difficult about hardware? The cost of forgetting how to deal with it will be much higher in the long run.

* Yes, monopolies are healthy.

Re: The future of Kubernetes is virtual machines

#104

Post by akvadrako »

shaklee3 wrote: post #70
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.

That's kind of the point of k8s. Are you saying containers have too much overhead?

I don't think he knows what he's saying. At a small scale you have overhead because you need to run the orchestration software.

But everything else (disk, CPU, network) typically amounts to less than 1%.

Re: The future of Kubernetes is virtual machines

#105

Post by barrkel »

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.

I want to be in a world where allocating hardware is as simple (at the API level) as allocating a block of memory or creating a thread. Kubernetes is a means to that end, and with an API that isn't tied to a specific vendor.

The efficiency of the actual code executing on the hardware is secondary to the efficiency of being able to automate allocation of hardware at the application level.

Re: The future of Kubernetes is virtual machines

#106

Post by barrkel »

clagio wrote: post #45
tlrobinson wrote: post #41

Earlier quoted context omitted.

Or maybe raw performance isn’t always the most important attribute of a system?

Not directly, but cost usually it is. Being able to serve the same number of customers with less computational power means reducing your cost.

The biggest cost for growth companies is opportunity cost: what they aren't able to sell and deliver because of constraints in their development and operational setup.

If you have customers beating down your door to buy your product after you add n+1 feature, you can find investors to eat the extra operational cost without a problem as long as you can build n+1 fast enough that those customers don't go elsewhere.

The other element is elastic workload, of course. Having the application dynamically scale across a pool of machines in as tractable a manner as possible at the developer level can be an enormous cost saving all on its own. Instead of allocating machines based on individual high water marks, you can allocate a cluster based on the sum of average usage + as many standard deviations of resource usage to get as many 9s as you need.

Re: The future of Kubernetes is virtual machines

#107

Post by aprdm »

TuringTest wrote: post #98
mattbillenstein wrote: post #46

Dammit, most of you reading this do not need any of this shit! Build simple things!

You don't need them until you're hired by a client with nation-wide deployment requirements, and then you need them.

Not necessarily. Needless to say containers and kubernetes are pretty new technologies and nation wide deployment requirement existed before docker / k8s.

Most of the old big companies aren't using docker or k8s for their core services. They're all using legacy fat apps that are load balanced in baremetal or vms.

Re: The future of Kubernetes is virtual machines

#108

Post by sigi45 »

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.

10 Years ago when i needed a machine for anything, i had to create a ticket, wait a week or so to get what? One machine.

Than i got told, that they have to control it, otherwise backup and restore is not supported and on the other hand, they were only able to install stuff like svn by spending virtual 3 project days! 3! I never asked what it would cost to install some etherpad.

Two years ago in a startup, i logged into aws, clicked around for an hour and had 2 isolated networks, 4 instances, a load balancer, dns server, snapshot and backup configured. A few mouseclicks later i could have had an autoscaler as well.

Ops / own Hardware is a means to an end.

Re: The future of Kubernetes is virtual machines

#109

Post by rbanffy »

davidopp__ wrote: post #80
jacques_chester wrote: post #65

Earlier quoted context omitted.

> I don't think multi-tenancy has been "retrofitted" onto Kubernetes. Kubernetes was designed with multi-tenancy in mind from the very early releases -- namespaces, authn/authz (initially ABAC, later RBAC), ResourceQuota, PodSecurityPolicy, etc. My complaint is that these require assembly and are in many cases opt-in (making RBAC opt-out was a massive leap forward). Namespaces are the lynchpin, but are globally visib…

> The biggest is going to be utilisation. Combining workloads pools variance, meaning you can safely run at a higher baseline load. Utilization is arguably the biggest benefit (fewer nodes if you can share nodes among users/workloads, fewer masters if you can share the control plane among users/workloads), but I wouldn't under-estimate the manageability benefit of having fewer clusters to run. Also, for applications…

One trick I used before was to create resources and leave them unused until they are allocated, at which point I create another one to top off the pool of pre-created resources. A stopped cluster takes up disk space and nothing else and this is an easy solution to the user experience issue.

Of course, hardening multi-tenant clusters is also needed. Even if the use case requires resource partitioning, there are use cases that don't and keeping one friend from stepping on another's toes is always a good idea.

Re: The future of Kubernetes is virtual machines

#110

Post by rbanffy »

caymanjim wrote: post #90
dilyevsky wrote: post #85

Earlier quoted context omitted.

Your definition of efficiency is too simplistic. In many cases it’s more “efficient” to have rapid development cycle and low ops overhead than save a few bucks on hardware. Even if we accept that server cost is key, Google realized long time ago that they can squeeze more out of their fleet if they can overcommit it because many workloads have variable utilization over time. Hence “containers” were conceived.

Very much this. People time is always the biggest cost. Docker and Kubernetes have been a game changer in time-to-production. Unless you need maximum performance out of the biggest iron available, it's cheaper to buy the next tier of EC2 instance than to waste developer and operations staff time trying to squeeze more out of existing servers. There are many levels of abstraction, but...who cares? It's about productiv…

> People time is always the biggest cost

It really depends on scale. If I spend 15 minutes improving the utilization of my home cluster by 10%, the only payoff I get is experience. If I do the same to Google's indexing infrastructure, I probably delayed the collapse of civilization by global warming by a full year.

This attitude leaves a lot of low-hanging fruit that, as the operation grows, can shave a couple million dollars off the operating costs.

Post reply on HN