06.11.2024 07:03
aleksluov 0 663 Источник

Со 2 июля 2024 года на канале обновлений Stable сменилось четыре версии Deckhouse Kubernetes Platform (DKP) — c 1.61 по 1.64. В этом дайджесте мы пройдёмся по самым важным изменениям в платформе и расскажем, как это скажется на работе её пользователей. Полный список изменений можно найти по ссылкам в описании каждого релиза.

Deckhouse Kubernetes Platform 1.61: статические диски в Yandex Cloud и повышение отказоустойчивости с Fencing

Версия DKP 1.61 на канале обновлений Stable появилась 2 июля 2024 года. Из ключевых особенностей можно выделить добавление поддержки Ubuntu 24.04 и РЕД ОС 8.0, возможность указывать тип диска статических узлов при использовании провайдера для Yandex Cloud, новые метрики для модуля управления узлами и функции для обеспечения автоматической изоляции проблемных узлов в кластере Kubernetes для повышения его надёжности и отказоустойчивости.

Рассмотрим изменения подробнее.

Добавлена поддержка Ubuntu 24.04 и РЕД ОС 8.0 

Это обновление обеспечивает совместимость с последними версиями Ubuntu LTS и РЕД ОС. Теперь система правильно определяет и устанавливает необходимые для них пакеты.

Добавлена поддержка NGINX Ingress Controller 1.10

Он включает поддержку nginx 1.25 (возможна несовместимость директив на уровне configuration-snippet и т. п.) и HTTP/3. Также в версии 1.10 удалена поддержка GeoIP в пользу GeoIP2.

Добавлен параметр diskType для masterNodeGroup и nodeGroups в YandexClusterConfiguration

В предыдущих версиях DKP не было возможности выбора типа диска для узлов. Все узлы создавались с жёстко заданным типом диска — SSD. Это означало, что если администратору требовался один из типов допустимых значений для узла, то он должен был сначала создать узел с SSD, а затем вручную менять диск на необходимый тип. Такой подход мог привести к проблемам с состоянием узла, так как изменение типа диска после создания могло нарушить целостность данных и конфигурации.

Теперь, начиная с версии 1.61, можно указывать тип диска статических узлов при использовании провайдера для Yandex Cloud (параметры nodeGroups.instanceClass.diskType и masterNodeGroup.instanceClass.diskType). Допустимые значения: network-ssd, network-ssd-io-m3, network-ssd-nonreplicated.

Добавлена возможность реализации отказоустойчивого egress gateway

Единственное решение для настройки egress gateway ранее — использовать ресурс CiliumEgressGatewayPolicy, который предоставляет CNI Cilium. Но у него есть ограничение — он может использовать только один конкретный узел в качестве egress gateway. Если тот выйдет из строя, тогда механизмов отказоустойчивости не будет и сетевое соединение будет разорвано. Но в новой реализации шлюз будет обеспечивать отказоустойчивость egress gateway. Это возможно благодаря новым ресурсам EgressGateway и EgressGatewayPolicy:

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

  • Ресурс EgressGatewayPolicy используется для перенаправления исходящих запросов приложений через настроенные с помощью ресурса EgressGateway шлюзы (доступно только при использовании модуля cni-cilium).

Добавлены метрики мониторинга по группам узлов

  • d8_node_group_ready — количество узлов группы, находящихся в статусе Ready;

  • d8_node_group_nodes — количество узлов в группе (в любом статусе);

  • d8_node_group_instances — количество инстансов в группе (в любом статусе);

  • d8_node_group_desired — желаемое (целевое) количество объектов Machines в группе;

  • d8_node_group_min — минимальное количество инстансов в группе;

  • d8_node_group_max — максимальное количество инстансов в группе;

  • d8_node_group_up_to_date — количество узлов в группе в состоянии up-to-date;

  • d8_node_group_standby — количество резервных узлов (см. параметр standby) в группе;

  • d8_node_group_has_errors — единица, если в группе узлов есть какие-либо ошибки.

Добавлена функция Fencing

Функция Fencing обеспечивает автоматическую изоляцию проблемных узлов в кластере Kubernetes для повышения его надёжности и отказоустойчивости. Когда система обнаруживает, что узел теряет связь с Kubernetes API, она инициирует процесс отключения этого узла. Это предотвращает возможные сбои и минимизирует риски потери данных, обеспечивая более надёжную работу Stateful-приложений.

Полный список изменений версии 1.61.

Deckhouse Kubernetes Platform 1.62: поддержка Kubernetes 1.30 и Deckhouse CLI для Windows

Версия DKP 1.62 появилась на канале обновлений Stable 1 августа 2024 года. Из основных изменений можно выделить прекращение поддержки Kubernetes 1.25 и добавление поддержки Kubernetes 1.30, а также выход утилиты командной строки для управления кластерами от разработчиков Deckhouse (Deckhouse CLI) для операционной системы Windows.

Рассмотрим изменения подробнее.

Добавлена поддержка Kubernetes 1.30 и прекращена поддержка Kubernetes 1.25

