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

61–70 of 131 posts

Re: Kubernetes Documentary: A Critical Review

#61

Post by Eritico »

Its just a very bad and uneducated stand from some person.

I'm running a small k8s instance at home, for a small startup and at my job in a big version.

Abstraction of VMs is a real benefit: Have you ever had to restart a VM because of some security issues? Yes? Were you worried that your server comes up again?

With k8s, you know that 1. its cloud native to a certain extend. It will come up again because it came up before. 2. you have more nodes available. Either to surge or because you have more than just one node running.

Your pod will be scheduled away from your node, thats it.

you have a very stable and smart abstraction layer for sooo many features you get as soon as you configure them ONCE centrally:

- LoadBalancing

- certificate management

- Volume abstraction -> making snapshots from your PV? yes!

- Rollout strategies

- health checks (readiness and liveness probes)

- declaritive style (setup a prometheus, every service can be autoscraped due to convetion over configuration)

- Certified opensource abstraction layer! (get yourself a certified k8s distribution and stop worrying about vendor lock in)

- Unified setup for plenty of apps (monitoring, logging, app store, tracing, storage systems, iam etc. etc. etc.) We had deb before and rpm and whatnot. Now you have a helm chart for a certified k8s platform)

- Already quite small -> there is k3s. ubuntu supports it also with not that much overhead

- IaC as first class citizen. Due to k8s being declarative, IaC is much easier than it was before.

- FOSS

- Central easy policy implementation and management. Write your central policies, allow your teams to manage their own namespace and make sure to allow only certain registries etc.

- ArgoCD / GitOps (a dream come true srsly!)

I cant understate how much i love k8s and how much better it is then everything i have seen before. This is the main reason why i even spend the time writing here because that çritical review' is just utterly bullshit.

Did we had similiar things somehow before? yes. So whats new on k8s? K8s unites across companies and just drives this further. For me k8s is the winner of this race which happened in parallel (mesos, docker, nomad etc. etc.)

Re: Kubernetes Documentary: A Critical Review

#62

Post by jobegrabber »

politelemon wrote: post #6
tombh wrote: post #5

> especially [a code base] as shit as Kubernetes I completely agree that Kubernetes is best understood through the lens of Google's corporate interests. But 1. resorting to language like "shit" makes me question the writer's credentials and reliability and 2. the code base may not be exemplary but its quality is far from belonging to the poorer end of the known spectrum.

"Shit" is so commonly used in developer/tech circles that I'm more surprised someone would zero in and take issue with it. I would not question their credentials and reliability over a word.

> I would not question their credentials and reliability over a word

In more or less informal discussions, I agree. From my POV it's not about a singular word though, it's about the context: The author labelled the (entire) code base of Kubernetes as "shit":

>[...] forking a large code base, especially one as shit as Kubernetes, and still getting community support can be daunting without some sort of titanic change in the market.

It's not that it's not "nice" language, it's about the statement. It could very well be that the code base of Kubernetes is in a bad state, but with this wording and without any references, it doesn't come off as neutral or particularly reasonable.

Re: Kubernetes Documentary: A Critical Review

#63

Post by nostrebored »

zozbot234 wrote: post #34
danpalmer wrote: post #31

Earlier quoted context omitted.

There are several layers of abstraction here, all bringing benefits. Layer 1: bare metal servers, bare metal routers, hardware appliances, etc. Layer 2: virtual servers, VLANs/security groups/etc, some appliances. Layer 3: containers, container networks, storage resources, etc. Kubernetes, arguably Heroku. Layer 4: functions as a service? In the article the suggestion, or how I read it, is essentially "Kubernetes is…

Process boundaries do imply a kind of virtualization, OP is not wrong there. What containers add as a feature though is comprehensive namespacing for the resources that the OS manages on behalf of "virtualized" processes.

But the initial question was how it differs from public cloud. This is not a difference. You can define your kubernetes or your terraform and have whichever brand of logical isolation you prefer

Re: Kubernetes Documentary: A Critical Review

#64

Post by nostrebored »

dijit wrote: post #41
lima wrote: post #36

Earlier quoted context omitted.

Network performance is tied to the instance type on GCP, AWS and presumably Azure.

