undefined | Better HN

0 pointsremram1y ago0 comments

And system calls and filesystems and sockets and LVM and...

Sure at some point there are too many layers to count but I wouldn't say any of this is "Kubernetes". What people tend to be hung about is the difficulty of Kubernetes compared to `docker run` or `docker compose up`. That is what I am surprised about.

I never had any issue with kubelet, or kube-proxy, or CSI plugins, or CNI plugins. That is after years of running a multi-tenant cluster in a research institution. I think about those about as much as I think about ext4, runc, or GRUB.

0 comments

ffsm81y ago

But you just said that you had issues with ceph? How is that not a CSI problem?

And CNI problems are extremely normal. Pretty much anyone that didn't just use weavenet and called it a day has had to spend quiet a bit of time to figure it out. If you already know networking by heart it's obviously going to be easier, but few devs do.

remramOP1y ago

Never had a problem with the CSI plugin, I had problems with the Ceph cluster itself. No, I wouldn't call Ceph part of Kubernetes.

You definitely can run Kubernetes without running Ceph or any storage system, and you already rely on a distributed storage system if you use the cloud whether you use Kubernetes or not. So I wouldn't count this as added complexity from Kubernetes.

ffsm81y ago

I'm not sure I can agree with that interpretation. CSI is basically an interface that has to be implemented.

If you discount issues like that, you can safely say that it's impossible to have any issues with CSI, because it's always going to be with one of it's implementation.

That feels a little disingenuous, but maybe that's just me.

1 more reply

p_l1y ago

Because CSI is just a way to connect a volume to a pod.

Ceph is its own cluster of kettles filled with fishes

freedomben1y ago

Very fair, although with managed services which are increasingly available, you don't typically need to think about CSI or CNI.

cuu5081y ago

Hence

> Kubernetes is not the first thing that comes to mind when I think of "understanding where their code is running and what it's doing"...

1 more reply

ghaff1y ago

Well, and the fact that in addition to Kubernetes itself, there are a gazillion adjacent products and options in the cloud-native space. Many/most of which a relatively simple setup may not need. But there's a lot of complexity.

But then there's always always a lot of complexity and abstraction. Certainly, most software people don't need to know everything about what a CPU is doing at the lowest levels.

j / k navigate · click thread line to collapse

0 pointsremram1y ago0 comments

And system calls and filesystems and sockets and LVM and...

0 comments

ffsm81y ago

But you just said that you had issues with ceph? How is that not a CSI problem?

remramOP1y ago

Never had a problem with the CSI plugin, I had problems with the Ceph cluster itself. No, I wouldn't call Ceph part of Kubernetes.

ffsm81y ago

I'm not sure I can agree with that interpretation. CSI is basically an interface that has to be implemented.

If you discount issues like that, you can safely say that it's impossible to have any issues with CSI, because it's always going to be with one of it's implementation.

That feels a little disingenuous, but maybe that's just me.

1 more reply

p_l1y ago

Because CSI is just a way to connect a volume to a pod.

Ceph is its own cluster of kettles filled with fishes

freedomben1y ago

Very fair, although with managed services which are increasingly available, you don't typically need to think about CSI or CNI.

cuu5081y ago

Hence

> Kubernetes is not the first thing that comes to mind when I think of "understanding where their code is running and what it's doing"...

1 more reply

ghaff1y ago

But then there's always always a lot of complexity and abstraction. Certainly, most software people don't need to know everything about what a CPU is doing at the lowest levels.

j / k navigate · click thread line to collapse