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

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

Контейнеры находятся в центре экосистемы Kubernetes и являются строительными блоками сервисов, созданных и управляемых K8S. Понимание того, как работают контейнеры, является ключом к оптимизации вашей среды Kubernetes.

Что такое контейнеры и среды выполнения контейнеров?

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

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

Сами среды выполнения контейнеров бывают двух видов: среды выполнения контейнеров высокого уровня, которые занимаются управлением образами и жизненным циклом контейнеров, и среды выполнения низкого уровня, совместимые с OCI, которые фактически создают и запускают контейнеры.

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

Какую высокоуровневую среду выполнения контейнера следует выбрать?

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

- Docker: Это среда выполнения контейнера, которая включает создание контейнера, упаковку, совместное использование и выполнение. Docker был создан как монолитный демон, dockerd и клиентская программа docker, и имеет клиент-серверную архитектуру. Демон обрабатывал большую часть логики для создания контейнеров, управления образами и эксплуатации контейнеров, а также предоставлял API.

- ContainerD: он был создан для использования Docker и Kubernetes, а также любой другой контейнерной технологией, которая хочет абстрагировать системные вызовы и функциональные возможности, специфичные для ОС, для работы контейнеров в Linux, Windows, SUSE и других операционных системах.

- CRI-O: он был создан специально как облегченная среда выполнения только для Kubernetes и может обрабатывать только такие виды операций.

Упомянутые среды выполнения популярны и предлагаются каждым крупным поставщиком облачных услуг. В то время как Docker, как высокоуровневая среда выполнения контейнера, уходит, другие две остаются.

Параметры, которые следует учитывать

- Производительность: ContainerD или CRI-O, как правило, известны своей лучшей производительностью, поскольку накладные расходы на операции ниже. Docker — это монолитная система, которая имеет все необходимые биты функций, что увеличивает накладные расходы. Хотя производительность сети между ними не сильно отличается, можно выбрать любой из них, если это важный фактор.

- Особенности: Поскольку ContainerD — это легкая система, она не всегда имеет все функции, если это важно, тогда как Docker имеет большой набор функций. Если сравнивать ContainerD с CRI-O, то CRI-O имеет меньший набор функций, поскольку он нацелен только на Kubernetes.

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

Почему стоит рассмотреть вариант ручного развертывания?

До сих пор разработчики DST Global рассказывали об управляемом развертывании K8S , которое предоставляется крупнейшими поставщиками облачных услуг, такими как Amazon, Microsoft, Google и т. д. Но есть и другой способ размещения вашей инфраструктуры — управлять ею самостоятельно.

Вот тут-то и вступает в дело ручное развертывание. У вас есть полный контроль над каждым компонентом в вашей системе, что дает вам возможность удалять ненужные функции. Но это вносит накладные расходы на управление развертыванием.

Оптимизация кластера GKE: 14 тактик для более плавного развертывания K8s

Большинство инженеров не хотят тратить больше времени, чем необходимо, чтобы поддерживать высокую доступность, безопасность и экономичность своих кластеров. Как убедиться, что ваш кластер движка Google Kubernetes готов к грядущим бурям?

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

Вот три основных раздела этой статьи:

- Управление ресурсами

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

- Нетворкинг

Советы по управлению ресурсами для кластера GKE

1. Автомасштабирование

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

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

- Горизонтальный автомасштабатор подов: HPA автоматически добавляет или удаляет реплики подов на основе показателей использования. Он отлично подходит для масштабирования приложений без сохранения и сохранения состояния. Используйте его с Cluster Autoscaler, чтобы уменьшить количество активных узлов при уменьшении количества подов. HPA также удобен для обработки рабочих нагрузок с короткими пиками высокой загрузки.

- Вертикальный автомасштабатор pod: VPA увеличивает и уменьшает запросы ресурсов ЦП и памяти контейнеров pod, чтобы гарантировать соответствие выделенного и фактического использования кластера. Если ваша конфигурация HPA не использует ЦП или память для определения целей масштабирования, лучше использовать его с VPA.

- Автомасштабирование кластера: динамически масштабирует количество узлов в соответствии с текущим использованием кластера GKE. Отлично работает с рабочими нагрузками, разработанными для удовлетворения динамически меняющегося спроса.