Это обновление предоставит пользователям возможность воспользоваться последними функциями и улучшениями, доступными в Kubernetes 1.30. В каждом релизе DKP поддерживается не менее четырёх последних версий. Перейти на новую версию можно в любой момент.

На активный под контроллера DKP добавлена метка лидера

С выходом версии 1.59 в DKP был внедрён НА-режим для оператора DKP, который позволяет запускать несколько подов приложения Deckhouse в зависимости от количества мастер-узлов. Ранее существовал только один под, что упрощало администрирование и выполнение таких команд, как анализ логов.

С введением поддержки нескольких подов возникла небольшая проблема: администратору необходимо определить, какой из подов является лидером, чтобы получить доступ к актуальной информации системы. Для решения этой проблемы была добавлена специальная метка leader=true, которая всегда будет присутствовать на поде-лидере. Это упрощает выполнение команд, позволяя администраторам не беспокоиться о количестве реплик Deckhouse. А ещё это позволяет удобнее выполнять команды в поде DKP, независимо от того, работает ли он в режиме высокой доступности или нет. Например: kubectl -n d8-system -l app=deckhouse,leader=true -c deckhouse logs.

Добавлен параметр для конфигурации узлов в OpenStack

В провайдере OpenStack для layout SimpleWithInternalNetwork добавлен булевый параметр nodeGroups.instanceClass.configDrive, определяющий, будет ли монтироваться на узел дополнительный диск, содержащий конфигурацию узла. Параметр необходимо включать, если в сети, указанной в качестве mainNetwork, отключён DHCP.

Deckhouse CLI стала доступна и для Windows

Deckhouse CLI — это утилита для работы с кластерами Deckhouse Kubernetes Platform. Раньше она была доступна только для операционных систем Linux. Теперь и у пользователей Windows есть интерфейс командной строки для управления кластерами DKP, благодаря чему можно выполнять задачи управления и мониторинга эффективнее и быстрее, используя знакомые команды. 

Полный список изменений версии 1.62.

Deckhouse Kubernetes Platform 1.63: Grafana 10 и поддержка ALT Linux p11

Версия DKP 1.63 на канале обновлений Stable появилась 28 августа 2024 года. Из основных изменений: Grafana 10 стала версией по умолчанию, в DKP поддерживается ALT Linux p11, а в кластер можно добавлять узлы, настроенные без Cluster API Provider Static (CAPS).

Рассмотрим изменения подробнее.

Добавлена поддержка ALT Linux p11

В июне вышла новая стабильная ветка репозиториев ALT — p11. Теперь новая версия поддерживается в DKP в качестве ОС для узлов.

Grafana v10 заменила Grafana v8 

Grafana 10 становится версией по умолчанию. В рамках этого обновления:

  • Grafana версии 10 теперь станет доступна на основном домене.

  • Для пользователей, которым требуется больше времени для миграции, предыдущий инстанс Grafana 8 переедет на вторичный домен. Старая Grafana будет находиться по адресу grafana-v8 (согласно шаблону DNS-имён кластера).

Это второй этап нашего трёхэтапного процесса перехода на Grafana 10. Он обеспечивает плавный переход пользователей, сохраняя доступ к обеим версиям в течение периода миграции. На заключительном этапе произойдёт полный отказ от Grafana 8, поэтому этот шаг очень важен для того, чтобы все пользователи знали о переходе и имели достаточно времени для полной миграции своих рабочих процессов.

В Istio для sidecar-контейнеров установлен лимит использования CPU

Для всех новых подов лимит CPU будет установлен на 2 ядра в sidecar-контейнере Istio. Если это значение слишком мало, его можно изменить в параметре sidecar.resourcesManagement.static.limits.cpu. Чтобы применить новые ограничения к ранее созданным подам, нужно перезапустить их вручную.

Добавлены проходные inlet’ы для SSL

Новый тип инлетов Ingress-контроллера — LoadBalancerWithSSLPassthrough и HostPortWithSSLPassthrough — используется для передачи SSL-трафика без его терминирования на Ingress-контроллере.

  • LoadBalancerWithSSLPassthrough — устанавливается Ingress-контроллер и заказывается сервис с типом LoadBalancer. Этот инлет включает функцию SSL Passthrough, которая позволяет сконфигурировать бэкенды на принятие SSL-трафика напрямую, без его терминации на Ingress-контроллере.

  • HostPortWithSSLPassthrough — устанавливается Ingress-контроллер, который доступен на портах узлов через hostPort. Этот инлет также включает функцию SSL Passthrough.

Добавлена ​​поддержка принятия вручную созданных узлов под управлением CAPS

Представим, что есть необходимость настройки кластера с тремя мастер-узлами, но при использовании Cluster API Provider Static (CAPS) этот процесс получается несогласованным, так как для разных мастер-узлов используются разные подходы. 

При создании кластера первый мастер-узел добавляется вручную с помощью dhctl bootstrap, а остальные два мастера — через дополнительную master node-group и StaticInstance. Получается противоречие: два мастера входят в StaticInstance, а третий — нет. 

