Всем привет, как вы создаете образы БД? Заранее туда делаете миграции и потом тянете образ в кубер, или во время деплоя накатываете миграции?

Всем привет, как вы создаете образы БД? Заранее туда делаете миграции и потом тянете образ в кубер, или во время деплоя накатываете миграции?

накатываю как шаг в ci/cd

накатываю как шаг в ci/cd

Build -> Deploy -> Migrate?

Минус только один, ci/cd должно на этом шаге иметь доступ в базы, но это такой себе минус. Да, именно так.

test ещё

а, не

build -> test -> migrate -> deploy

И у меня в миграциях (sqitch) пишутся проверки на все. Некоторую часть миграций нужно руками делать, такой процесс это ловит (миграция не пройдет verify)

И это отличный подход, потому что обычно приложения не проверяют схему перед стартом, а пользователи будут ловить 500, если миграции катятся вместе или после доплоя.

И это отличный подход, потому что обычно приложения не проверяют схему перед стартом, а пользователи будут ловить 500, если миграции катятся вместе или после доплоя.

Совершенно верно, нужно ведь проверить что все работает до доставки. Подскажите sqitch можно подружить с .net core & postgresql?

build -> test -> migrate -> deploy

Здесь получается migrate работает с уже созданным образом и снова билдит новый образ?

Совершенно верно, нужно ведь проверить что все работает до доставки. Подскажите sqitch можно подружить с .net core & postgresql?

там скорее всего свои инструменты, это отдельная штука по вкусу. А migrate делает что-то вроде docker run —rm -it app migrate

image приложения уже собран и обычно там уже есть тузлы для миграций.

И это отличный подход, потому что обычно приложения не проверяют схему перед стартом, а пользователи будут ловить 500, если миграции катятся вместе или после доплоя.

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

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

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

Проверка на миграции у rake например это время старта приложения + время проверки самих миграций. И часто это 5-10с умножить на количество подов и пример минутная задержка на пустом месте.

Т.е. это тупо увеличивает время старта пода в 2 раза у rails конкретно (беру самый общий пример, с чем работаю, без всяких goapp+sqitch)

Мы много всяких вспомогательных сервисов и тасок переписали на go, потому что go образы мало весят и сами задачи стартуют мгновенно. И деплой какой-то отдельной штуки стал занимать секунд 30 от git push до Running. Это крайне приятно и минутные зажержки на миграции при старте тут не вписываются.

Никто не настраивал http->https redirect при L4 ELB в Амазоне? У меня, разумеется, получается TOO_MANY_REDIRECTS, если скастова force-ssl-redirect на nginx

ребят я еще вот с k8s на bare-metal не работал но как там организовывать доступ к сервисам только через ингресс ? со специфическим поротом (80:443) ?

ну я имею ввиду как достучать до сервиса если нет внешнего load balancer

ну я имею ввиду как достучать до сервиса если нет внешнего load balancer

Мне кажется есть какие-то специальные LB для bare metal

вариантов масса на самом деле

https://dzone.com/articles/kubernetes-metallb-bare-metal-loadbalancer

Первая же ссылка

мне кажется тот же haproxy можно поставить

а вот такой вопрос когда используешь внутренний nginx-ingress как если поднять еще один правила ingress будут на оба распространяться ?

видимо нужно переформулировать мысль

задача балансировки трафика между 1+ серверами. К k8s это мало относится и на уровень ниже.

не было бы k8s на baremetal, задача стояла такая же. Там куча разных классических решений.

можно через cloudflare даже

видимо нужно переформулировать мысль

почему я вот поднял deployment ingress-nginx и если сейчас подыму второй то как будут работать правилла которые создаются в ресурсе ingress

почему я вот поднял deployment ingress-nginx и если сейчас подыму второй то как будут работать правилла которые создаются в ресурсе ingress

daemonset нужен, да будут работать

daemonset нужен, да будут работать

а причем тут daemonset ?

