Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kubernetes on Oxide: How customer needs shaped our integrations

oxide.computer

Post reply on HN
Print view View original

41–50 of 71 posts

Re: Kubernetes on Oxide: How customer needs shaped our integrations

#41

Post by esseph »

bakies wrote: post #25
bitlad wrote: post #19

I am wondering when would you use kubernetes on oxide vs running kubernetes with kubevirt on baremetal? At first look, it feels like oxide is equivalent to proxmox or some virtualization tool, may be it uses qemu stuff underneath. Just curious. The reason I am asking this is that, we have lot onprem scenarios in our business. We are tightly coupled with k8s, to solve this we started building an internal project that…

Yeah me too. Like I kinda compare oxide to coreweave and coreweave is built on top of k8s afaik. I'm wondering what the underlying tech oxide leans on. If I was doing this I would be using talos and k8s on baremetal and building on top of that. Container first rather than VM first seems like a big advantage imo. Most workloads will be containers.

Most security minded orgs and also AWS deploy containers in VMs for better security

oxide and coreweave?

Oxide is in-house custom everything. Switches. Racks. Power bus. BMC. Firmware. OS. Software and APIs. Virtualization. Etc.

Re: Kubernetes on Oxide: How customer needs shaped our integrations

#42

Post by orf »

lkasjdas wrote: post #36
pianoben wrote: post #4

I have seldom wanted anything as much as I want an Oxide rack at home. Maybe in 40 years we'll start to see the first ones show up in surplus auctions...

Every single Oxide article has comments about people wanting one at home. A great example of completely misdirected marketing and/or engineering. Oxide should have developed home microcomputers, and they would have sold like cupcakes, with their ASCII art marketing. Instead they do million dollar "mainframes" that no one (except VCs) wants to buy.

This comment is a great example of completely misunderstanding… everything?

Just because a few people on a niche tech site are excited by niche tech stuff doesn’t mean you should focus your entire business on them, and the implication that you’d be successful in marketing a consumer product with ASCII art is mind blowing.

Re: Kubernetes on Oxide: How customer needs shaped our integrations

#43

Post by bakies »

bitlad wrote: post #32
bakies wrote: post #25

Earlier quoted context omitted.

Yeah me too. Like I kinda compare oxide to coreweave and coreweave is built on top of k8s afaik. I'm wondering what the underlying tech oxide leans on. If I was doing this I would be using talos and k8s on baremetal and building on top of that. Container first rather than VM first seems like a big advantage imo. Most workloads will be containers.

Coreweave is a cloud provider right? I dont think it is apple to apple comparison.

What's a cloud? K8s is a cloud imo, so is what oxide is providing afaict

Re: Kubernetes on Oxide: How customer needs shaped our integrations

#44

Post by bakies »

wmf wrote: post #26
bitlad wrote: post #19

I am wondering when would you use kubernetes on oxide vs running kubernetes with kubevirt on baremetal? At first look, it feels like oxide is equivalent to proxmox or some virtualization tool, may be it uses qemu stuff underneath. Just curious. The reason I am asking this is that, we have lot onprem scenarios in our business. We are tightly coupled with k8s, to solve this we started building an internal project that…

You would use Oxide if you hate Dell/HPE/Lenovo/Supermicro. Also most people won't run k8s on bare metal because they want to dynamically provision a bunch of clusters.

you can do that on k8s

Re: Kubernetes on Oxide: How customer needs shaped our integrations

#45

Post by p_l »

bitlad wrote: post #19

I am wondering when would you use kubernetes on oxide vs running kubernetes with kubevirt on baremetal? At first look, it feels like oxide is equivalent to proxmox or some virtualization tool, may be it uses qemu stuff underneath. Just curious. The reason I am asking this is that, we have lot onprem scenarios in our business. We are tightly coupled with k8s, to solve this we started building an internal project that…

Oxide is shipping the baremetal server as well, with integrated hypervisor - so running kubernetes with kubevirt on it makes less sense than integrating with the host hypervisor

Re: Kubernetes on Oxide: How customer needs shaped our integrations

#46

Post by sudomateo »

donatj wrote: post #34

Bug report I guess, but the pages top navigation seems completely inoperable to me on my iPad. Clicking with my finger does not work. Clicking with my Apple Pencil does not work. Any sort of hover state that might be there does not work (with the pencil)

Reported internally. Thank you!

Re: Kubernetes on Oxide: How customer needs shaped our integrations

#47

Post by sunshowers »

lkasjdas wrote: post #36
pianoben wrote: post #4

I have seldom wanted anything as much as I want an Oxide rack at home. Maybe in 40 years we'll start to see the first ones show up in surplus auctions...

Every single Oxide article has comments about people wanting one at home. A great example of completely misdirected marketing and/or engineering. Oxide should have developed home microcomputers, and they would have sold like cupcakes, with their ASCII art marketing. Instead they do million dollar "mainframes" that no one (except VCs) wants to buy.

Lots of people want to buy our stuff!

Re: Kubernetes on Oxide: How customer needs shaped our integrations

#48

Post by sudomateo »

dilyevsky wrote: post #35
sudomateo wrote: post #29

Earlier quoted context omitted.

I cover this a bit in the post. Today they are running something like Longhorn backed by Oxide storage. When we release our CSI plugin they can use that instead.

why longhorn and not mayastor? longhorn doesn't even have nvmeof that is not experimental

Could be whichever. Customers have expressed a desired for Longhorn given they were already using it so we started our testing there. Ultimately our CSI plugin will be the official Oxide path.

Re: Kubernetes on Oxide: How customer needs shaped our integrations

#49

Post by jefurii »

sudomateo wrote: post #28
pianoben wrote: post #4

I have seldom wanted anything as much as I want an Oxide rack at home. Maybe in 40 years we'll start to see the first ones show up in surplus auctions...

You can run the control plane at home. I have a video on how to do it. Until we make a smaller footprint that's the only way you'd get Oxide at home.

https://youtu.be/qwXtS0-r1uQ

Re: Kubernetes on Oxide: How customer needs shaped our integrations

#50

Post by kirici »

dilyevsky wrote: post #35
sudomateo wrote: post #29

Earlier quoted context omitted.

I cover this a bit in the post. Today they are running something like Longhorn backed by Oxide storage. When we release our CSI plugin they can use that instead.

why longhorn and not mayastor? longhorn doesn't even have nvmeof that is not experimental

Why Mayastor and not (Rook-)Ceph?
Post reply on HN