И редкий CI выдержит столько же реквестов как обычный кубернетес на 3х нодах

ну вот на вид клиенту надо передавать какой-то маленький запускатор в роли CI/CD, доступ к репо с конфигами приложения и доступ к докер-реджистри приложения. Деплоер узнает текущую версию системы, ищет в гитовом репо с конфигурациями следующую по тегу и применяет пока не нальется самая актуальная. Внутри каждой версии конфигурации прописана джоба с миграцией.

Не делайте миграции в init 🙈 Только землю греть лишними запусками, подумайте про экологию

Можно init'ом генерить джобу, Фть-ха!

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

ну вот на вид клиенту надо передавать какой-то маленький запускатор в роли CI/CD, доступ к репо с конфигами приложения и доступ к докер-реджистри приложения. Деплоер узнает текущую версию системы, ищет в гитовом репо с конфигурациями следующую по тегу и применяет пока не нальется самая актуальная. Внутри каждой версии конфигурации прописана джоба с миграцией.

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

так просвяти

так просвяти

https://en.m.wikipedia.org/wiki/Schema_migration Инструментов куча, может быть частью orm

Господа, подскажите, я могу как-нибудь в конфиг просунуть имя image при деплое?

Оно у меня с версией меняется

kubectl set image -f ./deploy.yaml nginx=nginx:1.9.1 --local -o yaml давайте конкурс на самый извращенный пример)

ты не понял про что я. я не про инструменты миграции базы как таковой а про организацию конфигураций для zero-downtime deployment. понятно что под капотом джобы liquibase или flyway

ты не понял про что я. я не про инструменты миграции базы как таковой а про организацию конфигураций для zero-downtime deployment. понятно что под капотом джобы liquibase или flyway

В чем проблема ее запустить, если известно что миграции не блокируют работу 💯

Не то чтобы проблема, но вдруг появились стандартизированные практики и инструменты, на вид-то задача нужная каждому первому, кто делает софт с деплоем в кубер

Это какой то мутный кейс, когда приложение деплоят в частный цод, куда доступа нет? Стараюсь не думать о таких вариантах

И ещё нужно снабжать софт инструкцией, чтобы любой мог его развернуть, желательно через визард?

Ну вот ты атлассиан к примеру и делаешь джиру. Дистрибутив под кубер. Хочешь чтобы у клиента все разворачивалось без единого разрыва.

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

У него в проде дистриб годовой давности

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

Ладно, это все оффтоп

Спасибо всем

У него в проде дистриб годовой давности

у gitlab открытая документация по всем процессам компании, можно смотреть. обновляется нормально. https://about.gitlab.com/handbook/

Может у кого была такая проблема? https://github.com/terraform-providers/terraform-provider-helm/issues/20 * helm_release.dashboard: error creating tunnel: "could not find a ready tiller pod"

ладно хрен сним это только в первый раз произходит но вот это что: secrets is forbidden: User "system:serviceaccount:default:dashboard-kubernetes-dashboard". update: оказывается namespace прописать надо было

Доброго времени суток, прикручиваю EFK (на fluentd) логирование на кубернет, видит/собирает/парсит логи не всегда.. не во всех неймспейсав.. и не со всех подов. Подскажите куда смотреть?

Доброго времени суток, прикручиваю EFK (на fluentd) логирование на кубернет, видит/собирает/парсит логи не всегда.. не во всех неймспейсав.. и не со всех подов. Подскажите куда смотреть?

Лог fluentd смотри. Там по умолчанию 2мб буфер. Было такое же, пока не увеличил до 128, после этого все логи подтянулись очень быстро(больше 100кк записей)

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

Лог fluentd смотри. Там по умолчанию 2мб буфер. Было такое же, пока не увеличил до 128, после этого все логи подтянулись очень быстро(больше 100кк записей)

2019-04-02 05:12:14 +0000 [warn]: Size of the emitted data exceeds buffer_chunk_limit. 2019-04-02 05:12:14 +0000 [warn]: This may occur problems in the output plugins `at this server.` 2019-04-02 05:12:14 +0000 [warn]: To avoid problems, set a smaller number to the buffer_chunk_limit 2 увеличил, теперь он говорит сделай меньше 😅

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

не подскажешь что это за параметр? не читать сначала

read_from_head false

FLUENTD_BUFFER_CHUNK_LIMIT в env даемонсета добавь

До скольки увеличивал? И версия флюентд какая?

Всем привет! В kube-state-metrics увидел метрику: kube_endpoint_address_not_ready А если у меня к примеру в service указан external endpoint, то на него тоже будет эта метрика распространятся?

по дефолту - name: FLUENT_ELASTICSEARCH_BUFFER_CHUNK_LIMIT_SIZE value: "2M" - name: FLUENT_ELASTICSEARCH_BUFFER_QUEUE_LIMIT_LENGTH value: "64" было, увеличивал до 128 и 256, потом уменьшал, чем меньше ставил тем меньше подобных ошибок было