daemonset это паттерн 1 под на 1 ноду

нене я имел ввиду что я хочу поднять второй чтобы мягко перевести на другой ip адрес

Правила буду рабоать на обоих ингресс-контроллерах

на 1 ноде 2 ip?

Это тут при чем?

Если нет, то это задача 2 ingress-controller в deaemonset на двух нодах. Оно само плавно переедет.

Такое впечатление, что вы создали не сущетсвующуюп проблему и пытаетесь её решить странными методами

Я так понимаю демон сетом вы пытаетесь гарантированть запуск подов на разных нодах?

а вот такой вопрос когда используешь внутренний nginx-ingress как если поднять еще один правила ingress будут на оба распространяться ?

у них есть свои class

Это тут при чем?

при том, что зачем-то человек ххочет deployment

Вай нот?

В ч>м проблема?

ты когда в аннотациях для Ingress пишешь kubernetes.io/ingress.class: nginx - они привязываются к nginx с классом nginx

можно переопределить класс и указывать в нужных тебе внутренних ингрессах другую аннотацию

ты когда в аннотациях для Ingress пишешь kubernetes.io/ingress.class: nginx - они привязываются к nginx с классом nginx

да спасибо я уже чуть понял

да спасибо я уже чуть понял

тут хороший пример https://github.com/kubernetes-incubator/external-dns/blob/master/docs/tutorials/public-private-route53.md

нене я имел ввиду что я хочу поднять второй чтобы мягко перевести на другой ip адрес

трафик на другую ноду будет приходить? вообще ingress nginx controller собирает конфиг для nginx из описаний ingres resources. при этом он может ограничится каким то ns. сколько реплик ты там запустишь или сколько раз задеплоишь и каких kind - твое дело. самый простой вариант - daemonset + hostnetwork. так можно получить везде nginx ingress, который откроет 80 443 tcp порты

В ч>м проблема?

в том, что если сверху балансер, то стоит гарантировать, что на нодах под балансером будут поды. И под такие задачи есть daemonset

Ребят, а kubernetes ingress nginx умеет http2 без ssl?

nginx сам по себе может, но наверное придется хернуть свой шаблон

Всем привет! Помогите разобраьтся, есть 4 сервера (1 мастер 3 воркера), есть 4 внешних ip. Почему при таком конфиге весь трафик на 80 и 443 идет на nginx со ВСЕХ 4-ех ip-шников?

externaIPs только один, а порты 80 и 443 почему-то работают как nodePort (приниют запросы со всех четырех ip и шлют в сервис nginx-a)

как можно отдебажить kops, если он после смены типа инстанса, старую ноду прибил, а новую не создал? И теперь ig висит как READY, но ready nodes = 0, при том что минимум 1

это амазон?

Подскажите, в какое место Kubernetes вы добавляете static, которая обычно рядом с nginx лежит? на ingress? собираете отдельный контейнер nginx со статикой? или же статика в контейнере с приложением?

Подскажите, в какое место Kubernetes вы добавляете static, которая обычно рядом с nginx лежит? на ingress? собираете отдельный контейнер nginx со статикой? или же статика в контейнере с приложением?

у нас какая-то статика на s3 лежит, какая-то в контейнере с frontend приложением

отдельно контенером nginx или через minio. пока не определился на 100%

это амазон?

нет, это провайдер без поддержки внешнего LB

нет, это провайдер без поддержки внешнего LB

тогда зачем делать type: LoadBalancer?

у нас какая-то статика на s3 лежит, какая-то в контейнере с frontend приложением

походу все так =)

Подскажите, в какое место Kubernetes вы добавляете static, которая обычно рядом с nginx лежит? на ingress? собираете отдельный контейнер nginx со статикой? или же статика в контейнере с приложением?

В s3 и оттуда клиенты забирают ее

походу все так =)

ingress или свой контейнет nginx забирает статику с S3?

ingress или свой контейнет nginx забирает статику с S3?

