Live data from Hacker News

Kubernetes Documentary: A Critical Review

cloudcritical.org

31–40 of 131 posts

Re: Kubernetes Documentary: A Critical Review

#31

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?

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 nothing new, we've had [layer 2] for years". However I see Kubernetes as sitting squarely in "layer 3" here.

These layers are pretty subjective, all of the boundaries are blurred, but when I'm working these do require fairly different skills sets. I've never had the skillset to work at "1", I was fairly good at "2" for a while, but spent too much of my time working on that and too little shipping software, so my workplace moved to Kubernetes and it allowed me as an application engineer to do much less infra work, and for it to be at "3" when necessary.

To just write off everything in "3" as being "virtualisation" is ignoring the significant step in level of abstractions and the benefits brought by that.

Re: Kubernetes Documentary: A Critical Review

#32

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.

That's true, but not a particularly interesting fact.

For example, if you use GKE (Google Cloud's K8s offering), you attach your K8s cluster to an auto-scaling node pool and it handles (de)provisioning of your VMs for you. You essentially don't care about the VMs, there's essentially no overhead.

If you are in a private cloud, this also creates a good "API boundary" between the team responsible for running hardware, and the team responsible for shipping software to run on that hardware. On the former side you can essentially just adopt a machine into the cluster and leave it, and on the latter side K8s lets you programmatically reference resources, but you don't need to know how/where they came from.

Re: Kubernetes Documentary: A Critical Review

#33
post #24

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.

That's a PAAS and they existed long before k8

A good mental model is to think of K8s as a portable PaaS with a more well-defined API. That's a good thing, not a criticism of K8s.

Re: Kubernetes Documentary: A Critical Review

#34

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?

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.

Re: Kubernetes Documentary: A Critical Review

#35
post #28

Earlier quoted context omitted.

You don’t really have no concern for the underlying hardware. You pick and choose the CPU/GPU horsepower, memory, storage type and storage class, network transfer speed, and many other things. It’s at the point of needing to scale horizontally where I begin to disagree with your premise. This is where you’ll typically get into proprietary and/or ugly offerings.

>You pick and choose the CPU/GPU horsepower, memory, storage type and storage class, You still do with kubernetes > network transfer speed, and many other things. No, you don't. There's no slider for "network performance" on GCP, Azure or AWS.

There might not be on GCP, but there are on other providers (alibaba cloud comes to mind)

Re: Kubernetes Documentary: A Critical Review

#36
post #28

Earlier quoted context omitted.

You don’t really have no concern for the underlying hardware. You pick and choose the CPU/GPU horsepower, memory, storage type and storage class, network transfer speed, and many other things. It’s at the point of needing to scale horizontally where I begin to disagree with your premise. This is where you’ll typically get into proprietary and/or ugly offerings.

>You pick and choose the CPU/GPU horsepower, memory, storage type and storage class, You still do with kubernetes > network transfer speed, and many other things. No, you don't. There's no slider for "network performance" on GCP, Azure or AWS.

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

Re: Kubernetes Documentary: A Critical Review

#38
post #20

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 "…

What does gaslighting mean in this context? I thought it meant making the "victim" question their own sanity/perception of reality?

Gaslighting has almost entirely lost its original meaning because people use it for anything now. Drives me crazy.

Re: Kubernetes Documentary: A Critical Review

#39
I'm surprised that neither the documentary nor the review gets into the legacy of OpenStack. I may be biased, but it seems to me that a huge amount of the success of kubernetes is directly attributable to OpenStack.

First, OpenStack paved the way for a bunch of companies to invest real money in working together to compete with AWS. Second, there was massive turnover in ~2013 in open source contributors from OpenStack to Kubernetes. I wouldn't be surprised if a good 50% of the kubernetes community was inherited directly from OpenStack.

Re: Kubernetes Documentary: A Critical Review

#40

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.

Wouldn't your example be horizontal scaling?
Post reply on HN