А ты ищешь gbrqq

Спасибо за помощь, видимо после ребута забыл поправить, теперь работает.

Кроме того что tiller все равно офф, пишу kubectl logs -n kube-system tiller-deploy-64c9d747bd-xdvtt ничего не выводи, возможно ли опередлить в чем может быть причина? Пробовал заного инициализировать tiller

а зачем смотреть на имя пода?

а зачем смотреть на имя пода?

Не совсем понял, разьве это не верный способ получить логи?

логи - возможно

там coredns лежит, никого не беспокоит?

коллеги, имею такой вопрос: есть managed k8s есть куча сервисов которые надо выставить наружу девелоперам, но которые не умеют в авторизацию, прикрывать их буду ingress+basic auth + есть часть сервисов которая умеет в авторизацию собственную. хочу сделать один источник, на ум приходит ldap, ingress и сервисы в него умеют. не хочу завязываться на cloud auth backend'ы, надо оставаться в этом плане cloud-agnostic а есть предложения получше?

Оно? https://kubernetes.github.io/ingress-nginx/examples/auth/oauth-external-auth/

Там из примера нефига не понятно, но работает через https://nginx.org/en/docs/http/ngx_http_auth_request_module.html

Приветствую, подскажите при установке кластера через kubespray обязательно ставить python 3?

На 3 сеть плохо поднималась в последний раз

Привет, можете подсказать как лучше всего делать миграции схемы бд? Видел варианты с джобами, initContainer, вшивать в сами сервисы. Выглядит, что джобы самый хороший вариант - запускается 1 раз, если фейлится, то можно не пытаться перезапускать и остановить весь билд

ну я делал джобами через Helm hook'и. пока честно говоря не понял насколько это хорошо. Helm хуки запускает последовательно, даже если у них веса одинаковые. В итоге не очень быстро получается. Миграции на разные базы так-то можно было бы параллельно запускать.

Спасибо!

коллеги, я потрачу два дня на ресерч ouath и авторизации и напишу отчет что вышло одна проблема, есть большая вероятность, что кластер с ouath переедет в amazon china и как там будет работать таже гугл авторизация - большой вопрос к китайской великой стене

Я в обычном Прометее указывал role: pod и дискаверил все поды, а как это в прометеус операторе?

Что-то у меня такое ощущение что там для каждого сервиса надо писать свой сервис монитор

я думал в этом и соль

Да, возможно.

Привет, можете подсказать как лучше всего делать миграции схемы бд? Видел варианты с джобами, initContainer, вшивать в сами сервисы. Выглядит, что джобы самый хороший вариант - запускается 1 раз, если фейлится, то можно не пытаться перезапускать и остановить весь билд

Я запускаю в ci/cd. И там и не полян, почему так никто не делает.

Зачем писать костыли с ожиданием нужной версии базу и тп. С ограничениями на «запустить 1 раз» и тп. Вместо того, чтобы просто запускать миграции до kubectl apply

+ у меня в принципе миграции отдельный подпроект на sqitch. От которого зависят куча других сервисов.

Привет, можете подсказать как лучше всего делать миграции схемы бд? Видел варианты с джобами, initContainer, вшивать в сами сервисы. Выглядит, что джобы самый хороший вариант - запускается 1 раз, если фейлится, то можно не пытаться перезапускать и остановить весь билд

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

И опять, ну почемууу не запускать в ci/cd?

привет всем. подскажите плз как прикрутить к ingress-nginx блокировку по странам?

Я запускаю в ci/cd. И там и не полян, почему так никто не делает.

т.е. миграции не изнутри k8s запускаются? Или я не понимаю значение "запускаю в ci/cd"

У меня базы не в кластере. А были бы в кластере... ну тоже не проблема подключится и выполнить.

т.е. миграции не изнутри k8s запускаются? Или я не понимаю значение "запускаю в ci/cd"

Имеется в виду что в пайплане CI | CD инструмента запускается таска, которая делает все это дело.

И опять, ну почемууу не запускать в ci/cd?

ну кстать да. Хорошая идея.

И это на 100% решает проблему «миграции не прошли», а в кубе пошла раскатка

т.е. миграции не изнутри k8s запускаются? Или я не понимаю значение "запускаю в ci/cd"

Там где вы делаете kubectl apply... где-то перед этим делать migrate. Это не обязательно ci/cd

Но по хорошему ci/cd конечно

Там где вы делаете kubectl apply... где-то перед этим делать migrate. Это не обязательно ci/cd

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

На kubectl тоже доступы нужны. А там можно даже kube proxy к базе, если она в кубе

