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

Kubernetes Documentary: A Critical Review

cloudcritical.org

Post reply on HN
Print view View original

121–130 of 131 posts

Re: Kubernetes Documentary: A Critical Review

#121

Post by [deleted] »

goodpoint wrote: post #17
sovietmudkipz wrote: post #12

I regularly listen to the kubernetes podcast run by Google employees. Through time and through various guest interviews I've gotten the impression that some (most?) who created borg/kubernetes did basically all of the work that Docker did creating containers but are upset Docker has all that recognition. I can't quite articulate it but it seems like the Googlers are super judgmental and want to snub their noses at Do…

Most of the heavy lifting to implement containers was done by the kernel developer community and projects like LXC. Yet, docker and kubernetes are very much hype/marketing driven and took away a lot of recognition from the kernel developers.

[deleted]

Re: Kubernetes Documentary: A Critical Review

#122

Post by danpalmer »

Trasmatta wrote: post #91
umvi wrote: post #54

Earlier quoted context omitted.

Same with "toxic" which now just means "any speech I don't like"

Calling something toxic, problematic, or gaslighting is a great way to silence further discussion

Toxic or problematic, perhaps, but gaslighting is a specific term that means more than "bad" (or toxic), and I intended it in that very specific way. I think it's a useful term because of this specificity, and because it helps to explain the very specific feeling of confusion that it instils in those it is used against.

Re: Kubernetes Documentary: A Critical Review

#123

Post by goodpoint »

mohanmcgeek wrote: post #107
vinceguidry wrote: post #86

Earlier quoted context omitted.

funded != did the work

The kernel is developed by Linux foundation and a variety of companies that have a vested interest in Linux like Intel, AMD, SUSE, RedHat, Google, Canonical. It's not a team of volunteers like it's popularly portrayed. The foundation itself is also primarily funded by such companies.

> It's not a team of volunteers like it's popularly portrayed.

This is not correct. There is such thing as a *paid volunteer*.

Additionally, a large percentage of contributors are unaffiliated, independent or part of small companies:

https://www.cnet.com/tech/services-and-software/paid-develop...

Re: Kubernetes Documentary: A Critical Review

#124

Post by goodpoint »

Eritico wrote: post #65
jasonrichardsmi wrote: post #18

Earlier quoted context omitted.

Hi danpalmer, I kind of hit on this in the article. How do you think abstracting away the server adds any value in "public cloud"? Where you can get bespoke VMs, with no concern for the underlying hardware? Can you elaborate?

I can tell you what it does for me: Full disk on your VM? Nope. Storage is abstracted away. Your server will not fill up anymore. Only one service might break which might heal itself. Is your VM/node broken? It will heal itself because you throw it away and the new VM/node is fixed. It enforces the abstraction of Service and VM. You will not install normal software on that VM just because you can. You don't need to g…

None of this is done by k8s. Network storage, hardware virtualization, network virtualization? The all existed before.

Re: Kubernetes Documentary: A Critical Review

#125

Post by goodpoint »

jobegrabber wrote: post #44
fguerraz wrote: post #4

Slightly biased? This is the way they present the extract of the dotScale conference in this K8s documentary: https://youtu.be/BE77h7dmoQU?t=185 And the source media: https://youtu.be/3N3n9FzebAA?t=30 They've altered the quality of the audio and video to make it look old. They even cropped it to 4:3! This is preposterous.

I mean, the title of the website is "Cloud Critical - Your service mesh is garbage". And the author says >No critical conversations about Kubernetes are taking place, aside from outspoken critics on HackerNews or Slashdot, but those are few and far between. The author's agenda is about highlighting that "Kubernetes is not a good solution for most if not all cloud deployments". I'd say there's quite a decent chance th…

> No critical conversations about Kubernetes are taking place

And this is spot on.

Re: Kubernetes Documentary: A Critical Review

#126

Post by dijit »

orf wrote: post #117
dijit wrote: post #115

Earlier quoted context omitted.

Leaving aside the fact that I don’t believe anyone does this. You just maybe proved the point that I originally asserted: the things you configure on kubernetes are the same things you configure on cloud VMs.

> Leaving aside the fact that I don’t believe anyone does this. Everyone who uses GPUs with Kubernetes does exactly this. GPUs are not a native thing to Kubernetes. > You just maybe proved the point that I originally asserted: the things you configure on kubernetes are the same things you configure on cloud VMs You are of course entirely missing the point, and I’m not sure if you’re doing it on purpose or not. You ha…

Except 2 things:

1. Kubernetes manifests require "requests" to be specified. (mem/CPU allocation)

2. Getting 100 VMs identical is not difficult on the cloud.

The point I'm making is that you've already abstracted a lot of the things away with Cloud, and we abstract the same exact things even more on top of kubernetes.

If K8S was running on bare metal I'd agree with you though.

Re: Kubernetes Documentary: A Critical Review

#127

Post by orf »

dijit wrote: post #126
orf wrote: post #117

Earlier quoted context omitted.

