81–90 of 136 posts
That's not what bare-metal means.
What does it mean, in your opinion?
Think various boards bootloaders, not even BIOS to rely on, that's running on bare metal. Calling something running on a normal x64 OS launched with UEFI as such is silly and inaccurate.
The post mentions kube-vip. I would be curious to hear peoples experiences with kube-vip. The documentation for kube-vip seems a bit scant unfortunately. Does anyone know how this compares/differs to the MetalLB project?
Howdy! https://kube-vip.io does two things: - Control Plane HA w/BGP or ARP - Service Type: LoadBalancer w/BGP or ARP It is similar to metallb but has a number of differences under the covers in how it works inside Kubernetes, it is cloud controller agnostic so as long as something attaches an IP to spec.IngressIP then kube-vip will advertise it. For edge deployments loadBalancers addresses can use the local DHCP for…
This was atually the part I was curious about. Could you elaborate? Or is there a design doc somewhere?
Earlier quoted context omitted.
It is somewhat "newspeak", as bare metal has meant "without an OS" in the embedded space for a very long time. This is just a case of two different spaces using the same term for different ideas.
Bare metal has meant "whithout a supervisor" to operations for more than a decade. It has also meant "without an emulator" to the emulation community for a really long time. I imagine it also has some meaning for the music community.
https://apps.dtic.mil/dtic/tr/fulltext/u2/a219356.pdf (search for bare-metal)
I suspect it comes from the automotive paint industry. Sanding down to the "bare metal" for the best finish...where the primer and paint are as close to the substrate as they can be.
Earlier quoted context omitted.
Howdy! https://kube-vip.io does two things: - Control Plane HA w/BGP or ARP - Service Type: LoadBalancer w/BGP or ARP It is similar to metallb but has a number of differences under the covers in how it works inside Kubernetes, it is cloud controller agnostic so as long as something attaches an IP to spec.IngressIP then kube-vip will advertise it. For edge deployments loadBalancers addresses can use the local DHCP for…
>"It is similar to metallb but has a number of differences under the covers in how it works inside Kubernetes" This was atually the part I was curious about. Could you elaborate? Or is there a design doc somewhere?
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…
This times 100. Deploying basic clusters is easy. Keeping a test/dev-cluster running for a while? Sure. Keeping production clusters running (TLS cert TTLs expiring, anyone?), upgrading to new K8s versions, proper monitoring (the whole stack, not just your app or the control-plane), provisioning (local) storage,... is where difficulties lie.
Earlier quoted context omitted.
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.
Can you explain why one would use Kubernetes? I know containerization but still haven’t figured out wtf Kubernetes is. Everyone and their mother keeps telling me it’s an orchestration tool for containers. It’s as helpful as saying a Pecan pie is an orchestration of flour, sugar and pecans.
It's neat. It is a lot of moving parts tho. I am just now trying it in a big infrastructure because we have so many bespoke parts that we have to glue together that we might as well try to use what is standard now...
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.
Earlier quoted context omitted.
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…
I wouldn't put much stock in page made just in 2016 that started like this https://en.wikipedia.org/w/index.php?title=Bare-metal_server...
If you disagree with what's on the page, please add or edit the information there. With proper references, it will be appreciated by everyone that uses Wikipedia.
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…
> 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. This times 100. Deploying basic clusters is easy. Keeping a test/dev-cluster running for a while? Sure. Keeping production clusters running (TLS cert TTLs expiring, anyone?), upgrading to new K8s versions, proper monitoring (the whole stack, not just your app or the contr…
Our cluster configuration is public[1] and I’m almost done with a blog post going over all the different choices you can make wrt the surrounding monitoring/etc infrastructure on a Kubernetes cluster.
Earlier quoted context omitted.
>For example, you're no longer manually editing nginx conf, You now have to do the configuration in YAML, which is MUCH MUCH worse.
Or more accurately, you now have to understand both the nginx.conf file format, and the right way to nudge the YAML so it produces what you want. Plus some intermediate wrapper script that sets things up on container start that does more funky things based on environment variables.
My last employer had something like 10 hits every 5 minutes. Somehow we needed the entire Kube ecosystem for that.
I’ve been storing good JSON templates in Dynamodb and iterating on code to query and deploy. Building up a collection that lets me deploy to AWS or GCP with one tool, editing fields I want to edit per setup.
Working with just my code and validating outputs is way less.
On the one hand everyone is all “write less code, it’s too complicated.” while ignoring ops tooling always ends up a fiasco of DSLs and templating hell.