Всем DevOps! 🖖

В одной из рассылок (старый добрый email 🥰) была поднята интересная тема.

Итак, полторы недели назад инженер по машинному обучению написал анализ под названием «Падение Stack Overflow». Из собранных им данных и из данных, которыми делится StackOverflow с самой активной частью комьюнити, следует, что Stack Overflow потерял около 50% своего трафика. Впрочем оказалось, что данные о трафике не учитывают изменения в Google Analytics. С учетом этого падение составило бы 35%. Тем не менее, самая тревожная часть статистики — это не трафик, а снижение количества задаваемых вопросов и ответов.

Кажется, что падение Stack Overflow (и прочих подобных сайтов) связано с активным развитием AI-инструментов для написания кода (ChatGPT, Copilot и т.д.) — пользователи все больше отдают им предпочтение.

Автор рассылки связался со Stack Overflow, чтобы получить официальный комментарий и разобраться в ситуации.

В общем, можете посмотреть это письмо в Telegraph, ну и поделиться своим мнением в комментариях :)

Пользуетесь ли вы AI-инструментами для работы с кодом? Или просто для рабочих задач? А Stack Overflow — пользуетесь?

#статьи

Всем DevOps! 🖖

Сегодня хочется рассказать что-нибудь полезное. Решили поделиться советами. Потом по традиции соберем в один пост, чтобы сохранять было удобнее :) Погнали!

Как выбрать оптимальную архитектуру для вашего Kubernetes-кластера?

Вопрос, конечно, интересный. Управление Kubernetes-кластером — это не та задача, где есть одно правильное решение на все случаи жизни. Есть много способов оптимизации кластера и главное здесь — это обеспечение стабильной и отказоустойчивой работы приложений.

Выбор правильного размера ноды критичен для разработки масштабируемых приложений. Иметь множество маленьких нод или несколько больших — это две крайности. Для кластера, которому нужно всего 24Gb памяти и 12 CPU лучше выбрать 12 машин по 1-CPU/2GB или две по 6-CPU/12GB ?

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

Отказоустойчивость

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

Если у нас есть две больших воркер ноды и одна их них упадет, то мы потеряем половину всех ресурсов кластера. Если вы не предусмотрели 100% запас ресурсов, то это приведет к катастрофе, так как оставшаяся нода не сможет выдержать двойную нагрузку. Наличие множества воркеров снижает эти риски на n. К примеру, если у вас есть 10 нод в кластере и выключится одна, то вы потеряете только 10% от всей мощности кластера.

Победители: множество маленьких нод 🎉

Сложность управления

С большим количеством нод вам нужно будет заботиться о большем количестве серверов, их обновлении и обслуживании. Сократив количество нод их проще обслуживать. Как DevOps и SRE вы можете использовать такие инструменты как Ansible или Puppet, чтобы упростить эти процессы за счет автоматизации.

Если вы используйте managed Kubernetes-кластер, то ваш облачный провайдер будет патчить и обновлять ноды за вас. В итоге с современными инструментами этот пункт не дает существенного преимущества.

Победители: нет 🎉

Простота в распределении контейнеров

Kubernetes оценивает многие параметры, когда распределяет контейнеры. Одни из них — это количество доступных ресурсов на ноде, ресурсные запросы и ограничения для контейнеров. С большим количеством ресурсов на каждой ноде Kubernetes проще найти ноды, на которые можно переселить поды, чем если бы у вас было множество маленьких нод.

Победители: несколько больших нод 🎉

Нагрузка на kubelet

Kubelet отвечает за взаимодействие с нижележащим container runtime (движком для контейнеров) для запуска приложений на воркер нодах. Если вы запускаете множество контейнеров на одной ноде, что типично для кластеров с большими нодами, это может перегрузить kubelet, так как ему нужно будет оперировать большим количеством контейнеров.

Kubelet оптимизирован для управления только определённым ограниченным количеством контейнеров и многие облачные провайдеры ограничивают число контейнеров, которые можно запускать на одной воркер ноде. Следовательно, наличие нескольких больших нод это не всегда верное решение, если вы планируете запускать множество маленьких контейнеров.

