образ докера же

логи из kubelet uberuntime_container.go:66] Can't make a ref to pod "runner-aa571....", container helper: selfLink was empty, can't make reference status_manager.go:446] Failed to update status for pod "runner-aa57.....": Operation cannot be fulfilled on pods "runner-aa57....": the object has been modified; please apply your changes to the latest version and try again docker_sandbox.go:343] failed to read pod IP from plugin/docker: NetworkPlugin cni failed on the status hook for pod "runner-aa57.....": Unexpected command output nsenter: cannot open /proc/30965/ns/net: No such file or directory with error: exit status 1 weave-cni: error removing interface "eth0": nsenter: cannot open /proc/30965/ns/net: No such file or directory : exit status 1 weave-cni: unable to release IP address: 400 Bad Request: Delete: no addresses for 13cf....

я понимаю что докера но может у них там trunk based development - билдят образ, деплоят на дев и потом промоутят на стейдж и прод и тд

у нас так сделано

я понимаю что докера но может у них там trunk based development - билдят образ, деплоят на дев и потом промоутят на стейдж и прод и тд

ну вот меня сам процесс и интересует, я не знаю как и ищу решение, хоть направление

а с миллионом веток и мердж коммитами подход с промоутом артефактов через энвайроменты не подходит имхо

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

потом у нас 19 прод инстансов - деплоим на них по очереди, если количество ошибок после деплоя за Х минут меньше Y

этакий канари rollout

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

вот я пока к примерно этому варианту тоже пришёл, а изначально не туда завернул.

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

у фланта в гитхабе все исходники, вики, всё описано, но часть CI\CD - TODO ))

ну флант же деньги берет с людей, им все наработки выкладывать ен с руки

не, я говорю что есть, плохо это или хорошо - уже другой вопрос

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

спасибо :)

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

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

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

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

судари, а расскажите про ваши неудачи с "засунуть СУБД в куб и горя не знать"

Я сейчас слил проект в папку, создал у себя пустой проект, залил туда файлы и запустил пайплайн. Он отработал очень быстро, без ошибок. Все нужные поды поднялись в лёт. Какие-то глюки гитлаба бяли

могу про удачи рассказать только

Я сейчас слил проект в папку, создал у себя пустой проект, залил туда файлы и запустил пайплайн. Он отработал очень быстро, без ошибок. Все нужные поды поднялись в лёт. Какие-то глюки гитлаба бяли

а с той поломанной нодой что? возможно в этот раз под попал на несломанную ноду

а с той поломанной нодой что? возможно в этот раз под попал на несломанную ноду

всё на одной ноде запускается сейчас, нода рабочая.

Гитлаб кривой

могу про удачи рассказать только

и как запускали?

монго крутится в statefulset уже больше года

всего у меня сейчас в проде крутится 2 репликасета маленьких (меньше 1тб данных) и один средний на 2.5 тб

А доступ к диску как оформлен?

еще у меня небольшой инстанс influxdb крутится в кубе, но там буквально пару десятков гиг

А доступ к диску как оформлен?

PVC шаблон, EBS volume создается динамически но deletion policy стоит не удалять

а кто провайдер? как решаете проблему шедулинга подов стейтфулсета на одной ноде? через афинити?

не туда)

потом у нас 19 прод инстансов - деплоим на них по очереди, если количество ошибок после деплоя за Х минут меньше Y

А как ошибки детектите?

PVC шаблон, EBS volume создается динамически но deletion policy стоит не удалять

как решаете multi-az ремаунт?

выставлением стейтфулсету аффинити на конкретную AZ? 😊

а кто провайдер? как решаете проблему шедулинга подов стейтфулсета на одной ноде? через афинити?

у меня куб старый, 1.5 - там афинити не было вроде ещё. Тут 2 момента: 1. dynamic volume provisioner будет создавать вольюмы раунд робином во всех AZ в которых есть ноды, т.е. минимум 2 ноды разные будут 2. Для небольших репликасетов может выйти что 2 реплки на одной ноде, для той что побольше нет т.к. ноды у меня по 120 гиг а этот репликасет хочет 75 гиг рама

