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

111–120 of 131 posts

Re: Kubernetes Documentary: A Critical Review

#111

Post by mohanmcgeek »

Eritico wrote: post #77
jasonrichardsmi wrote: post #68

Earlier quoted context omitted.

I am sorry you feel that way. The point of the article was not really attempting to address the feature sets of Kubernetes (which I also have issues with), it was really about the sales pitch being delivered by Google. I have A LOT of issues with the things you posted above, and I hope to address them in future articles. Stay tuned for more, and thanks for reading.

I still don't get your motivation on writing your criticism. What is your endgoal? Getting people not to like k8s? Because you don't like to work with it? To push people away from k8s? How do you add value to the current infrastructure/platform ecosystem by 'hating' on it without providing something different? Of course companies present this k8s story as a successful thing. Why would that documentary be negative? An…

> I still don't get your motivation on writing your criticism.

OP is an AWS consultant. Kubernetes is/was designed to make his skillset irrelevant. And he alludes to it in several places.

This is nothing but a poorly researched hit piece on K8s completely detached from reality

Re: Kubernetes Documentary: A Critical Review

#112

Post by joshuamorton »

jasonrichardsmi wrote: post #95
rrdharan wrote: post #87

Earlier quoted context omitted.

They really aren’t.

https://policies.google.com/privacy#infocollect "We also collect the content you create, upload, or receive from others when using our services. This includes things like email you write and receive, photos and videos you save, docs and spreadsheets you create, and comments you make on YouTube videos." Their words not mine.

They have to to store it. Every third party email service collects the content you create, upload, or recieve. Even, under this definition, the "private" encrypted ones.

Re: Kubernetes Documentary: A Critical Review

#113

Post by orf »

withinboredom wrote: post #97
Eritico wrote: post #65

Earlier quoted context omitted.

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 true.

It’s all true though.

Re: Kubernetes Documentary: A Critical Review

#114

Post by orf »

dijit wrote: post #81
nostrebored wrote: post #64

Earlier quoted context omitted.

why is this slider important? You’ve picked something very arbitrary here

Uh. Because the parent said that kubernetes and VMs are different because "with VMs you have to configure things [..] like networking performance". But you configure the exact same things as with VMs and kubernetes. Network performance (as per OP) is not configurable on either. You just accept whatever accidental default you happen to have, it's not a conscious decision people are making, and it's an awkward assumpti…

Uh, no. If network performance is an issue then you configure some labels (slow, medium, mega-fast). You then launch your services on “hardware with network:slow” labels, and new instances will be brought up based on the labels it needs.

Even better: you define a “bandwidth” resource and each service requests a slice of that. Kubernetes takes care of the box packing. If you care so much about it you can then enforce that in a number of different, flexible ways depending on your infrastructure or requirements. At the end of the day it’s no different to CPU, memory or GPU requests.

Re: Kubernetes Documentary: A Critical Review

#115

Post by dijit »

orf wrote: post #114
dijit wrote: post #81

Earlier quoted context omitted.

Uh. Because the parent said that kubernetes and VMs are different because "with VMs you have to configure things [..] like networking performance". But you configure the exact same things as with VMs and kubernetes. Network performance (as per OP) is not configurable on either. You just accept whatever accidental default you happen to have, it's not a conscious decision people are making, and it's an awkward assumpti…

Uh, no. If network performance is an issue then you configure some labels (slow, medium, mega-fast). You then launch your services on “hardware with network:slow” labels, and new instances will be brought up based on the labels it needs. Even better: you define a “bandwidth” resource and each service requests a slice of that. Kubernetes takes care of the box packing. If you care so much about it you can then enforce…

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.

Re: Kubernetes Documentary: A Critical Review

#116

Post by withinboredom »

Eritico wrote: post #99
withinboredom wrote: post #97

Earlier quoted context omitted.

None of this is true.

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 network buffers fill up.

> You no longer have dependencies to your VM because you can't have dependencies on your VM OS.

Your containers rely on the OS's kernel and whatever features it was compiled with.

> You will not install normal software on that VM just because you can

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.

> You no longer need to collect all logfiles from VMs because you do it for your services and for your services

Whatever you installed to collect logfiles is getting them from the VM's disk (in /var/log/pods in k3s), unless your container is redirecting them somewhere that isn't stdout.

Re: Kubernetes Documentary: A Critical Review

