А оракл вообще в контейнер лезет?

А оракл вообще в контейнер лезет?

Я видел статьи что можно засунуть. Только зачем? У любого DBA крыша потечёт от такого

Именно для этого :-) Знакомому DBA показать :-)

Теперь, хорошие новости в том, что при использовании сетевых плагинов, основанных на маршрутизации, типа calico, kube-router, в сеть подов и сеть сервисов можно попасть, если знать к ним маршруты. Собственно, внутри кластера они по дефолту будут (их распространит сетевой плагин), а вот внешним хостам их можно как-нибудь сообщить, например, через BGP (что эти сетевые плагины тоже умеют). Можно хоть статические маршруты прописать, однако это не очень хороший путь, так как при изменении состава кластера их придётся обновлять вручную.

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

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

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

А оракл вообще в контейнер лезет?

Отлично лезет. Можно скачать здесь: https://store.docker.com/images/oracle-database-enterprise-edition

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

Нельзя, но можно сделать отдельные сети сервисов и подов маршрутизируемыми.

Нельзя, но можно сделать отдельные сети сервисов и подов маршрутизируемыми.

Боль

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

это конечно не снимет нат оверхеда, но хотя бы не запутает по ip

Да не, ну там же просто всё. С дефолт гейтвеем пиришься по BGP и всё. Это звучит сложно, а по факту там настроек - AS и IP пира на кластере, ну и с десять строк в конфиге дефолт гейтвея, каким бы он ни был.

И всё, устанавливается tcp-соединение и в нём передаются маршруты.

Да не, ну там же просто всё. С дефолт гейтвеем пиришься по BGP и всё. Это звучит сложно, а по факту там настроек - AS и IP пира на кластере, ну и с десять строк в конфиге дефолт гейтвея, каким бы он ни был.

BGP это еще одна абстрация которая может пойти по пизде

BGP это еще одна абстрация которая может пойти по пизде

Не хватает только гластерфс и арубахостинга

Не хватает только гластерфс и арубахостинга

та видимо и это прийджется педалить)

Мда... Вот какие у вас нагрузки, да ещё с контейнерами, что вам штатный нат мешает?

BGP это еще одна абстрация которая может пойти по пизде

BGP в любом случае внутри кластера работает, если у тебя calico или kube-router.

BGP в любом случае внутри кластера работает, если у тебя calico или kube-router.

пока юзаю фланель, не дошел еще до изучения сети кубера

в плане выбора драйвера

В случае flannel роль BGP-демона выполняет демон flannel.

Мда... Вот какие у вас нагрузки, да ещё с контейнерами, что вам штатный нат мешает?

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

Ну и там очевидные минусы в духе "следить за таблицей соединений".

Но я не говорю, что НЕТ НАТ НЕЗЛЬЗЯ, просто надо понимать, как его использование на что будет влиять.

Если спросить щас кого-нибудь, у кого бд живёт уже пять лет, думаю 0 человек скажут, что они в кубере живут

ага, и специалистов по куберу с опытом 5+ лет тоже не найти

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

Мне просто чужда идея для nginx фронта использовать адрес ноды

А почему, собственно?

Впрочем, да, это внутри кубернетеса практически.

просто прийдется пилить ингриз который смотрит на nginx который смотрит на node

лишняя итерация

Выдели пару нод специально для nginx, по-моему, это будет проще, чем выделять дефицитные нынче белые адреса разбираться с BGP специально для того, чтобы избавиться от nginx вообще.

Тем более :-)

В openshift-же haproxy. Там где можно свои велосипеды сделали.

А неважно, что там, haproxy или nginx, по-моему... Возможности пересекаются.

Если спросить щас кого-нибудь, у кого бд живёт уже пять лет, думаю 0 человек скажут, что они в кубере живут

у нас живут, хотим старые базы тоже в куб перекочевать

что такое этот ваш openshif?

что такое этот ваш openshif?

в нем все из коробки.

а как чинить если что?

Я слышал что он умеет image docker по хэшу перекачивать)

Я слышал что он умеет image docker по хэшу перекачивать)

куб тоже же умеет

куб тоже же умеет

Я тут просто уже не один раз задавал этот вопрос... Блин было бы круто понять как это сделать

