Gunslinger

Ребят, а как через kubectl узнать что поды деплоймента не поднялись после деплоя? Т.е. например если несуществует или не получилось спулить image. В kubernetes-dashboard я вижу ошибку Failed to pull image .... А как узнать об этом через kubectl? Основная цель, автооткат на CI, если при деплое случилась ошибка или не прошла readiness проба

kubectl get pods. статус же пишет у пода

Константин

1. Вендорлок, 2. Редхат

это да, согласен)

Oleg

Всем привет. может кто нибудь пояснить за pod dns. есть headless service и pods. Создаются в ns: app https://pastebin.com/aEyr73SP Но поды не резолвятся вообще никак: ни proc-1.app.pod.cluster.local, ни proc-1.proc-headless.app.pod.cluster.local

Mikhail

Ребят, а как через kubectl узнать что поды деплоймента не поднялись после деплоя? Т.е. например если несуществует или не получилось спулить image. В kubernetes-dashboard я вижу ошибку Failed to pull image .... А как узнать об этом через kubectl? Основная цель, автооткат на CI, если при деплое случилась ошибка или не прошла readiness проба

Нужно правильно настроить ливнес и рединес пробы, они отвечают за перевод трафика но новые поды

Gunslinger

Ребят, а как через kubectl узнать что поды деплоймента не поднялись после деплоя? Т.е. например если несуществует или не получилось спулить image. В kubernetes-dashboard я вижу ошибку Failed to pull image .... А как узнать об этом через kubectl? Основная цель, автооткат на CI, если при деплое случилась ошибка или не прошла readiness проба

будет тот же статус ImagePullBackOff в строчке пода

Andrey

Нужно правильно настроить ливнес и рединес пробы, они отвечают за перевод трафика но новые поды

это да, знаю, спасибо

Mikhail

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

Artem

Всем привет. может кто нибудь пояснить за pod dns. есть headless service и pods. Создаются в ns: app https://pastebin.com/aEyr73SP Но поды не резолвятся вообще никак: ни proc-1.app.pod.cluster.local, ни proc-1.proc-headless.app.pod.cluster.local

Для таких штук, как раз сделан statefulset

Mikhail

он дожидается определенных кондиций, если деплой не прошел, то падает с ошибкой

Andrey

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

ну я как раз сооружаю нечто вроде него. У меня версия 1.10.4, там wait еще нету. Мне по сути нужна какая-то команда которая мне скажет что с выкатом деплоймента все ок или не ок. Включая пробы

Oleg

Для таких штук, как раз сделан statefulset

🤔 не знал. он автоматом задает днс fqdn ?

Aleksei

он дожидается определенных кондиций, если деплой не прошел, то падает с ошибкой

вообще лучше сделать грамотные readliness probe что бы не получить в одночасье неработающий продукт

Mikhail

ну я как раз сооружаю нечто вроде него. У меня версия 1.10.4, там wait еще нету. Мне по сути нужна какая-то команда которая мне скажет что с выкатом деплоймента все ок или не ок. Включая пробы

ПРосто обнови kubctl клиент до 11 версии

Mikhail

эта фича у клиента появилась

Anton

https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#deployment-status

Andrey

https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#deployment-status

То что нужно!! Спасибо!

Artem

ну я как раз сооружаю нечто вроде него. У меня версия 1.10.4, там wait еще нету. Мне по сути нужна какая-то команда которая мне скажет что с выкатом деплоймента все ок или не ок. Включая пробы

Если хотите пробы, то лучше через метрики, прометеус, вот это вот всё

Anton

ну я как раз сооружаю нечто вроде него. У меня версия 1.10.4, там wait еще нету. Мне по сути нужна какая-то команда которая мне скажет что с выкатом деплоймента все ок или не ок. Включая пробы

пользуюсь helm blabla --wait он блокируется до момента, пока не появится минимальный набор подов. если что не так - по таймауту выпадает.

Andrey

