Но такая проблема в основном у тех, кто делает по чьим-то howto, которые быстро протухают

Сам на это попался

Именно

так самый правильный путь - почитать как люди делают и сделать по аналогии

Как делают или как делали?

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

Как делают или как делали?

а откуда тебе знать если ты видишь этот продукт первый раз?

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

Столкулся еще с одной проблемой. Как правильно сгенерировать tls секрет лля ingress, в случае, когда есть цепочка своих untrusted сертификатов, подписанных своим CA? Каков порядок catа файлов в файл сертификата и в файл ключа, которые потом станут секретом?

а без ингресса и кубера умеешь это настраивать?

Наверно, цепочку cert, CA, root в certfile, ключ в keyfile, да kubectl create secret tls secretname --key keyfile --cert certfile

а без ингресса и кубера умеешь это настраивать?

Судя по гуглежу там есть определенный порядок.

То есть ты это никогда раньше в жизни не настраивал, так?

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

но по сути там сертификат первый и дальше все CA по цепочке конкатенируешь в один файл

Кстати, в кубе все в принципе понятно, остальное доходится при помощи смекалки. Либо это уже проблемы порога вхождения.

Я прям в восторге от того, как там классно все устроено.

ты ещё скажи "просто"

Кстати, да.

То есть ты это никогда раньше в жизни не настраивал, так?

Делал конечно, но без цепочки

Нужно просто понять все сущности куба и их иерархию. Это описано в первых страницах мануала. Остальное - мелочи, которые решаются либо тыком, либо скрупулёзным изучением мануалов.

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

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

helm?

Нет

Kontemplate для шаблонизации и скрипты

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

там этот функционал из коробки.

Kontemplate для шаблонизации и скрипты

ещё один

В тему актуальной документации: у кого-нибудь есть рабочий пример мониторинга, например, nginx с помощью prometheus operator?

У меня нет желания бороться с приколами helm Трогал, не понравилось Простые шаблоны + немного обвязки меня устраивает

Andor а что не так?

Приколы Хелм? Там же просто все.

а kubectl rollout status не подходит?

для кейса когда меняется только image в деплоейменте - должно быть достаточно

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

watch kubectl get pods —all-namespaces?

ну если вы хельм не хотите) пушьте ямлик, и смотрите пока все не станет Running, обновлением инфы раз в сколько то сек))

watch kubectl get pods —all-namespaces?

нужно так же смотреть и в loadbalancer если они существуют например на aws, иногда они деплояются сильно долго (до 3-4 минут), а поды уже ready

Парни, могу ли я забиндить SA на несколько NS ? kubectl create rolebinding user-role —clusterrole=admin —serviceaccount=user:default —namespace=user-ns

Так с prom operator никто не работал?

В чяте метрик спроси

Не могу удалить поды, где копать? $ kubectl delete -n kube-system --force=true --now=true pod kube-dns-bb945d984-jrqrh pod "kube-dns-bb945d984-jrqrh" deleted $ kubectl delete -n kube-system --force=true --now=true pod kube-dns-bb945d984-jrqrh pod "kube-dns-bb945d984-jrqrh" deleted $ kubectl delete -n kube-system --force=true --now=true pod kube-dns-bb945d984-jrqrh pod "kube-dns-bb945d984-jrqrh" deleted $ kubectl -n kube-system get pod kube-dns-bb945d984-jrqrh NAME READY STATUS RESTARTS AGE kube-dns-bb945d984-jrqrh 0/3 Terminating 28 11d

Они не стартуют новые и ничего не работает

describe?

Не могу удалить поды, где копать? $ kubectl delete -n kube-system --force=true --now=true pod kube-dns-bb945d984-jrqrh pod "kube-dns-bb945d984-jrqrh" deleted $ kubectl delete -n kube-system --force=true --now=true pod kube-dns-bb945d984-jrqrh pod "kube-dns-bb945d984-jrqrh" deleted $ kubectl delete -n kube-system --force=true --now=true pod kube-dns-bb945d984-jrqrh pod "kube-dns-bb945d984-jrqrh" deleted $ kubectl -n kube-system get pod kube-dns-bb945d984-jrqrh NAME READY STATUS RESTARTS AGE kube-dns-bb945d984-jrqrh 0/3 Terminating 28 11d

пересоздать deployment?

describe?

Warning FailedKillPod 34m kubelet, localhost error killing pod: [failed to "KillContainer" for "kubedns" with KillContainerError: "rpc error: code = Unknown desc = Error response from daemon: cannot stop container: 9d2f1a078f7765841f4709c0d092b43da49a646e56216ef844ae8fc4259cab55: Cannot kill container 9d2f1a078f7765841f4709c0d092b43da49a646e56216ef844ae8fc4259cab55: grpc: the client connection is closing: failed precondition" ...

Причем эти логи я смотрю за 34 минуты назад

О деплоймент я удалить тоже не могу

А чего-то я ничего удалить не могу видимо

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

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

кублета и системные

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

Я пробовал убить ноду, удалить все контейнеры на ней. И запустить ее опять. Оно начинает вроде стартовать но потом опять та же ситуация

dmesg?

Народ, чото я не пойму, а где включаются класические пользователи? Kind: User ?

dmesg?

dmesg чистый, обычный, без ошибок

Что вообще такое Kind: User? Может я не совсем понимаю его назначение?

https://kubernetes.io/docs/admin/authorization/rbac/#user-facing-roles а тут читали?

Как лучше сделать? для единовременного выполнения миграций в базе данных лучше в деплойменте сделать контейнер с политикой restartPolicy: Never или как-то через job сделать?

https://kubernetes.io/docs/admin/authorization/rbac/#user-facing-roles а тут читали?

Читал, но видимо не так понял, в голове уже все перемешалось :) А можно как то групировать ресурсы в кубике? К примеру я хочу дать админский доступ одному ServiceAccout до нескольких Namespace?! Можно это реализовать не прибивая его к каждому ручками?

