This was a great read. I've been a sysadmin/SRE/Devops/Platform/infra ( Why are there so many different titles) engineers for many years, for the past ~5 years I've been using Kubernetes and have helped companies migrate lots of workloads to k8s. I've worked with many people who dislike k8s, but almost all of them had almost no experience with k8s. A lot of the anti-k8s people would eventually build out something similar to k8s, which made me love [this blog post](https://www.macchaffee.com/blog/2024/you-have-built-a-kubern...) that helped explain that more.
Anyway, I love that you are/were skeptical of Kubernetes, but then looked into k8s more; we need more people like that in the world.
I think you did a great job explaining the internals of Kubernetes and then comparing it to "not" k8s. e.g. when you said the following:
> Compared to "classic" clusters, a Service provides a similar abstraction to the combination of:
** N nodes running Keepalived + NGINX (with a dynamic set of backends)
** CNAME records for the virtual (Keepalived) IP
It's a great point because a lot of anti-k8s people just say "Just put your service on a few VMs and put a LB in front of it". But if you don't just pay someone else to do it (ALB,NLB,etc) you gotta do something like Keepalived + NGINX like you mentioned, and then you are one step into creating your own k8s.
I also love how you still brought up issues with k8s. For as much love and experience I have of k8s, I feel like there is some odd behavior it has as defaults. e.g. the default is no cpu or mem requests (don't get me started on storage). I've worked many places where an engineers app that "shouldn't" use a ton of resources used up enough to cause the k8s worker node to have issues, which then caused other pods to fail.
If you want something with more power look into the Dell Latitude 5400 Chromebook Enterprise or the Dell latitude 5300 2-in-1 Chromebook Enterprise. Both of these devices have DDR4 user replaceable memory.
There is also the Framework 13 Chromebook edition, but that seems almost impossible to find now-a-days.
It's possible this type of "radical" behavior is why this project exists in the first place. I'm willing to bet if the Libreboot maintainer(s) were not "radical" they'd just be using a Mac and be content with a closed source bootloader.
Not to say this "radical" behavior is helpful, and I understand why people don't like it.
I don't really see it as a question of "separating art from the artist". That's usually invoked when other aspects of the personal life of the artist has the potential to distract from the art itself.
The parent comment is closer to saying that Picasso wouldn't have been Picasso if in an alternate universe he had avoided controversial/politically charged subjects like the Spanish Civil War and instead appealed to the lowest common denominator for a mainstream commercial audience to sell postcards.
I'm surprised Libreboot was able to add all the ChromeOS devices at once, Just adding the 2 ports for Heads hasn't been easy, although I'm not an expert when it comes to Coreboot.
Anyway, I love seeing more support for Chromebooks, they are great devices. Funny enough my Acer Chromebook (Kano) is now more open and more secure than my Framework 13s.
It’s great to see this happening at the same time—Heads has some important features that Libreboot lacks.
It may be harder to port it if those features require neutered (rather than simply removed) blobs. Maybe that’s why the Libreboot port was easier? Not sure, I’m aware of the benefits that Heads provides but I don’t know much about the internals.
In general, we try to keep things extremely simple. And then we simplify some more. If you're very strict on this basic rule and apply it at every level, from the start, you can go a long way with a small but stable team.
Regarding k8s: EKS is a very different beast compared to managing your own cluster in terms of complexity. We invested months into understanding a lot, yes, but then the day-to-day operations are not that heavy. At least, that's our opinion after 6 months; we'll see!
I would say k8s is a piece of software that enable teams to stay small. While the internals are insanely complex the developer experience is not that hard to learn.
I agree, though it takes some discipline to keep it simple and small. It can be really easy to let your clusters get huge, tools get complex, operator sprawl, etc. but keeping it simple and understandable is worth it in the long term.
The biggest problem is that most of the popular tools are built for the target audience of "dedicated infra team", when in reality most k8s users don't really have that.
I think what they should have said is "there isn't a tool like Helm for ECS" If you want to deploy a full prometheus, grafana, alertmanager, etc stack on ECS, good luck with that, no one has written the task definition for you to consume and override values.
With k8s you can easily deploy a helm chart that will deploy lots of things that all work together fairly easily.
Anyway, I love that you are/were skeptical of Kubernetes, but then looked into k8s more; we need more people like that in the world.
I think you did a great job explaining the internals of Kubernetes and then comparing it to "not" k8s. e.g. when you said the following:
> Compared to "classic" clusters, a Service provides a similar abstraction to the combination of:
It's a great point because a lot of anti-k8s people just say "Just put your service on a few VMs and put a LB in front of it". But if you don't just pay someone else to do it (ALB,NLB,etc) you gotta do something like Keepalived + NGINX like you mentioned, and then you are one step into creating your own k8s.I also love how you still brought up issues with k8s. For as much love and experience I have of k8s, I feel like there is some odd behavior it has as defaults. e.g. the default is no cpu or mem requests (don't get me started on storage). I've worked many places where an engineers app that "shouldn't" use a ton of resources used up enough to cause the k8s worker node to have issues, which then caused other pods to fail.
reply