Live data from Hacker News

Bare-Metal Kubernetes with K3s

blog.alexellis.io

51–60 of 136 posts

Re: Bare-Metal Kubernetes with K3s

#51

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

Re: Bare-Metal Kubernetes with K3s

#52
post #31
post #21

Earlier quoted context omitted.

Where do you see the difficulty? I've installed k8s with ansible on baremetal (kubespray), more or less just followed the steps here: https://kubernetes.io/docs/setup/production-environment/tool... No network virtualisation, just Calico. Announce the service ips via BGP from each node running the service and ECMP gives you a (poor mans) load-balancing. Ingress gets such a service-ip. I used simply nginx. Important he…

I guess you don't even realize how cryptic is your post for someone uninitiated :) Calico? Network virtualization? BGP? ECMP? Resilient hashing? No big surprise all this stuff is easy for you.

I was assuming since tasqa wanted to know, how it works on baremetal in contrast to on the cloud. And since they brought network virtualisation up, that they were already knowledgeable about the networking part.

Networking is handled in kubernetes with CNI plugins, Calico is one of them. They define how one pod can talk to another.

Probably best described in how it does it is by the project itself: https://docs.projectcalico.org/about/about-networking

My simplyfied version: Calico uses the IP routing facilities to route IP packets to pods over hosts. Either from another pod or from a gateway router.

BGP is a protocol to exchange routing information, so it can be used to inform the router or kubernetes nodes (in this case physical hosts) about where to send the IP packets.

If a pod is running on a node, the node announces with BGP that the pod IP can be routed over the IP of the node. If the pod provides a service (in the kubernetes sense), the node can also announce that the service IP can be routed over the same host. Now, if two pods on different nodes are providing the same service, then both are announcing the same service IP. So, there are multiple routes or multiple paths for the same IP. That are the last to letters of the acronym ECMP (Equal Cost Multiple Path). Equal cost, because we do not express a preference over one or the other.

The router then can make a decision where to send the packets to. Usually that is done by hashing some part of the IP packet (IP and port of source and target for example).

Now the question is how is that hash deciding to which host it goes? In most cases it is very simply that you have an array of hosts, and the hash modulo the length gives you the host. Problem is, if you add or remove one item from that, practically all future packets will end up at a different host than before you did so. And they don't know what to do with it, breaking the connection (in case of TCP). Resilient hashing describes a feature that the mapping won't change under changes.

Re: Bare-Metal Kubernetes with K3s

#53
post #19

Earlier quoted context omitted.

In the dark ages, when running an OS in the way you're referring to 'bare metal' was the default, it meant running something without a traditional kernel underneath it. Not many things are written to do that, of course. Oracle used to offer an installation mode like this. It was generally a gimmick - you pay for a tiny bit of performance with a ton of flexibility. There are probably use cases where it makes sense, bu…

Hmm - what's the overlap between your definition of "bare metal" and the current definition of "embedded"? I will say, this comment section is the first time I'm hearing about "bare-metal" meaning "without an OS", but the above question is genuine curiosity.

Those terms are orthogonal. Embedded typically refers to running on some HW that is not typically thought of as a computer. Embedded SW can run within an OS or on bare metal.

Re: Bare-Metal Kubernetes with K3s

#54
post #49
post #18

Earlier quoted context omitted.

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.

It is possible to run containers directly on top of type 1 hypervisors.

If you mean something like runV which runs Linux kernel in a lightweight VM still then how does that move the needle in the bare-metal direction exactly?

Re: Bare-Metal Kubernetes with K3s

#56
post #18

Earlier quoted context omitted.

Kubernetes relies on containers, which are made out of cgroups and namespaces. Those are Linux features, so there's no way around that. This is as bare-metal as it gets since it's not running on a VM.

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.

This is not how I've heard any of my coworkers define bare-metal. Obviously anecdotal, but I think you are in the minority here.

Re: Bare-Metal Kubernetes with K3s

#57
post #40
post #23

Earlier quoted context omitted.

It's not "Newspeak". Kubernetes is an application, it runs on an OS. You can call it "Newspeak" if you consider anything after VMs became super popular "Newspeak" (around 2010, I think?). Bare-metal = no VMs or other virtualization involved.

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.

Sometimes terms are overloaded for different domains. This is pretty common; no need to argue about which is The One True Definition.

Re: Bare-Metal Kubernetes with K3s

#58
post #40

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.

Sometimes terms are overloaded for different domains. This is pretty common; no need to argue about which is The One True Definition.

Hence, "just a case".

Re: Bare-Metal Kubernetes with K3s

#59
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 do in half a day or so. Learning to manage a cluster, that's tricky. Even if you resort to tools like Rancher or similar, you're still in deep waters.

Also why would people assume that there's any difference in installing Kubernetes on an operating system running on physical hardware vs. on virtual machines?

Re: Bare-Metal Kubernetes with K3s

#60
post #18

Earlier quoted context omitted.

Kubernetes relies on containers, which are made out of cgroups and namespaces. Those are Linux features, so there's no way around that. This is as bare-metal as it gets since it's not running on a VM.

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.
Post reply on HN