Обзор
Кластер Managed Kubernetes — готовый кластер Kubernetes на базе облачной инфраструктуры MWS Cloud Platform. Он представляет собой совокупность Control Plane (управляющего слоя) и групп узлов. Control Plane включает в себя API-сервер и другие компоненты, которые контролируют состояние кластера, а на узлах в группе запускаются контейнеры приложений пользователя.
Создать кластер можно с помощью веб-консоли, MWS CLI, Terraform или API-запроса. Пользователь задает базовые параметры, остальное настраивается на стороне сервиса.
После создания работать с кластером можно с помощью утилиты командной строки kubectl или любой Kubernetes IDE, например Lens.
Типы кластеров
Заголовок раздела «Типы кластеров»В Managed Kubernetes доступны два типа кластеров: standalone и high-availability.
В standalone-кластере для работы Control Plane используется один управляющий узел. Standalone-кластер — экономичный вариант, который подходит для разработки, тестирования и умеренных нагрузок, но не обеспечивает отказоустойчивость.
В high-availability-кластере для работы Control Plane используются три управляющих узла, размещенных в одной зоне доступности. Такая конфигурация обеспечивает отказоустойчивость за счет кворума: кластер продолжает работать при отказе одного управляющего узла, но становится недоступным при отказе второго.
Сеть в кластере
Заголовок раздела «Сеть в кластере»Подключиться к кластеру можно как с виртуальной машины, которая находится в той же сети, так и через интернет. Обеспечить кластеру доступ в интернет можно только с помощью Egress NAT.
Кластер с CNI
Заголовок раздела «Кластер с CNI»Для организации сетевого взаимодействия в кластере Managed Kubernetes используется спецификация Container Networking Interface (CNI), которая реализуется с помощью сетевого плагина (CNI-плагина, CNI). Сетевой плагин можно выбрать во время создания кластера. В Managed Kubernetes доступны два сетевых плагина:
Calico — в кластер устанавливается стандартная поставка Calico без поддержки технологии eBPF. Используется сетевой компонент kube-proxy, который работает в режиме nftables. Вариант по умолчанию.
Cilium — в кластер устанавливается стандартная поставка Cilium. Плагин использует технологию eBPF и полностью заменяет компонент kube-proxy. Трафик между узлами кластера передается с помощью технологии VXLAN. Встроенный инструмент для мониторинга Hubble собирает информацию о DNS-запросах, отброшенных пакетах, TCP-соединениях, сетевых потоках, ICMP-пакетах и HTTP-запросах.
Функциональность сетевого плагина Cilium находится на стадии бета-тестирования.
Одновременно в кластере может использоваться только один сетевой плагин. После создания кластера изменить сетевой плагин невозможно.
Кластер без CNI
Заголовок раздела «Кластер без CNI»Режим без CNI предназначен для опытных пользователей. Воспользоваться им можно двумя способами:
Создать кластер без CNI. В этом случае пользователь устанавливает сетевой плагин и компонент kube-proxy самостоятельно. Ответственность за настройку и поддержку сетевой связности ложится на пользователя. До установки сетевого плагина узлы кластера будут находиться в статусе
NOT READY.Перевести существующий кластер в режим без CNI. В этом случае установленный сетевой плагин не удаляется из кластера, но сервис Managed Kubernetes перестает управлять сетевым плагином и дальнейшее обслуживание плагина выполняет пользователь. Выключение CNI необратимо.
Режим без CNI недоступен по умолчанию. Чтобы получить возможность выключать CNI, обратитесь в техническую поддержку.
Функциональность режима без CNI находится на стадии бета-тестирования.
Управление доступом
Заголовок раздела «Управление доступом»Доступ к кластеру регламентируется ролями IAM на уровне проекта.
Мониторинг кластера
Заголовок раздела «Мониторинг кластера»Получить статистику производительности кластера можно с помощью сервиса мониторинга.
Сервис мониторинга отслеживает следующие метрики:
- Утилизация CPU компонентами Control Plane, %.
- Утилизация RAM компонентами Control Plane, %.
- Количество запросов к API-серверу в секунду:
- по типам запросов: на чтение, на запись, прочие;
- по результату выполнения: успешные (коды состояния
2xx) и неуспешные (коды состояния, отличные от2xx).
- Количество запросов к API-серверу на чтение в секунду по группам кодов состояния:
2xx,3xx,4xx,5xx. - Количество запросов к API-серверу на запись в секунду по группам кодов состояния:
2xx,4xx,5xx. - Количество объектов в базе данных ETCD, шт.
- Объем данных в базе данных ETCD, ГБ: использованный объем и установленная квота.
- Количество операций в базе данных ETCD в секунду по методам:
PUT,DELETE,RANGE.
Получать данные мониторинга можно следующими способами:
- просматривать графики за выбранный период и в режиме онлайн-мониторинга;
- получать метрики через API сервиса мониторинга, в том числе с помощью Prometheus.