But there’s no slider. Typically you slide the instance size for other reasons. Here’s the thing: either you care about it (and you can game the sizing of the instance) or you dont and you run kubernetes. But you if you don’t care then it doesn’t matter. There’s no slider for you to care about. It is not extra overhead.

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

Re: Kubernetes Documentary: A Critical Review

#65

Post by Eritico »

jasonrichardsmi wrote: post #18
danpalmer wrote: post #15

I'm not sure this was authored in full good faith. Things like dismissing Kubernetes attempts to "abstract away the servers" as being pointless because we already had virtualisation is at best ignorance of the differences, and at worst, gaslighting. It's clear that the author doesn't like Kubernetes, and to be honest this documentary is unlikely to change their mind because they are not the target audience. All the "…

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 give access to a VM to a developer who then needs root access and has dependencies and doesn't update the VM.

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

Abstracting it away from your VM also streamlines things like logfiles. You no longer need to collect all logfiles from VMs because you do it for your services and for your services, you only do it once (if even, log to stdout and be done with it)

Re: Kubernetes Documentary: A Critical Review

#66

Post by nostrebored »

zozbot234 wrote: post #27
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?

The principled way of "abstracting away the server" is in fact namespacing of all OS-managed resources ala containers. This opens up possibilities like automated process checkpointing and migration, or even seamless vertical scaling to a multi-node cluster (as opposed to a single server node) via a SSI (single system image) environment.

Horizontal scaling of systems is not a way that kubernetes or containerization benefits over the cloud. Resource utilization on those horizontally scaled workers can be, however.

Re: Kubernetes Documentary: A Critical Review

#67

Post by Eritico »

jasonrichardsmi wrote: post #21
charcircuit wrote: post #19

Earlier quoted context omitted.

I think part of the confusion is that server can refer to both a physical box and a VM. Abstracting away servers is about not having to think about VMs. You have a service which requires some amount of compute, memory, and storage and you just want that service to run. There is value to not having to worry about provisioning a VM or administering it.

But you still have to do that in Kubernetes, unless you are running Fargate. Someone has to provision and maintain that machine, and in the process introduce a ton of administrative overhead.

Its not the same. You can easily run node pools automatically because your abstraction layer is k8s with containerd or docker.

You also know that you can throw away VMs because they don't contain any state. You are not losing data just because you kill a VM or a VM breaks.

It is way easier to just spin up n nodes and provision them all equally than whatever you did before.

In my team, we can manage way way way more nodes than we ever could. We spin up 100 VMs and destroy them on a regular basis automatically.

Gardener for example supports autoscaling on bare metal. The whole ecosystem is providing tons of great options.

Re: Kubernetes Documentary: A Critical Review

#68

Post by jasonrichardsmi »

Eritico wrote: post #61

Its just a very bad and uneducated stand from some person. I'm running a small k8s instance at home, for a small startup and at my job in a big version. Abstraction of VMs is a real benefit: Have you ever had to restart a VM because of some security issues? Yes? Were you worried that your server comes up again? With k8s, you know that 1. its cloud native to a certain extend. It will come up again because it came up b…

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.

Re: Kubernetes Documentary: A Critical Review

#69

Post by nostrebored »

darkwater wrote: post #56

On one side there are the Kubernetes corporate enthusiasts that are probably exactly doing what this post i saying: try to remove the advantage that AWS has over all the other vendors. On the other, we are also plagued by AWS shills/fanbase that hate Kubernetes exactly because of that (they are trying to push you toward serverless with Lambda). In the middle ground there is probably the truth, where AWS had a program…

I don’t think k8s is the draw that you say it is. Anecdotally my wife and I heavily penalize jobs that have migrated from serverless to k8s. My current work uses kubernetes but it’s a step in the right direction from where they were before.

Re: Kubernetes Documentary: A Critical Review

#70

Post by Eritico »

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…

I actually believe that the k8s api could be the best abstraction for services we ever had.

While i'm running k3s at home (which is very nice to be honest) and big instances at work, i would prefer to have more managed k8s offerings but many already exist. They exist from DigitalOcean, Google, Azure, AWS and its probably way easier for smaller service providers to make a managed solution available. You can also use rancher or gardener to create and manage k8s clusters 'raw' by yourself.

Post reply on HN