Hacker News Reader

Going to EKS would take less time than exploring hacks.

EKS has had networking layer issues in the past from personal experience and I've heard from good engineers that their CNI layer code (which is open source) is not very good. That would make me concerned on how well EKS (which is different from Kubernetes itself) can scale and what edge cases you're liable to hit.

EKS may be a different implementation in some components (CNI), and have some set defaults (EBS for PVs, etc), but at it's core it is still a relatively vanilla Kubernetes.

Making a switch to EKS doesn't mean that you are stuck with EKS forever, and can set you up nicely to make the transition to a more complex/customized cluster implementation/deployment (likely still on AWS, think kops) easier if you find it's necessary for your use case in the future.

Yeah, I've had the same issues. Eventually a node would run out of some network resource which would make scheduling containers onto it impossible until it was rebooted.

There seem to be some other intermittent network issues as well. I just moved some stuff for a client off EKS and back onto ECS because it wasn't worth troubleshooting.

That said, I am not a fan of ECS at all. The scheduler is slow and it does really just take way too long for it to even start acting on new deployments.

Reply on news.ycombinator.com