Если хотите пробы, то лучше через метрики, прометеус, вот это вот всё

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

Andrey

пользуюсь helm blabla --wait он блокируется до момента, пока не появится минимальный набор подов. если что не так - по таймауту выпадает.

а readiness пробы ждет?

Anton

да, ждет когда все готово хотя бы в одном поде

Andrey

$ kubectl rollout status deployment/test-deployment error: deployment "test-deployment" exceeded its progress deadline А кто в курсе, в этот "progress deadline" входит readiness проба?

Anton

кнчно

Andor

засекаем время до спама

Andrey

кнчно

Блин, оно кароч работает немного иначе. Оно просто ждет некий таймаут. Если после него деплоймент не пришел в себя, то говорит что все плохо. Т.е. если readiness проба имеет таймаут 10 сек, а .spec.progressDeadlineSeconds = 1, то даже если под удачно пройдет все пробы и задеплоится, но не успеет на 1 секунду, то будет завален =\

Vadim

так он вроде платный

он не платный, конечно же

blkmrkt

кто использовал GPU в кластере от Гугла? В инструкции написано что нужно запрашивать ресурсы вот так: resources: limits: nvidia.com/gpu: 2 Но куб ругается что контейнеры становятся нескалируемыми с ошибками о невозможности предоставить достаточно ресурсов com.gpu, nvidia (sic), cpu.

blkmrkt

если под уже крутится на gpu-enabled пуле, то гпу должны быть уже доступны, да? Просто из докера нужно динамически подгрузить либы?

G72K

Ребят, а как через kubectl узнать что поды деплоймента не поднялись после деплоя? Т.е. например если несуществует или не получилось спулить image. В kubernetes-dashboard я вижу ошибку Failed to pull image .... А как узнать об этом через kubectl? Основная цель, автооткат на CI, если при деплое случилась ошибка или не прошла readiness проба

В доке по Deployment описано, ищите по слову Progress

Konstantin

столкнулся с таким поведением: kubectl rollout status отдал статус ОК AVAILABLE 1, хотя под в итоге не поднялся из-за ошибки внутри контейнера и реальный статус AVAILABLE 0 я так понимаю, без livenessProbe\readinessProbe полагаться на rollout status не стоит или где-то в другом месте проблема?

Anton

обязательно нужны probes, иначе как?

Anton

ведь на них куча всего завязано

Anton

ready говорит что трафик может идти к поду live - что процесс в поде вообще жив

Anton

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

Anton

вроде как если ты всеравно не сможешь в mq отправить\принять сообщение или записать результат работы куда то, то и толку нет тебе трафик принимать

Rainbow

/report

Konstantin

обязательно нужны probes, иначе как?

да, это понятно) но скажем так, CI\CD процесс с автодеплоем для staging по шаблону, полное отстутствие манифестов куба. Разработчик пушит только код\Dockerfile. И тут особо пробы не воткнёшь.

Anton

да, это понятно) но скажем так, CI\CD процесс с автодеплоем для staging по шаблону, полное отстутствие манифестов куба. Разработчик пушит только код\Dockerfile. И тут особо пробы не воткнёшь.

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

Konstantin

да, но я рассматриваю худший вариант, а зачастую именно он и происходит (

Andor

да, это понятно) но скажем так, CI\CD процесс с автодеплоем для staging по шаблону, полное отстутствие манифестов куба. Разработчик пушит только код\Dockerfile. И тут особо пробы не воткнёшь.

Воткнёшь организационно

Konstantin

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

Anton

тогда похуй, кати как есть

Andor

Ну ты объясни ему проблемы

Andor

А дальше он пусть сам решает

Andor

Пусть хоть с даунтаймом деплоится

Konstantin

угу, так и есть

Konstantin

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

G72K

Господа, вы когда с несколькими кластерами живете, то cluster.local суффикс переопределяете? Хочу чтобы они могли друг с другом говорить, вот думаю переопределить, тогда и сервис с ручными endpoints развесить можно и в сертификатах все правильно пропишется. Ну это в теории , как на практике?