Победители: множество маленьких нод 🎉

Нагрузка на систему

И наоборот, множество нод нагружают ваши мастер ноды, так как им нужно взаимодействовать со множеством воркер нод. Kubernetes не оптимизирован для работы более чем с 500 нодами на кластер (хотя они и пишут, что могут управлять до 5000 нод).

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

Победители: несколько больших нод 🎉

*️⃣1/3: продолжение следует :)

#лонгрид

Выбор размера нод

Что ж, выбор зависит от множества факторов, как всегда! Истина где-то посередине и не стоит выбирать ни одну из крайностей.

Вам нужно ответить на вопросы ниже, чтобы найти свой оптимальный размер.

Какой тип приложений вы запускаете?

Вы запускаете микросервисы из множества контейнеров, которые занимают мало места, или несколько монолитов, требующих гигабайты оперативной памяти и целые ядра CPU? Базы данных? Или все вместе?

Можно ли объединить приложения в группы?

Для смешанных окружений, можете ли вы разделить приложения по категориям? Например, если вы запускаете микросервисное приложение, которое работает с БД MySQL, вы разделяете его компоненты на группы приложений и баз данных. Аналогично, если вы запускаете вместе и монолиты и микросервисы, как ELK стек для мониторинга кластера, вы можете разместить его компоненты по разным группам. Для простоты я назвал только три категории, но вы можете создать столько, сколько хотите.

Максимальное количество ресурсов для каждой категории

Если вы можете сгруппировать приложения по категориям, то после этого вам нужно понять сколько максимум ресурсов может потребоваться на одно приложение из каждой категории. Например, если вы запускаете микросервисы, монолиты и БД в кластере, вам нужно взять максимальные затраты на один инстанс БД, микросервис или монолит.

Посчитать количество приложений в каждой категории

Следующий шаг это найти планируемое количество приложений в каждой из категорий. У вас может быть, например, 8 БД MySQL, 200 микросервисов и 9 монолитов. Запишите их. Не перебарщивайте. Kubernetes спроектирован для масштабирования и вы всегда можете использовать автоматическое масштабирование кластера у некоторых провайдеров. Либо, вы можете добавить ноду вручную позже.

Поместите каждую категорию в отдельный пул нод

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

Заложите отказоустойчивость

Нужно иметь минимум две ноды в каждом пуле для достижения отказоустойчивости. Kubernetes рекомендует максимум 110 контейнеров на ноду. Так же есть ещё системные контейнеры, которые запущены на нодах, так что имейте это ввиду.

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

Подгоните свои ноды под контейнеры для оптимального управления ресурсами

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

Подгоните ваши контейнеры и ноды для лучшего возможного управления ресурсами. Например, если у нас есть 20 контейнеров, лучше всего будет распределить по 4 пода на одну ноду, тогда нам нужно иметь в запасе 20% ресурсов на каждой ноде, вместо 100% как если бы у нас было всего 2 ноды.

Как мы пришли к этой цифре? Просто возьмите квадратный корень от количества контейнеров и округлите в меньшую сторону. Это даст вам максимальное количество контейнеров, которое должно быть у вас на ноде.

Учтите нагрузку от самого Kubernetes

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

*️⃣2/3: продолжение следует :)

#лонгрид

Подводя итог

Учитывая все вышесказанное, вам нужно сделать следующее, чтобы найти оптимальные значения:

Количество контейнеров на ноде = Корень квадратный из количества контейнеров, округленный до целого в меньшую сторону, при условии, что количество контейнеров на ноду не превышает рекомендуемое значение

Количество нод = Количество контейнеров/Количество контейнеров на ноду

Запас ресурсов = Количество контейнеров на ноду * Максимальное количество ресурсов на контейнер/(Количество нод - Максимальное допустимое количество отключенных нод)

Ресурсы ноды = максимальное кол-во ресурсов, требуемое контейнеру * кол-во контейнеров на ноде + запас ресурсов + ресурсные требования системных компонент Kubernetes

Чтобы понять, как это работает, давайте рассмотрим пример.

Давайте скажем, что нам нужны два пула нод:

Микросервисы - 200 микросервисов с 0.1 CPU и 100MB RAM, требуемых на контейнер.