Лучшие практики автоматического масштабирования в кластере GKE

- Используйте HPA, VPA и Node Auto Provisioning (NAP): используя HPA, VPA и NAP вместе, вы позволяете GKE эффективно масштабировать ваш кластер горизонтально (модули) и вертикально (узлы). VPA устанавливает значения для ЦП, запросов памяти и лимиты для контейнеров, в то время как NAP управляет пулами узлов и устраняет ограничение по умолчанию, заключающееся в запуске новых узлов только из набора пулов узлов, созданных пользователем.

- Проверьте, не конфликтуют ли политики HPA и VPA: убедитесь, что политики VPA и HPA не мешают друг другу. Например, если HPA полагается только на показатели ЦП и памяти, HPA и VPA не смогут работать вместе. Также проверьте настройки плотности упаковки бинов при проектировании нового кластера GKE для уровня обслуживания бизнес-класса или назначения.

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

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

2. Выберите топологию для вашего кластера GKE

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

- Региональная топология: в региональном кластере Kubernetes Google реплицирует плоскость управления и узлы в нескольких зонах одного региона.

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

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

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

3. Узлы Bin Pack для максимального использования

Это разумный подход к оптимизации затрат GKE, которым поделилась команда инженеров DST Global.

Чтобы максимизировать использование узла, лучше всего добавлять pods к узлам уплотненным способом. Это открывает дверь к снижению затрат без какого-либо влияния на производительность. Эта стратегия называется bin packing и противоречит Kubernetes, который выступает за равномерное распределение pods по узлам.

Команда DST Global использовала GKE Autopilot, но его ограничения заставили инженеров самостоятельно создавать упаковку bin.

Благодаря объединению пулов узлов и выполнению упаковки контейнеров модули размещаются в узлах более эффективно, что помогает DST Global сократить общее количество узлов в этой команде примерно на 60%.

4. Внедрение мониторинга затрат

Мониторинг затрат играет важную роль в управлении ресурсами, поскольку он позволяет вам следить за своими расходами и мгновенно реагировать на оповещения о резких скачках затрат.

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

Измерение использования GKE позволяет вам отслеживать использование ресурсов, отображать рабочие нагрузки и оценивать потребление ресурсов. Включите его, чтобы быстро определить наиболее ресурсоемкие рабочие нагрузки или пики потребления ресурсов.

Этот шаг — минимум, который вы можете сделать для мониторинга затрат. Отслеживание этих 3 показателей — вот что действительно влияет на то, как вы управляете своими облачными ресурсами: ежедневные расходы на облако, стоимость предоставленного и запрошенного ЦП и историческое распределение затрат.

5. Используйте спотовые виртуальные машины

Spot VMs — это невероятная возможность экономии средств: вы можете получить скидку до 91% от цены с оплатой по факту использования. Проблема в том, что Google может в любой момент забрать машину, поэтому вам нужно иметь стратегию, чтобы справиться с перерывом.

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

Лучшие практики для запуска кластера GKE на спотовых виртуальных машинах

- Как выбрать правильную точечную VM? Выберите немного менее популярный тип точечной VM — он менее подвержен прерываниям. Вы также можете проверить частоту прерываний (скорость, с которой этот экземпляр восстанавливал емкость в течение следующего месяца).

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

Лучшие практики безопасности для кластеров GKE

Отчет Red Hat 2022 State of Kubernetes and Container Security показал, что почти 70% инцидентов происходят из-за неправильных конфигураций.

GKE защищает ваш кластер Kubernetes на многих уровнях, включая образ контейнера, его среду выполнения, сеть кластера и доступ к серверу API кластера. Google обычно рекомендует реализовать многоуровневый подход к безопасности кластера GKE.

Наиболее важными аспектами безопасности, на которых следует сосредоточиться, являются:

- Аутентификация и авторизация

- Плоскость управления

- Узел

- Сетевая безопасность

1. Следуйте показателям CIS

Все ключевые области безопасности являются частью эталонных показателей Центра интернет-безопасности (CIS) — всемирно признанного сборника лучших практик, который поможет вам структурировать усилия по обеспечению безопасности.

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

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

2. Внедрение RBAC