Я тут просто уже не один раз задавал этот вопрос... Блин было бы круто понять как это сделать

Нутк меняешь в описании пода имедж, разве нет?

Я тут просто уже не один раз задавал этот вопрос... Блин было бы круто понять как это сделать

image: example.org/myimage@sha256:c011cb2c4d597650093ecc5e72952446a8f5b23f9c1bc895de438f1ee6b4b26d

Ну а чтоб поды обновились сами, надо updateStrategy выставить в RollingUpdate, например.

В спеке ресурса.

image: example.org/myimage@sha256:c011cb2c4d597650093ecc5e72952446a8f5b23f9c1bc895de438f1ee6b4b26d

Наверное не правильно выразился( Сорян У нас image девелоперские метятся тегом develop, т.е тэг всегда одинаковый. K8s при обновлении релиза смотрит что тэг не изменился и ничего не делает. Я вышел из этой ситуации при помощи Helm, а точнее опции recreate pod и imagePullPolicy: Always

Наверное не правильно выразился( Сорян У нас image девелоперские метятся тегом develop, т.е тэг всегда одинаковый. K8s при обновлении релиза смотрит что тэг не изменился и ничего не делает. Я вышел из этой ситуации при помощи Helm, а точнее опции recreate pod и imagePullPolicy: Always

ну это оно самое

Наверное не правильно выразился( Сорян У нас image девелоперские метятся тегом develop, т.е тэг всегда одинаковый. K8s при обновлении релиза смотрит что тэг не изменился и ничего не делает. Я вышел из этой ситуации при помощи Helm, а точнее опции recreate pod и imagePullPolicy: Always

а откатываться назад как?

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

а откатываться назад как?

Вот именно не как) Девелоперы исправляют косяки в коде и перезапускают CI. Там имейдж билдится заново и потом деплоится в кластер. ? Я дико уже ору чтобы деволопер сборки начать тегировать или там отдельные фич-ветки)

ну тогда прочитай уже про sha256 manifest

ну тогда прочитай уже про sha256 manifest

Спасибо за подсказку, изучу этот момент. Просто ранее уже задавал этот вопрос тут, и мне кидали стикер " В openshif это из каробки" ?

Рил уже хочу этот Helm выкинуть куда подальше)

никакой магии там нет, просто есть imagestreams которые сами автоматически подставляют sha256sum в деплоймент

никакой магии там нет, просто есть imagestreams которые сами автоматически подставляют sha256sum в деплоймент

Да я это понял. Сейчас смотрю в спеку пода в класте и вижу k8s прям по хэшу выкачивает имейдж: @sha256:f264342e00705fe2812f77decbb5fe547d29298deed469e9cf2e81842cf60010

Да я это понял. Сейчас смотрю в спеку пода в класте и вижу k8s прям по хэшу выкачивает имейдж: @sha256:f264342e00705fe2812f77decbb5fe547d29298deed469e9cf2e81842cf60010

да, я уже у себя так сделал. не делать docker push повторов и использовать sha256, чтобы не передергивать deployment зря.

да, я уже у себя так сделал. не делать docker push повторов и использовать sha256, чтобы не передергивать deployment зря.

А что для CI используешь?

gitlab

gitlab

Крутяк! Щас сижу доку чекаю, но так и не нашел переменную, которая бы в себе хранила хэш докер билда

там один минус, работает с 1 билд сервером, на двух уже расходится @vrutkovs подсказывал.

docker inspect --format="{{index .RepoDigests 0}}" image:tag

подробности думаю не сильно интересны.

RepoDigests появляется только после docker push

RepoDigest как-раз таки расходиться не должен

RepoDigest как-раз таки расходиться не должен

я не лажу в registry пока не уверен, что нужно. Это работает с 1 билд сервером. С 2+ придётся каждый раз лазить.

там один минус, работает с 1 билд сервером, на двух уже расходится @vrutkovs подсказывал.

У нас один Gitlab Ci на проект, если имел в виду про это Спасибо за совет, реально работает)

я криво выразился. в общем docker inspect --format="{{index .RepoDigests 0}}" image:tag появляется после docker push и это то, с чем k8s сможет стянуть образ.

я криво выразился. в общем docker inspect --format="{{index .RepoDigests 0}}" image:tag появляется после docker push и это то, с чем k8s сможет стянуть образ.

