I still don't know what it is tbh. Something for docker?

yard2010 3 hours ago | parent | next [-]

I was in the same boat as you until I needed to learn how to use it in my $dayjob. It was like discovering a new continent. I couldn't care less about it before, but the moment I realized it's a kind of cloud OS I was astounded by how this thing is genius. It's the kind of thing that gives you dopamine rushes when you use it. Something about how there is a solution to every problem you didn't know even mattered turns it into a magical perfect software. I just love it.

There is something special about complex systems that just-work(tm)

▲

jdub 3 hours ago | parent | next [-]

This is the initial endorphin rush you get when wielding a complex system. The feeling changes when the complexity explodes in your face.

	▲	mystifyingpoi 2 hours ago \| parent [-]
		Well said. The rush is when one understands the loosely coupled control loops and how they work together... until something fails in the middle with no error.

▲

johnvanommen an hour ago | parent | prev | next [-]

> the moment I realized it's a kind of cloud OS

The foundation of this is thirty years old:

Mark Andreesen founded a company to do what Amazon did: Loudcloud. This was cloud computing, BEFORE AWS was public. Loudcloud was founded in the nineties; AWS opened its APIs in 2006.

Loudcloud failed and became Opsware. Opsware was server automation.

Its competitor was Bladelogic.

Luke Kanies, from BladeLogic, founded Puppet. Puppet was open source, and steamrollered over nearly every installation of BladeLogic and Opsware in existence, because you can’t beat free.

Folks from BladeLogic migrated to jobs at DCOS.

DCOS was steamrollered by Kubernetes, the same way Puppet steamrollered BladeLogic.

The author of the piece predicts that open weight models will steamroller everything next.

I fear he’s right.

I worked for Opsware and BladeLogic.

I watched it happen in real time.

Financially, Andreesen’s wealth stems from Opsware. He is known for Mosaic, but Opsware put him on the map, financially. HP bought them.

If one wants to follow in Andreesen’s footsteps, study how he did it at Opsware.

Conveniently, there is a book.

“The Hard Thing about Hard Things.”

▲

m4rtink 3 hours ago | parent | prev [-]

So Kubernetes is LSD? ;)

▲

chias 4 hours ago | parent | prev | next [-]

I was in this state a few weeks ago. I spent a bit of time familiarizing myself then wrote up my learnings as a series of exercises.

If you think of docker as "kinda like vms except not really" and k8s as "kinda like deploying and composing docker containers but not really", this may be for you:

https://ojensen.net/infra/understanding-k8s-1

It's actually really neat, i wish i had bothered to learn it years ago.

▲

munchler 3 hours ago | parent [-]

I appreciate the effort and I'm in your target audience, but that document didn't help me. It seems to dive into the details of installing and running k8s without saying much about the purpose.

From my very ignorant standpoint, K8s seems to be about running a "cluster", but I don't know why I would want to do that.

▲

what-is-water 2 hours ago | parent [-]

Kubernetes orchestrates your container workloads over a cluster, which consists of virtual/bare metal machines(nodes). This means you can tell the kubernetes API "I want to run a container workload" and it will be started on one of the nodes that form the cluster, unlike e.g. Docker, where a docker daemon belongs to a specific node. If you remove the node your workload is running on from the cluster the workload will be rescheduled on a different one, or if you have a new image version it will start the new container, wait for it to become healthy and ready, and then route requests to it. And if you want to send requests to your workload kubernetes allows you to define standardized abstractions to easily route them to your workload, irrespective of the node it is running on.

It allows you to stop caring about the individual machines, and just treat them as combined compute, which starts mattering if you leave a single machine setup and need to start thinking about scaling in and out and gluing the individual parts together. Then you have known abstractions to do it.

Of course you can do everything kubernetes does using a bespoke solution, and the concepts aren't new, but having a widely supported technology has a lot of advantages and creating something with even half the feature has a high chance of just being worse.

	▲	munchler 43 minutes ago \| parent [-]
		Thank you for this explanation. It makes sense, but I don't really understand why it has become so popular. Professionally, my experience is that certain software components need to run together on an individual machine (e.g. database server, app server, web server), and then those machines need to be networked in a certain way (e.g. web server talks to app server, which talks to database server), so I really need to care about the architecture of individual machines. You can then scale this out horizontally (e.g. add another web server) or vertically (e.g. upgrade your database server). I'm old, so maybe I'm out of date, but having a cluster of "compute" that I can run arbitrary workloads on sounds neat, but is a capability that I've never needed.

▲

genghisjahn 4 hours ago | parent | prev | next [-]

If you can get it implemented for anything you can’t be fired.

▲

Pxtl 4 hours ago | parent | prev | next [-]

It's for running a massive number of docker containers and automatically managing them and scaling them up and down on demand. It is also so famously brutally complex that basically you need a dedicated Kube expert to handle it.

▲

honkycat 4 hours ago | parent [-]

to be fair, at any large scale you need infra people.

▲

RussianCow 3 hours ago | parent [-]

The problem is that companies tend to exaggerate their own scale and think they need k8s and dedicated infra people when they could get by with a handful of beefy VMs or dedicated servers.

	▲	honkycat 13 minutes ago \| parent [-]
		Or you could use hosted k8s and be future proof. I would take a kube cluster over a bunch of VMs I have to hand wire: wire releasing to, managing processes, restarting crashed processes, log aggregation, load balancing, networking, secret injection, cert management, DNS management, monitoring, etc... Any day of the week. You just don't know what you're talking about, sorry. Kube is really easy now.

▲

marcosdumay 3 hours ago | parent | prev | next [-]

Kubernetes is for docker what your init system is for daemons.

▲

spicyusername 4 hours ago | parent | prev [-]

You... don't know what Kubernetes is... pretty impressive, honestly.

Its 2026 and its the de facto method of deploying software basically everywhere.

You gotta really work for it to not know what its for by now.

▲

recursive 4 hours ago | parent | next [-]

I don't do much deployment but I'm in the same boat. Something something docker automation?

▲

chrisandchris 4 hours ago | parent | prev | next [-]

> Its 2026 and its the de facto method of deploying software basically everywhere.

That is some really impressive bubble you are living within. Basically everywhere - nowhere near that, no.

[edit]: Maybe containers, but software in general is so much more broad than containers.

▲

thewebguyd 4 hours ago | parent | prev | next [-]

Everywhere, huh? Still plenty just running on VMs or serverless that don't need full blown container orchestration.

I'll agree that (nearly) everyone should know when Kubernetes is useful, but let's not pretend its the default method for everything. Even then, choosing to deploy on K8s falls on the sysadmins/DevOps I wouldn't expect the devs know or do much more than provide the Dockerfile.

▲

YetAnotherNick 4 hours ago | parent | prev [-]

2026 is the year for vercel and Render.

▲

RussianCow 3 hours ago | parent [-]

I haven't used them but aren't they basically modernized Heroku? What's different?

	▲	throw-the-towel 2 hours ago \| parent [-]
		Heroku is dying, these are not.