Базы данных - 20 PostgreSQL баз данных с 2 CPU и 4GB RAM, требуемых на контейнер.

Предположим, что компоненты Kube system будут потреблять 0.5 CPU и 0.5 GB RAM и мы рассчитываем, что только одна нода может быть недоступна за раз.

Для микросервисного пула:

Ближайшее меньший целый квадрат числа = 196

Кол-во контейнеров на ноду = sqrt(196) = 14

Кол-во нод = 200/14 = 14.28 ~ 15

Максимальное допустимое число неработающих нод = 1

Запас ресурсов = 14 * (0.1 core + 100MB RAM)/(15–1) = 0.1 core + 100MB RAM

Ресурсы ноды = (0.1 core + 100MB RAM) * 14 + 0.1 core + 100MB RAM + 0.5 cores + 500MB RAM = 2 core + 2GB RAM

Для пула баз данных:

Ближайшее меньший целый квадрат числа = 16

Кол-во контейнеров на ноду = sqrt(16) = 4

Кол-во нод = 20/4 = 5

Максимальное допустимое число неработающих нод = 1

Запас ресурсов = 4 * (2 core + 4GB RAM)/(5–1) = 2 core + 4GB RAM

Ресурсы ноды = (two core + 4GB RAM) * 4 + 2 core + 4GB RAM + 0.5 cores + 0.5 GB RAM = 10.5 core + 20.5 GB RAM

Следовательно, для микросервисного пула вам будет нужно 15 воркер нод с 2 ядрами и 2 GB RAM каждая, и для пула БД вам нужно будет 5 воркер нод с 10.5 ядрами и 20.5 GB RAM каждая. Для простоты можно округлить числа до ближайшей большей доступной конфигурации машины.

*️⃣3/3

#лонгрид

Не любите Docker? Вы просто не умеете его готовить! 🤣

С Docker Cookbook есть шанс научиться. Ладно, если серьезно, эту отличную книгу нам порекомендовал подписчик, большое спасибо :) Разумеется, делимся!

В "кулинарной книге" — 10 глав. Каждая глава состоит из "рецептов", написанных в формате "проблема, решение, обсуждение". Можно читать книгу от начала до конца или выбрать конкретную главу — каждая глава независима от других, но когда требуются концепции из других разделов, предоставляются соответствующие ссылки

Как раз можно на выходных почитать (хотя, конечно, на выходных лучше отдыхать 🏖)

Всем пятница и хороших выходных! 🔥

P.S. Если вы знаете какой-то классный материал, инструмент, увидели интересную новость и т.д. и хотите поделиться ими с сообществом — пишите!

#книги

В эфире — новости! ⚡️

▪️ Мировой рынок облаков за год вырос на $10 млрд — затраты на облачные ресурсы во II четверти 2023-го составили приблизительно $65 млрд. Это на $10 млрд больше по сравнению с аналогичным периодом предыдущего года. Таким образом, зафиксирован третий квартал подряд, когда рынок облачных вычислений вырос на $10 млрд в годовом исчислении.

▪️ Анонсирована стабильная версия Ceph Reef 18.2.0 — из важного: по состоянию на 07.08.23 невозможен билд Ceph этой версии на Debian GNU / Linux 12.0 (Bookworm) из-за ошибки на стороне Debian. С тех пор апдейтов не было.

▪️ C 16 августа 2023 г. GitLab будет требовать от пользователей, которые не используют двухфакторную аутентификацию ( 2FA ), подтвердить действительный адрес электронной почты при входе в систему.

▪️GitLab Container Registry теперь поддерживает артефакты Falcoctl OCI. Точнее это обновление войдет в релиз GitLab 16.3. Falcoctl — одна из новейших разработок сообщества Falco. Это инструмент командной строки, который позволяет управлять полным жизненным циклом правил и плагинов Falco, используя возможности OCI Artifacts.

▪️Про релиз Kubernetes 1.28 уже все знают, но обратите внимание на официальный блог k8s — после релиза там начинают выходить полезные статьи, рассказывающие про важнейшие обновления релиза, уже вышло три.