Anton

а как ты их по внутренним именам собираешься связывать?

G72K

да, это понятно) но скажем так, CI\CD процесс с автодеплоем для staging по шаблону, полное отстутствие манифестов куба. Разработчик пушит только код\Dockerfile. И тут особо пробы не воткнёшь.

Можно healthcheck из докерфайла выдернуть , ну а вообще сложно с одним докерфайлом жить, надо ж знать сколько ресурсов, сколько подов, крон джобы всякие, секреты, диски нужны/ненужны и проч

G72K

а как ты их по внутренним именам собираешься связывать?

В клиенском кластере сделать сервис и в него вручную endpoints прописать навроде того как родной kubernetes.default.svc.cluster.local работает

Artem

Господа, вы когда с несколькими кластерами живете, то cluster.local суффикс переопределяете? Хочу чтобы они могли друг с другом говорить, вот думаю переопределить, тогда и сервис с ручными endpoints развесить можно и в сертификатах все правильно пропишется. Ну это в теории , как на практике?

Для этого есть kubefed

Anton

В клиенском кластере сделать сервис и в него вручную endpoints прописать навроде того как родной kubernetes.default.svc.cluster.local работает

endpoints тычат в lb\ingress на другом кластере?

Anton

Для этого есть kubefed

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

Anton

Господа, вы когда с несколькими кластерами живете, то cluster.local суффикс переопределяете? Хочу чтобы они могли друг с другом говорить, вот думаю переопределить, тогда и сервис с ручными endpoints развесить можно и в сертификатах все правильно пропишется. Ну это в теории , как на практике?

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

Konstantin

Можно healthcheck из докерфайла выдернуть , ну а вообще сложно с одним докерфайлом жить, надо ж знать сколько ресурсов, сколько подов, крон джобы всякие, секреты, диски нужны/ненужны и проч

Почти всё авто или из переменных ci/cd. Да понятно это всё. Но никто вникать не будет, а нужно задеплоить вчерновую и без меня

Andor

если создавать софт для деплоя в кубер без участия разработчиков, то можно получить кучу гемора :(

ㅤ

если создавать софт для деплоя в кубер без участия разработчиков, то можно получить кучу гемора :(

Если разрабы рукожопы)

Rainbow

Лучше делать чтобы разрабы без участие админа все деплоили

Stanislav

/report

Konstantin

Лучше делать чтобы разрабы без участие админа все деплоили

Для этого они должны что-то понимать в этом. Всё всё равно не автоматизируешь

Andor

...но стремиться к этому стоит

Konstantin

если создавать софт для деплоя в кубер без участия разработчиков, то можно получить кучу гемора :(

Ну хз, работает и хорошо)

Konstantin

Взял идею у gitlab autodevops, сделал своё. А то у них прям сильно не то. Ещё и под каждую репу свой namespace😳

Vitalii

Господа, вы когда с несколькими кластерами живете, то cluster.local суффикс переопределяете? Хочу чтобы они могли друг с другом говорить, вот думаю переопределить, тогда и сервис с ручными endpoints развесить можно и в сертификатах все правильно пропишется. Ну это в теории , как на практике?

Мы не смогли придумать как dns имена сервисов автоматом раздавать по всей инфраструктуре и как сделать сетевую связность в сервисные ip. Поэтому от этой идеи пришлось отказаться. В итоге сделали metallb с LoadBalancer сервисами и вручную пишем dns имена для таких сервисов, т.к. их очень мало.

tod

кто использовал GPU в кластере от Гугла? В инструкции написано что нужно запрашивать ресурсы вот так: resources: limits: nvidia.com/gpu: 2 Но куб ругается что контейнеры становятся нескалируемыми с ошибками о невозможности предоставить достаточно ресурсов com.gpu, nvidia (sic), cpu.

Мы используем, все верно resources: requests: nvidia.com/gpu: 1 limits: nvidia.com/gpu: 1