Live data from Hacker News

Kubernetes on Bare Metal

joshrendek.com

21–30 of 34 posts

Re: Kubernetes on Bare Metal

#21
post #10

Earlier quoted context omitted.

I don't disagree with your statement but I would have expected an article with "bare metal" in the title to cover some of the unique issues associated with bare metal. Like measuring, planning, and managing capacity.

In my (perhaps unique) experience measuring planning & managing capacity is more of a problem when using VPS's. Bare metal has so much more capacity per node than small VPS's that the minimum 3 node cluster will handle a few hundred small sites before hitting any sort of limit. So why bother measuring. :)

In my experience, adding more VMs when capacity is needed is trivial to automate on a platform like AWS. With real physical machines it takes advanced planning and actual physical work to deploy more machines. Even with a managed hosting provider there is work to do to automate the provisioning.

Re: Kubernetes on Bare Metal

#22

Interesting, I always thought Bare Metal is synonym for actual hardware server, but the author mixes those: > Bare metal for this conversation means a regular VM/VPS provider or a regular private provider like Proxmox with no special services - or actual hardware. Is this a common theme nowadays? The article itself is of course really nice, it shows that "Kubernetes is hard to set up" theme is not always right.

I used bare metal to combine both bare VPS providers and regular hardware -- basically anything without 'cloudy' options (ie: VPCs, ELBs, etc)

Re: Kubernetes on Bare Metal

#23

Interesting, I always thought Bare Metal is synonym for actual hardware server, but the author mixes those: > Bare metal for this conversation means a regular VM/VPS provider or a regular private provider like Proxmox with no special services - or actual hardware. Is this a common theme nowadays? The article itself is of course really nice, it shows that "Kubernetes is hard to set up" theme is not always right.

I used bare metal to combine both bare VPS providers and regular hardware -- basically anything without 'cloudy' options (ie: VPCs, ELBs, etc)

I think "self-hosted" would be the right term.

Re: Kubernetes on Bare Metal

#24
post #21

Earlier quoted context omitted.

In my (perhaps unique) experience measuring planning & managing capacity is more of a problem when using VPS's. Bare metal has so much more capacity per node than small VPS's that the minimum 3 node cluster will handle a few hundred small sites before hitting any sort of limit. So why bother measuring. :)

In my experience, adding more VMs when capacity is needed is trivial to automate on a platform like AWS. With real physical machines it takes advanced planning and actual physical work to deploy more machines. Even with a managed hosting provider there is work to do to automate the provisioning.

Adding a new bare metal machine or a new VM to the setup in the original article is exactly the same amount of work, automated or not.

Re: Kubernetes on Bare Metal

#25

Slightly off topic, but I feel like calling an internet server running an OS "bare-metal" is a disgrace to what "bare-metal" originally and historically referred to, i.e. computer hardware without any OS. Maybe IaaS providers are running out of creative names that they are now polluting other techs' namespace?

To me, bare metal has meant running on an OS that’s directly on the hardware, instead of a virtual machine. However, I can see your point about what it could mean (i.e. the software itself is compiled to directly run on the hardware with no OS), but I’m struggling to think of a time when anything worked like that. You have to go really, really far back in history to apply that definition to general purpose computing systems. I’m left thinking that it would only really apply to embedded systems and hardware controllers, and many of those now even have some kind of micro-os that runs on them.

Re: Kubernetes on Bare Metal

#26
post #25

Slightly off topic, but I feel like calling an internet server running an OS "bare-metal" is a disgrace to what "bare-metal" originally and historically referred to, i.e. computer hardware without any OS. Maybe IaaS providers are running out of creative names that they are now polluting other techs' namespace?

To me, bare metal has meant running on an OS that’s directly on the hardware, instead of a virtual machine. However, I can see your point about what it could mean (i.e. the software itself is compiled to directly run on the hardware with no OS), but I’m struggling to think of a time when anything worked like that. You have to go really, really far back in history to apply that definition to general purpose computing…

Not virtualized doesn't mean bare metal. I think the term would make more sense to you if you worked through "Linux from Scratch." There are things between embedded and running a full Linux OS.

Re: Kubernetes on Bare Metal

#27
post #18

Slightly off topic, but I feel like calling an internet server running an OS "bare-metal" is a disgrace to what "bare-metal" originally and historically referred to, i.e. computer hardware without any OS. Maybe IaaS providers are running out of creative names that they are now polluting other techs' namespace?

That's a little unfair. The article shows options to run on "real" bare-metal hardware, but the same tools will work on cloud instances as well.

While real hardware has metal, that's not what bare metal means.

Re: Kubernetes on Bare Metal

#28
post #21

Earlier quoted context omitted.

In my experience, adding more VMs when capacity is needed is trivial to automate on a platform like AWS. With real physical machines it takes advanced planning and actual physical work to deploy more machines. Even with a managed hosting provider there is work to do to automate the provisioning.

Adding a new bare metal machine or a new VM to the setup in the original article is exactly the same amount of work, automated or not.

How so? If I need a new VM I just click (or make an api call) and it's almost instantly ready to go. If I want a new physical server I have to order it and get it delivered to my cage and then have someone rack and wire it before I can even start provisioning. There is a lot more involved in the second case.

Re: Kubernetes on Bare Metal

#29
post #25

Earlier quoted context omitted.

To me, bare metal has meant running on an OS that’s directly on the hardware, instead of a virtual machine. However, I can see your point about what it could mean (i.e. the software itself is compiled to directly run on the hardware with no OS), but I’m struggling to think of a time when anything worked like that. You have to go really, really far back in history to apply that definition to general purpose computing…

Not virtualized doesn't mean bare metal. I think the term would make more sense to you if you worked through "Linux from Scratch." There are things between embedded and running a full Linux OS.

What would those things be? Maybe it's a continuum but concepts are not continuous. Surely there are various degrees of OS but if it's anything that manages the "bare" hardware it's something like an OS. Arguably you could also call Xen Dom0 an operating system.

Re: Kubernetes on Bare Metal

#30

Slightly off topic, but I feel like calling an internet server running an OS "bare-metal" is a disgrace to what "bare-metal" originally and historically referred to, i.e. computer hardware without any OS. Maybe IaaS providers are running out of creative names that they are now polluting other techs' namespace?

From your profile I see that you are interested in embedded systems, so that probably explains why you are upset. After almost two decades of virtualization I think "bare metal" has become a common term for server computing without VM. I am old but had no problems understanding the term as it was meant. Meanings of words vary with context and change over time.
Post reply on HN