8 ms·
hint: it's going to use the same platform. allow us having the ability to inject certain manifest into any eks cluster within the org.
by tuananh 3y ago
hint: it's going to use the same platform. allow us having the ability to inject certain manifest into any eks cluster within the org.
- JohnMakin 3y agoHave you done this or attempted this yet? Every kubernetes cluster is different, but in my time working with them the last several years I anticipate the following issues: - dependent services not coming up in the order you expect/want - issues draining nodes due to crashlooping/erroring pods (can also be caused by dependent upstream services going down in wrong order) - Persistent Volume retention/synchronization - IAC not cooperating - Configuration annoyances with deployments’ availability/replica settings - Thundering herd types of problems I can think of tons of things that can make this extraordinarily difficult. I’ve had many managers over the years pitch this idea of “rapidly deployable/destructable EKS clusters” and the projects always get killed due to the complexity around this. IMHO they simply aren’t really designed for this type of thing, however, I could be misunderstanding exactly what you’re trying to do.
- tuananh 3y ago> I’ve had many managers over the years pitch this idea of “rapidly deployable/destructable EKS clusters” and the projects always get killed due to the complexity around this. This is exactly what we do: blue green eks cluster. We just thought if we do it on monthly basis, DRP will be piece of cake :)
- JohnMakin 3y agoLook forward to the writeup! thanks
- Too 3y agoAutomatic reconciliation is like half the reason Kubernetes exists. A well designed system should handle this, not having expectations in order for example. I’ve seen several clusters where one could kill more or less everything and it would just come back again.