Всем 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: продолжение следует :)

#лонгрид