Перейти к содержимому

Обзор

Кластер 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.

Для организации сетевого взаимодействия в кластере 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. В этом случае пользователь устанавливает сетевой плагин и компонент 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.

Получать данные мониторинга можно следующими способами: