Pull to refresh

Comments 4

Вы написали, что сервисы общаются через api шлюз. А почему не используете внутреннюю сетку k8s? Не сопряжено ли это с оверхедом на шифрование трафика?
Общение происходит через внутреннюю сетку, api-шлюз нужен для гибкой маршрутизации. Например, при внедрении нового сервиса, на который нужно перевести часть запросов со старых.
Красивое переиспользование сервисов из default namespace.

API-шлюз не нравится, в kubernetes есть отдельные абстракции (Service) для этого. Но, может, просто специфики не понимаю (это же не выкатка на staging-production, чтобы частично трафик раздавать). Ssl-offloader похож на Ingress абстракцию, но можно оставить и так, если всем хватает одной универсальной настройки.

Есть автоматическое удаление playground при удалении соответствующей ветки? Еще можно сделать рассылку еженедельную со списком долгоживущих веток и временем их жизни и их «стоимостью» в cpu/ram.
1) Service существует, но это примитивный tcp-балансировщик, а это значит, что, если один из pod возвращает ошибку, он просто транслирует её пользователю, а nginx может спросить у следующего. Это тонкий момент работы с абстракцией svc.
2) Ssl-offloader похож на Ingress, и это факт, но Ingress существует чуть более полугода, а проект несколько старше. Плюс сейчас prod переезжает на GCP и там мы решаем этот вопрос родными средствами платформы.
3) Удаление namespace сделано при принятии PR из фича-ветки в мастера.
4) Рассылка — хорошая идея, попробую реализовать.
Sign up to leave a comment.

Articles