Помните большой пост про деньги, которые вы сливаете в облако?

В нем я разбирал типичные примеры, озаглавленные общей идеей «Играл с облаками и проиграл». Если пропустили или присоединились к каналу позже — ловите ссылку.

➡️ Классная новость для тех, кто хочет лучше разобраться в вопросе — Слёрм запускает серию бесплатных встреч, на которых будут разбирать решения в области FinOps:

🟠 неверное использование облачных ресурсов из-за непонимания их специфики;
🟠 избыточную надёжность (SRE);
🟠 оverengineering — избыточное усложнение инструментов, пайплайнов, процессов.

➡️ Первый вебинар «Облачные решения: как снизить затраты и повысить эффективность?» — уже на следующей неделе.

Программа вебинара:
➡️ Типичные ошибки при работе с облачными сервисами и их влияние на бизнес.
➡️ Настройка сетевых сервисов и контроль доступа.
➡️ Как неправильный выбор ресурсов может привести к сбоям.
➡️ Почему резервное копирование — обязательная часть стратегии.

Когда: 11 июня в 17:00 мск

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

Оптимизация запуска тяжелых образов для ML

Представьте простую задачу.

Есть k8s. Есть ML модели, где веса вшиты в образ приложения. Любая выкатка или переезд контейнера — боль и нагрузка на container registry, потому что не факт, что образ был закеширован на ноде.

Вы спросите, почему не держать веса в S3? Их оттуда при старте тоже придется скачивать, либо имплементировать способ кеширования на ноде. Тоже возможны разные решения, но пойдем более простым путем, где не нужно переписывать приложения, которые ожидают файлы весов в локальной файловой системе.

➡️ Как ускорить процесс запуска многогигабайтных образов?

Конечно, кеш!

Задействуем спящий DaemonSet. Идея простая.

🟠 Создаем DaemonSet с нужным/нужными образами (может быть много разных).
🟠 В качестве команды для этих контейнеров используем, например, sleep infinity.

В результате образы будут загружены в локальный кеш каждой ноды и будут доступны мгновенно.

При выкатке приложения:

1. Сначала катим DaemonSet
2. Ожидаем в пайплайне, пока все поды в DaemonSet поднимутся
3. Деплоим приложение

Пример решения, где вместо sleep используется pause container:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: prepuller
spec:
  selector:
    matchLabels:
      name: prepuller
  template:
    metadata:
      labels:
        name: prepuller
    spec:
      initContainers:
        - name: prepuller-1
          image: nginx # Наш образ, что подтягиваем в кеш ноды
          command: ["sh", "-c", "'true'"]

        # - name: prepuller-2
        #   image: ...
        #   command: ["sh", "-c", "'true'"]

      containers:
        - name: pause
          image: gcr.io/google_containers/pause:3.2
          resources:
            limits:
              cpu: 1m
              memory: 8Mi
            requests:
              cpu: 1m
              memory: 8Mi

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

Существуют и другие подходы к кешированию, например, такой. Но внутри он все так же создает DaemonSet 😊

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

Столько разговоров про этот ваш кубернетес, как будто это что-то вкусное. Хочу разобраться, почему вы все с ним так носитесь, поэтому решил спросить:

➡️ Какой аспект Kubernetes (сети, хранилища, безопасность, RBAC, операторы и т.д.) вы считаете самым недооцененным, но критически важным для стабильной работы?

Поделитесь в комментариях ⬇️

Разгружаем etcd

Представим ситуацию: поток записи и чтения в кластере такой, что etcd еле справляется, iops дисков ушли в потолок, расти уже некуда.

➡️ Давайте просто добавим больше нод! И тут кроется подвох. Дело в том, что etcd работает на основе алгоритма RAFT. И даже чтение данных, не говоря уже о записи, происходит через лидера. Думаю, тут я ни для кого не открыл ничего нового.

Как работает запись в etcd:

