I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever

Re:I Stopped Using Kubernetes. Our DevOps Team Is Happier Th... by AtlasBarfed on Wednesday November 27, 2024 @08:35AM (#42255965)

K8s requires a flat plane addressability model across all containers, meaning anyone can see and call anyone else?

I can see security teams getting uppity about that.

Also budgetary and org boundaries, cloud providers, disaster recovery/hot spares/redundancy/AB hotswap, avoid single tank point of failure.

[ Parent | on HN ]

Re:I Stopped Using Kubernetes. Our DevOps Team Is Happier Th... by wbl on Wednesday November 27, 2024 @08:58AM (#42256114)

Addressability is not accessibility . It's easy to control how services talk to each other through NetworkPolicy.

[ Parent | on HN ]

Re:I Stopped Using Kubernetes. Our DevOps Team Is Happier Th... by withinboredom on Wednesday November 27, 2024 @01:35PM (#42258470)

This… sounds remarkably like the problems kubernetes solves.

[ Parent | on HN ]

Re:I Stopped Using Kubernetes. Our DevOps Team Is Happier Th... by AtlasBarfed on Wednesday November 27, 2024 @01:45PM (#42258561)

single tank point of failure should be

single YAML point of failure

mobile autocorrect is super "helpful"

[ Parent | on HN ]

Re:I Stopped Using Kubernetes. Our DevOps Team Is Happier Th... by withinboredom on Thursday November 28, 2024 @03:21AM (#42263547)

I have completely tanked a kubernetes cluster before. Everything kept working. The only problem was that we couldn’t spin up new containers and if any of the running ones stopped, dns/networking wouldn’t get updated. So for a few hours while we figured out how to fix what I broke, not many issues happened.

So sure, I can kinda see your point, but it feels rather moot. In the cluster, there isnt much that is a single point of failure that also wouldn’t be a point of failure in multiple clusters.

[ Parent | on HN ]