Везде написано просто by design (ip per pod). Но нигде профиты не описаны такого подхода

Ребятушки. Есть что-то готовое для мониторинга сервисов в слаке? Я хочу получать оповещения, когда поды обновляются, запускаются и останавливаются. Я нашел wongnai/kube-slack, но он оповещает только о падениях и ошибках.

безопасность

Ты хочешь выгружать ивенты в слак?

flannel не дает network policy, calico.. думаю тут может 1% их пишут

если бизнес метрики алертить, то не будет шумом

Лично я не уверен, что это будет не бессмысленный шум

ну не все евенты. Рестарт, например, чтобы понять, что можно тестить

А чо ты делать-то с этим будешь?

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

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

Ну то есть это тоже ивент, но ты пошёл не с той стороны

./deploy curl -X POST -H 'Content-type: application/json' --data '{"text":"Deploy!!!"}' YOUR_WEBHOOK_URL

Примерно так сейчас и работает, я хочу это вынести в контур инфраструктуры

инфраструктура не знает когда деплой закончился

ну не все евенты. Рестарт, например, чтобы понять, что можно тестить

лучше напилить своё со спецификой, типа https://github.com/vrutkovs/telek8s

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

ну допилишь в CI что-то вида kubectl wait --for=condition=Ready deployment/.. && curl, так потом же попросят всё равно добавить фичей

ну допилишь в CI что-то вида kubectl wait --for=condition=Ready deployment/.. && curl, так потом же попросят всё равно добавить фичей

а как кастомные команды делаются?

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

Я не уверен, но вроде термин CNI появился позже, чем проекты flannel или weave

У flannel readme есть ответ, хоть что-то. Спасибо > The advantage of this model is that it removes the port mapping complexities that come from sharing a single host IP. "сложно рулить портами на хосте, давайте рулить ip отдельными" ну ок

кажется это вообще разный уровень

у тебя консул коннект может запретить приложению ходить куда-то?

нетворкс полиси это правила в iptables

у тебя консул коннект может запретить приложению ходить куда-то?

Да. Он не даст пойти к базе, если не даш прав

представь что приложение знает адрес базы и пытается пойти в неё напрямую мимо твоего consul connect

представь что приложение знает адрес базы и пытается пойти в неё напрямую мимо твоего consul connect

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

но ведь он не может запретить сходить приложению куда-нибудь о чём он например сам не знает?

@Andorka это просто другой подход. Зато cni не нужен с его проблемами

Как?

и ты всё ещё путаешь разные уровни, CNI и нетворк полиси немножко ниже находится, чем юзерспейс прокси

Я понимаю как это работает. Это другой подход без дикого количества правил в iptables и тп. Я ж не говорю, что это плохо. Альтернативы это хорошо

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

И кто будет выполнять network policy?

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

И кто будет выполнять network policy?

например никто

Тогда в плюс в виде «безопасность» не плюс как выше говорил @LuckySB