14 ms·

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

spicyusername 3mo ago
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.
- chrisandchris 3mo ago
  > 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.
- recursive 3mo ago
  I don't do much deployment but I'm in the same boat. Something something docker automation?
- YetAnotherNick 3mo ago
  2026 is the year for vercel and Render.
  - RussianCow 3mo ago
    I haven't used them but aren't they basically modernized Heroku? What's different?
    - throw-the-towel 3mo ago
      Heroku is dying, these are not.
    - mindwok 3mo ago
      Pretty close, they're very close to Heroku in spirit except the new wave of hosted backends (Vercel, and to a lesser extent Supabase and Cloudflare Workers) are much more tightly integrated with the app layer. You can almost think of them as libraries that run in the cloud which you can just use inside your app.
- thewebguyd 3mo ago
  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.
genghisjahn 3mo ago
If you can get it implemented for anything you can’t be fired.
Pxtl 3mo ago
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 3mo ago
  to be fair, at any large scale you need infra people.
  - RussianCow 3mo ago
    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 3mo ago
      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.
chias 3mo ago
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 https://ojensen.net/infra/understanding-k8s-1 It's actually really neat, i wish i had bothered to learn it years ago.
- munchler 3mo ago
  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 3mo ago
    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.
yard2010 3mo ago
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)
- m4rtink 3mo ago
  So Kubernetes is LSD? ;)
- jdub 3mo ago
  This is the initial endorphin rush you get when wielding a complex system. The feeling changes when the complexity explodes in your face.
  - mystifyingpoi 3mo ago
    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 3mo ago
  > 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.”
marcosdumay 3mo ago
Kubernetes is for docker what your init system is for daemons.

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.

chrisandchris 3mo ago
> 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.
recursive 3mo ago
I don't do much deployment but I'm in the same boat. Something something docker automation?
YetAnotherNick 3mo ago
2026 is the year for vercel and Render.
- RussianCow 3mo ago
  I haven't used them but aren't they basically modernized Heroku? What's different?
  - throw-the-towel 3mo ago
    Heroku is dying, these are not.
  - mindwok 3mo ago
    Pretty close, they're very close to Heroku in spirit except the new wave of hosted backends (Vercel, and to a lesser extent Supabase and Cloudflare Workers) are much more tightly integrated with the app layer. You can almost think of them as libraries that run in the cloud which you can just use inside your app.
thewebguyd 3mo ago
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.

genghisjahn 3mo ago

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

Pxtl 3mo ago

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 3mo ago
to be fair, at any large scale you need infra people.
- RussianCow 3mo ago
  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 3mo ago
    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.

chias 3mo ago

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 https://ojensen.net/infra/understanding-k8s-1 It's actually really neat, i wish i had bothered to learn it years ago.

munchler 3mo ago
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 3mo ago
  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.

yard2010 3mo ago

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)

m4rtink 3mo ago
So Kubernetes is LSD? ;)
jdub 3mo ago
This is the initial endorphin rush you get when wielding a complex system. The feeling changes when the complexity explodes in your face.
- mystifyingpoi 3mo ago
  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 3mo ago
> 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.”

marcosdumay 3mo ago

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