🟠 API-сервер отправляет запрос на запись одной из нод etcd.
🟠 Если повезло и запрос попал на лидера, то лидер реплицирует запись на мажоритарное количество нод (например, 2 из 3 или 3 из 5). Только после этого запись считается успешной.
🟠 Если же запрос прилетел на реплику, то он все равно перенаправляется лидеру.
🟠И только после записи на лидере и мажоритарном количестве реплик API-сервер получает подтверждение.

Теперь, зная это, давайте подумаем о масштабировании etcd.

➡️ Представьте себе кластер с 7 нодами etcd. В этом случае запись нужно реплицировать на 4 из 7 нод, что может существенно замедлить процесс (хотя все, конечно, относительно).

Оптимальным считается иметь 3-5 нод etcd. Это обеспечивает достаточную отказоустойчивость и не перегружает репликацию между нодами etcd. Однако, в таком сетапе мы все равно ограничены ресурсами одной ноды.

Но есть решение! Хотя и применять его стоит с большой осторожностью.

Можно вынести хранение events в отдельный кластер etcd (а это, как минимум, еще 3 ноды в ваш кластер). Для этого в конфиге API-сервера нужно указать следующее:

# /etc/kubernetes/manifests/kube-apiserver.yaml
command:
  - kube-apiserver
  - --etcd-servers-overrides=/events#https://etcd-events.example.com:2379
  ...

Разобраться в тонкостях работы etcd можно в гайде от Слёрма ➡️ в боте.

Rancher в продакшен: лучшие практики управления кластерами

Мы с Вячеславом Федосеевым (и Маркусом, конечно же) решили провести совместный веб и поговорить про Rancher. Будем обсуждать:

🔷 централизованное управление кластерами через единый интерфейс;
🔷 автоматизированные бэкапы и восстановление;
🔷 настройку доступа для команд и интеграцию внешней аутентификации;
🔷 встроенные мониторинг и использование магазина приложений.

Подробно покажем и расскажем, как Rancher упрощает эксплуатацию k8s и управление инфраструктурой, поделимся собственным опытом и best practices.

Когда: 16 июня в 19:00 мск

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

Cloud native практики, которые постоянно нарушаются

Все мы знаем базовые правила.

➡️ Не храните секреты в коде, будь то код приложения или код инфры (terraform, ansible, puppet, etc.).
➡️ Разделяйте prod и dev. Лучше на разные облачные аккаунты, чтобы уменьшить blast radius.
➡️ Руководствуйтесь принципом наименьших привилегий. Да, часто хочется просто накинуть побольше прав очередной IAM роли и не разбираться, а какие права реально нужны.

Но раз за разом эти простые вещи игнорируются в силу разных причин. Ловите чек-лист, на что обратить внимание, чтобы потом не было мучительно больно:

🟠 Безопасность

➡️ Least privilege: начинать с широких прав доступа кажется удобным, но приводит к огромным проблемам безопасности в будущем.

➡️ Использование IAM ролей (или аналогов)
- Использовать IAM роли для доступа к ресурсам.
- Не использовать статические креды для доступа.
- Использовать короткоживущие ключи доступа.
- Использовать AssumeRole (или аналоги), чтобы позволить, например, EC2 инстансу, временно получить нужные права доступа.

➡️ Регулярная ротация ключей и сертификатов: своевременная ротация ключей доступа и SSL/TLS сертификатов - must have, особенно для прода. Многие подобные ротации в публичных облаках работают из коробки, а где-то нужно дополнительно это настроить.

➡️ Проверка неиспользуемых ролей (пример)

➡️ Включать MFA для всех аккаунтов, особенно для root аккаунта.

➡️ Федеративные аккаунты: должен быть ровно один аккаунт, через который можно управляться всеми остальными (пример)

➡️ Сегментация сети: изоляция различных сред (dev, staging, prod) с помощью VPC и Security Group.

➡️ Шифрование данных: шифрование данных как при хранении (at rest) так и при передаче (in transit). At rest — не опциональный момент и должен быть включен обязательно.

🟠 Infrastructure as code

➡️ Terraform: автоматизация развертывания и управления инфраструктурой. Это позволяет отслеживать изменения, автоматизировать развертывание и избежать ручных ошибок.

