а если б было , что б я тогда делал?

так же руками бы удалил под стейтфулсета

и ждал бы пока оно поднимется на другом узле

а данные бы не потерял?

pv бы примонтировалось к новому узлу

storage class standard в гуглоклауде - это обычные тома из GCE

а данные бы не потерял?

почитай как statefulset работает

Да спасибо, я осознаю что у меня провалы есть да.

ипочему при удалении всего стейтфулсета pvc,которые были им созданы не удаляются

коллеги) повторю вопрос) как кто подходит к организации резервного кластера и поддержке его в актуальном состоянии/процедурах переключения? условно все приложения стэтлесс, хранилища внешние, но многа крон-задач которые работают с БД или никто об этом не задумывается и на все божья воля?)

коллеги) повторю вопрос) как кто подходит к организации резервного кластера и поддержке его в актуальном состоянии/процедурах переключения? условно все приложения стэтлесс, хранилища внешние, но многа крон-задач которые работают с БД или никто об этом не задумывается и на все божья воля?)

Деплоим паралельно, крон задач нет

коллеги) повторю вопрос) как кто подходит к организации резервного кластера и поддержке его в актуальном состоянии/процедурах переключения? условно все приложения стэтлесс, хранилища внешние, но многа крон-задач которые работают с БД или никто об этом не задумывается и на все божья воля?)

А зачем вам резервный кластер? Что резервируете? Если у вас всё состояние отказоустойчиво, то почему вы также не задеплоите etcd?

задам этот вопрос еще раз, юзает кто velero(ark) для бэкапирования кубера? интересует вопрос, читаю и не могу понять до конца, он умеет делать бэкап конкретного вольюма в заданом неймспейсе? в планах хотелось бы делать полный бэкап неймспейса и дополнительно отдельно вольюмы, с целью что если вдруг чет произойдет с данными, не восстанавливать весь неймспейс, а только нужные данные вольюма..

Всем привет , столкнулся со следующей проблемой: ipшник core-dns сервиса не резолвится внутри контейнеров, при этом эндпоинты, на которые он сыылаются, резолвятся частично (если под находится на одной ноде с подом core-dns, то его эндпоинт резолвится) никто не сталкивался с такой проблемой? В чем трабла может быть?

а давайте табличку https://docs.google.com/spreadsheets/d/1LxSqBzjOxfGx3cmtZ4EbB_BGCxT_wlxW_xgHVVa23es/edit#gid=0 в FAQ добавим?

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

Всем привет , столкнулся со следующей проблемой: ipшник core-dns сервиса не резолвится внутри контейнеров, при этом эндпоинты, на которые он сыылаются, резолвятся частично (если под находится на одной ноде с подом core-dns, то его эндпоинт резолвится) никто не сталкивался с такой проблемой? В чем трабла может быть?

Чёт мне кажется, что все поды на разных нодах не могут ходить друг к другу. Например, cni требует l2-связность между нодами, а её нет.

Чёт мне кажется, что все поды на разных нодах не могут ходить друг к другу. Например, cni требует l2-связность между нодами, а её нет.

днс работает, если в резолв.конф поставить ипшник пода core-dns находящегося на той же ноде что и под, не работает, фактически, кластер IP, который выдан сервису, который балансит поды core-dns. обчный пинг до кластер ИП с пода нет, с ноды - есть. да мне не нужно чтобы между нодами трафик ходил у меня обычный раундробин не отрабатывает, если бы он отработал, под бы нашёл днс сервер у себя на ноде

sum(kube_deployment_status_replicas_unavailable{deployment=~"web-deployment"}) как показать namespace?

by (namespace)?

by (namespace)?

как правильно вставить (by (namespace) sum(kube_deployment_status_replicas_unavailable{deployment=~"web-deployment"})) не верно

sum by (namespace) (kube_deployment_status_replicas_unavailable{deployment=~"web-deployment"})

sum by (namespace) (kube_deployment_status_replicas_unavailable{deployment=~"web-deployment"})

пасиб

а кто-нибудь держит pgsql в k8s? если да, то какими средствами?

мне под HA)

kubedb/patroni-operator. Но у патрони производительность ниже. Они там кучу всего напихали в контейнер.

