поумнели что-то боты последнее время

@SinTeZoiD предлагаю захостить https://github.com/xvitaly/ecasbot - он на три дня запретит новоприбывшим постить линки и картинки. Если это человек, то ручками можно разбанить

оно еще умеет фильтровать китайских рекламщиков

@SinTeZoiD предлагаю захостить https://github.com/xvitaly/ecasbot - он на три дня запретит новоприбывшим постить линки и картинки. Если это человек, то ручками можно разбанить

Посоветуюсь с владельцем канала)

я ж тут так Вахтёру только да набрасываю

Народ, а кто как готовит логи с containerd?

C докером то более менее понятно, подключил драйвер и вперед. А вот с containerd не очень

файлы только парсить filebeat?

Столько людей новых сегодня

половина спамеры небось

Захваченные может аккаунты

all your kubernetes are belong to us

whosyourdaddy

iseedeadpeople

ребят, чем плох OpenShift?

Эх, на настольгию пробило )

ребят, чем плох OpenShift?

Наверное, вопрос не до конца раскрыт?

ребят, чем плох OpenShift?

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

Как будто это что-то плохое

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

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

Как будто это что-то плохое

ну хорошо, чем хорош OpenShift)

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

не знаю, никогда об этом не думал "голый" куб пока устраивает)

я просто пытаюсь понять для себя) я его кручу, вроде бы неплохо)

но может быть просто я криворукий мудак)

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

Есть много денег - OpenShift с саппортом. Нет много денег - кубер

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

Есть много денег - OpenShift с саппортом. Нет много денег - кубер

благодарю, значит потрогаю глубже

Ну это моё мнение, не более

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

describe

ребят, чем плох OpenShift?

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

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

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

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

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

Всем привет. может кто нибудь пояснить за 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

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

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

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

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

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

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

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

Всем привет. может кто нибудь пояснить за 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

кнчно

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

ERROR: S client not available

кнчно

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

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

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

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

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

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

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

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

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

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

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

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

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

/report

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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