Hacker News Reader

Comment by cdogl | Hacker News Reader

A big part of the Kubernetes value proposition is “autoscaling”, used in the loosest sense. Pods will come and go over time, in response to events, etc. as part of normal operations for many systems.

If I still had to deploy to Kubernetes, I’d consider this an outage.

View on HN

I would expect the Venn diagram of:

1) actually using autoscaling in prod

2) using it for a stateful workload (with PV’s)

3) needing to scale that workload during this time window

4) using this specific k8s version

To be razor thin.

I’m honestly surprised they’ve reported the impact on this dashboard; but good to see they did.

It seems like 1.25 is a month and a half out from retirement, maybe it's related to that.

Kubernetes 1.25 (in Danny Glover voice): I'm getting too old for this shit!

autoscaling isn't necessary to elicit downtime.

Need to deploy a dev copy of your cluster? How about the CI/CD pipelines that are blocked? Go sit on your hands and wait it out. Almost 2 days now.

Woah, I completely missed that this has been going on since the 13th?! That’s outrageous, surely something can just be rolled back.

This isn't preventing pods from moving from node to node, and for a lot of workloads it wouldn't even prevent making new pods. This is if you make a new storage claim (a PVC) the underlying storage filling that claim isn't being created at the moment, for one particular version of Kubernetes. Existing volumes are not impacted. Every other version is not impacted.

Loads of pods don't even use PVCs. In the several hundred deployments I routinely manage, there's only a handful of PVCs, and they aren't exactly dynamically created and destroyed. I've got many GKE clusters and no workloads I'm running are affected, and I imagine most existing workloads in GKE clusters aren't affected. I'm then also doubly not affected, because I'm not running 1.25.

Reply on news.ycombinator.com