Управление доступом на основе ролей (RBAC) — это важный компонент для управления доступом к кластеру GKE. Он позволяет вам устанавливать более детализированный доступ к ресурсам Kubernetes на уровне кластера и пространства имен, а также разрабатывать подробные политики разрешений.

В CIS GKE Benchmark 6.8.4 подчеркивается, что команды отдают предпочтение RBAC по сравнению с устаревшим контролем доступа на основе атрибутов (ABAC).

Другой CIS GKE Benchmark (6.8.3) предлагает использовать группы для управления пользователями. Так вы упрощаете управление удостоверениями и разрешениями и не нужно обновлять конфигурацию RBAC каждый раз, когда вы добавляете или удаляете пользователей из группы.

3. Следуйте принципу наименьших привилегий.

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

В CIS GKE Benchmark 6.2.1 указано: « Предпочтительнее не запускать кластеры GKE с использованием учетной записи службы Compute Engine по умолчанию» .

По умолчанию узлы получают доступ к учетной записи службы Compute Engine. Это удобно для нескольких приложений, но открывает дверь к большему количеству разрешений, чем необходимо для запуска кластера GKE. Создайте и используйте минимально привилегированную учетную запись службы вместо учетной записи по умолчанию — и следуйте тому же принципу везде.

4. Повысьте безопасность вашего уровня управления

Google реализует модель общей ответственности для управления компонентами плоскости управления GKE. Тем не менее, вы несете ответственность за безопасность узлов, контейнеров и pod.

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

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

5. Защитите метаданные узла

Тесты CIS GKE 6.4.1 и 6.4.2 указывают на два критических фактора, которые могут поставить под угрозу безопасность вашего узла и отразиться на вас.

Kubernetes прекратил поддержку конечных точек сервера метаданных Compute Engine v0.1 и v1beta1 в 2020 году. Причина в том, что они не обеспечивали принудительное использование заголовков запросов метаданных.

Некоторые атаки на кластеры Kubernetes основаны на доступе к серверу метаданных виртуальных машин. Идея здесь заключается в извлечении учетных данных. Вы можете бороться с такими атаками с помощью идентификации рабочей нагрузки или сокрытия метаданных.

6. Регулярно обновляйте GKE

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

Хорошей новостью о GKE является то, что он автоматически исправляет и обновляет плоскость управления. Автоматическое обновление узла также обновляет узлы кластера, и CIS GKE Benchmark 6.5.3 рекомендует оставить эту настройку включенной.

Если по какой-либо причине вы хотите отключить автоматическое обновление, Google рекомендует выполнять обновления ежемесячно и следить за бюллетенями по безопасности GKE на предмет критических исправлений.

Советы по оптимизации сети для вашего кластера GKE

1. Избегайте совпадений с IP-адресами из других сред.

При проектировании более крупного кластера Kubernetes помните о необходимости избегать перекрытий с IP-адресами, используемыми в других средах. Такие перекрытия могут вызвать проблемы с маршрутизацией, если вам необходимо подключить сеть VPC кластера к локальным средам или другим сетям поставщиков облачных услуг через Cloud VPN или Cloud Interconnect.

2. Используйте GKE Dataplane V2 и сетевые политики

Если вы хотите контролировать поток трафика на уровне OSI 3 или 4 (уровень IP-адреса или порта), вам следует рассмотреть возможность использования сетевых политик. Сетевые политики позволяют указать, как pod может взаимодействовать с другими сетевыми сущностями (pod, сервисами, определенными подсетями и т. д.).

Чтобы вывести свою кластерную сеть на новый уровень, GKE Dataplane V2 — правильный выбор. Он основан на eBPF и обеспечивает расширенную интегрированную сетевую безопасность и видимость.

Кроме того, если кластер использует Google Kubernetes Engine Dataplane V2, вам не нужно явно включать сетевые политики, поскольку первый управляет маршрутизацией служб, применением сетевых политик и ведением журналов.

3. Используйте Cloud DNS для GKE

Разрешение DNS Pod и Service может быть выполнено без дополнительных накладных расходов на управление поставщиком DNS, размещенным в кластере. Cloud DNS для GKE не требует дополнительного мониторинга, масштабирования или других действий по управлению, поскольку это полностью размещенная служба Google.

Заключение

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