kubedb/patroni-operator. Но у патрони производительность ниже. Они там кучу всего напихали в контейнер.

мб postgres-operator (zalando)?

Ну да, там просто все равно внутри патрони

угу, так а что лучше kubedb или operator ?

Нам больше kubedb зашел, и по скорости работы и по удобству. Хотя второе достаточно субъективно.

А зачем вам резервный кластер? Что резервируете? Если у вас всё состояние отказоустойчиво, то почему вы также не задеплоите etcd?

кластер на баре метале когда один раз переживешь пожар в ДЦ начинаешь беспокоится)

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

а кто делает кубедб ещё надо проверять

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

kubedb/patroni-operator. Но у патрони производительность ниже. Они там кучу всего напихали в контейнер.

а что именно они напихали и куда?

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

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

Это где такое? Я так понял, если надо что-то еще, собирай свой спило

в смысле "где"?

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

у оператора опция

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

$ curl -fsSL https://raw.githubusercontent.com/kubedb/cli/0.11.0/hack/deploy/kubedb.sh | bashчота уже не хочется даже пробовать

too hipsta

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

в смысле "форка их репы"?

зачем форк, если надо лишь собрать кастомный образ

А да, чет я загнул.

короче я не-универсальной поделке заландо просто интуитивно больше доверяю, чем "универсальной" поделке нонеймов

но переубеждать тебя не буду, мне лень

Так это, а столон не пробовали в k8s?

это тоже zalando поделка вроде, не?

Нет

Ребзя, подскажите, как синтасически в halm будет правильно? updateStrategy: {} # rollingUpdate: # maxUnavailable: 1 # type: RollingUpdate

Кстати, интересно, именно в проде stolon + pgsql в кубере кто-то юзает?

Нет

хотя нет, слово не грузинское)

updateStrategy: {} - подразумевается json?

updateStrategy: {} - подразумевается json?

JSON - подмножество Yaml

updateStrategy: {} - подразумевается json?

подразумевается то что там закомменчено

updateStrategy: {rollingUpdate: {maxUnavailable: 1},{type: RollingUpdate} }

какой синтаксис правильный чтобы раскоментить?

какой синтаксис правильный чтобы раскоментить?

у меня cmd+/ в атоме ;)

Жсон умеешь?

Он подмножество и он правильный будет

да просто сотри #

Неужели ямль это так сложно?

{ "rollingUpdate": { "maxUnavailable": 1 }, "type": "RollingUpdate" }

{ "rollingUpdate": { "maxUnavailable": 1 }, "type": "RollingUpdate" }

это то же самое что и ``` updateStrategy: rollingUpdate: maxUnavailable: 1 type: RollingUpdate ``` я просто не понял зачем тебе именно json..

потому что это helm чарт и в темплейте ожидается json

это то же самое что и ``` updateStrategy: rollingUpdate: maxUnavailable: 1 type: RollingUpdate ``` я просто не понял зачем тебе именно json..

Затем что ямль это сложно, видимо

потому что это helm чарт и в темплейте ожидается json

Нет, там ожидается ямль

Жсон - подмножество ямля и тоже будет работать

{{ toYaml .Values.controller.updateStrategy | indent 4 }}

toYaml yне значит ли что он попытается преобразовать?

или увидел yaml он не будет его преобразовывать?

Хер его знает, это же хельм

он с объектами работает а не с нотацией он сначала грузит файл values в объекты а потом там где ты пишешь toYaml он их дампит в yaml формат

Ребят, привет. А есть ли универсальный способ получить логи деплоя в случае неудачи? Чтобы покрывать проблемы создания контейнера, например ошибки при pull image, случаи когда readiness проба не прошла и все остальное.

Ребят, привет. А есть ли универсальный способ получить логи деплоя в случае неудачи? Чтобы покрывать проблемы создания контейнера, например ошибки при pull image, случаи когда readiness проба не прошла и все остальное.

kubectl get events?

kubectl get events?

А его можно фильтровать по pod_name/deployment и тп? Просто если там параллельно деплоится несколько деплойментов, то будет каша у всех

Котаны, если у меня под ingress controller в ns dev, а сам ingress в ns qa, то работать такая схема не будет? только если и контролер и ингресс в одном нейм спецсе?