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

101–110 of 131 posts

Re: Kubernetes Documentary: A Critical Review

#101

Post by throwaway894345 »

chousuke wrote: post #84
throwaway894345 wrote: post #76

Earlier quoted context omitted.

With Kubernetes you don't have to configure log exfiltration, process management, SSH, host metrics, etc. You don't have to touch Ansible--there's no host management at all. The stuff that you still have to configure (e.g., firewalls, NFS) is all configured through a consistent, declarative interface (Kubernetes manifests) rather than a dozen bespoke, byzantine formats or imperative commands.

Kubernetes is not quite that easy though. Out of the box, you get basically no isolation between anything, and you still have to deal with security contexts and have processes in place for keeping your container images secure. If you use community Helm charts your services may end up running with essentially random privileges that may easily conflict. The declarative interface is going on the right direction (as far…

I suspect you may be confusing "cloud provider Kubernetes" (the topic at hand) with running your own Kubernetes on bare metal. The bare metal Kubernetes story still has a long way to go, but we're talking about public cloud providers.

> Out of the box, you get basically no isolation between anything

I'm pretty sure AWS Fargate and GCP's GVisor solve (or attempt to solve) isolation. Not sure about other cloud providers.

> you still have to deal with security contexts and have processes in place for keeping your container images secure

How do VMs help secure software artifacts beyond the security practices in the container ecosystem? And I would argue that "dealing with security contexts" is strictly better in Kubernetes than the equivalent in VMs if only because of the unified interface (Kubernetes manifests).

> If you use community Helm charts your services may end up running with essentially random privileges that may easily conflict.

You can run into the same issue with Ansible scripts on VMs. This isn't a Kubernetes specific issue--ultimately, all system administrators need to take care to run secure software on their systems. Neither Kubernetes nor VMs offer a silver bullet here.

> configuration management for it is still unsolved

If "configuration management" refers to configuration of the hosts, then yes, public cloud provider Kubernetes offerings solve for this--you don't have to manage the host configuration at all (unless you want to opt into it).

> Backups are also often forgotten; they're very easy with virtual machines.

The etcd backups are managed by the cloud providers, as are backups for mounted volumes. Not sure what backups you're thinking about.

Re: Kubernetes Documentary: A Critical Review

#102

Post by Eritico »

chousuke wrote: post #84
throwaway894345 wrote: post #76

Earlier quoted context omitted.

With Kubernetes you don't have to configure log exfiltration, process management, SSH, host metrics, etc. You don't have to touch Ansible--there's no host management at all. The stuff that you still have to configure (e.g., firewalls, NFS) is all configured through a consistent, declarative interface (Kubernetes manifests) rather than a dozen bespoke, byzantine formats or imperative commands.

Kubernetes is not quite that easy though. Out of the box, you get basically no isolation between anything, and you still have to deal with security contexts and have processes in place for keeping your container images secure. If you use community Helm charts your services may end up running with essentially random privileges that may easily conflict. The declarative interface is going on the right direction (as far…

They are as easy on k8s as they are on VMs.

Or 'can':

If you use a VM on AWS, you also need to know that you need to configure a vm snapshot (very easy, totally agreeing here with you).

But you can also use a managed k8s from AWS which you can also backup as they are all on PV and they have snapshotfeatures.

I don't want to compare a VM + Snapshotting 1:1 with kubernetes though. It wouldn't be fair to k8s and it wouldn't be fair for all usecases which work very very well on one VM.

Re: Kubernetes Documentary: A Critical Review

#103

Post by jasonrichardsmi »

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…

https://www.infoworld.com/article/2626313/why-red-hat-should...

This was 2010, so I think I may understand better than you think.

Re: Kubernetes Documentary: A Critical Review

#104

Post by desmondl »

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…

Agreed, I have a small 3 node cluster at home and I use all of those things you listed. I had to dive very deep in the details and learn a ton of new things to get it right, and I had all the time I wanted because it was just for fun and learning. It's almost like having my open source self-hosted AWS (in terms of abstraction from infra, not in reliability)

Would I host any of my critical side projects on my cluster? Probably not. Kubernetes was made with large organizations (google made it after all) in mind. As a solo developer, it's better for me to host my apps on a VM and move to AWS/Azure/GCP if I need to scale.

Re: Kubernetes Documentary: A Critical Review

#106

Post by jasonrichardsmi »

Eritico wrote: post #98
jasonrichardsmi wrote: post #85

Earlier quoted context omitted.

I think the emperor is wearing no clothes. I want to move that discussion forward. I feel it is inevitable.

K8s doesn't solve problems which haven't been solved before. It doesn't do any particular magic in itself. The handful of things kubernetes does, are easy to explain but the impact is big nonetheless. It is trustworthy because it is FOSS, certified and lots of companies use it because of this. Lets take Java vs. PHP: PHP is developed by one group of people. Thats it. There was facebook hhvm/php alternative which then…

Hi you are getting into details out of the scope of this article. I want to address your points but in an article, then we can link it on HN and discuss it there.

The CNCF is an entirely different beast... which I have already started writing about already. It is the Mos Eisley of Open source. I am just kidding, it is not that bad.

You asked why I was writing this, and I told you why.

Re: Kubernetes Documentary: A Critical Review

#107

Post by mohanmcgeek »

vinceguidry wrote: post #86
mohanmcgeek wrote: post #51

Earlier quoted context omitted.

> kernel developer community This effort was funded in part by Google.

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.

Re: Kubernetes Documentary: A Critical Review

#108

Post by mohanmcgeek »

jasonrichardsmi wrote: post #58
mohanmcgeek wrote: post #46

A bulk of this criticism seems to rely on the author's understanding that somehow Google app engine and AWS were competitors before Google seriously realised that AWS was a high margin business that was bankrolling all of Amazon. I remember those days and Google app engine was trying to compete with Heroku. Google is also known to exist in markets in the form of 20% projects and not take put serious muscle behind tho…

Google released VMs in 2013, the year of this documentary, which means they were working on it for some time prior to this discussion.

The tipping point was NASA dropping out of openstack to sign a contract with AWS.

You should checkout Azure presentations from 2012 to find out how nobody saw the "cloud" coming.

Kubernetes was a very effective strategy to make AWS knowledge irrelevant by providing a layer on top/alternative interface and it succeeded. Obviously AWS consultants would hate it for it.

Re: Kubernetes Documentary: A Critical Review

#109

Post by mohanmcgeek »

jasonrichardsmi wrote: post #103
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…

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.

Re: Kubernetes Documentary: A Critical Review

#110

Post by herodoturtle »

zozbot234 wrote: post #79
herodoturtle wrote: post #60

> It also makes me think if OSS is created solely to promote profit margins, is that really good OSS, or just a tactic to wrap strategy in a thin veneer of altruism? Is that not a false dichotomy? Kubernetes could promote profit margins for Google whilst simultaneously being good for OSS. Sure, if Kubernetes was touted purely as being about what's good for OSS, then that would be disingenuous. But throughout the docu…

> Kubernetes could promote profit margins for Google whilst simultaneously being good for OSS. Yup, a typical "commoditize complements" dynamic. Google/Azure's cloud services do not implement AWS's existing API's and ways to interact with the platform, so they address this by making an alternative available.

Yup 100%.

Every couple of years I re-read Spolsky’s excellent article on this dynamic.

For those that are curious: https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/

Post reply on HN