Всем DevOps! 🖖

Хочется порекомендовать отличный блог про инфраструктуру, платформы, Linux, Open Source, DevOps, Kubernetes, контейнеризацию и облака. А еще автор пишет про Python, Go и shell.

Начать знакомство можно, например, со статьи «Kubernetes Taints, Tolerations, and Understanding the PreferNoSchedule Effect» — в ней говорится про эффект PreferNoSchedule в Kubernetes и его отличия от NoExecute и NoSchedule. Есть классная схема про принцип работы PreferNoSchedule.

Еще автор иногда пишет на смежные темы, например, заметка «12 Tips for Effective Technical Blogging». Вдруг вы ведете блог или просто пишете на Хабр? Будет полезно 😎

P.S. Кстати про технические блоги и Хабр! Может, здесь есть авторы? Расскажите о своих блогах в комментариях (ТГ, Хабр, что угодно) 🙃 Почему решили вести блог? А если вы не автор, можете рассказать — что вообще думаете о технических блогах? Почему не хотите писать сами?

Ну и, конечно, делитесь — кого читаете?

#блог

Открытое исследование «Защита персональных данных 2023» 🔒

За 2022-2023 год ужесточились условия и регулирование по 152-ФЗ.

На форумах мы слышим как всё меняется, но лозунги со сцен конференций и обновление ФЗ — это одна сторона медали, а реальная практика и опыт сообщества — совсем другая.

Компания Cortel проводит открытое исследование «Защита персональных данных 2023» чтобы выяснить:

• Как эксперты на местах смотрят на ситуацию;
• Как в действительности обстоят дела с ПДн и их защитой на практике.

Пожалуйста поделитесь своим мнением и пройдите короткий опрос на 3 минуты по этой ссылке, вы очень поможете.

🛡 Результатами исследования поделятся осенью в этом канале.

Всем 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 и отличной недели! 🖖

#новости