Посмотрим типичные примеры, озаглавленные общей идеей «Играл с облаками и проиграл»

1️⃣ Overprovisioning

Вы решили прикинуть размер виртуальных машин для нового сервиса и выбрали X4 на основе ожидаемой нагрузки. Но по факту оказалось, что сервис потребляет от силы 10% выделенных ресурсов, а в графики потребления ресурсов мало кто заглядывает, пока все идет хорошо. Вы только что переплатили облаку в 5 раз, но узнаете про это немного позже.

2️⃣ Стоимость трафика

Поставили тестовый сервис, который через NAT Gateway ходит в S3. Да, в проде. А что, работает же. Потом пришли счета за трафик — просто космос. А всего-то нужно было использовать S3 VPC Gateway Endpoint, и было бы счастье. Но опять же, никто это не мониторил и не задумывался об оптимизации.

3️⃣ Автоскейлинг (нет)

Вы ведь не тестируете в проде, правда? Для таких случаев у вас наверняка есть dev инфраструктура. Надеюсь, полностью в отдельном аккаунте облака, чтобы случайно не сломать прод. Но вот нюанс: dev простаивает ночами. Его можно было бы тушить с 18:00 до 9:00, а заодно отключить лишние реплики, бэкапы, CDN и прочее, что в проде критично, а тут — нет. Но вы об этом могли забыть, и облако снова забирает себе деньги, чтобы подогревать воздух в датацентрах.

4️⃣ Платим за мусор

Представьте, в коде настройки одного ресурса terraform пропущена важная опция. Но это вы уже потом узнаете, когда начнете счета анализировать.
Конкретно речь про incomplete multi-part uploads S3 (почитать подробнее — тут).

S3 bucket конечно же создан новый, под новый сервис. Плановая стоимость его использования рассчитана очень приблизительно, поэтому еще предстоит узнать его реальную стоимость.

Проходит месяц, второй — а мусор в S3 bucket копится, потому что часть загрузок по разным причинам не завершаются успешно. Вы этого не замечаете, ведь инфра огромная. Новый S3 bucket капля в этом океане. И только может быть через полгода-год, при анализе затрат в рамках отдельных команд кто-то заметит, что на этот мусор ушел солидный кусок бюджета команды.

5️⃣ Но как же мониторинг и алерты?

Спросят дотошные читатели. А вот так. Большие инфраструктуры — это сложно: сегодня ты настраиваешь Kubernetes, завтра разбираешься с S3, послезавтра — с репликацией базы данных. Команда, которая управляет бюджетами, вообще может сидеть в другой стране. Пока вы укладываетесь в их планы, никто не проверяет, на что именно идут деньги.

6️⃣ FinOps — спаситель или костыль?

В современном мире появилась даже специальная должность — FinOps. Но если у вас нет отдельного человека, то будьте добры: садитесь и разберитесь, как оптимизировать свои расходы самостоятельно. И помимо стандартного мониторинга подумайте и настройте еще и мониторинг костов.

➡️ Почему это важно?

Системы становятся сложнее, количество слоев абстракции растет. Даже с кучей инструментов, которые должны бить вас по рукам за глупые ошибки в конфигурации, вы не сможете предусмотреть все. И линтеры не спасут, если их не подключить, не настроить и не объяснить всем, почему их предупреждения — это не просто запись в логе пайплайна. А если ваш пайплайн не падает, а только ругается в логах, то будьте уверены, что никто и не подумает это исправлять.

➡️ Мораль
Никогда не рассчитывайте, что облако всё сделает за вас. Настройки по умолчанию — это компромисс, который подходит на старте. Что применяет компания X, может частично или полностью не работать для компании Y. Хотите надежную, оптимальную и недорогую инфраструктуру? Изучите возможности и ограничения каждого сервиса, который используете. И не поленитесь почитать документацию сервиса перед выполнением terraform apply).

И да, прежде чем запускать что-то новое, проверьте дважды. А лучше — трижды. Помните, что облако с удовольствием монетизирует ваши ошибки. Но в этой игре можно и выигрывать, если не идти по самому простому пути.

Остались вопросы? Напоминаю, что о наболевшем можно спросить в комментариях к этому посту — на лайве разберем 🔥

Кстати, кое-что осталось за кадром!

Например, зачем нам вообще нужны capabilities? И что происходит, когда на этапе сборки proxy-init вызывается вот это:

setcap cap_net_raw,cap_net_admin=+eip /$APP_NAME

Если коротко: эти capabilities открывают приложению в контейнере возможность использовать "сырые" сокеты и доступ к управлению iptables.

👉 Про CAP_NET_RAW и CAP_NET_ADMIN можно почитать тут.
Но если вы, как и я, предпочитаете более практические описания — смотрите здесь.

А теперь вопрос на засыпку: почему команда ping работает без прав root?

А потому что на её бинарнике стоит CAP_NET_RAW. И тут в игру вступают «сырые» сокеты.

👉 Подробнее про них — по ссылке.

Лайв-стрим сегодня вечером 🔥

Обсудим:

🔸как строить отказоустойчивые системы;
🔸как правильно готовить kubernetes в дикой природе, для больших и для маленьких систем;
🔸как правильно гладить котиков;
🔸как выстраивать процессы observability;

и всё-всё-всё, что вы придумаете и принесёте на лайв в качестве своих вопросов.

Приносите свои боли с инфраструктурой, будем прикладывать подорожник ☘️

➡️ Начало сегодня в 18:30. Включайте уведомления и подключайтесь!

