I don't entirely understand what's happening here. The title and the post talk a lot about "Bare-Metal", but it also seems to indicate that everything is hosted on servers running Ubuntu. Which, if accurate, seems to be Kubernetes running on Linux, not bare-metal?
It appears there's two camps in the audience. The camp I'm familiar with (and it appears the author as well) use bare-metal to mean running on your own computers (either in-house or colo) instead of in a VM on a cloud provider.
I am yet to come across usage where the context doesn't make it unambiguous what it means. It can mean both things at the same time.
I don't entirely understand what's happening here. The title and the post talk a lot about "Bare-Metal", but it also seems to indicate that everything is hosted on servers running Ubuntu. Which, if accurate, seems to be Kubernetes running on Linux, not bare-metal?
It appears there's two camps in the audience. The camp I'm familiar with (and it appears the author as well) use bare-metal to mean running on your own computers (either in-house or colo) instead of in a VM on a cloud provider.
Getting Kubernetes up and running isn't really the issue anymore, that's pretty easy to do. The tricky part is long term maintenance and storage. I'm not really sure what people expect gain from these kinds of article, they're great as notes, but it's not something I'd use as a starting point for installing a production Kubernetes cluster. The initial setup of a Kubernetes cluster is something most HN readers could d…
When people talk about “bare metal” k8s they mean on-prem without the support of integrated cloud infrastructure. All the external stuff like load balancers, ingress controllers, routing, bgp, public ip pools, shared storage, vm creation for scaling, are all things the cluster can’t do for itself and have to be implemented and integrated.
How stable do you see it ? What's your cluster size? How long has it been running? Any tips for how to approach starting such setup?
we scale up to about 100 machines. We use spot instances EXTENSIVELY. And that configuration was tricky actually. Its been a couple of months now. Works pretty ok. k3s is actually pretty simple to use now. the tricky part was to integrate with https://github.com/kubernetes/cloud-provider-aws and https://github.com/DirectXMan12/k8s-prometheus-adapter The hardest part is to get it to work with spot instances. we use ht…
Wow! Impressive... what are the advantages over EKS? Just cost benefits or others as well?
Getting Kubernetes up and running isn't really the issue anymore, that's pretty easy to do. The tricky part is long term maintenance and storage. I'm not really sure what people expect gain from these kinds of article, they're great as notes, but it's not something I'd use as a starting point for installing a production Kubernetes cluster. The initial setup of a Kubernetes cluster is something most HN readers could d…
I'm still looking for a good resource as someone who's taken their eye off the ball for a decade or so. Things have (and continue to) move at an astounding pace...and I'm needing something that goes from 'Pets and autoconf' to where we are now.
Wikipedia [0] doesn't agree with you (neither do I, but who am I anyway?): "A bare-metal server is a computer server that hosts one tenant, or consumer, only.[1] The term is used for distinguishing between servers that can host multiple tenants and which utilize virtualisation and cloud hosting.[2] Such servers are used by a single consumer and are not shared between consumers. Each server may run any amount of work…
See https://en.wikipedia.org/wiki/Bare_machine . Quoting the important part: > In computer science, bare machine (or bare metal) refers to a computer executing instructions directly on logic hardware without an intervening operating system. Bare-metal server has indeed been used to refer to non-virtualized servers, but it's a misnomer. The current terminology for this is "dedicated server".
I've never heard of that before. Besides, dedicated server is an unfortunate term in practice either; I may pay Hetzner for a bunch of dedicated servers, some run a bunch of VMs, some run Kafka without a virtualization layer. My services in containers on Kubernetes in VMs on dedicated servers are still running on dedicated servers, but definitely not what I'd call bare metal. In my experience, calling the Kafka server "bare metal" is understood by everyone, used by pretty much everyone I've come across and doesn't get mixed up with adjacent concepts so easily. Maybe that's different in niche/research circles where "bare machine" is a concept that's actually relevant in day-to-day work, I wouldn't know. As far as I'm aware, the term is very much alive and kicking.
Point here is that term bare-metal cannot apply to applications relying on OS features. Unikernels are the closest thing you can use this term in this area.
Seems like a wasted term for something only 10 people in the world will care about doing.
Even Apple named their API Metal in reference to existing phrases like "running close to the metal" back in 2014 and even then it raised some eyebrows in my opinion, but that usage is still miles better than basically saying you're running a program normally. Since when absence of virtualization requires articles to be written about?
But that's not (Orwellian) newspeak at all, is it? That term carries some very strong negative connotations.
I did couch it with "somewhat". Though it does fit the theme of a diminished meaning for the same word, since the newer meaning is a much simpler thing to do.
Getting Kubernetes up and running isn't really the issue anymore, that's pretty easy to do. The tricky part is long term maintenance and storage. I'm not really sure what people expect gain from these kinds of article, they're great as notes, but it's not something I'd use as a starting point for installing a production Kubernetes cluster. The initial setup of a Kubernetes cluster is something most HN readers could d…
I'm still looking for a good resource as someone who's taken their eye off the ball for a decade or so. Things have (and continue to) move at an astounding pace...and I'm needing something that goes from 'Pets and autoconf' to where we are now.
It's still using the same old stack, just containerized. For example, you're no longer manually editing nginx conf, but instead writing the config as yaml annotation to tell the nginx ingress what to do. Instead of editing wp-config.php when deploying wordpress, you specify the db config as environmental variables in yaml file, etc.