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

91–100 of 128 posts

Re: The future of Kubernetes is virtual machines

#91

Post by serverascode »

lykr0n wrote: post #31
serverascode wrote: post #29

Earlier quoted context omitted.

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 A…

Because the OpenStack control plane is made up of many (some required, some optional) services that are basically Python daemons. It makes sense to run them in containers and manage their life cycle...which means it makes perfect sense (to me, and others) to run openstack as an application managed by k8s.

Re: The future of Kubernetes is virtual machines

#92

Post by otabdeveloper1 »

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.

False.

> Docker and Kubernetes have been a game changer in time-to-production.

False.

> ...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.

Only if your management is completely clueless. You can't solve people problems by buying machines or installing containers.

> It's about productivity per dollar.

No. Or, rather, only if by "productivity" you mean "clueless management KPI, meaning wasted company dollars per hour".

The root problem is higher-up management being unable to any set useful goals except "let's get investment capital and waste it ASAP to get more investment capital next year, growth, #yolo lol".

Re: The future of Kubernetes is virtual machines

#93

Post by de_watcher »

clagio wrote: post #42
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 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.

Re: The future of Kubernetes is virtual machines

#94

Post by rantanplan »

peterwwillis wrote: post #84

I'm convinced that Kubernetes is very good for job security, and not much else. Unless you're a managed services host, you should probably not be running it. Please, for the love of all that is holy, use a cloud services provider if you need K8s-style service features. If you don't, then just cobble together your infrastructure in the simplest way possible that uses DevOps principles, methods and practices.

Could you elaborate a bit?

Re: The future of Kubernetes is virtual machines

#95

Post by Annatar »

And people still wrangle with this... how can it be easier to struggle like this than learn how to use SmartOS and Triton? Kubernetes is a solution to severe OS virtualization deficiency in Linux, most notably orchestration. You, know, the problem which is non-existant in SmartOS with Triton and large scale configuration management with operating system packages. Every so often this hits "Hacker News" and people will rather struggle than master something new. But one cannot polish a turd.

Re: The future of Kubernetes is virtual machines

#96

Post by kacbskjbc »

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.

Unfortunately, it's only really possible when you stand on the shoulders of massive companies like Amazon and Google, at which point you're not really doing "dev" and "ops", you're just doing "dev" and outsourcing "ops" to a big company that'll only do half the work for you.

Re: The future of Kubernetes is virtual machines

#97

Post by sascha_sl »

otabdeveloper1 wrote: post #92
caymanjim wrote: post #90

Earlier quoted context omitted.

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. False. > Docker and Kubernetes have been a game changer in time-to-production. False. > ...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. Only if your management is completely clueless. You can't solve people problems by buying machines or installing containers. > It's about p…

how can you say these are false when they're quite evidently true in some circumstances?

I'm on a team that provides a kubernetes-based internal SaaS thing and personnel costs seem to be easily recouped by the money we save from having autoscaling and a common node pool instead of 2 machines per service.

This has been going on for a number of years now and the most important part has always been to be backwards compatible with whatever developers have been doing for those years. That is productivity.

That's not to mention the leverage Kubernetes gives you to optimize and discover costs. Being able to see where optimization yields the best results is much better than optimizing everything. Sometimes it just isn't worth it.

Re: The future of Kubernetes is virtual machines

#99

Post by ownagefool »

jacques_chester wrote: post #78
smarterclayton wrote: post #71

Earlier quoted context omitted.

I’m not sure who at Red Hat is advocating one cluster to rule them all, but it’s just one point on the spectrum. There are lots of places where one cluster makes sense and two would be overkill - if you want to run lots of simple workloads, or have one very large scale app. But it’s equally smart to separate clusters by security domain or regulatory zone, or to create partitions to force your teams to treat clusters…

I don't have an example to hand, so it's obvious I went on second-hand accounts. Do you have something you'd normally point customers to when describing the tradeoffs? For myself I see the argument for fewer clusters as about utilisation, the argument for more clusters about isolation. It's the oldest tug-of-war in computing. I think that shared node pools for multiple masters is going to be the combination that for…

It's also about tooling.

I've seen many clusters being sold, but with no tooling to automatically build, monitor, secure and maintain these clusters, so you've got a DevOps team playing cluster wack-a-mole.

Of course the consultancies love that because it's a bespoke layer for them to build and support, but the reality is setting up a small team to run a couple of clusters eases the job of discoverability and secops, and for many orgs is "good enough".

Still, there is room for improvement, buy I doubt it's many masters without another product on top.

Re: The future of Kubernetes is virtual machines

#100

Post by ownagefool »

davidopp__ wrote: post #54
georgebarnett wrote: post #28

Earlier quoted context omitted.

> It should be OK to have one big cluster Assuming you're deploying your Kube cluster in the cloud, the costs of having multiple clusters is really reduced. You don't have to allocate physical machines or worry about utilisation as much - you just pick a node size and autoscale. What that enables is thinking about other concerns when deciding how many clusters and where they are is right for your team. There are oper…

A pattern we're seeing a lot of recently is one cluster per "stage" per region, where a "stage" is something like dev/test, canary, and prod. (In some cases only prod is replicated across multiple regions.) I think this may end up being the "sweet spot" for Kubernetes multi-tenancy architecture. The number of clusters isn't quite at the "Kubesprawl" level (I love that phrase and am absolutely going to steal it) -- yo…

I basically split the clusters into livedata, nolivedata, random untrusted code (ci), shared tooling.

The idea being that you have process around getting your code to run on the livedata cluster and this we add more stringent requirements for accessing each API.

This is for soft tenancy, and you want to write admission controllers to reject apps that haven't went through the defined process.

Post reply on HN