image: fluent/fluentd-kubernetes-daemonset:elasticsearch

На версии 1.14 с размером чанка 256 - все ок, размер очереди не трогал. Вообще плохо указывать имаджи без указания конкретной версии, если он рестартанет, а там imagepullpolicy: always - получишь другую версию latest сборки. А потом искать по хешу имаджей почему что-то сломалось или не так работает, такое себе занятие.

конфиг был составлен до меня.. я вот привожу в порядок, но опыта мало..

Конфиг кастомный в конфигмапе?

Или только энв настроен?

ещё такой вопрос.. в логах пишет 2019-04-02 05:31:00 +0000 [info]: reading config file path="/fluentd/etc/fluent.conf" при этом идёт паттерн для парсинга логов и задаётся параметр: read_from_head true конфиг видимо тоже дефолтный.. где он может сидеть? чтобы править

Конфиг кастомный в конфигмапе?

в конфиг-мап перенёс с другого сервера, но шаблоны не те что идут при ините пода..

Там написано же, все в /fluentd/etc Туда и подключай. Вот только версия может быть разная и того что было, и того что у тебя сейчас, по этому надо отрывать руки тем кто latest имаджи указывает и маунтит кастомный конфиг. Какая версия флюентд была, а какая сейчас? Ищи старую и пиши тег явно

буду пробовать на image: fluent/fluentd-kubernetes-daemonset:v0.12-debian-elasticsearch запустить

Там написано же, все в /fluentd/etc Туда и подключай. Вот только версия может быть разная и того что было, и того что у тебя сейчас, по этому надо отрывать руки тем кто latest имаджи указывает и маунтит кастомный конфиг. Какая версия флюентд была, а какая сейчас? Ищи старую и пиши тег явно

а вот где это /fluentd/etc? не совсем понимаю.. в под таких волумов не монтируется, нигде такого пути нет, в самой системе тоже не существует

при этом конфиг оттуда есть

Он в поде, внутри

т.е. нужно подмонтировать туда конфигмап загруженный в кубере?

Ага

Но я бы сначала посмотрел чем он от дефолтного отличается, хотя бы диффом

фигово когда пока ещё мало что понимаешь 😅

на первый взгляд другие пути до pos_file /var/log/es-containers.log.pos -> pos_file /var/log/fluentd-containers.log.pos

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

спасибо, хоть какие-то логи побежали, есть куда дальше смотреть

в облаке отвалилась одна нода, вопрос как в k8s вывести ее пока

kubectl cordon?

kubectl cordon?

There are pending nodes to be drained: aks-nodepool1-42616560-7 error: pods with local storage (use --delete-local-data to override): mongodb-mongodb-replicaset-0;

ну и с --delete-local-data и с --ignore-daemonsets не вынести ноду

@SinTeZoiD

Много кластеров - удобная переключалка

Надо что-то, что показывает текущий контекст

@SinTeZoiD

👌

Кто кубик с гитлабом юзает. Возникла странность. При создании все ок а когда апгрейд делается вываливает ошибку.

ну вот на вид клиенту надо передавать какой-то маленький запускатор в роли CI/CD, доступ к репо с конфигами приложения и доступ к докер-реджистри приложения. Деплоер узнает текущую версию системы, ищет в гитовом репо с конфигурациями следующую по тегу и применяет пока не нальется самая актуальная. Внутри каждой версии конфигурации прописана джоба с миграцией.

Если надо отдавать на сторону, то мне кажется все должно быть максимально примитивно: отдаем только образы и какие-нибудь примеры конфигов. Приложение при старте само делает миграцию. Многие (все?) миграторы берут правильные локи в базе сами , так что больше одного за раз базу месить не будет

Кто кубик с гитлабом юзает. Возникла странность. При создании все ок а когда апгрейд делается вываливает ошибку.

Это хелм.

у gitlab открытая документация по всем процессам компании, можно смотреть. обновляется нормально. https://about.gitlab.com/handbook/

А ещё они сломали всем нетривиальные пайплайны: https://gitlab.com/gitlab-org/gitlab-ce/issues/59703

Много кластеров - удобная переключалка

Ещё есть https://github.com/heptiolabs/ktx

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

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

зачем даемонсеты передеплоивать? они на то и демонсеты

зачем даемонсеты передеплоивать? они на то и демонсеты

чтоб работали пока проблемной ноды нет в строю

они же на других нодах норм работают?

они же на других нодах норм работают?

да

чтоб работали пока проблемной ноды нет в строю

демонсеты у тебя работают на всех нодах

тогда проблема в чем не понял

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

в этом вопросе с pvc возможно @kvaps поможет

тогда проблема в чем не понял

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

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

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

В смысле? Переменные окружения вроде подключаются в деплоймент е

похоже что я затупил. Вопрос снят. Всё нормально ) переменные уникальные для каждого деплоя.