как решаете multi-az ремаунт?

Специально никак не решаю, в этом кластере крутятся ещё приложения и сейчас 7 нод - не было такого чтобы нода умерла, новая поднялась в другой AZ а вольюм некуда прикрутить

не уверен что так вообще может случиться, ASG по идее создаст инстанс в той же AZ где была убита нода (но могу ошибаться)

не уверен что так вообще может случиться, ASG по идее создаст инстанс в той же AZ где была убита нода (но могу ошибаться)

нет, он в принципе очень хреново умеет работать с EBS дисками по ощущению. так что да, создает их так что порой мешает. аффинити через размер ОЗУ и request mem ваще интересное решение в условиях отсутствия аффинити

спасибо

колхозно конечно, но с другой стороны больше года в прод и пока полёт нормальный. В дальних планах есть идея вынести монгу из кластера куда-то на отдельную ASG (соседняя команда должна когда-нибудь сделать терраформ модуль для этого, но посмотрим)

почему - dynamic volume provisioner не умеет в xfs фаорматировать

плюс пришлось навернуть sysctl на свю ноду типа huge pages, что может быть не очень хорошо для других приложений в этом кластере

поэтому если будет возможность - я все-таки бы монгу вынес из куба

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

блин, я думал речь будет про базы данных, а там про монгу и инфлюкс

Приветствую. Можете подсказать по поводу Persistent Volume. Имеется statefulset с репликой 1(так как нельзя таких 2 пода поднимать). Ему из ceph подключается pv. После падения ноды под пересоздаётся, но замаунтить pv никак не может, где-то минут 10, потом маунтит и всё становтися хорошо. Вот только так долго ждать нельзя. Как можно это обойти?

Приветствую. Можете подсказать по поводу Persistent Volume. Имеется statefulset с репликой 1(так как нельзя таких 2 пода поднимать). Ему из ceph подключается pv. После падения ноды под пересоздаётся, но замаунтить pv никак не может, где-то минут 10, потом маунтит и всё становтися хорошо. Вот только так долго ждать нельзя. Как можно это обойти?

имхо цеф лочит rbd, кажись туда копать

имхо цеф лочит rbd, кажись туда копать

точно нет, локи на цефе смотрел, их там нет

точно нет, локи на цефе смотрел, их там нет

а доступ есть? попробуй уронить ноду с pv и на другой руками замаунтить rbd? чот помню было похожее, под рукой нет

а доступ есть? попробуй уронить ноду с pv и на другой руками замаунтить rbd? чот помню было похожее, под рукой нет

там лок держит kubernetes ибо pvc в Bound

там лок держит kubernetes ибо pvc в Bound

куб говорит цефу, что замаунтил и цеф лочит на него. Если нода hard-reset, то команды на релиз нет и цеф всё ещё дрежит для него. Мысли в слух, может где-то и в pvc ковырять надо

куб говорит цефу, что замаунтил и цеф лочит на него. Если нода hard-reset, то команды на релиз нет и цеф всё ещё дрежит для него. Мысли в слух, может где-то и в pvc ковырять надо

в целом всё как вот тут: https://stackoverflow.com/questions/49942285/how-respawn-a-pod-with-persistent-volume-which-stuck-on-failed-node-in-kubernete вот только вопрос в том, может кто нашёл какой-то воркэраунд

в целом всё как вот тут: https://stackoverflow.com/questions/49942285/how-respawn-a-pod-with-persistent-volume-which-stuck-on-failed-node-in-kubernete вот только вопрос в том, может кто нашёл какой-то воркэраунд

очень похоже вот на это: The automatic volume detach process does not kick in until kubernetes marks the node as down (5 min 40 sec), once this happens and the original pod is deleted then the attach/detach controller waits 6 minutes to ensure the node is not back before the volume is detached (meaning 11 minutes after the original node goes down for the detach process to automatically kick off). но всё также хочется какого-то решения

Привет, народ. Хотел спросить, можно ли при помощи Dashboard UI заставить обновиться деплойменты? Я выкладываю новые контейнеры в тегом latest. Мне нужно, чтобы кубер перевыкачал эти контейнеры и запустил их в деплойменте.

Привет, народ. Хотел спросить, можно ли при помощи Dashboard UI заставить обновиться деплойменты? Я выкладываю новые контейнеры в тегом latest. Мне нужно, чтобы кубер перевыкачал эти контейнеры и запустил их в деплойменте.

Мож тебе CI нужен?)

Привет, народ. Хотел спросить, можно ли при помощи Dashboard UI заставить обновиться деплойменты? Я выкладываю новые контейнеры в тегом latest. Мне нужно, чтобы кубер перевыкачал эти контейнеры и запустил их в деплойменте.

containers: - name: $CI_PROJECT_NAME image: docker.ecp-share.com/$CI_PROJECT_NAME-$CI_COMMIT_REF_NAME:latest imagePullPolicy: Always env: - name: REDEPLOY_VARIABLE value: '$DATE'

В $DATE подставлять текущую дату всегда. deployment поменяется и передёрнется в кубере

DATE=$(date) envsubst < .ci/deployment.template.yml > .ci/deployment.yml Я это вот так делаю в lgitlab-ci.yml

Через анус жопы, короче

У нас DevOps написла небольшой скриптик на shell для убийства подов, после убийства выкачивается новая версия из регистри set +e POD=$(kubectl get pods -n NAMESPACE | grep -E '^POD_NAME-[0-9]+.*$' —color=none | cut -d ' ' -f 1) kubectl delete pods "$POD" -n NAMESPACE

наверняка есть лучше способ передавать переменные в деплоймен?

У нас DevOps написла небольшой скриптик на shell для убийства подов, после убийства выкачивается новая версия из регистри set +e POD=$(kubectl get pods -n NAMESPACE | grep -E '^POD_NAME-[0-9]+.*$' —color=none | cut -d ' ' -f 1) kubectl delete pods "$POD" -n NAMESPACE

Так RollingUpdate не сработает

да

наверняка есть лучше способ передавать переменные в деплоймен?

Насколько я знаю - нет. И 3 дня в неделю тоже говорят об этом

вакатку на боевые делаем через изменение тега образа у деплоймента

а если надо быстро и просто то таким скриптом

У нас DevOps написла небольшой скриптик на shell для убийства подов, после убийства выкачивается новая версия из регистри set +e POD=$(kubectl get pods -n NAMESPACE | grep -E '^POD_NAME-[0-9]+.*$' —color=none | cut -d ' ' -f 1) kubectl delete pods "$POD" -n NAMESPACE

вопервых поду можно найти через селектор и не городить эти грепы, во вторых есть же kubectl set

Ну как-то в тестинге тоже не хочется ронять всё разом

сколько ресурсов вы отдаете gitlab-ci runner в kubernetes, чтобы добиться его максимальной производительности?

Чтобы сетить дату? Поды пересоберутся?

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

пример kubectl delete po -l name=имя_деплоймента -n prod

Чтобы сетить дату? Поды пересоберутся?

через set можено менять любое поле в деплойменте

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

У меня поинт был именно в том, чтобы использовать latest

через set можено менять любое поле в деплойменте

Значит и поды пересоберутся. Не подумал об этом, это хороший способ, согласен. Но лично в моём случае у меня один и тот же темплейт на группу проектов + заменяются переменные в deployment и Dockerfile, посему нет возможности не использовать envsubst.

Ну т.е. есть, но теряется гибкость

Значит и поды пересоберутся. Не подумал об этом, это хороший способ, согласен. Но лично в моём случае у меня один и тот же темплейт на группу проектов + заменяются переменные в deployment и Dockerfile, посему нет возможности не использовать envsubst.

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

containers: - name: $CI_PROJECT_NAME image: docker.ecp-share.com/$CI_PROJECT_NAME-$CI_COMMIT_REF_NAME:latest imagePullPolicy: Always env: - name: REDEPLOY_VARIABLE value: '$DATE'

за imagePullPolicy большое спасибо а зачем устанавливаете в окружение REDEPLOY_VARIABLE?