Helm в Kubernetes: открытый вебинар

👉 Когда: 29 января в 19:00 мск

Приглашаю всех, кто хочет потрогать руками продвинутую шаблонизацию манифестов и разобраться, как это работает:

🔸 Рассмотрим создание ресурсов в Kubernetes с помощью YAML-файлов
🔸 Обсудим шаблонизаторы ресурсов: Kustomize, Helm, CUE и Jsonnet
🔸 Разберемся с терминологией Helm и основными командами
🔸 Изучим внутреннее устройство одного helm-чарта
🔸 Научимся искать и работать с готовыми helm-чартами с Artifact HUB

Ведущие: я и Маркус (куда без него?)

Приглашенный эксперт: Руслан Гайнанов, Тимлид DevOps-команды проекта «Осмакс» в ИТ-Холдинге Т1

Занять место на вебинаре — через бота ⬅️

Фото Маркуса для привлечения внимания и поднятия настроения 👇

Привет! На связи Маркус.

Я здесь, чтобы показать вам свои новые книжки и поделиться записью вебинара по Observability. Как видите, книжки я уже показал 😼

Вебинар мы с моим человеком провели 16 января (да, я там был, просто не афишировался) и обсудили на нем:

▶️Выявление аномалий в работе кластера
▶️Мониторинг сетевой активности и предотвращение сбоев
▶️Обеспечение соответствия политик безопасности
▶️Снижение времени простоя за счет быстрого устранения инцидентов
▶️Упрощение эксплуатации сложных систем с минимальными затратами

Посмотреть можно тут:

📺  YouTube
📺  VK Video

А в этом посте предлагаю выбрать тему для следующего вебинара:

1️⃣ Что нового появилось в k8s за последние пару лет
2️⃣ Использование и настройка service mesh
3️⃣ Инструменты вокруг k8s, которые позволяют добавлять конкретные функции в кластер: для CI/CD, для мониторинга, для дебага, для анализа трафика и так далее.

Напишите в комментариях, какая из тем вам интересна (третью можно и нужно сократить до конкретной группы проблем) или напишите свой вариант 😻

Kubernetes Мега: старт уже сегодня!

Ну что, котятки, углубимся в практику работы с k8s? 😸

Сегодня стартует первый в этом году поток курса «Kubernetes Мега». В течение следующих семи недель мы будем учиться:

👉 сопровождать и деплоить приложения в k8s
👉 переносить продукт на платформу kubernetes
👉 внедрять service mesh, настраивать внешний доступ, применять сертификаты
👉 использовать возможности k8s при проектировании платформенных решений
👉 повышать осознанность при внедрении решений

и много чего еще (полная программа есть на странице курса).

Курс мы обновили совсем недавно: актуализировали версию kubernetes и сертификацию, добавили новые практические задания и теоретические материалы — можно смело применять в самых современных проектах 😎

❗️Вкатиться в текущий поток можно еще неделю, пока идут установочные встречи и знакомство с курсом. Так что если не успели или пропустили — велкам, всех жду!

Занять место — по ссылке ⬅️

Helm в Kubernetes: вебинар уже завтра

Встречаемся в 19:00, будем обсуждать, как устроен Helm, зачем он нужен, и обязательно посмотрим, насколько глубока helmова падь.

Если вы поняли, отсылку к каким двум замечательным произведениям я спрятал в этой фразе, обязательно ставьте 🔥 и напишите комментарии, посмотрим, сколько нас!

Также в комментариях можно написать вопросы, которые вы хотели бы разобрать на вебинаре (или задать их прямо завтра в чате трансляции) — постараюсь на все ответить.

Занять место — через бота ⬅️

Привет! На связи Маркус.

Собрал вещи и упаковался сам, потому что до путешествия в helmову падь остался всего час.

Кто с нами? Занимайте места через бота ⬅️

⭐️ Мы начинаем ⭐️

Ссылки уже в боте.

Запись вебинара по Helm

Всем привет! Кто вчера не смог попасть на веб про продвинутую шаблонизацию манифестов?

Для тех, кто все пропустил, напомню: вчера мы с Русланом Гайнановым посмотрели на практике, как работать с Helm. Никакого rocket science)

В конце вебинара обсудили практики деплоя через Helm, пробежались по другим инструментам, и когда они нужны (argocd), и поделились советами, как делать, а как не делать.

Запись можно найти тут:

📺 YouTube
📺 VK Видео

Дайджест материалов за январь

Ну что, котятки, первый месяц года позади. Решил собрать в одном посте ссылки на все материалы, которые выкладывал в январе — в дальнейшем планирую делать такие дайджесты в конце каждого месяца.

1️⃣Как работают requests/limits изнутри

2️⃣ Что такое Design Patterns
→ Используем Sidecar Pattern во благо. Часть 1
→ Используем Sidecar Pattern во благо. Часть 2

3️⃣ Вебинар «Observability и k8s: полный контроль над инфраструктурой и сервисами»
→ YouTube
→ VK Видео
→ Ссылки на документацию

4️⃣ «Играл с облаками и проиграл»: про деньги, которые вы сливаете в облако

5️⃣ Что лежит в основе работы service mesh, и как нам в этом поможет Linux?

6️⃣ Вебинар «Helm в Kubernetes: продвинутая шаблонизация манифестов»
→ YouTube
→ VK Видео

В комментариях под этим постом можно написать темы, которые вы хотели бы обсудить в следующем месяце.

Ну или скинуть фотку котика — это тоже приветствуется 😺