Ну мы так и делаем.
Type Loadbalancer и используем NLB для expose)

Я тупой, пошёл резать себе Вены или лучше, как голуб

короче в AWS есть два подхода использовать LB
1) Это традиционный, основной и тд. Заключается в сетапе NLB и nginx ingress. NLB стандартный разворачиваетcя из коробки при описании стандартного кубиковского LoadBalancer в EKS.
2) ALB Ingress Controller. Опробовал его, работает сносно, 500-к минимум при миграции контейнеров, но там могут быть нюансы с дополнительными pre-stop sleep. Зато никакого оверхеда на внутреннюю сеть кубика, всё работает на VPC

Да, решили делать вариант 1. Может быть придётся сделать потом вариант 1+2

на вариант 1 у меня легли всякие UI и служебные дырки, сервисы под нагрузкой пошли по пункту 2

Отпирался от пункта 1 пока не понадобилось дырку к Elasticsearch внутри VPC проковыривать

так это факты, что существующие чарты почти все трешачок.
и все пишут для себя сами.
мы на кастомайз перешли, какой смысл спорить об очевидных фактах )

вот например, как вам такое ?

Манифесты всегда сами пишите или юзаете готовые?

когда как

Заменить indent на nindent и читаемость сразу повысится

дело не в читаемости )

Ну я к тому насколько удобно кастомайзом существующие манифесты обходить?

не всегда, вот гитлаб, ты хоть как обходи, 13к строк это не мыло по тазику гонять )

когда запускаешь хелм, как правило ты уже не знаешь, что конкретно ты ставишь и как.
Если чарт некачественный, огребешь проблем, а качественные чарты сейчас никто кроме тебя не напишет,
вот я про что говорил

++++

вторая проблема - хелм никаких гарантий не дает. он может, например, не порестарить поды при апгрейде, может просто упасть тихо и без ошибок

Ну в jsonnet обходится на раз-два