Size: a a a

RU.Docker — Официальное Русское Сообщество

2019 January 17

S

Sergii (Kyiv) in RU.Docker — Официальное Русское Сообщество
Ок спасибо думал узнаю что то новое
источник

AB

Aleksandr Bukhalo in RU.Docker — Официальное Русское Сообщество
Всмысле?
источник

AB

Aleksandr Bukhalo in RU.Docker — Официальное Русское Сообщество
На сайте дока по установке лежит
источник

AB

Aleksandr Bukhalo in RU.Docker — Официальное Русское Сообщество
источник

IM

Iurii Medvedev in RU.Docker — Официальное Русское Сообщество
источник

IM

Iurii Medvedev in RU.Docker — Официальное Русское Сообщество
😂
источник

IM

Iurii Medvedev in RU.Docker — Официальное Русское Сообщество
Блин не успел
источник

N

Navern in RU.Docker — Официальное Русское Сообщество
Sergii (Kyiv)
Ок спасибо думал узнаю что то новое
А что новое то?
источник

N

Navern in RU.Docker — Официальное Русское Сообщество
я не оч понял что ты хочешь узнать
источник

MR

Maks Rafalko in RU.Docker — Официальное Русское Сообщество
Привет. Может быть кто подскажет по Kubernetes вариант решения следующей задачи: есть бесконечно пополняемая очередь (work queue в терминологии k8s), например RabbitMQ. Необходимо сделать параллельные консьюмеры, которые бы обрабатывали эту очередь постоянно (не одноразовые джобы).

Ньюанс в том, что для предотвращения утечки памяти, консьюмеры принято (например в  PHP) перезапускать через некоторе время или некоторое количество обработанных сообщений.

Вопрос, как это ложится на Job абстракцию k8s? Там есть только restart: OnFailure | Never, а перезапуск имеет Success код (т.е. k8s не перезапустит такой Job)

или может впринципе тут подход с Job неверный? И надо использовать нечто другое
источник

AA

Alexandr Alexandr in RU.Docker — Официальное Русское Сообщество
можно просто не использовать php
источник

MR

Maks Rafalko in RU.Docker — Официальное Русское Сообщество
PHP тут как пример, это может быть любой другой ЯП
источник

AA

Alexandr Alexandr in RU.Docker — Официальное Русское Сообщество
просто я не сталкивался с проблемой утечки памяти используя консьюмеры, они правда написаны на js
источник

MR

Maks Rafalko in RU.Docker — Официальное Русское Сообщество
вам повезло :)

продолжаю изучение вопроса - судя по всему вместо Job надо использовать https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/ - ReplicationController, который даже в случае успешного завершения контейнера будет его перезапускать, держа постоянно N реплик
источник

DZ

Dmitriy Z in RU.Docker — Официальное Русское Сообщество
deployment с обработчиками и не периться
источник

DZ

Dmitriy Z in RU.Docker — Официальное Русское Сообщество
сдохнет - куб его переподымет
источник

DZ

Dmitriy Z in RU.Docker — Официальное Русское Сообщество
Maks Rafalko
вам повезло :)

продолжаю изучение вопроса - судя по всему вместо Job надо использовать https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/ - ReplicationController, который даже в случае успешного завершения контейнера будет его перезапускать, держа постоянно N реплик
RC в сыром виде лучше не использовать, лучше пусть с ним deployment работает
источник

MR

Maks Rafalko in RU.Docker — Официальное Русское Сообщество
спасибо за совет
источник

MR

Maks Rafalko in RU.Docker — Официальное Русское Сообщество
а почему в сыром виде не стоит? если есть где почитать об этом - ткните ссылкой пожалуйста
источник

DZ

Dmitriy Z in RU.Docker — Официальное Русское Сообщество
Maks Rafalko
спасибо за совет
deployment управляет rc (на этом так же реализован механизм обновлений/откатов), а rc управляет уже pod`ами
источник