Аддоны

Обновлена 15 апреля 2024 г. в 08:50

Аддоны

Для кластеров Cloud Containers доступны различные аддоны (дополнительные сервисы). Их можно выбрать в любой комбинации и установить либо при создании кластера с помощью Terraform, либо позднее в уже существующий кластер. Процесс установки автоматизирован и требует минимального вмешательства пользователя.

Аддоны устанавливаются на worker-узлы кластера и потребляют их вычислительные ресурсы.

Ниже приведены системные требования аддонов, исходящие из стандартных значений requests и limits для ресурсов Kubernetes в коде настройки аддона. При использовании нестандартных значений системные требования аддонов изменятся.

Аддоны могут быть установлены на выделенную группу worker-узлов или на выбранные планировщиком Kubernetes worker-узлы. Использование первого подхода позволяет исключить влияние аддонов на работу production-сервисов, развернутых в кластере.

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

Установка аддонов возможна в трех вариантах:

Стандартная установка на выбранные планировщиком Kubernetes worker-узлы с изменением кода настройки аддона.
Установка на выделенные worker-узлы с изменением кода настройки аддона.
Быстрая установка на выбранные планировщиком Kubernetes worker-узлы без изменения кода настройки аддона (с настройками по умолчанию).

Не все аддоны поддерживают все три варианта установки.

Процесс установки описан в разделе Настройка и установка аддонов.

Кластеры Kubernetes позволяют организовать логическое разделение ресурсов Kubernetes на уровне отдельных пространств имен (namespaces). Однако этого может быть недостаточно, чтобы организовать разделение и изоляцию ресурсов в сложных сценариях. Например, нужно предоставить разным командам разработчиков разные наборы ресурсов. Для этого можно создать отдельные кластеры для каждой команды, но если таких кластеров много, ими сложно управлять.

Capsule позволяет изолировать наборы ресурсов в рамках одного кластера с помощью тенантов (tenants). Тенант представляет собой пространства имен в сочетании с ограничениями на создание и потребление ресурсов Kubernetes, назначенные определенной группе пользователей. Движок политик Capsule (policy engine) не только следит за соблюдением политик по использованию ресурсов в рамках тенанта, но и обеспечивает изоляцию одного тенанта от другого. Так можно организовать работу нескольких команд в одном мультитенантном кластере (multi-tenant cluster) без необходимости администрировать дополнительные кластеры.

С помощью инструмента cert-manager можно управлять сертификатами в кластерах Kubernetes:

Выпускать сертификаты, в том числе самоподписанные (self-signed). Для этого cert-manager отправляет запросы к источникам, выступающим в роли центра сертификации (certificate authority, CA).

Примеры источников:

провайдеры решений по кибербезопасности, такие как Venafi;
провайдеры сертификатов, такие как Let’s Encrypt;
хранилища секретов, такие как HashiCorp Vault;
локальные контейнеры, содержащие внутри себя публичную часть сертификата и приватный ключ.

Автоматически перевыпускать сертификаты с истекающим сроком действия.

Выпущенный с помощью cert-manager сертификат будет доступен другим ресурсам Kubernetes. Например, его можно использовать для Ingress.

Реестр Docker предназначен для размещения и хранения образов Docker. Работает в отказоустойчивой конфигурации (high availability, HA). Образы из реестра можно использовать при развертывании сервисов в кластере.

Подробнее в разделе Подключение к реестру Docker.

Ingress-контроллер на базе NGINX работает в качестве обратного прокси (reverse proxy) и позволяет организовать единую точку входа для сервисов в кластере, которые работают по HTTP или HTTPS.

При наличии контроллера достаточно создать ресурс Ingress, чтобы такие сервисы стали доступны извне кластера Kubernetes.

Ingress-контроллер тесно интегрируется с платформой VK Cloud. Подробнее в разделе Сеть в кластере.

Istio — это фреймворк, реализующий концепцию сервисной сетки (service mesh), при которой для взаимодействия между сервисами приложения выделяется отдельный слой. Использование Istio обеспечивает для сервисов управление трафиком без изменения кода самих сервисов (используются sidecar-контейнеры). Преимущества Istio:

Расширяются возможности для безопасной передачи трафика:

можно настраивать политики для трафика;
можно использовать TLS для коммуникации между сервисами;

Расширяются возможности мониторинга трафика.

Возможна сложная маршрутизация и балансировка трафика между сервисами.

В распределенных системах, основанных на микросервисах, постоянно идет обмен запросами (requests). Платформа Jaeger создана для распределенной трассировки запросов. Jaeger отслеживает путь потока запросов через микросервисы и позволяет:

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

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

Jaeger выполняет трассировку запросов на основе данных, которые получает от микросервисов. Поэтому в микросервисы необходимо интегрировать инструментальный стек OpenTelemetry для отправки данных о запросах. Познакомиться с интеграцией OpenTelemetry в микросервисное приложение можно на примере Hot R.O.D.

Kiali — веб-интерфейс для работы с Istio. Он позволяет управлять сервисной сеткой (service mesh), отслеживать ее состояние и визуализировать ее.