#117

Post by orf »

dijit wrote: post #115
orf wrote: post #114

Earlier quoted context omitted.

Uh, no. If network performance is an issue then you configure some labels (slow, medium, mega-fast). You then launch your services on “hardware with network:slow” labels, and new instances will be brought up based on the labels it needs. Even better: you define a “bandwidth” resource and each service requests a slice of that. Kubernetes takes care of the box packing. If you care so much about it you can then enforce…

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 have 100 units of work that you need to run. A unit of work is some “thing” that needs a certain number of CPU cores, memory, GPUs and other user-defined resources. Each unit of work also needs an individual identity, distinct from other units of work.

Go and code something to run that workload on the minimum number of cloud VMs, taking into account cost and your own user-defined scaling policies, minimizing the amount of unused resources. Now make it handle adapting to changes in the quantity and definitions of those units of work. Now make it handle over-committing, allowing units of work to have hard and soft limits that depend on the utilization of the underlying hardware. Now make it provision some form of secure identity per unit of work.

After you’ve spent time coding that, you’ll realize that:

1. It’s hard

2. You’ve re-invented part of Kubernetes

3. Your implementation is shit

4. It’s very much not “the same things you can configure on cloud VMs”

Re: Kubernetes Documentary: A Critical Review

#118

Post by freedomben »

mohanmcgeek wrote: post #109
jasonrichardsmi wrote: post #103

Earlier quoted context omitted.

https://www.infoworld.com/article/2626313/why-red-hat-should... This was 2010, so I think I may understand better than you think.

Except you don't. Openshift started as a paas that ran on... AWS.

Disclaimer: Former Red Hat employee working on OpenShift

Correct, OpenShift has been around longer than k8s. Red Hat identified that K8s was a remarkable platform for platforms, and rewrote OpenShift on top it.

OpenShift is good on clouds, but the real shine is on-prem. For anybody with on-prem hardware, OpenShift gives you an abstraction that you can use to make it indistinguishable to your users where something is running. This means you can go cloud when scaling quickly is required, and you can build the foundation on-prem where you save a ton of money. The apps won't have to change at all (as long as they're using the OpenShift abstractions rather than say an EBS storage operator that requires AWS).

Considering K8s (and/or OpenShift) only in a cloud context, is a huge error that will lead one to completely miss the "why" behind why they're so important.

Re: Kubernetes Documentary: A Critical Review

#119

Post by freedomben »

koffiezet wrote: post #89
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?

It's not just "abstracting the server". Kubernetes abstracts more than just "a server", it works on a level higher. It does this for storage, networking, compute, services, workloads, scaling, ... and all this is done through a standardised API. This APIforces you to standardise application deployments, making centrally managed logging, monitoring, tracing, ... a breeze. Once you have it working for one application,…

I completely agree with everything you said, except:

> Cloud specific services and persistent storage will be the main issues, but that's something you can't really get around.

That isn't wrong necessarily, but products like OpenShift Container Storage (OpenShift Data Foundations now actually) can provide a common API to erase that problem. ODF uses Ceph under the hood so you can get block, file, and (s3 compatible) object storage no matter where you are.

Cloud specific services are indeed a problem, but many of them have open source/portable solutions that you an choose that can run everywhere. Such as Fission, RabbitMQ, Kafka (not my favorite), Argo CD, etc. Really the things I run into most now are things like AWS machine learning services.

Re: Kubernetes Documentary: A Critical Review

#120

Post by freedomben »

koffiezet wrote: post #94

As a freelancer focusing on k8s, and who has quite a few clients running OpenShift on-prem or outside of cloud providers, his analysis of RedHat's need for OpenShift shows he does not understand RedHat's biggest customers. They run OpenShift because they want Kubernetes with it's organisational advantages on-prem, while having the support they're used to. With the exception of Azure, none of the cloud providers can o…

This is a personal message and off-topic for HN, but I didn't see any contact info in your profile and decided it was worth a public comment. There's a chance I'll need a freelancer to help with some (IMO fun) work that needs to be done (company info in profile). If you're interested, we should talk more. My public-ish email address is in my HN profile, although I get a ton of email there so if you email me please reply to this comment and let me know so I can look for it. Alternatively, Keybase.io (also in profile) is a good way to contact me if you already have an account (or are willing to create one).
Post reply on HN