https://www.elastic.co/guide/en/elasticsearch/client/curator/current/ilm.html

да

научить свое приложение смотреть в HTTP заголовки. в них nginx передает адрес с которого запрос пришел

Расскажите в каком месте elasticsearch настраивается на сколько и как долго будут пухнуть индексы?

Срок жизни индексов - 1 день, после чего удаление. Объём - до 5-10Gb/Day. Настраиваем в приватном кластере на собственном железе. Планируется привязать контейнеры ES к отдельной хранилке через NFSv4 по разным аплинкам

не могу

приложение не мое

и оно работает не по текстовому протоколу

тогда никак

Срок жизни индексов - 1 день, после чего удаление. Объём - до 5-10Gb/Day. Настраиваем в приватном кластере на собственном железе. Планируется привязать контейнеры ES к отдельной хранилке через NFSv4 по разным аплинкам

предполагаю что вам остается использовать это https://www.elastic.co/guide/en/elasticsearch/client/curator/current/ex_delete_indices.html или писать свой скрипт

предполагаю что вам остается использовать это https://www.elastic.co/guide/en/elasticsearch/client/curator/current/ex_delete_indices.html или писать свой скрипт

Так вопрос изначальный был не про удаление индексов(это я и так делаю своими скриптами), а про управление elasticsearch'ами через какой-либо operator

а сорри я не тому ответил )

https://www.elastic.co/guide/en/elasticsearch/reference/current/index-lifecycle-management.html

ES на NFSv4 хммм, виноват всё же куб наверное

А это, разве, не про то, что мне нужно?

есть свое бинарное приложение которое работает по сети и оно получает кривые айпишники из-за прокси

Ведь непонятно каким образом оно берет информацию о ip

ES на NFSv4 хммм, виноват всё же куб наверное

???

Ведь непонятно каким образом оно берет информацию о ip

Ну по сокету

И все

Ну по сокету

ну видимо тогда тут не ингрес нужен

А как?

А это, разве, не про то, что мне нужно?

думаю да, я смотерл у версии oss

думаю да, я смотерл у версии oss

А-а, мне для oss.

А как?

не знаю как в целом устроено, сколько репликаций и т.д. Но возможно проброс порта и round robind dns. Сложно сказать без подробностей

Но это уже не в кластере запускать надо

Да?

Но это уже не в кластере запускать надо

Ну почему. Я делал подобную схему в кластере. Настраивал kafka из трех экземпляров без ингрес. Но тут конечно есть свои нюансы

а в какую сторону копать ?

Ну почему. Я делал подобную схему в кластере. Настраивал kafka из трех экземпляров без ингрес. Но тут конечно есть свои нюансы

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

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

Что-то вроде того, что в конторе использовались сертики только от letsencrypt, своих не было. На кафку самоподписные. И как-то я не смог это сопоставить. Может конечно я просто не сумел это приготовить. Сделал так

Я думаю, что минус - как в анекдоте про нюанс

И работает кмк непредсказуемо при падениях

Можно к нодам приколотить, но тогда зачем куб

Можно к нодам приколотить, но тогда зачем куб

Да. Тут вот такой нюанс собственно)

Можно к нодам приколотить, но тогда зачем куб

Наверное затем, что Нода - это определение из кубера, без кубера нет нод

Можно и так на каких-то инстансах в докере поднять и снять ненужный в этом случае слой абстракции

А если у тебя воркеры ещё и динамически создаются - убиваются, то ещё и от геморроя избавишься

Я про то и говорю, что надо смотреть по ситуации. Это лишь был пример, который в 95% случаев не подойдёт, но мало ли

подскажите есть секрет apiVersion: v1 kind: Secret metadata: name: services-secrets type: Opaque data: sendgrid_token: somesecret и есть деплоймент где он используется в env env: - name: SENDGRID_TOKEN valueFrom: secretKeyRef: name: services-secrets key: sendgrid_token но пишет secrets "services-secrets" not found: CreateContainerConfigError в GKE

они в одном namespace ? что-то с отсутпами в деплойменте какая то фигня творится

они в одном namespace ? что-то с отсутпами в деплойменте какая то фигня творится

Отступы могут быть ошибкой, но тогда бы он писал ошибку парсинга, а так да, похоже на namespace

они в одном namespace ? что-то с отсутпами в деплойменте какая то фигня творится

блин, спасибо не заметил что в bash скрипте создается в цикле по неймспейсам без указания неймспейса

