Прекрасная ссылка!

Отличная статья в блоге Bitnami про использование SLA, SLO, SLI с Prometheus и Grafana для мониторинга Kubernetes.

http://amp.gs/vd2Y

Свежак от фланта про наш любимый stateful в kubernetes https://habr.com/company/flant/blog/428451/

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

Если так сложилось исторически, что есть cron для чего либо, и его нужно менеджить, то лучше уже костылить полностью:

http://kray.me/2018/10/cron_monitoring_in_slack/

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

Накидайте плиз в личку (@mukolaich) как ризолвить такие штуки, а вечером расшарим инфу 🙂

Моя версия:
👉 https://aws.amazon.com/lambda - если AWS
👉https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/ - если кубер
👉https://github.com/mcuadros/ofelia - если докер

Вот есть такой пост у коллег, и  хочу добавить - перестаньте использовать cron, пожалуйста! Вы можете поспорить - мол, нужно выбирать подходящие инструменты под задачи и тд и тп. Нет! Это так не работает - можно написать грамотный bash скрипт, который репортит о том что не смог отработать или слать репорты в логи и собирать потом попытки неудачного выполнения, но никто так не делает! Я постоянно вижу неработающие скрипты в cron, которые перестали выполнятся полгода назад и никто об  не знает. crond решает только одну задачу - он обязуется запустить некую задачу в определенное время. Проконтроллировать успешность выполнения? Проследить чтобы задача отвалилась по таймауту, если что-то пошло не так? Проследить, чтобы не запускалось несколько задач и не было "гонки". Посмотреть выхлоп запуска двухмесячной давности? Все эти проблемы crond не решает! Вы можете городить многоэтажные bash скрипты и пытаться угадать всевозможные сценарии того что может пойти не так, а можете просто не использовать crond. Современная система запуска задач по расписанию должна быть централизована, желательно с возможностью обеспечить отказоустойчивость, она должна уметь сообщать вам или овнеру процесса о неуспешности попытки запуска и уметь хендлить ошибки, должна иметь историю запусков, запускать задачи параллельно на многих инстансах и удобный механизм включения-выключения запуска на группе инстансов по необходимости. Круто если она при этом еще будет уметь скейлится. Более или менее "идеальный" cron описан в SRE book от google. Мы выбрали для себя Rundeck, кое где я вообще в таких случаях использовал Jenkins - они не удовлетворяют некоторым из требований выше, но даже это в разы лучше мертвых башнянок, которые годами пытаются безуспешно  запуститься. Если вы знаете еще примеры нормальной замены cron - пишите, я с удовольствием опубликую.
#dontusecron #cron #гдеавторскийконтент #hate

спасибо @HoustonHeat за новый чанпик )

Раз уж зашел разговор про cron, а еще у нас пятница, то посмотрите на эту прелесть
https://github.com/pjungwir/cron2english/

Хорошее видео для выходного дня про BPF и том, как Cilium использует эту технологию для управления сетью в Kubernetes

#kubernetes #networking #linux

Статья о том, почему за кластера Kubernetes в AWS люди часто платят больше, чем следовало бы.

Хотя, Kubernetes-specific там только первый пункт, а остальные советы применимы к инфраструктуре на AWS в принципе

#kubernetes  #aws

Понятный и простой HOWTO по makefile https://medium.freecodecamp.org/makefiles-101-how-to-use-make-as-a-task-automation-tool-69d2ccc3f25e #makefile

А кому работу + релок в Амстердам?

Дорогие коллеги, а есть ли в стане амазонщики, желающие переехать в страну велосипедов и легальной травы?

Наша контора в скором времени откроет позицию инженера-архитектора AWS.
Из buzzwords, которые надо знать: Docker, DC/OS, TeamCity, AWS.
Как сказал мой шеф - бумажки не важны, важны навыки, но наличие амазоновских сертификатов сделает вас более привлекательным для моего работодателя. 😉

Свое резюме отправляйте мне на почту: thomas.storm@protonmail.com
Вопросы сюда - @ThomasStorm

Хотелось бы выразить благодарность организаторам Highload++ 2018 - конкретно @RimmaDjan, а также @lady_noname за возможность присутствовать на конференции. Расписание в этом году дико интересное, от докладов просто разбегаются глаза - многие крутые доклады пересекаются по времени, придется разрываться чтобы выбрать. Постараюсь потекстовать по мере возможности самые интересные. Если кто-то очень хочет задать вопрос какому-то докладчику, пишите - я буду держать вас в курсе своего расписания. Не уверен что попаду везде где хотелось бы, но в поле зрения linux (будет доклад по eBPF от Петра Зайцева из percona), как всегда kubernetes, микросервисы, golang, dba.

Некоторые доклады, на которые завтра собирался

eBPF для анализа производительности Linux
Петр Зайцев (Percona)

Базы данных и Kubernetes
Дмитрий Столяров (Флант)

Настраиваем систему бэкапирования PostgreSQL
Data Egret

Эксперименты с Postgres в Docker и облаках — оптимизация настроек и схемы вашей БД без риска «уронить прод»
Николай Самохвалов (PostgreSQL.support)

Ключевые DevOps-практики
Игорь Курочкин, Андрей Александров (Экспресс 42)

Масштабирование реплик PostgreSQL под нагрузкой с точки зрения технологий резервного копирования
Андрей Бородин, Владимир Лесков (Яндекс, Яндекс)

Ещё одна статья на medium.com про service mesh на envoy https://medium.com/@dnivra26/service-mesh-with-envoy-101-e6b2131ee30b #servicemesh #envoy

Есть мнение, что кликхаус все таки тормозит )

Стандартных индексов может хватить не всем