Агенты у меня разделены на обычные и protected которые могут лезть в базу. Те на docker build, тесты и тп база не нужна.

А там где можно сделать kubectl apply можно и дописать код, которы залезет в базу и сделает что нужно. Т.е в этом месте нет смыла ограничивать доступ к базе.

А там где можно сделать kubectl apply можно и дописать код, которы залезет в базу и сделает что нужно. Т.е в этом месте нет смыла ограничивать доступ к базе.

А я как то ansible джобу щапускал с таском) тот еще кастыль был

@SinTeZoiD ^^^

@SinTeZoiD ^^^

че? снесли?

че? снесли?

Погляди плиз в логах чата, видимо ИИ заработало

Погляди плиз в логах чата, видимо ИИ заработало

да

меня пугает твои ИИ правда

https://media2.giphy.com/media/8fen5LSZcHQ5O/200.gif

да

если лень тянутся в админку, то в ответ на спам реплайни /ban и готово

https://stackoverflow.com/questions/37523615/dynamic-proxy-pass-in-nginx-to-another-pod-in-kubernetes пример 2 контейнеров в поде. Так просто под руку попалось, часто спрашивают.

nginx + dns resolver на сервисы кластера

Конретно мне это нужно для nginx, который делает proxy_pass на imageproxy (resize), который берёт соседний сервис с картинками. nginx с proxy_cache location ~ ^/images/(?<size>\d+)/(?<path>.*)$ { expires 15d; add_header Pragma public; add_header Cache-Control "public"; proxy_pass http://imageproxy:8080/$size,q80/http://erp:3000/uploads/$path; proxy_cache thumbs; proxy_cache_valid 200 24h; } Может такое как-то по другому лучше решить?

Привет, можете подсказать как лучше всего делать миграции схемы бд? Видел варианты с джобами, initContainer, вшивать в сами сервисы. Выглядит, что джобы самый хороший вариант - запускается 1 раз, если фейлится, то можно не пытаться перезапускать и остановить весь билд

я через отдельный деплоймент делаю: - через ci поднимаю деплоймент с 1 подом, в котором новые миграции - через kubectl exec pod_name запускаю команду для миграций - если все ок и код возврата команды 0 то удаляется деплоймет и дальше хелмом выкатывается приложение разрабы пишут обратно совместимые миграции, т.е новая схема не ломает старую версию приложения через джобы чот не понравилось, т.к не удобно смотреть что там сломалось в миграции, а так сразу в зафейленой джобе в ci это видно

я через отдельный деплоймент делаю: - через ci поднимаю деплоймент с 1 подом, в котором новые миграции - через kubectl exec pod_name запускаю команду для миграций - если все ок и код возврата команды 0 то удаляется деплоймет и дальше хелмом выкатывается приложение разрабы пишут обратно совместимые миграции, т.е новая схема не ломает старую версию приложения через джобы чот не понравилось, т.к не удобно смотреть что там сломалось в миграции, а так сразу в зафейленой джобе в ci это видно

похоже что вы job переизобрели

похоже что вы job переизобрели

Kubectl exec синхронный и с кодом возврата сразу

я через отдельный деплоймент делаю: - через ci поднимаю деплоймент с 1 подом, в котором новые миграции - через kubectl exec pod_name запускаю команду для миграций - если все ок и код возврата команды 0 то удаляется деплоймет и дальше хелмом выкатывается приложение разрабы пишут обратно совместимые миграции, т.е новая схема не ломает старую версию приложения через джобы чот не понравилось, т.к не удобно смотреть что там сломалось в миграции, а так сразу в зафейленой джобе в ci это видно

kubectl run делает похожее но в одну команду

кстати да, это то, что меня в helm раздражает - нельзя достать оттуда логи свалившегося ресурса

подкинули такую штуку https://github.com/Praqma/helmsman

Есть какой-то тул, чтобы сделать backward tunnel, который будет service в кубе? Нужно из-за ната достать сервис.

Любой контейнер с ссх у которого есть доступ к сервису

Привет, можете подсказать как лучше всего делать миграции схемы бд? Видел варианты с джобами, initContainer, вшивать в сами сервисы. Выглядит, что джобы самый хороший вариант - запускается 1 раз, если фейлится, то можно не пытаться перезапускать и остановить весь билд

Я заюзал инит контейнер.

И опять, ну почемууу не запускать в ci/cd?

Ну как вариант прийдется в раннер прокидывать дБ коннекшн.

И это на 100% решает проблему «миграции не прошли», а в кубе пошла раскатка

Да, вариант хороший.

Есть какой-то тул, чтобы сделать backward tunnel, который будет service в кубе? Нужно из-за ната достать сервис.

Если к apiserver доступ есть, то с него можно проксировать куда угодно

только http

кстати да, это то, что меня в helm раздражает - нельзя достать оттуда логи свалившегося ресурса

kubectl logs -l release=релиз чарта

Добрый день, подскажите пытаюсь подключить в куб хранилище ceph(rbd), создал пул и токены, опирался на статью https://habr.com/company/flant/blog/329666/ Создаю PersistentVolumeClaim провиженер создаёт PersistentVolume в статусе Bound но когда я создаю поду она постоянно висит в ContainerCreating и валит Unable to mount volumes for pod "nginx-kzk9q_default(67554154-bb0d-11e8-a168-d2e32a8364ee)": timeout expired waiting for volumes to attach or mount for pod "default"/"nginx-kzk9q". list of unmounted volumes=[mypvc]. list of unattached volumes=[mypvc default-token-dkrnn]

Товарищи, подскажите . У меня в кластере есть нода, которая помечена как NoSchedule. тут произошла авария в кластере, и все поды смигрировали на этот воркер. Это нормально?

kube-controller-manager брал quay.io/attcomdev/kube-controller-manager:v1.6.1 куб версии v1.10.5

Добрый день, подскажите пытаюсь подключить в куб хранилище ceph(rbd), создал пул и токены, опирался на статью https://habr.com/company/flant/blog/329666/ Создаю PersistentVolumeClaim провиженер создаёт PersistentVolume в статусе Bound но когда я создаю поду она постоянно висит в ContainerCreating и валит Unable to mount volumes for pod "nginx-kzk9q_default(67554154-bb0d-11e8-a168-d2e32a8364ee)": timeout expired waiting for volumes to attach or mount for pod "default"/"nginx-kzk9q". list of unmounted volumes=[mypvc]. list of unattached volumes=[mypvc default-token-dkrnn]

посмотрите, есть ли у вас ceph-common на ндах и доступна ли цефовая сеть

kubectl logs -l release=релиз чарта

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

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

тогда kubectl describe -l

о. ещё раз спасибо

решение было на поверхности

посмотрите, есть ли у вас ceph-common на ндах и доступна ли цефовая сеть

да на нодах установлена версия ceph-common-12.2.8-0.el7.x86_64 на мастере правда небыло, доставил. Целевая сеть доступна

Товарищи, подскажите . У меня в кластере есть нода, которая помечена как NoSchedule. тут произошла авария в кластере, и все поды смигрировали на этот воркер. Это нормально?

Нода в статусе: Ready,SchedulingDisabled. Я в первые столкнулся с такой проблемой, и думал раньше что отсутсвие толерантности у подов, они не смогут запустится на этой ноде(

подскажет кто где в ui гугл клаудового кубера посмотреть крон джобы

через консоль понятно kubectl --namespace=trata get cronjob

а в ui

Добрый день, подскажите пытаюсь подключить в куб хранилище ceph(rbd), создал пул и токены, опирался на статью https://habr.com/company/flant/blog/329666/ Создаю PersistentVolumeClaim провиженер создаёт PersistentVolume в статусе Bound но когда я создаю поду она постоянно висит в ContainerCreating и валит Unable to mount volumes for pod "nginx-kzk9q_default(67554154-bb0d-11e8-a168-d2e32a8364ee)": timeout expired waiting for volumes to attach or mount for pod "default"/"nginx-kzk9q". list of unmounted volumes=[mypvc]. list of unattached volumes=[mypvc default-token-dkrnn]

Я на сентоси к этлй проблеме 3 подхода сделал, так никто и не смог помочь, забил и на глюстере за 10мин развернул

да на нодах установлена версия ceph-common-12.2.8-0.el7.x86_64 на мастере правда небыло, доставил. Целевая сеть доступна

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

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

хорошо, ребята говорят что нужно брать kube-controller-manager той же версии что и сам куб

1.7.3 последний брал

подскажет кто где в ui гугл клаудового кубера посмотреть крон джобы

вроде там же, где и deployment'ы

в workloads

Добрый день, пожскажите пожалуйста. Использую связку Rancher 2 и kubernetes v1.10.5. Создан кластер из 3 тачек на амазоне(control, etcd, worker). И при загрузке рам воеркера более чем на 70 процентов кластер падает. Куда копать, что читать?

куда падает? на пол?

Вопрос: кто как борится с rbd locked images? Сейчас приходится в ручную, т.е. ansible скриптом если не отпускает image нод.

Зависает control, а точнее перестает отвечать kubelet