Такой вопросик

https://netty.io/4.1/api/io/netty/handler/codec/haproxy/HAProxyMessage.html HAPROXY передает на 4 уровне доп инфу какую-то о реальном айпишинке

если я ingress сделаю через kubernetes на haproxy Это будет работать?

как вообще это в ингресе можно заюзать?

по-любому есть что-то такое на nginx'e

https://netty.io/4.1/api/io/netty/handler/codec/haproxy/HAProxyMessage.html HAPROXY передает на 4 уровне доп инфу какую-то о реальном айпишинке

Приложение должно понимать PROXY-протокол для этого

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

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

https://kubernetes.github.io/ingress-nginx/user-guide/exposing-tcp-udp-services/

Спасибо большое

подскажите, в случае +80 микросервисов ~32гига оперативы сумарно, хелм чарты лучше для каждого сервиса отдельно делать, или объеденить общим?

подскажите, в случае +80 микросервисов ~32гига оперативы сумарно, хелм чарты лучше для каждого сервиса отдельно делать, или объеденить общим?

Разделяй по логике. Тебе вряд-ли необходимо за один раз 80 кусков обновлять нужно

подскажите, в случае +80 микросервисов ~32гига оперативы сумарно, хелм чарты лучше для каждого сервиса отдельно делать, или объеденить общим?

Ответ на твой вопрос не от количества сервисов, а от того, как их разрабатывают и выкладывают. Если все "правильно" и слабосвязано - то на каждый сервис всё своё делать. А если "микросервисный монолит"... :)

Разделяй по логике. Тебе вряд-ли необходимо за один раз 80 кусков обновлять нужно

спасибо

Ответ на твой вопрос не от количества сервисов, а от того, как их разрабатывают и выкладывают. Если все "правильно" и слабосвязано - то на каждый сервис всё своё делать. А если "микросервисный монолит"... :)

спасибо!

Я правильно понимаю что сервера с разных датацентров лучше не объеденять в кластер. А лучше создать по мастеру в разных ДЦ и объеденить их в федерацию по необходимости?

Я правильно понимаю что сервера с разных датацентров лучше не объеденять в кластер. А лучше создать по мастеру в разных ДЦ и объеденить их в федерацию по необходимости?

Егор, в каждом ДЦ у тебя обязательно должен быть хотя бы один мастер.

Я правильно понимаю что сервера с разных датацентров лучше не объеденять в кластер. А лучше создать по мастеру в разных ДЦ и объеденить их в федерацию по необходимости?

Зависит от расстояния (пинга) между ДЦ и наличия прямого канала связи между ними

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

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

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

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

А БД между ними может шустро перемещаться?

Ну это от твоей бд зависит

Во втором дц может быть реплика чтения

И если первый упал, то она мастером становится

И если первый упал, то она мастером становится

А если не упал, а датацентры перестали видеть друг друга?

Тоже все будет работать

Тоже все будет работать

А что будет с БД?

А что будет с БД?

Зависит от БД

Stolon хранит состояние в etcd например

Stolon хранит состояние в etcd например

А есть те кто на нём развернули БД поверх кластеров в разных ДЦ?

А есть те кто на нём развернули БД поверх кластеров в разных ДЦ?

Гугл, у них в каждом дц атомные часы

Гугл, у них в каждом дц атомные часы

То есть в GKE можно развернуть федерацию кластеров и декларативно указать что нужно захватить мир?

То есть в GKE можно развернуть федерацию кластеров и декларативно указать что нужно захватить мир?

Не знаю как в Гугле, но в Amazone их EKS разворачивается в 3 AZ.

Нюанс конечно в отставании версии - сейчас только 1.13

ребят подскажите кто уже решал когда надо чтобы в кластере был LB ipv6 и ipv4

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

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

отработать заранее процедуру disaster recovery

всем привет. подскажите как часто серт бот выпускает серты? спрашиваю потому что есть серт выпущенный и мне пришло письмо от ЛЕ и там сказано что осталось вот 19 дней.

всем привет. подскажите как часто серт бот выпускает серты? спрашиваю потому что есть серт выпущенный и мне пришло письмо от ЛЕ и там сказано что осталось вот 19 дней.

Let’s Encrypt CA issues short-lived certificates (90 days). Make sure you renew the certificates at least once in 3 months.

про 90 дней я знаю

обычно сертбот выпускает серты за 30 дней до истечения