Детальная информация

Работа посвящена разработке прототипа платформы канареечной по- ставки сервисов в кластере Kubernetes. В отличие от существующих промыш- ленных решений (Argo Rollouts, Flagger, средства сервисных сеток Istio и Linkerd), разработанная платформа не требует сервисной сетки и специализи- рованного сетевого шлюза, а распределение трафика реализуется на основе ручного управления стандартными объектами Endpoints и EndpointSlice. Это позволяет применять подход в учебных, исследовательских и небольших производственных кластерах, для которых развёртывание сервисной сетки нецелесообразно. Задачи, решённые в ходе работы: • Спроектировать пользовательский ресурс CanaryDeployment и определить его жизненный цикл в виде машины состояний с шестью фазами и перехо- дами, управляемыми результатами оценки качества. • Реализовать контроллер на основе фреймворка kopf, выполняющий идемпо- тентный цикл согласования желаемого и фактического состояния кластера и корректно восстанавливающийся после собственного перезапуска. • Реализовать механизм распределения трафика между стабильной и канаре- ечной версиями без использования сервисной сетки за счёт ручного управ- ления Endpoints и EndpointSlice сервиса без селектора, а также механизм плавного переключения версий через временное превышение числа подов, исключающий падение пропускной способности на переходных шагах. • Реализовать подсистему оценки качества с тремя взаимозаменяемыми про- вайдерами по архитектурному шаблону «стратегия»: прямой HTTP-опрос подов, запрос к источнику метрик, совместимому с Prometheus, и поиск шаблона в журналах работы приложения. • Подготовить воспроизводимый стенд на основе minikube, набор сценариев испытаний и автоматизированные скрипты запуска. В результате работы разработана платформа, состоящая из контрол- лера (контейнерный образ canary-controller), пользовательского ресурса CanaryDeployment, эмулятора источника метрик (fake-prometheus) и набора скриптов автоматизации. Платформа демонстрирует все основные сценарии канареечной поставки: пошаговое увеличение доли трафика на канареечной версии, автоматический промоушен при достижении целевой доли, автомати- ческий откат при деградации показателей качества. Корректность реализации проверена на пяти сценариях испытаний; механизм плавного переключения обеспечивает неизменное число готовых подов в наборе Endpoints на протя- жении всего процесса развёртывания, что подтверждается измерениями. Для достижения данных результатов в работе использовались следую- щие информационные технологии и программное обеспечение: платформа оркестрацииконтейнеровKubernetes;локальнаясредаminikube;языкпрограм- мирования Python (стандарт 3.11); фреймворк операторов kopf; клиентская библиотека kubernetes-python-client; средство контейнеризации Docker; язык описания конфигурации YAML; командная оболочка Bash; система контроля версий Git.

The work is devoted to the development of a prototype platform for canary service delivery in a Kubernetes cluster. Unlike existing industrial solutions (Argo Rollouts, Flagger, the native facilities of service meshes such as Istio and Linkerd), the developed platform does not require a service mesh or a specialised ingress controller. Traffic splitting is implemented through manual control of standard Endpoints and EndpointSlice objects. This makes the approach applicable to educational, research and small production clusters in which deploying a service mesh is not justified. The research set the following goals: • To design the CanaryDeployment custom resource and to specify its lifecycle as a state machine with six phases and transitions driven by the results of quality evaluation. • To implement a controller based on the kopf framework that performs an idem- potent reconciliation loop between the desired and actual states of the cluster and correctly recovers from its own restart. • To implement a mechanism for traffic distribution between the stable and canary versions without a service mesh, by direct management of Endpoints and End- pointSlice of a selectorless Service, and a graceful version-switching mechanism that temporarily exceeds the total number of pods in order to avoid throughput drops during transitions. • Toimplementaqualityevaluationsubsystemwiththreeinterchangeableproviders organised under the Strategy pattern: direct HTTP probing of pods, querying a Prometheus-compatible metrics source, and pattern matching in application logs. • To prepare a reproducible test bed based on minikube, a set of verification scenarios, and automated launch scripts. As a result of the work, a platform was developed that consists of a controller (container image canary-controller), the CanaryDeployment custom resource, an emulatorofametricssource(fake-prometheus),andasetofautomationscripts. The platform demonstrates all the main scenarios of canary delivery: stepwise increase of the canary traffic share, automatic promotion upon reaching the target share, and automatic rollback upon degradation of quality indicators. The correctness of the implementation has been verified on five test scenarios; the graceful switching mechanismkeepsthenumberofreadypodsintheEndpointssetconstantthroughout the entire deployment, which is confirmed by measurements. Toachievetheseresults, thefollowinginformationtechnologiesandsoftware were used: the Kubernetes container orchestration platform; the minikube local environment; the Python programming language (version 3.11); the kopf operators framework; the kubernetes-python-client library; the Docker containerisation tool; the YAML configuration description language; the Bash command shell; and the Git version control system.

• []Введение
• 1 []Задача автоматизации канареечнойпоставки релизов в Kubernetes
  • 1.1 Постановка задачи автоматизации поставки релизов
    • 1.1.1 Стратегии обновления и канареечный подход
    • 1.1.2 Декомпозиция задачи на независимые механизмы
  • 1.2 Обзор существующих систем канареечного развёртывания
    • 1.2.1 Контроллеры поверх сервисных сеток
    • 1.2.2 Сервисные сетки как самостоятельные решения
    • 1.2.3 Стандартные средства Kubernetes
    • 1.2.4 Самостоятельные разработки на основе CRD
    • 1.2.5 Обобщающие наблюдения
  • 1.3 Уточнённая постановка задачи и требования
• 2 []Архитектура и реализация платформыканареечной поставки
  • 2.1 Общая архитектура платформы и состав компонентов
  • 2.2 Модель пользовательского ресурса CanaryDeployment
  • 2.3 Цикл согласования и машина состояний контроллера
  • 2.4 Распределение трафика без сервисной сетки
  • 2.5 Плавное переключение версий через временное превышение числа подов
  • 2.6 Подсистема оценки качества канареечной версии
• 3 []Экспериментальная проверкаработоспособности платформы
  • 3.1 Воспроизводимый стенд на основе minikube
  • 3.2 Сценарии экспериментальной проверки
    • 3.2.1 Сценарий 1: успешное развёртывание
    • 3.2.2 Сценарий 2: мгновенный откат по HTTP-опросу
    • 3.2.3 Сценарий 3: отложенный откат
    • 3.2.4 Сценарий 4: откат по метрике источника, совместимого с Prometheus
    • 3.2.5 Сценарий 5: откат по содержимому журналов
  • 3.3 Результаты испытаний и анализ
  • 3.4 Сравнение разработанной платформы с внутренними решениями компании
• []Заключение
• []Список использованных источников