Live data from Hacker News

Turing Pi: Kubernetes Cluster on Your Desk

turingpi.com

31–40 of 65 posts

Re: Turing Pi: Kubernetes Cluster on Your Desk

#32
post #27
post #19

Earlier quoted context omitted.

The other part of 'on your desk' is hearing damage. Server hardware vendors have traditionally not given two shits about their servers being north of 90 decibels, and I'm pretty sure I've witnessed a few that were pushing 100. That Raspberry Pi is probably going to absorb more noise than it makes.

Is there any reason you need a kubernetes cluster literally on your desk? Isn't the whole point of using these layers of abstraction over hardware that you pay someone else to manage it? The only times I can imagine needing hardware on my desk are when latency is super important or when I constantly need to manipulate the hardware (change hardware, play in bios, etc). In either case, I would not use k8s to run my sof…

It's fun to play around with and learn on. If you can build a cluster from scratch with Pi hardware, you get a lot of knowledge of how things work under the hood for a real cluster.

Re: Turing Pi: Kubernetes Cluster on Your Desk

#33
post #27
post #19

Earlier quoted context omitted.

The other part of 'on your desk' is hearing damage. Server hardware vendors have traditionally not given two shits about their servers being north of 90 decibels, and I'm pretty sure I've witnessed a few that were pushing 100. That Raspberry Pi is probably going to absorb more noise than it makes.

Is there any reason you need a kubernetes cluster literally on your desk? Isn't the whole point of using these layers of abstraction over hardware that you pay someone else to manage it? The only times I can imagine needing hardware on my desk are when latency is super important or when I constantly need to manipulate the hardware (change hardware, play in bios, etc). In either case, I would not use k8s to run my sof…

Because at the end of the day you are a mammal and pretending you don't have visceral reactions to sensory input is impoverishing your options, and honestly, robbing you of motivational tools.

Information radiators make no sense at all if you view them from a purely objective standpoint. Wouldn't it be faster to just open the web page on your computer? They only make sense because of the way humans interact with the world (and I suspect in particular, the doorway effect).

The last demo I saw for Pi clustering, the guy fiddled with the blink rate and color of an LED on the motherboards. Sounds boring, as a demo it summed up a whole lot of crap into a simple visual.

Re: Turing Pi: Kubernetes Cluster on Your Desk

#34
post #2

Looking at the specs, it seems almost dishonest to promote this for kubernetes. > The nodes interconnected with the onboard 1 Gbps switch. However, each node is limited with 100 Mbps USB speed. Not only that but Compute Module 3+ are limited to 1GB RAM, is it really expected someone could run a realistic workload? How stable is the control plane node with such limited resources? It seems like picking up 3 raspi4s (4G…

I'm holding out to see if a CM 4 with 4GB ram comes out before I commit to something like this.

Re: Turing Pi: Kubernetes Cluster on Your Desk

#35

This is neat, but I'm really more interested to hear about potential use cases. I'm guessing this is mostly useful for ARM workloads? Maybe some situations with low power requirements? Personally, for my multi-node test clusters, I just run VMs on cheap x86 hardware.

What's the practical point of running containers on VM?

This sounds like every talk given by Bryan Cantrill regarding public clouds running containers.

Re: Turing Pi: Kubernetes Cluster on Your Desk

#36
Someone had one of these 'backplane' style boards a few years ago, but they only used it for flashing Pis for distribution. I don't think they ever made it commercially available.

This looks fairly similar.

And can we all just pause for a moment and look at that heat sink on the ethernet controller? Holy cats, what's goin' on there?

Re: Turing Pi: Kubernetes Cluster on Your Desk

#37

There is also the https://www.pine64.org/clusterboard/ for $99 which takes these modules https://www.pine64.org/sopine/ at $29 a piece, which are quad-core ARM Cortex A53 with 2GB LPDDR3. This is their wiki: https://wiki.pine64.org/index.php/PINE_A64-LTS/SOPine

Do you happen to know how long these have been around? I build a little nanopi cluster using a combination of standoffs, cases, and a little light tinkering (aka filing), about 18 months ago and I couldn't seem to find anything like this.

Re: Turing Pi: Kubernetes Cluster on Your Desk

#38

There's something amusingly cyclical about a blade server architecture for Kubernetes. The tech comes out of a whole movement towards combining commodity machines using clever software instead of buying specialist hardware, but then adds the specialist hardware back in. Some deeper integration between Kubernetes and the hardware (acceleration/offload ASICs maybe), branding of k8s + this hardware as a unified product,…

Some mumblings have been heard accusing us all of trying to reimplement mainframes, badly.

For a long time I have been watching the ebb and flow between peer to peer and client server and it’s gotten quite a bit fuzzy lately. I suppose if you treat cloud providers as a large amorphous server, it sort of still fits the mold.

Re: Turing Pi: Kubernetes Cluster on Your Desk

#39

This is neat, but I'm really more interested to hear about potential use cases. I'm guessing this is mostly useful for ARM workloads? Maybe some situations with low power requirements? Personally, for my multi-node test clusters, I just run VMs on cheap x86 hardware.

What's the practical point of running containers on VM?

To expand on my personal use-case, I don't want or need a whole stack of physical servers sitting around just for a test k8s environment. There are some things that you can only really test properly in a real multi-node environment rather than single-node solutions like minikube: failovers, shared storage, some networking particularities, etc.

But there are reasons to run containers on VMs in production too. Hypervisors and container orchestration tools solve very different problems. Depending on what problems you are trying to solve, it might be useful to leverage both.

Re: Turing Pi: Kubernetes Cluster on Your Desk

#40
post #23

Note the $189 price tag doesn't include the Raspberry Pi compute modules, which are about $30-40 each. It's a neat form factor but you could just buy some regular Raspberry Pis and an Ethernet switch.

That's without eMMC though. Having a bunch if normal Pi's running SD cards would end up in tears at some point.

Isn't eMMC on each RPi board? No?
Post reply on HN