Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think they're more getting a k8s requiring a whole mess of 3rd party code to actually be useful when bringing it to prod. For EKS you end up having coredns, fluentbit, secrets store, external dns, aws ebs csi controller, aws k8s cni, etc.

And in the end it's hard to say if you've actually gained anything except now this different code manages your AWS resources like you were doing with CF or terraform.



We have all of that neatly extracted into a Terraform module. Write it once and now EKS clusters are essentially disposable.


You just added yet another Thing in that huge pile of things representing millions of lines of code. That's the point.


Everything we run our workloads on is based on millions of LoCs, whether it's in the OS, in K8S, in is built-in or external kinds. If you decide to run K8S in AWS, you'll be better of using Karpenter, external-secrets and all these things as they will make your life easier in various ways.


Why is that inherently a problem?

How many LOCs in the linux kernel again?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: