Stanislav
/me припомнил, что на текущей работе основная БД как была на отдельной виртуалке 10 лет назад, так и осталась
Stanislav
50Гб
bebebe
У меня в загашнике оракл на центоси 4.х с 2006 по-моему крутится. Только диски меняем
Stanislav
А оракл вообще в контейнер лезет?
bebebe
А оракл вообще в контейнер лезет?
Я видел статьи что можно засунуть. Только зачем? У любого DBA крыша потечёт от такого
Stanislav
Именно для этого :-) Знакомому DBA показать :-)
Grisha
Соответственно, если сеть подов доступна, поды можно публиковать как headless сервис и получать все недостатки балансировки через DNS, но и все профиты от отсутствия ната где бы то ни было.
в итоге, из того что я понял, без определенных сношений с таблицой маршрутиации нет возможности выделить сервису адрес из сети ноды?
Vlad
А оракл вообще в контейнер лезет?
Отлично лезет. Можно скачать здесь: https://store.docker.com/images/oracle-database-enterprise-edition
Grisha
Получаете чтобы сильно не рукоблудить кубер ноды с ингризом или сервисами нужно поднимать в отдельных ВМ и натить
Grisha
это конечно не снимет нат оверхеда, но хотя бы не запутает по ip
Никита
Да не, ну там же просто всё. С дефолт гейтвеем пиришься по BGP и всё. Это звучит сложно, а по факту там настроек - AS и IP пира на кластере, ну и с десять строк в конфиге дефолт гейтвея, каким бы он ни был.
Никита
И всё, устанавливается tcp-соединение и в нём передаются маршруты.
bebebe
BGP это еще одна абстрация которая может пойти по пизде
Не хватает только гластерфс и арубахостинга
Grisha
Не хватает только гластерфс и арубахостинга
та видимо и это прийджется педалить)
Stanislav
Мда... Вот какие у вас нагрузки, да ещё с контейнерами, что вам штатный нат мешает?
Никита
BGP это еще одна абстрация которая может пойти по пизде
BGP в любом случае внутри кластера работает, если у тебя calico или kube-router.
Grisha
BGP в любом случае внутри кластера работает, если у тебя calico или kube-router.
пока юзаю фланель, не дошел еще до изучения сети кубера
Grisha
в плане выбора драйвера
Никита
В случае flannel роль BGP-демона выполняет демон flannel.
Никита
Мда... Вот какие у вас нагрузки, да ещё с контейнерами, что вам штатный нат мешает?
Нат - это стейт. Например, обратный трафик из пода должен обязательно пройти через тот балансер, через который он попал в под.
Никита
Ну и там очевидные минусы в духе "следить за таблицей соединений".
Никита
Но я не говорю, что НЕТ НАТ НЕЗЛЬЗЯ, просто надо понимать, как его использование на что будет влиять.
Stanislav
Ну то есть, это такая попытка не ставить отдельный фронтенд вне кубера для публичного сервиса? Просто в случае, если сервис непубличный, нат вряд ли хоть как-то заметно повлияет на работу - просто не будет такого количества соединений.
Grisha
Мне просто чужда идея для nginx фронта использовать адрес ноды
Stanislav
А почему, собственно?
Stanislav
Впрочем, да, это внутри кубернетеса практически.
Grisha
просто прийдется пилить ингриз который смотрит на nginx который смотрит на node
Grisha
лишняя итерация
Stanislav
Выдели пару нод специально для nginx, по-моему, это будет проще, чем выделять дефицитные нынче белые адреса разбираться с BGP специально для того, чтобы избавиться от nginx вообще.
Stanislav
Тем более :-)
Vlad
В openshift-же haproxy. Там где можно свои велосипеды сделали.
Stanislav
А неважно, что там, haproxy или nginx, по-моему... Возможности пересекаются.
Grisha
что такое этот ваш openshif?
Sergei
что такое этот ваш openshif?
в нем все из коробки.
Grisha
а как чинить если что?
Denis
Я слышал что он умеет image docker по хэшу перекачивать)
Denis
куб тоже же умеет
Я тут просто уже не один раз задавал этот вопрос... Блин было бы круто понять как это сделать
𝚔𝚟𝚊𝚙𝚜
Никита
Ну а чтоб поды обновились сами, надо updateStrategy выставить в RollingUpdate, например.
Никита
В спеке ресурса.
Denis
image: example.org/myimage@sha256:c011cb2c4d597650093ecc5e72952446a8f5b23f9c1bc895de438f1ee6b4b26d
Наверное не правильно выразился( Сорян У нас image девелоперские метятся тегом develop, т.е тэг всегда одинаковый. K8s при обновлении релиза смотрит что тэг не изменился и ничего не делает. Я вышел из этой ситуации при помощи Helm, а точнее опции recreate pod и imagePullPolicy: Always
𝚔𝚟𝚊𝚙𝚜
просто вместо тэга указываешь хэш, если такого image с этим хэшом на ноде нет, скачивается новый image
Denis
а откатываться назад как?
Вот именно не как) Девелоперы исправляют косяки в коде и перезапускают CI. Там имейдж билдится заново и потом деплоится в кластер. 😂 Я дико уже ору чтобы деволопер сборки начать тегировать или там отдельные фич-ветки)
Vadim
ну тогда прочитай уже про sha256 manifest
Denis
ну тогда прочитай уже про sha256 manifest
Спасибо за подсказку, изучу этот момент. Просто ранее уже задавал этот вопрос тут, и мне кидали стикер " В openshif это из каробки" 😁
Denis
Рил уже хочу этот Helm выкинуть куда подальше)
Andor
Vadim
никакой магии там нет, просто есть imagestreams которые сами автоматически подставляют sha256sum в деплоймент
Denis
никакой магии там нет, просто есть imagestreams которые сами автоматически подставляют sha256sum в деплоймент
Да я это понял. Сейчас смотрю в спеку пода в класте и вижу k8s прям по хэшу выкачивает имейдж: @sha256:f264342e00705fe2812f77decbb5fe547d29298deed469e9cf2e81842cf60010
Rainbow
Да я это понял. Сейчас смотрю в спеку пода в класте и вижу k8s прям по хэшу выкачивает имейдж: @sha256:f264342e00705fe2812f77decbb5fe547d29298deed469e9cf2e81842cf60010
да, я уже у себя так сделал. не делать docker push повторов и использовать sha256, чтобы не передергивать deployment зря.
Rainbow
gitlab
Denis
gitlab
Крутяк! Щас сижу доку чекаю, но так и не нашел переменную, которая бы в себе хранила хэш докер билда
Rainbow
там один минус, работает с 1 билд сервером, на двух уже расходится @vrutkovs подсказывал.
Rainbow
docker inspect --format="{{index .RepoDigests 0}}" image:tag
Rainbow
подробности думаю не сильно интересны.
Rainbow
RepoDigests появляется только после docker push
Vadim
RepoDigest как-раз таки расходиться не должен
Rainbow
RepoDigest как-раз таки расходиться не должен
я не лажу в registry пока не уверен, что нужно. Это работает с 1 билд сервером. С 2+ придётся каждый раз лазить.
Denis
там один минус, работает с 1 билд сервером, на двух уже расходится @vrutkovs подсказывал.
У нас один Gitlab Ci на проект, если имел в виду про это Спасибо за совет, реально работает)
Rainbow
я криво выразился. в общем docker inspect --format="{{index .RepoDigests 0}}" image:tag появляется после docker push и это то, с чем k8s сможет стянуть образ.
Rainbow
По sha256 ещё можно смотреть нужно ли делать docker push. Экономит секунд 5, на монорепе ощутимо, стараюсь реализовать git push до running в кластере за <1min.
Denis
По sha256 ещё можно смотреть нужно ли делать docker push. Экономит секунд 5, на монорепе ощутимо, стараюсь реализовать git push до running в кластере за <1min.
Понял, ну у нас с этим проблем особо нет. Есть стадия на которой смогу получать эту перемнную и потом в темплейт ее вставлять. Там Helm используется) Сначала формирую релиз при помощи sed -i , потому пушу его в репозиторий helm, и деплою его в кластер.
Rainbow
sed -i замена переменных?
Anonymous
м
Denis
sed -i замена переменных?
вот мой деплой в пайлайне: script: - export TAG="$(python3 /bin/release-tag.py)" - mv ./helm/chart ./helm/$CI_PROJECT_NAME - sed -i "s/{%version%}/$TAG/g" ./helm/$CI_PROJECT_NAME/Chart.yaml - sed -i "s/{%projectname%}/$CI_PROJECT_NAME/g" ./helm/$CI_PROJECT_NAME/Chart.yaml - sed -i "s/{%image_tag%}/$CI_BUILD_REF_NAME/g" ./helm/$CI_PROJECT_NAME/values.yaml - helm package ./helm/$CI_PROJECT_NAME - helm s3 push --force $CI_PROJECT_NAME-$TAG.tgz retail - helm s3 reindex retail - helm-values -u $GITLAB_URI - helmfile --selector release=develop sync