ingress -> nginx со статикой

ingress -> minio

minio это свой s3

тогда зачем делать type: LoadBalancer?

Сразу так было сделано и в принципе работало.. до такого момента как на остальные ip не понадобилось тоже заиспользовать 80порт под другие сервисы

Сразу так было сделано и в принципе работало.. до такого момента как на остальные ip не понадобилось тоже заиспользовать 80порт под другие сервисы

копипаста из доки, у меня тоже так было. Там просто будет сервис в вечном pending. Работает как ClusterIP

ingress -> nginx со статикой

это 2 разных контейнера? ingress это nginx. его нельзя использовать для раздачи статики?

кстати у меня норм, pinding ip на новом сервисе которому нужен 80

это 2 разных контейнера? ingress это nginx. его нельзя использовать для раздачи статики?

в теории можно использовать, но будет сильно неудобней. Типа для каждого фронта часто нужен особенный config. nginx в отдельном контейнере со статикой отлично решает задачу. как htaccess

в теории можно использовать, но будет сильно неудобней. Типа для каждого фронта часто нужен особенный config. nginx в отдельном контейнере со статикой отлично решает задачу. как htaccess

спасибо

о люди добрые и умные подскажите пожалуйста в чем может быть разница в этих анотациях к ingress ingress.kubernetes.io/cors-allow-credentials: "true" ingress.kubernetes.io/cors-allow-origin: '*' ingress.kubernetes.io/enable-cors: "true" kubernetes.io/cors-allow-credentials: "true" kubernetes.io/cors-allow-origin: '*' kubernetes.io/enable-cors: "true”

У одного контроллера есть опция --annotations-prefix ingress.kubernetes.io, а другого нет.

У одного контроллера есть опция --annotations-prefix ingress.kubernetes.io, а другого нет.

а где и как вообще это описывается опзиональность и работа с анотациями

Здесь: https://github.com/kubernetes/ingress-nginx/tree/master/docs

а где и как вообще это описывается опзиональность и работа с анотациями

в helm чарте под это есть отдельная value

в helm чарте под это есть отдельная value

да я больше вопрос о контроллерах так как еще напрямую не имел с ними работу я так понял это какая то отдельная сущность у кубера

А Кубер от DO уже обсудили? Выглядит фантастически дёшево

да я больше вопрос о контроллерах так как еще напрямую не имел с ними работу я так понял это какая то отдельная сущность у кубера

контроллеры? отнюдь, это просто контейнеры

контроллеры? отнюдь, это просто контейнеры

да но которые управляются аннотациями ?

да но которые управляются аннотациями ?

аннотациями управляется скорее loadbalancer и то, как твой контроллер будет с Ingress работать

А Кубер от DO уже обсудили? Выглядит фантастически дёшево

Что по ценам? Просто не смотрел даже

А Кубер от DO уже обсудили? Выглядит фантастически дёшево

ну наверное как и везде цена просто за виртуалки там они дешевле чем gcloud aws azure в раза 2-3

И ничего за контроллер платить не надо

ну наверное как и везде цена просто за виртуалки там они дешевле чем gcloud aws azure в раза 2-3

У aws сразу предлагают кластер за $200+ ha, не нашел как сделать тестовый подешевле

И ничего за контроллер платить не надо

гугле вроде тоже за контроллер не платишь только виртуалки

А как дам DO себя чувствует? Я с него увел даже свои проекты, потому что бан по ip не удобен.

Пишем обвязки и перепокупаем по 40 машин)

Пишем обвязки и перепокупаем по 40 машин)

пока не попадётся ip вне списка?

вот за мониторинг вопрос, прометей и к8, хочу мониторинг нод, для этого юзают node-exporter, однако, в поле instance я вижу только ip:port, что логично для job role: pods, значит ли это, что надо скрейпить их из job role: nodes ?

пока не попадётся ip вне списка?

агаг

агаг

вам бы награду за костыли))