Нововведение позволяет передать запущенные вручную узлы под контроль CAPS, навесив на них StaticInstance-аннотацию static.node.deckhouse.io/skip-bootstrap-phase: "".

Для статических узлов, настроенных без CAPS, появилась возможность их включения под управление CAPS. Для этого нужно в соответствующем ресурсе StaticInstance установить аннотацию static.node.deckhouse.io/skip-bootstrap-phase: "".

Добавлена поддержка аутентификации на основе токенов для облаков в vCloud Director

Теперь пользователи облаков в vCloud Director могут проходить аутентификацию более безопасным по сравнению с паролем способом.

Полный список изменений версии 1.63.

Deckhouse Kubernetes Platform 1.64: прекращение развития l2-load-balancer и перевод его функций в MetalLB, а также новая ролевая модель доступа

Версия DKP 1.64 на канале обновлений Stable появилась 16 октября 2024 года. Из основных изменений можно выделить новую ролевую модель доступа, возможность скачивания утилиты Deckhouse CLI (d8) из кластера (без необходимости доступа в интернет) и возможность расширения планировщика внешними плагинами через вебхуки.

Рассмотрим изменения подробнее.

Прекращено развитие модуля l2-load-balancer 

Модуль будет удалён в следующем релизе DKP. Если он будет включён, кластер не будет обновляться. Функции модуля l2-load-balancer будут реализованы в модуле MetalLB, поэтому нужно переходить на его использование.

Реализована новая ролевая модель доступа 

Новая ролевая модель не использует ресурсы ClusterAuthorizationRule и AuthorizationRule. Вся настройка прав доступа выполняется стандартным для RBAC Kubernetes способом — с помощью создания ресурсов RoleBinding или ClusterRoleBinding с указанием в них одной из подготовленных модулем user-authz-ролей. Рекомендуем в новых проектах использовать только эту модель.

Подробнее о новой ролевой модели доступа в документации Deckhouse Kubernetes Platform. 

Добавлен новый модуль deckhouse-tools 

Модуль реализует веб-интерфейс для скачивания утилиты Deckhouse CLI (d8) из кластера (без необходимости доступа в интернет). Веб-интерфейс доступен по домену tools в соответствии с установленным шаблоном DNS-имён.

Добавлена возможность расширения планировщика внешними плагинами через вебхуки (ресурс KubeSchedulerWebhookConfiguration)

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

Полный список изменений версии 1.64.

Заключение

Deckhouse Kubernetes Platform продолжает активно развиваться. В этом обзоре мы постарались кратко осветить основные изменения, произошедшие с платформой за последние пару месяцев. Резюме:

  • Поддержка Ubuntu 24.04 и РЕД ОС 8.0: обеспечена совместимость с последними версиями операционных систем.

  • Поддержка NGINX Ingress Controller 1.10: включает поддержку HTTP/3 и обновления для GeoIP.

  • Параметр diskType для YandexClusterConfiguration: позволяет указывать тип диска статических узлов при использовании Yandex Cloud.

  • Отказоустойчивость egress gateway: введены ресурсы EgressGateway и EgressGatewayPolicy, что позволяет назначить группу узлов в качестве шлюзов для внешних запросов и автоматически перенаправлять их через новый активный узел в случае выхода из строя текущего.

  • Повышение отказоустойчивости с Fencing: автоматическая изоляция проблемных узлов, предотвращающая сбои и минимизирующая риск потери данных.

  • Новые метрики мониторинга: введены метрики для отслеживания состояния узлов в группах.

  • Поддержка Kubernetes 1.30: обновление позволяет использовать последние функции Kubernetes.

  • Deckhouse CLI для Windows: утилита командной строки теперь доступна для пользователей Windows, улучшая управление кластерами.

  • Метки лидера для подов оператора DKP: упрощает выполнение команд, позволяя определять лидера среди нескольких подов Deckhouse.

  • Замена Grafana 8 на Grafana 10: обеспечен плавный переход на новую версию с сохранением доступа к старой.

  • Поддержка аутентификации на основе токенов для vCloud Director: более безопасный способ аутентификации пользователей.

  • Прекращение развития модуля l2-load-balancer: его функции будут реализованы в модуле MetalLB.

  • Реализация новой ролевой модели доступа: она не использует ресурсы ClusterAuthorizationRule и AuthorizationRule. 

  • Добавление нового модуля deckhouse-tools: веб-интерфейс для скачивания утилиты Deckhouse CLI (d8) из кластера без интернета.

  • Возможность расширения планировщика внешними плагинами через вебхуки: позволяет увеличить потенциал планировщика и учитывать более сложные условия при планировании нагрузки в кластере.

Для знакомства с платформой Deckhouse рекомендуем изучить раздел «Быстрый старт» (доступен на русском и английском языках).

Полезные ссылки на ресурсы проекта:

P. S.

Читайте также в нашем блоге:

Комментарии (0)