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

Меня зовут Дайшо Като, я учусь на первом курсе магистратуры Высшей школы информационных наук и технологий Токийского университета.

Я участвовал в четырехнедельной стажировке в собственной команде разработчиков PaaS LINE Yahoo. В этом отчете я расскажу о теме «Достижение горизонтального масштабирования пользовательских контроллеров Kubernetes», над которой я работал во время стажировки.

фон

LINE Yahoo разрабатывает «LINE Yahoo Internal PaaS» как платформу для облегчения развертывания веб-приложений. Этот внутренний PaaS LINE Yahoo построен на Kubernetes, и просто применяя абстрактный манифест для разработчиков, можно запускать приложения и автоматически публиковать их для пользователей. Кроме того, мы централизованно предоставляем консоль управления, автоматическую передачу телеметрической информации, аутентификацию/авторизацию и управление конфиденциальной информацией посредством сотрудничества с секретным менеджером.

Многие сервисы LINE Yahoo работают на внутренней PaaS LINE Yahoo, и это очень крупномасштабная среда с более чем 10 000 узлов и 100 000 модулей. Таким образом, внутренняя PaaS LINE Yahoo состоит из платформы, которая объединяет несколько кластеров Kubernetes: кластер приложений (кластер, где фактически запускается приложение) и кластер управления, который их контролирует.

Для получения подробной информации,Проблемы и уроки, извлеченные из реализации сверхкрупномасштабной платформы LINE Yahoo!Пожалуйста, обратитесь к

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

Во время этой стажировки я работал над тем, чтобы сделать возможным горизонтальное масштабирование для этого специального контроллера.

Шардинг контроллера Kubernetes

Шардинг контроллера Kubernetes — это OSS (программное обеспечение с открытым исходным кодом), разработанное на основе магистерских исследований Тима Эберта и также анонсированное на KubeCon Europe в 2025 году (ссылка: За пределами ограничений: горизонтальное масштабирование контроллеров Kubernetes — Тим Эберт, STACKIT). Основная идея этого механизма — пометить управляемые ресурсы ответственным контроллером, что позволит контроллерам масштабироваться горизонтально, избегая при этом конфликтов.

Однако было сложно напрямую внедрить сегментирование контроллера Kubernetes во внутреннюю PaaS LINE Yahoo. Причина кроется в способе генерации хеш-ключей, используемых для маркировки. Этот механизм использует хэш-ключи и аренду настраиваемых контроллеров для расчета согласованного хеширования и маркирует ресурсы на основе результатов вычислений. Родительские и дочерние ресурсы должны иметь один и тот же хеш-ключ, чтобы иметь одну и ту же метку. Для получения этого хеш-ключа используется комбинация пространства имен родительского ресурса, GVK (набор группы, версии и типа для различения ресурсов Kubernetes) и имени ресурса. С другой стороны, дочерний ресурс имеет ссылку OwnerReference на своего родителя (для справки:Владельцы и зависимые лица — Kubernetes) используется для получения того же ключа.

Однако если у вас есть структура ресурса с тремя или более поколениями, один и тот же хэш-ключ не может быть назначен дочерним ресурсам, поскольку они не имеют прямой ссылки владельца на родительский ресурс.