➡️ Версионирование IaC: хранить код инфраструктуры в git.

➡️ Автоматизированные пайплайны для развертывания IaC: Интегрировать IaC с CI/CD пайплайнами.

🟠 Мониторинг и логирование

➡️ Централизованное логирование: собирать логи со всех компонентов системы в централизованное хранилище для упрощения анализа и отладки.

➡️ Мониторинг: настройка мониторинга ключевых метрик для отслеживания производительности и выявления проблем на раннем этапе, а не когда все уже развалится.

➡️ Алерты: никто не будет постоянно смотреть в ваши метрики и логи. Без алертов они почти бесполезны для раннего выявления проблем.

🟠 CI/CD

➡️ Автоматизация всего, что возможно: автоматизация развертывания, тестирования, масштабирования и восстановления.

➡️ CI/CD: непрерывная интеграция и непрерывная доставка - основа современной разработки.

➡️ Автоматизированные тесты: писать и запускать тесты (unit, integration, end-to-end) в CI/CD пайплайне.

🟠 Стоимость

➡️ Использовать reserved instances, saving plans или аналоги для сокращения расходов

➡️ Использовать менее отказоустойчивые решения для тестовых сред. Вам не нужно тройное резервирование БД, S3 и так далее практически никогда для dev/staging.

➡️ Автоскейлинг: выключить тестовые среды на ночь — тоже вариант экономии. Увеличивать ресурсы на проде, зная заранее паттерны нагрузки — так же полезно.

➡️ Удаление неиспользуемых ресурсов: регулярно проверять и удалять неиспользуемые ресурсы.

➡️ Выбор правильного типа инстанса: использование правильного размера и типа инстанса для задач. Недоиспользование ресурсов один из ключевых факторов повышенной стоимости инфраструктуры. Но не стоит забывать про сезонные скачки нагрузки. То что сегодня кажется ненужным, в сезон распродаж приводит к нерабочему проду, потому что он не справляется с нагрузкой и приходится срочно скейлить ресурсы.

➡️ Тегирование ресурсов: правильная система тегов для отслеживания стоимости и принадлежности ресурсов командам.

Список далеко не полный, но подсвечивает все ключевые моменты, которые стоит соблюдать при работе с инфрастуктурой.

Что почитать, чтобы отвлечься от ваших кластеров

Подборка для длинных выходных

➡️ Brendan Gregg's Website
Это просто кладезь знаний от человека, который посвятил себя оптимизации Linux. Он не просто рассказывает, что делать, а объясняет, почему и как это работает. Его инструменты — мастхэв для тех, кто хочет копаться в системе на уровне ядра и видеть, где у нее узкие места.

➡️ Systems Performance, 2nd Edition
Это как Библия для системного администратора. Всё, что нужно знать про тюнинг под высокие нагрузки, — от анализа I/O до оптимизации памяти, — тут есть. Книга толстая, но она того стоит, если хотите понимать, как система работает, а не просто тыкать наугад, когда нужно вытянуть перформанс.

➡️ Joel Spolsky's Blog
Особенно обратите внимание на «The Law of Leaky Abstractions». Он объясняет, почему важно понимать, что происходит «под капотом», даже если вы используете самые крутые фреймворки. Он основал Stack Overflow и, наверное, что-то понимает в IT.

➡️ «Awesome Falsehood»
Это просто must-read для любого инженера. Список всех самых распространенных заблуждений, которые только можно себе представить. Почитайте, чтобы не наступать на те же грабли, что и все остальные. На Хабре, кстати, есть переводы на русский – «Заблуждения программистов о времени» и «о картах» — чтобы было понятнее, о чем речь.

➡️ «Wat» Talk
А это чтобы немного расслабиться и понять, что мир неидеален. Знаменитая лекция про странности Ruby и JavaScript. Помогает не воспринимать баги слишком серьезно и вообще немного философски относиться к разработке.

Уроки Google

Вчерашний масштабный сбой в Google Cloud, наряду с инцидентом в Cloudflare, а также недавний пример с падением Yandex Cloud, стали очередным напоминанием о важности диверсификации в построении современных систем.