> Leaving aside the fact that I don’t believe anyone does this. Everyone who uses GPUs with Kubernetes does exactly this. GPUs are not a native thing to Kubernetes. > You just maybe proved the point that I originally asserted: the things you configure on kubernetes are the same things you configure on cloud VMs You are of course entirely missing the point, and I’m not sure if you’re doing it on purpose or not. You ha…

Except 2 things: 1. Kubernetes manifests require "requests" to be specified. (mem/CPU allocation) 2. Getting 100 VMs identical is not difficult on the cloud. The point I'm making is that you've already abstracted a lot of the things away with Cloud, and we abstract the same exact things even more on top of kubernetes. If K8S was running on bare metal I'd agree with you though.

If you can’t understand why it’s more expensive and less efficient to run 1 unit of work per server on 100 servers as opposed to fitting them into 20 larger servers then I’m not sure what to say.

Re: Kubernetes Documentary: A Critical Review

#128

Post by dijit »

orf wrote: post #127
dijit wrote: post #126

Earlier quoted context omitted.

Except 2 things: 1. Kubernetes manifests require "requests" to be specified. (mem/CPU allocation) 2. Getting 100 VMs identical is not difficult on the cloud. The point I'm making is that you've already abstracted a lot of the things away with Cloud, and we abstract the same exact things even more on top of kubernetes. If K8S was running on bare metal I'd agree with you though.

If you can’t understand why it’s more expensive and less efficient to run 1 unit of work per server on 100 servers as opposed to fitting them into 20 larger servers then I’m not sure what to say.

I'm not sure why we're shifting around so much, I never claimed "efficiency" and especially not "efficiency of micro workloads".

This whole thread is discussing the "mental overhead" of managing VMs vs Kubernetes.

if you have to define the "size" of your workload, it hardly matters if it's a VM or k8s. You need to define the size.

Kubernetes can be more fine-grained (I want 1/4th of a CPU!) but you still define it.

I'm not talking about cost, or really anything, only that the original claim I originally responded to: "hurr durr but with VMs I have to configure everything!" but that is the same on kubernetes.

VMs are already a pretty good abstraction if you're looking at carving up compute resources. My "frustration" if I even have one is that we are doing both, one on top of the other. Which feels extremely wasteful.

But like everything it depends on your workloads, and I'm used to having things that consume entire CPU cores, not 1/4th of one. (I'm also not used to making web services these days, and kubernetes is optimised primarily for that kind of stateless workload)

Re: Kubernetes Documentary: A Critical Review

#129

Post by orf »

dijit wrote: post #128
orf wrote: post #127

Earlier quoted context omitted.

If you can’t understand why it’s more expensive and less efficient to run 1 unit of work per server on 100 servers as opposed to fitting them into 20 larger servers then I’m not sure what to say.

I'm not sure why we're shifting around so much, I never claimed "efficiency" and especially not "efficiency of micro workloads". This whole thread is discussing the "mental overhead" of managing VMs vs Kubernetes. if you have to define the "size" of your workload, it hardly matters if it's a VM or k8s. You need to define the size. Kubernetes can be more fine-grained (I want 1/4th of a CPU!) but you still define it. I…

I'm also used to having workloads that consume entire CPU cores, and as such I'd like the number of CPU cores dedicated to log aggregation, system monitoring, metrics etc to be as reduced as possible. I'd also like to not spin up a bunch of new VMs to do a rollout, and I'd also like to run all those small satellite workloads that always appear on the same platform. Oh, and I'd not like to have to run something that needs 3gb of memory and 3 cores on a machine with 4gb of memory and 4 cores because I'm constrained by AWS instance sizes.

Mixed workloads on smaller, larger machines are great for this.

With VMs you do need to configure everything, compared to a baseline stripped down AMI/image that runs nothing but docker and a Kubernetes daemon.

Yes, you can enumate Kubernetes with a bunch of custom tooling. No, it's not better. Yes, it is harder.

Re: Kubernetes Documentary: A Critical Review

#130

Post by hodgesrm »

withinboredom wrote: post #116
Eritico wrote: post #99

Earlier quoted context omitted.

I'm describing my real life issues i have and had. Feel free to actually write more than 'None of this is true.' in a way that a discussion is actually possible. Tx :)

I run k8s on bare-metal, and I can say a full disk is certainly possible if you have a service logging a few mb/s. Things will break in fun and interesting ways, data will get irrecoverably corrupted, etc. Your entire cluster will probably even break if said node was the etcd leader. This is pretty easy to reproduce by simply saturating a network and then watching the etcd leader spill its guts in your logs once the…

> If you're paying through the nose for managed k8s, this is true. If not, you'll eventually need to login to a node and diagnose some issue, which means installing things on the node.

Managed Kubernetes on Amazon (EKS) is quite inexpensive: $0.10/hr * 24 hrs/day * 30 days/month = $72/month. Other costs are VMs, networking, and storage, which you would have allocated anyway. There are some downsides like forced upgrades, but cost is not of them for our use cases.

We incidentally don't ever login to Kubernetes nodes using tools like ssh. It's asking for security trouble to have those ports open.

Post reply on HN