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 "criticism" about Kubernetes being a Google strategy could well be valid, but it's not exactly new, unique, or particularly impactful here.
(Disclaimer, I work at Google, nothing to do with cloud/k8s)
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.
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)
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.
The declarative interface is going on the right direction (as far as yaml can be) but configuration management for it is still unsolved. Backups are also often forgotten; they're very easy with virtual machines.
And do you need to run this on Amazon, Gcloud, Azure,one of the smaller cloud providers like DigitalOcean or locally on Kind/k3s? It'll require very little work to get them working on any of these - if any. Cloud specific services and persistent storage will be the main issues, but that's something you can't really get around.
Now is it perfect? Absolutely not, as with any tech, there will always be problems and bottlenecks. But it allows development to scale, not just the workloads, and the skills required are transferable, which makes it a much easier sell.
> 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.
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 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.
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.
https://archive.fosdem.org/2019/schedule/event/kubernetesclu...
It's a great talk to figure out how the kubernetes codebase works
Índependent of this, the abstraction layer (k8s api, kinds etc.) is independent of the code base btw. You can easily refactor and fix all issues in k8s. The abstraction is already there.
“You should, in science, believe logic and arguments, carefully drawn, and not authorities.” [1]
[1] https://twitter.com/anammostarac/status/1495594139865731074
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.
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.)
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.
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.
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?
And while you have 'A LOT of issues with the things you posted above' just to be clear: For me and a lot of other people who like kubernetes, it solves real problems, its a great choice and there are of course things which need to be optimized. But if you only rant about it in the next blog post from you, i'm not seeing any value you really add to the ecosystem.
For me, i never seen anything like kubernetes in the last 12 years. I can get certified k8s from many companies in many different forms (gke, aks, aws, digitalocean, ranger, rke2, k3s, minicube, microk8s). ArgoCD is a dream come true.
Can you do it differently with other tools? Yes sure, did we ever had something like k8s before? no. We never had that holistic view on Infrastructure in such a FOSS project.
Again what do you want to achieve? A real discussion on specific issues or just hating against something? Or doyou have the feeling that the blog posts writing about k8s are to one sided?
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
Yet, docker and kubernetes are very much hype/marketing driven and took away a lot of recognition from the kernel developers.
To the point of a throwdown on LKML when Lennart tried to "lay claim" to cgroups v2 as "owned solely by systemd", and got a rather... Funny response.
And only because google really needed it for internal use.
Many other companies, orgs and individual contributors contributed bigger chunks of work but you don't hear people praising them.
This effort was funded in part by Google.
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.
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 that bias is involved. At least a chance bigger than Kubernetes not being a good solution for any cloud deployment.
I don't think anyone is arguing that Kubernetes is the best solution for all cloud deployments. From my POV it might not even be the best solution for most cloud deployments. But I think there's bias involved if one is even considering the possibility that Kubernetes is always a bad solution.
Regarding modifying the source material and cropping it to 4:3, that's something I find odd as well and I personally find is not fitting.
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.
Even for tiny personal deployments, I find it a very compelling experience (I'm running micro-k8s at home).
With just a little bit of setup (configuring NAS storage, handing MetalLB an ip range, and installing cert-manager) I get a setup that is robust to any single machine failure (I run a 3 node system on old desktops/laptops), handles a bunch of previously manual tasks (backups, cert updates, auto-restarts) and gives me a wonderful host of tools I now use for personal projects, such as
- CI/CD (DroneCi)
- Private docker registry (Registry:2)
- Dashboard for service availability (kubernetesui/dashboard)
- A TON of personal hosted projects and tools (from bookstack to jellyfin to whatever project I'm working on now)
And for the most part - I just don't have to think about it all that much. Sure, the initial setup took a few hours. But I've torn down and rebuilt the entire thing from scratch in less than an hour from backups, and my README for "starting with nothing but a blank disk in an old machine to fully functional" is about 2 pages long, and the vast majority of it is local router config and DNS entries (still manual).
I'm easily replacing hundreds of dollars a month in SaaS/Cloud charges with it, and it's still just not taking up all that much of my time.
And this is spot on.
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 offer this.
RedHat saw this coming, and understood that if k8s became big in the cloud-space, someone needed to address that enterpricy market. If they could get there first, AND at the same time put a second big name behind this new tech giving it more viability, it also gave them more push.
But then again, the rest of the article showed the author understands very little of Kubernetes at all.
This was 2010, so I think I may understand better than you think.
Openshift started as a paas that ran on... AWS.
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.
When I had to work at IBM in the early 2000s because of an acquisition, we met a lot of ‘corporate edgelords’ whose personal brand was built on eloquently explaining to IBM audiences how every cloud computing innovation coming out of West Coast tech companies already existed on the mainframe since the 1970s, and was therefore stupid to invest in. Their big closer was usually some version of how ‘Silicon Valley is so far behind IBM they think they’re ahead’.
These were the same guys who ran Lotus Domino in their home lab for fun because gmail was stupid.
Very tedious.
Well Gmail is kinda stupid. I mean they are reading your emails.
"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.
This feels more like MST3K than any kind of critical review of the subject. The author is passionate and has a lot to say, thats for sure, but I see little substance here beyond definite wit.
It doesn't have to be neutral in my opinion. But it should clearly separate personal judgement or opinion from facts and overall rational.
In the "About me" section the author says:
>Originally I started this site attacking the big corporate interests (Google, IBM and VMWare) that drove this effort forward, but that really doesn’t speak to my intended audience. It also came off as acerbic, which I am fine with in regards to corporations and their CEOs, it does not do justice to all the engineers that slaved over the Kubernetes project. So I deleted those posts. Now, I just want to start, provoke, prod, or push a dialog forward, because if you just follow the tech blogs, you would think we should be running a Kubernetes cluster on our lawn mowers.
Even if the blog is not about simply "attacking the big corporate interests" anymore, the language clearly puts forward the post's agenda.
In my opinion, the post should have a different title, one that is clearly indicating the author's intention to highlight the negative things about Kubernetes and the documentary.
With bare metal code written in modern memory-safe languages, serverless/FaaS could easily become a cross-cloud abstraction much like k8s. AIUI, there are already some experiments along these lines. It turns out that the main cloud services differ slightly in how they account for resource utilization, etc. in serverless deployments, but not in a way that would make a cross-cloud abstraction useless.
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 documentary they allude to Google wanting to look after its bottom line.
So for me personally, I think that the quoted passage above (and several other parts of the write-up) are a tad biased.
Interesting read nonetheless.
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.
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/
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 those efforts: Take Orkut vs Facebook as an example vs the Google+ effort in 2010-11 when Facebook seemed like it was going to eat the world.
The documentary's narrative seems more accurate.
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.
In terms of consumers Kubernetes may have saved the cloud from becoming an AWS monopoly the way the PC got coupled to Microsoft Windows and Office.
Previously every Cloud provider no matter how small had their copy of EC2,IAM,VPC,S3,ELB and such, but struggled copying the dosens of other commonly used services. It is kind of like the saying that everyone uses 20% of Excels features, but for each user is a different 20%, and you want to keep your options open. Or you are fine with running Linux, but you need this one app that doesn't work on it.
Now all the minor clouds need to catch up is to add Managed Kubernetes and they are competitive with AWS. And vendors like VMWare can also hop on the bandwagon without having to deal with AWS.
On one axis, perhaps. This is patently absurd though.
"Minor" clouds still need a hypervisor and control plane, still need IAM, still need VPC-style networking, and still need load balancers and object storage to be technically competitive with AWS - just as a starting point.
All Kubernetes means here is that there is a common API style for these things.
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.
Let's be honest, a non trivial push for k8s was just how badly Open Stack sucked
One day a startup will bring CORBA Name Service or Web Service Repository, in yaml, and it will be great.
The K8S took my server away
They took her away
Away from me