Нет ничего вечного. Признание того, что всё ломается – первый шаг к построению надежных систем. Главное – как к этому подготовиться?

➡️Пример Cloudflare

Cloudflare - компания, обслуживающая огромную часть интернет-трафика. Парадоксально, но у них нет собственных дата-центров. Вместо этого они арендуют серверы по всему миру. Это позволяет:

🟠Географически распределять нагрузку, что снижает риск одновременного выхода из строя всех серверов.
🟠Быть ближе к пользователю, что улучшает скорость доступа к контенту.
🟠Избегать монополизации, что снижает зависимость от одного поставщика услуг.

Казалось бы, идеальная стратегия диверсификации! Но…

Привет, я Google Cloud и сегодня я упал.

Cloudflare использует Google Cloud для критически важной части своей инфраструктуры. Когда Google Cloud падает, это тянет за собой и Cloudflare, как мы выяснили вчера, а вместе с ним и огромное количество зависимых сервисов, то есть ту самую половину интернета.

➡️Мораль истории

🟠Диверсификация - это хорошо, но она должна быть продуманной. Недостаточно просто распределить ресурсы между разными дата-центрами. Нужно убедиться, что критически важные компоненты не зависят от одного единственного поставщика, даже если это Google Cloud или AWS (у AWS тоже происходят большие сбои).
🟠Необходима возможность не зависеть от одного вендора. Что произойдет, если одна из ваших критичных зависимостей станет недоступна на многие часы или дни? Компании, для которых особенно критична стабильная работа с гарантиями 99.99% надежности, идут в направлении собственных ДЦ и мульти клауд архитектур. И да, это очень дорого.

Если хотите научиться в надежность систем, welcome на курс по SRE. На 3 недели станете SRE для сервиса покупки билетов. Наплыв посетителей, отказ инфраструктуры, сбой платежной системы, а следом еще и DoS-атака. Как восстановить работу сервиса – решать вам.

Атаки на инфраструктуру через забытые ресурсы

Большой компании — большая инфраструктура. Сотни отдельных кластеров, сотни инфраструктурных репозиториев.

Относительно легко в такой системе получить «забытые» ресурсы. Настроили что-то с недостаточно жесткими ограничениями, потом оказалось, что нужно делать по-другому, а созданные ресурсы никуда не делись и остались работать. И хорошо, если остались они только во внутренней сети, без возможности достучаться до них снаружи.

А что финансы и оплата всего забытого добра? На фоне общих отчетов какой-нибудь забытый кластер или открытый S3 bucket (классика) будут незаметны в большинстве случаев.

Типовые случаи:

➡️ Неправильно настроенный S3 bucket

🟠 Сценарий

Компания A использовала S3 bucket для хранения бэкапов логов веб-серверов. После миграции на новую систему логирования, старый bucket был забыт. Bucket остался с прежними настройками доступа, включая возможность чтения для аутентифицированных(!) AWS пользователей.

🟠 Атака

Хакер получил доступ к скомпрометированному аккаунту одного из сотрудников компании A. Используя эти credentials, он обнаружил старый S3 bucket и скачал резервные копии логов, содержащие конфиденциальную информацию о пользователях, включая имена, адреса электронной почты и пароли. Да, в логах веб сервера чего только не попадается.

🟠Последствия 

Утечка данных привела к репутационным потерям и штрафам со стороны регуляторов (GDPR).

➡️ Забытый сервисный аккаунт с большими правами

🟠 Сценарий

В публичном облаке был создан сервисный аккаунт для управления инфраструктурой. После изменения процессов автоматизации,  аккаунт был забыт, но продолжал существовать с избыточными правами и без должного мониторинга (использование ролей, сервисных аккаунтов и прочих credentials тоже нужно мониторить — ваш кэп).

🟠 Атака 

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

🟠 Последствия 

Компания понесла значительные финансовые затраты, когда счет за облако неожиданно вырос в десятки раз. А что стало со слитыми данными, история умалчивает.