Да я понял. Буду просто отдавать k8s как image tag и должно все работать.

По sha256 ещё можно смотреть нужно ли делать docker push. Экономит секунд 5, на монорепе ощутимо, стараюсь реализовать git push до running в кластере за <1min.

По sha256 ещё можно смотреть нужно ли делать docker push. Экономит секунд 5, на монорепе ощутимо, стараюсь реализовать git push до running в кластере за <1min.

Понял, ну у нас с этим проблем особо нет. Есть стадия на которой смогу получать эту перемнную и потом в темплейт ее вставлять. Там Helm используется) Сначала формирую релиз при помощи sed -i , потому пушу его в репозиторий helm, и деплою его в кластер.

sed -i замена переменных?

м

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

вот мой деплой в пайлайне: 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

envsubst уберёт 3 строки =)

Добрый вечер. Один небольшой вопрос Есть 1 pod в replicaset. На нем выполняется длительная задача и кубернетес убивает этот под, сразу поднимает новый. Никаких лимитов на ресурсы нет. Таймаут LIveness probe очень большой и сервис работает по логам стабильно. Где можно посмотреть причины дестроя? Может есть какая-то статья про такой траблшутинг. Подумал что в логах kubelet, но там ничего нет.

Добрый вечер. Один небольшой вопрос Есть 1 pod в replicaset. На нем выполняется длительная задача и кубернетес убивает этот под, сразу поднимает новый. Никаких лимитов на ресурсы нет. Таймаут LIveness probe очень большой и сервис работает по логам стабильно. Где можно посмотреть причины дестроя? Может есть какая-то статья про такой траблшутинг. Подумал что в логах kubelet, но там ничего нет.

kubectl describe pod

а что дескрайбить, того пода уже нет

kubectl get pod -a

хах спасибо)

envsubst уберёт 3 строки =)

Я помню ты советовал мне это) Щас перепиливаю деплой в кубер, думаю там это реализую) Щас главная цель выкинуть Helm

Не там его нет. Это 7 часов назад произошло

всегда можно пойти на ноду и сделать docker ps -a, даже если не знать всех фишек куба (делал так, когда осваливался)

только живые поды

вариант подождать креша 100% гарантированный ? А так время утекло, не думаю, что можно.

А понял, спасибо, надо уведомление видимо ставить

на cron поставить describe в файл в крайнем случае, если редко и ночью. Самые простые варианты предлагаю, понятно, что можно мудрить много чего.

kubectl describe ... > describe$(date)

Добрый вечер. Один небольшой вопрос Есть 1 pod в replicaset. На нем выполняется длительная задача и кубернетес убивает этот под, сразу поднимает новый. Никаких лимитов на ресурсы нет. Таймаут LIveness probe очень большой и сервис работает по логам стабильно. Где можно посмотреть причины дестроя? Может есть какая-то статья про такой траблшутинг. Подумал что в логах kubelet, но там ничего нет.

Я обычно такие поды мониторю в режиме реального времени, или по логам потом смотрю события.

Да там падение очень непредсказуемое. Спасибо ,главное что я понял что просто так не посмотреть)

Да там падение очень непредсказуемое. Спасибо ,главное что я понял что просто так не посмотреть)

У меня подобные сервисы есть, но отлавливаем их ошибки по историям в логах. Задеплой себе в кластер fluent bit и потом смотри логи через kibana к примеру. Я так делаю)

Да проблема в том что у меня Гугл Клауд и пишется огромное количество логов. Плюс инстана есть. И там абсолютно ничего

Да проблема в том что у меня Гугл Клауд и пишется огромное количество логов. Плюс инстана есть. И там абсолютно ничего

Ну есть банальная опция в kibana фильтровать логи по дате

Да я вижу что в этой дате произошло - там просто обрыв в логах kubelet тоже обычные чеки какие то. Ну ладно

Да проблема в том что у меня Гугл Клауд и пишется огромное количество логов. Плюс инстана есть. И там абсолютно ничего

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

Да я вижу что в этой дате произошло - там просто обрыв в логах kubelet тоже обычные чеки какие то. Ну ладно

Событий, почему твой сервис упал может быть куча. Тут только в помощь метрики и логи.