Hacker News new | ask | show | jobs
by s-km 2281 days ago
What sort of fun projects/experiments do people do with a super low powered k8s cluster locally?

I'm kind of in this weird position where I understand the benefits and use of k8s, but I:

a) Can't think of any cutesy distributed systems/microservices type thing that I could or would want to run on a low power machine locally (lack of processing power or ISP getting pissed off @ massive amount of traffic if you're e.g. scraping a ton of data and doing stream processing on it in your little cluster)

b) Don't really understand the point in investing time in it, as it feels like one of those things you learn on the job as it comes up. And for a lot of people (the majority, probably?) it'll probably never even come up unless they just are hunting for new tech to introduce at work regardless of if the business actually needs it. Which IMO, most businesses don't even have a compelling reason to switch from the old 3 tier monolith architecture.

5 comments

One benefit is to learn how to admin a Kubernetes cluster.

Kubernetes knowledge is becoming an important job skill, and if your current employer does not use Kubernetes, you'll need to learn it on your own.

> Which IMO, most businesses don't even have a compelling reason to switch from the old 3 tier monolith architecture.

Compelling reasons include self-healing, autoscaling, and official support from all major cloud providers. In my experience, it's actually easier to adopt Kubernetes at a smaller company than a larger one.

It's also becoming harder to hire developers who are willing to work on monolithic codebases. It's been a while since those were the state of the art, and a lot of people with 5+ years in the industry have never seen them before.

This sounds a lot like CV-driven development, rather than any actual use cases. That's not to say it's a bad idea for an individual dev, but might not say great things about our industry.
We have adopted Kubernetes at our startup. It's solved a couple of problems but created a whole lot more. We aren't at the stage that we need the scaling yet.
We evaluated Kubernetes and chose Nomad instead. It works really well (although not as feature rich as K8s) and it allows smaller teams to understand how the whole setup works. It lowers key man risks, IMO.
What problems did it create ?

We adopted Kubernetes at our startup, it solved most ci/cd and devops issues for the team. We didn't need the scaling either, we have at max maybe 2 containers of a service but we know we are ready.

Out of memory issues because we use multiple small machines instead of one big one. There are othrs but we haven't worked out what they are yet.
> This sounds a lot like CV-driven development, rather than any actual use cases.

There are plenty of companies ou there that have old COTS lying around and require some sort of IT infrastructure. Being able to setup and manage a working cluster of COTS hardware is a great way to add computational resources to a company without spending au additional cash or having to rubber stamp permits.

I personally have done this in a previous job, and a small POC with minikube turned into a 3-node kubeadm cluster that deployed and managed two company-wide intranet services like a breeze. Zero cash was spent, the only resource used was a few hours of my time, everyone benefitted, and managers were very happy with the result.

Kubernetes is the 2020's equivalent of "nobody gets fired for buying IBM" of 1980s.
Sort of, but that's only considering the worst possible outcome...
This subthread is about playing with it at home.
Why do you think people write these blog posts.
I've been running K8s since it's first stable released. It worked wonderfully for a 30 micro-service stack of node.js and Scala applications for a financial services company. I would never want to manage that many services in ec2 or ecs instances.

I also baked a 25+service AI platform onto 4 virtual machines, running kubernetes, for deployment in an air-gapped system without a knowladgable operator. It was an excellent choice for that project because of the auto-healing capabilities.

I have also run it at a small startup where we had a combination of static nginx sites, ruby on rails sites, elixer sights, node.js app, and even a c++ app. (it was at a crypto company if you are wondering why so many disparate languages). Having a single deploy pipeline for 5+ different languages and architectures was awesome. I would have killed myself if I needed to support all of those in their native environments at the same time.

There are lots of good use cases for k8s, and honestly it's not that hard if you already have system admin skills because you understand the problems it solves and how it works. Most of the folks I have seen struggle with it are developers (and likewise, I struggle with OOP sometimes - i don't mean to diminish developers skills).

a) I'd advice to start with something fun. Many people do a usenet/torrent stack (jellyfin/plex, radarr, sonarr, jackett, transmission, ombi, NZB*, etc). And honestly most things you'd want to self-host are reasonable to run in containers. E-mail. Huginn. Cryptocurrency node. CalDAV, file hosting (Nextcloud?). Personal web site and whatever side-projects you have. GitLab. Docker image repository.

b) IMO, self-hosting and less centralization of the digital services we rely on is highly desirable for society. (If k8s is the right solution for any particular individual to orchestrate their stuff is a different story). I think for most people who do this, it's a hobby and something they enjoy. Why would you have a vegetable patch when there's food in the store and your employer has a complementary lunch cafeteria?

Hackers gonna hack, you know.

> Don't really understand the point in investing time in it, as it feels like one of those things you learn on the job as it comes up

I don't need to spend my time developing skills for the job I've already got, I need to develop skills for the next job I'll have

> most businesses don't even have a compelling reason to switch from the old 3 tier monolith architecture.

...thus showing I can't rely on my employer to keep my skills up to date for me.

Not that there's no market for specialists in older technology - back in 1999 I heard rumours that COBOL experts were commanding huge salaries to work on millennium bug mitigation in banks. But people following that career path should be choosing it consciously, not by accident :)

COBOL is still in demand and highly paid.
> COBOL is still in demand and highly paid.

Being in demand means close to nothing. Once I was contacted to work on a tool that was developed in Delphi and I would hardly suggest anyone should pivot from their career to jump on that gravy train.

You should build up the skills required for your next job, not your current offers.

You're betting on the technology demand to move to certain direction. To me it feels like investing in stocks, but instead of betting with your money you are betting with your time and brain cycles invested. What makes you so confident that this piece of technology will flourish compared to so many others?
Not the best analogy, IMHO

If the price of a stock or house or investment have been rising for two years, it's risen in cost to get into, and you might never see the gains people have seen in the past; I doubt you'll ever get a bitcoin for a dollar again!

But if job adverts for a new tech have been rising for two years, it doesn't cost any more to learn than on the day it was released. Maybe less, in fact, as there will be more tutorials and more experts to learn from.

Kuburnetes is lightweight, extensible and based on open standards, which is the recipe for a long-term solution in this space. It also has first class support in all of the major cloud providers and has an established tooling ecosystem around it.
I'll agree with everything here besides 'lightweight'.
> I'll agree with everything here besides 'lightweight'.

Kubernetes is pretty lean. It does require a significant mental load to get up and running, but that's mostly due to how it forces developers to venture into the old and largely unfamiliar sysadmin territory, where you need to pay attention to more stuff other than the compiler finishing a build job.

I also take some exception to that, but to be fair I've hward that it fits into a single, 40MB binary...
Especially as the labor market is about to be flooded with devops k8s folks, looking to apply their skills.
I use mine to run the CI/CD for my projects. I used minikube to setup a qemu-based k8s cluster.