➡️ Атака на цепочку поставок через незащищенный container registry

🟠Сценарий 

Компания X использовала устаревшую версию библиотеку в одном из сервисов.  Как потом выяснилось, с известной уязвимостью. Компания не проводила регулярное сканирование образов (почему это важно, и как привести в порядок свои процессы с точки зрения безопасности — на интенсиве Слёрма «DevSecOps Bootcamp»).

🟠 Атака 

Злоумышленник смог проэксплуатировать уязвимость, используй готовые инструкции.

🟠 Последствия 

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

Уроки

Эти примеры подчеркивают важность проактивного управления ресурсами и регулярного аудита инфраструктуры.

Забытые ресурсы могут представлять собой серьезную угрозу безопасности, даже когда они находятся строго во внутренней сети.

Rancher в продакшен: вебинар уже через час

В 19:00 встречаемся на бесплатном вебинаре с Вячеславом Федосеевым, чтобы обсудить:

🟠 централизованное управление кластерами через единый интерфейс;
🟠 автоматизированные бэкапы и восстановление;
🟠 настройку доступа для команд и интеграцию внешней аутентификации;
🟠 встроенные мониторинг и использование магазина приложений.

Подробно расскажем, как Rancher упрощает эксплуатацию k8s и управление инфраструктурой, и почему все продолжают использовать его неправильно.

➡️ Ссылки на трансляцию придут в бота. Подключайтесь!

🐈 Стартуем через 5 минут 🐈

Подключайтесь!

Заметки про публичные облака, или что можно узнать, если внимательно читать документацию

Примеры будут про AWS, т.к. это все еще самое большое публичное облако, но с небольшими допущениями может быть применимо к любым облакам.

➡️ AWS случайным образом сопоставляет физические AZ с названиями AZ для каждой учетной записи. В результате us-east-1a для вашей учетной записи AWS может отличаться от us-east-1a для другой учетной записи AWS и находиться в другом датацентре.

➡️ В рамках одного типа экземпляров (например, m5.large) могут использоваться разные поколения серверов с разной производительностью и разными поколениями процессоров. Это приводит к тому, что производительность ваших приложений на одном и том же классе инстансов может заметно отличаться.

➡️ Некоторые сервисы AWS доступны не во всех регионах или имеют разные версии и возможности в зависимости от региона. Например, новые типы инстансов могут появляться сначала в us-east-1.

➡️ Облачные ресурсы можно быстро масштабировать, но не всегда мгновенно. В периоды пиковых нагрузок ресурсы могут быть недоступны из-за недостатка ресурсов в конкретном регионе.

Пример: ваш кластер k8s автоматически скейлит кол-во нод через karpenter, но выбранный тип инстансов «закончился» на текущий момент и кластер остался без дополнительных нод, что привело к деградации сервиса.

➡️ Провайдеры могут обновлять свои сервисы без согласования с клиентом (это все равно прописано в условиях использования сервиса, но кто их читает, да?)), что иногда приводит к проблемам. Особенно это касается managed сервисов. Почитайте этот тред в reddit.

➡️ Стоимость использования ресурсов может вырасти неожиданно для вас, и вы не сможете с этим ничего сделать.

Неожиданные ошибки в k8s, или imagePullPolicy, который вас обманывал

*Суть проблемы в официальном блоге. Всего лишь 10 лет прошло от момента создания issue 😂

➡️ В чем была проблема с Image Pull Policy в Kubernetes до версии v1.33

До выхода k8s 1.33 существовала уязвимость в механизме работы с приватными образами, связанная с политикой imagePullPolicy: IfNotPresent.

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

🟠 Пример:

- Под A в Namespace X скачал приватный образ Foo с помощью Secret 1.
- Под B в Namespace Y на том же узле указывает тот же образ Foo, но не указывает никаких секретов.
- Благодаря политике IfNotPresent, kubelet не скачивает образ заново, а просто запускает контейнер на основе уже имеющегося локально образа - даже если у Pod B нет прав на доступ к этому образу.

🟠 Почему это плохо:

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

