пару вопросов перед тем как этим всем заняться.
1. стоит отдать предпочтение своим серверам или облаку всё же?
Лично я б наверное остался на наших железяках, тк ну это просто гораздо дешевле, но мб какие подводные имеются?
2. Есть у нас томы, которые нельзя потерять и хотелось бы уточнить как примерно можно обеспечить сохранение данные при случае падения сервера. Кубер поддерживает горизонтальное масштабирование, но я не совсем вкурсах как там реплицируются pv и реплицируются ли вообще.
3. и норм ли kong как ревёрс прокся для кубера? Есть сервис, который нужно закинуть за round-robin ревёрс проксю, думаю брать kong или traefik, макака в предпочтении 😁
1. решать тебе - есть плюсы/минусы у обеих решений 2. зависит от типа pv - начиная от тупого nfs(никак не репилицируется) и продолжая longhorn (iscsi с репликацией по нодам) 3. тебе решать опять же) но учти что чарты могут быть написаны с указанием ingress class
Лучше использовать обычный kubernetes и хранить все у себя на bare metal.
а чем обычный отличается от необычного - можно уточнить?)
Обычный это k8s. Необычные это k3s, k0s и другие версии "мы посмотрели и решили запилить свою версию kubernetes"
а можно поподробнее про третий пункт?
у нас прост чёт один сервис по rps отваливается, вот и решил поколдовать
Кубернетес поддерживает единый стандарт конфигурирования проксей, который под капотом переводится ингрес-контроллером в конфигурацию для конкретной реализации прокси - будь то NGINX или Envoy или еще что Если учитывать комментарий выше, с помощью указания ingressClass можно будет в будущем легко переключиться с NGINX на любую другую проксю не меняя код (за исключеним кастомных аннотаций каких-нибудь)
ну тут нужно смотреть что с сервисом не так - может быть проблемы как от балансера так и дальше по инфраструктуре
Только в теории. На практике это боль, как только заюзаешь любую мало мальски специфичную фичу
Обсуждают сегодня