Как лучше сделать? для единовременного выполнения миграций в базе данных лучше в деплойменте сделать контейнер с политикой restartPolicy: Never или как-то через job сделать?

https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

по миграциям тут все сильно зависит от базы и самих миграций

у нас джобами сделаны миграции

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

Читал, но видимо не так понял, в голове уже все перемешалось :) А можно как то групировать ресурсы в кубике? К примеру я хочу дать админский доступ одному ServiceAccout до нескольких Namespace?! Можно это реализовать не прибивая его к каждому ручками?

у меня 1.5 везде и только планируем переезд на 1.10 так что я в RBAC плаваю :(

у меня 1.5 везде и только планируем переезд на 1.10 так что я в RBAC плаваю :(

Вот и я чтото плаваю, не логичный он нихрена, либо слишком примитивный

https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

спасибо

Так с prom operator никто не работал?

Вопрос именно в этом, работал или нет?)

Вопрос именно в этом, работал или нет?)

Да никак не могу прицепить свой ServiceMonitor

А что именно не получается? Я первый раз по их доке на coreos все делал, вроде все ок

Может с labels намудрил чего то?

Может. В deployment и сервисе стоит labels: exporter: clickhouse в ServiceMonitor selector: matchLabels: exporter: clickhouse namespaceSelector: any: true Создаю в namespace где и пром, monitoring. После добавления operator в логах пишет "updating config skipped, no configuration change"

А в ServiceMonitor прописываешь label, которые ждет kind: Prometheus?

Ставил через helm coreos/kube-prometheus, на сколько я понял, по умолчанию SerivceMonitorSelector пустой, что означает что он должен дискаверить все ServiceMonitor

Кинул в личку свой пример. Про "дискаверить все ServiceMonitor" - не понмю, кажется я не пробовал. Я сразу label прописвывал

Всем спасибо, всё взлетело

Так а в чем проблема-то была? Интересно же)

Так а в чем проблема-то была? Интересно же)

Пока хз, но прописал в values файл то же самое и взлетело. Грешу на метки, узнаю уже в понедельник

Окееей. Спасибо

привет, настраиваю tls bootstrapping для кублетов и не работают ни logs ни exec, валятся с ошибкой: x509: certificate signed by unknown authority

как это поправить?

ну если вы хельм не хотите) пушьте ямлик, и смотрите пока все не станет Running, обновлением инфы раз в сколько то сек))

Вот кстати интересно. Деплою через bamboo, как узнать статус успешно прошел деплой или нет ? Сейчас деплою через yaml. Например возникает следующая ситуация yaml принят успешно, но допустим есть ошибка в коде и под валится после старта. И узнаю я об этом только от прометея. Helm может как то решить эту проблему ? Ну что бы я в выхлопе деплоя в bamboo выдел что что-то пошло не так ?

Вот кстати интересно. Деплою через bamboo, как узнать статус успешно прошел деплой или нет ? Сейчас деплою через yaml. Например возникает следующая ситуация yaml принят успешно, но допустим есть ошибка в коде и под валится после старта. И узнаю я об этом только от прометея. Helm может как то решить эту проблему ? Ну что бы я в выхлопе деплоя в bamboo выдел что что-то пошло не так ?

Добавить еще один таск с тестами?

Добавить еще один таск с тестами?

Ну не знаю... сам по себе pull образа из реджестри может быть долгим ... Хотя вполне вариант , спасибо за идею

Добавить еще один таск с тестами?

а откуда этот таск узнает что всё что надо раздеплоилось?

и что надо тест запустить

а кто-то настраивал у себя tls bootstrapping?

и что надо тест запустить

Сделать N retry’ев c интервалом в секунд 10

и что надо тест запустить

Ну он может быть последним в списке. И соответсвенно из переменных окружения будет знать какой под чекать

Сделать N retry’ев c интервалом в секунд 10

отличный костыль, но ведь надо проверять не старую версию?

можно отдавать release через nginx

это теория или сам так делал?

Пока не делал, но сделать чек внутри приложения с отдачей нужных данных не проблема

можно отдавать release через nginx

Ну release может и от старого придти...

а новое может вообще не запуститься например

ну короче смысл делать такой тест если всё равно прометей есть, который по сути частично этот тест дублирует

Ну release может и от старого придти...

Не вижу проблем. N попыток в надежде получить текущий релиз