➡️ Что изменилось в k8s 1.33

- Kubelet проверяет credentials каждого пода даже для уже скачанных приватных образов.
- Если под не предоставляет корректный секрет, он не сможет использовать приватный образ, даже если тот уже есть на узле.
- Если секрет совпадает с тем, что использовался при первоначальной загрузке образа, повторная аутентификация/скачивание не требуется.
- Для публичных образов или образов, не требующих аутентификации, ничего не меняется.

🟠 Для активации нового поведения:

- Необходимо включить фичу KubeletEnsureSecretPulledImages (пока в alpha и не включена по умолчанию).

Зоны ответственности kubelet

➡️ Kubelet получает манифесты подов (PodSpecs) в основном от API-сервера, но также берет их напрямую из файловой системы ноды (по умолчанию из каталога /etc/kubernetes/manifests). Это позволяет запускать control plane еще до того, как доступен API-сервер, решая проблему курицы и яйца при инициализации кластера.

➡️ После получения манифестов kubelet приводит в соответствие текущее состояние подов на ноде с желаемым состоянием, описанным в манифесте. Для запуска и управления контейнерами он взаимодействует с container runtime (containerd, CRI-O). Аргумент --container-runtime-endpoint сообщает kubelet, где находится этот container runtime.

➡️ Kubelet не только запускает поды, но и постоянно мониторит их состояние. Он реализует  liveness, readiness и startup пробы.

➡️ Kubelet регулярно отправляет информацию о статусе подов и самогй ноды в API-сервер, что позволяет control plane отслеживать состояние ноды и запущенных на ней подов.

➡️ Через kubelet реализуется доступ к exec, logs и другим операциям — все эти запросы идут через API-сервер, который в свою очередь обращается к kubelet для получения данных с нужной ноды (или нод).

➡️ Kubelet отвечает за контроль ресурсов узла: при возникновении нехватки ресурсов (например, памяти) инициирует вытеснение (eviction) подов с наименьшим приоритетом. При этом учитывается поле priorityClassName: поды с более низким приоритетом будут удалены первыми, чтобы освободить ресурсы для более важных сервисов (подробнее тут).

Почему неплохо всё это знать?

Бывают разные кейсы. Пример — этот тред на реддите, или почему важны лимиты. Под на ноде съедал всю память и из-за этого крешился kubelet, делая ноду недоступной. Упс.

Service mesh в K8s: костыль или must have?

➡️ прямой эфир в понедельник!

Специальный гость — Георг Гаал, Principal DevOps Engineer, Zodia Markets.

Эфир пройдет в формате интервью. Мы с Маркусом подготовили для Георга каверзные вопросы про стандартные и не очень способы применения service mesh. Попробуем выяснить: есть ли жизнь после сервис меша?

➡️ Встречаемся прямо здесь, на канале, 23 июня в 18:00 мск. Эфир бесплатный, предварительная регистрация не нужна.

Ждём вас!

Сбор ответов для State of DevOps Russia 2025 заканчивается

До завершения ежегодного исследования состояния DevOps осталось 2 дня.

Это исследование — единственное в своем роде в России. Оно позволяет получить полную картину того, как развивается DevOps в стране, какие инструменты и практики используют команды, с какими вызовами сталкиваются компании. Каждый новый голос делает исследование точнее и полнее, поэтому я прошу вас пройти его.

➡️ Результаты исследования будут доступны каждому участнику. А еще организаторы разыграют в лотерею мерч, промокоды и билеты на Highload++ и DevOps Conf.

20 минут вашего времени — возможность повлиять на будущее DevOps в России.

Пройти опрос — по ссылке.

Привет! Это Маркус.

Решил вздремнуть, чтобы набраться сил перед эфиром.

➡️ Напоминаю: сегодня в 18:00 мск мой человек встречается с Георгом Гаалом, Principal DevOps Engineer, Zodia Markets.

Будем задавать ему всякие каверзные вопросы про сервис мэш и кубернетисы ваши (если я не просплю, конечно).

Кто придёт — лапки вверх 😻