А еще Kubernetes представили репозитории, принадлежащие сообществу Kubernetes, для пакетов Debian и RPM: pkgs.k8s.io. Новые репозитории пакетов заменяют репозитории пакетов, размещенные в Google ( apt.kubernetes.io и yum.kubernetes.io), которые использовались, начиная с версии Kubernetes 1.5.

Что-то забыли? Дополняйте в комментариях :)

Всем DevOps и отличной недели! 🖖

#новости

Классный open-source инструмент — Docker Bench 💻

Это скрипт, который проверяет десятки распространенных best practices развертывания контейнеров Docker в продакшене. Все тесты автоматизированы и основаны на CIS Docker Benchmark v1.5.0.

Для работы Docker Bench требуется Docker 1.13.0 или более поздние версии.

Лицензия Apache-2.0, 8.5k звездочек на GitHub 🌟

#open_source

Немного про Mobile DevOps ♾

Кто-то считает, что Mobile DevOps'а — нет, есть только DevOps практики и методология, а где они используются — роли не играет. Но нам кажется, что своя специфика у Mobile DevOps есть.

Рекомендуем познакомиться с материалами по этой теме и сделать свои выводы. А еще лучше — поделиться мыслями в комментариях :)

Начать можно с двух статей:

⚙️ «Да кто такой этот ваш Mobile DevOps?» — интересный рассказ про типичные проблемы мобильных команд (да-да, вы можете узнать в них свои), а также что такое Mobile DevOps и как получить этот самый Mobile DevOps к вам в команду.

⚙️ «Зачем разработчикам приложений нужен Mobile DevOps?» — а в этой статье рассказывается про то, какие проблемы решает Mobile DevOps, почему он может принести большую пользу компаниям, стремящимся к полной интеграции IT и других операционных взаимодействий с их бизнес-целями.

▪️ После знакомства с общими статьями, можно углубиться в детали. Для этого отлично подойдет серия статей — как GitLab можно использовать для Mobile DevOps (часть 1, часть 2, часть 3)

▶️ А потом — посмотреть видео «Особенности SRE и Observability в мобильных приложениях». Так уж сложилось, что тема SRE получила наибольшее распространение именно в серверных средах — бэкенды, апишки, базы. Однако с ростом количества мобильных телефонов и увеличением их роли в жизни людей вопросы доступности, наблюдаемости и надёжности мобильных приложений стали вставать всё острее.

Что думаете про Mobile DevOps? ❓

#статьи #видео

Happy Birthday, Linux! 💻

Про эту дату мы не могли забыть :) Вообще с днем Рождения Linux история неоднозначная, есть как минимум 4 возможные даты:

🗓 3 июля. В этот день Линус Торвальдс впервые упомянул о разработке новой ОС и попросил нужные спецификации POSIX в ньюс-группе Minix.

🗓 25 августа. В этот день было опубликовано письмо в ньюс-группе Minix с официальным анонсом проекта. Это наиболее подходящая дата, потому что есть официальный документ с датой, временем и т.д., считает Линус Торвальдс.

🗓 17 сентября. В этот день был выпущен релиз 0.01.

🗓 5 октября. День первого истинно публичного релиза, когда вышла версия 0.02 (+1 патч).

В честь праздника от души рекомендуем несколько классных материалов про Linux:

⚙️ Документальный фильм «Revolution OS» — про историю GNU, Linux, а также open source и free software-движения. Ссылка ведет на русскую озвучку, начинайте с 6:35, до этого момента автор озвучки рассказывает про себя.

⚙️ Видео «The mind behind Linux | Linus Torvalds» (en | en sub / ru sub) — 7 лет назад Линус Торвальдс дал небольшое интервью на TED и рассказал о своем видении технологий, философии open-source и немного о себе.

⚙️ Статья «Собираем и запускаем Linux-0.01 в Minix 1.5, (почти) как это делал Линус Торвальдс» — автор попытался повторить, насколько это возможно, действия Линуса Торвальдса по компиляции и запуску самой первой версии ядра Linux 0.01.

Live long and prosper, Linux! 🎉

Всем пятница и хороших выходных! 🖖

#новости #статьи #видео