[Перевод] Kubernetes становится вендоронезависимым после изменения 1,5 млн. строк кода
В июле 2024 вышла версия Kubernetes 1.31, в которой были окончательно устранены встроенные интеграции облачных провайдеров.
Начиная с версии Kubernetes v1.7, проект Kubernetes преследовал амбициозную цель удаления встроенных интеграций облачных провайдеров (KEP-2395). Хотя эти интеграции сыграли важную роль в раннем развитии и росте Kubernetes, их удаление было обусловлено двумя ключевыми факторами: растущей сложностью поддержания собственной поддержки для каждого облачного провайдера в миллионах строк кода Go и желанием сделать Kubernetes по-настоящему независимой от поставщика платформой.
После многих релизов, все интеграции облачных провайдеров были успешно перенесены из основного репозитория Kubernetes во внешние плагины. В дополнение к достижению первоначальных целей, удалось значительно оптимизировать Kubernetes, удалив около 1,5 миллионов строк кода и уменьшив двоичные размеры основных компонентов примерно на 40%.
Эта миграция была сложной и длительной из-за многочисленных затронутых компонентов и критических путей кода, которые полагались на встроенные интеграции для пяти первоначальных поставщиков облачных услуг: Google Cloud, AWS, Azure, OpenStack и vSphere. Для успешного завершения этой миграции пришлось построить четыре новые подсистемы с нуля:
Менеджер контроллера облака (KEP-2392)
Сетевой прокси-сервер API (KEP-1281)
Плагины поставщика учетных данных kubelet (KEP-2133)
Миграция хранилища для использования CSI (KEP-625)
Каждая подсистема имела решающее значение для достижения полного паритета функций со встроенными возможностями и требовала нескольких релизов для доведения каждой подсистемы до уровня зрелости с безопасным и надежным путем миграции. Подробнее о каждой подсистеме ниже.
Менеджер облачного контроллера
Cloud Controller Manager был первым внешним компонентом, представленным в этой работе. Требовалось заменить функциональность в kube-controller-manager и kubelet, которая напрямую взаимодействовала с облачными API. Этот важный компонент отвечает за инициализацию узлов путем применения меток метаданных, которые указывают облачный регион и зону, в которых работает узел, а также IP-адреса, известные только поставщику облачных услуг. Кроме того, он запускает контроллер служб, который отвечает за предоставление облачных балансировщиков нагрузки для служб типа LoadBalancer.
Чтобы узнать больше, можно ознакомиться с разделом Cloud Controller Manager в документации Kubernetes.
API server network proxy
Проект API Server Network Proxy, начатый в 2018 году в сотрудничестве с SIG API Machinery, был направлен на замену функциональности туннелера SSH в kube-apiserver. Этот туннелер использовался для безопасного проксирования трафика между плоскостью управления Kubernetes и узлами, но он в значительной степени полагался на детали реализации провайдера, встроенные в kube-apiserver, для установки этих туннелей SSH.
Теперь API Server Network Proxy — это точка расширения уровня GA в kube-apiserver. Он предлагает универсальный механизм проксирования, который может направлять трафик с сервера API на узлы через защищенный прокси-сервер, устраняя необходимость для сервера API знать о конкретном поставщике облачных услуг, на котором он работает. Этот проект также представил проект Konnectivity, который все чаще внедряется в производственных средах.
Дополнительную информацию о сетевом прокси-сервере API можно найти в файле README .
Плагины поставщика учетных данных для kubelet
Плагин поставщика учетных данных Kubelet был разработан для замены встроенной функциональности kubelet для динамического извлечения учетных данных для реестров образов, размещенных в Google Cloud, AWS или Azure. Устаревшая возможность была удобна, поскольку позволяла kubelet беспрепятственно извлекать краткосрочные токены для извлечения образов из GCR, ECR или ACR. Однако, как и в других областях Kubernetes, поддержка этого требовала от kubelet определенных знаний о различных облачных средах и API.
Представленный в 2019 году механизм плагина поставщика учетных данных предлагает общую точку расширения для kubelet для выполнения двоичных файлов плагина, которые динамически предоставляют учетные данные для изображений, размещенных в различных облаках. Эта расширяемость расширяет возможности kubelet по извлечению краткосрочных токенов за пределы первоначальных трех облачных поставщиков.
Чтобы узнать больше, можно ознакомиться со статьей «Поставщик учетных данных Kubelet для аутентифицированных извлечений образов».
Миграция плагина хранилища из in-tree в CSI
Интерфейс хранилища контейнеров (CSI) — это стандарт плоскости управления для управления системами хранения блоков и файлов в Kubernetes и других оркестраторах контейнеров, который стал общедоступным в версии 1.13. Он был разработан для замены встроенных в дерево плагинов томов, встроенных непосредственно в Kubernetes, на драйверы, которые могут работать как Pod в кластере Kubernetes. Эти драйверы взаимодействуют с контроллерами хранения kube-controller-manager через API Kubernetes и с kubelet через локальную конечную точку gRPC. Теперь доступно более 100 драйверов CSI для всех основных поставщиков облачных решений и хранилищ, что делает рабочие нагрузки с отслеживанием состояния в Kubernetes реальностью.
Однако оставалась серьезная проблема в том, как справиться со всеми существующими API in-tree томов. Чтобы сохранить обратную совместимость API, в контроллеры был встроен слой трансляции API, который преобразует API томов в дереве в эквивалентный API CSI. Это позволило перенаправить все операции хранения на драйвер CSI, открыв для нас возможность удалить код для встроенных плагинов томов без удаления API.
Подробнее о миграции In-tree Storage можно узнать в статье Kubernetes In-Tree to CSI Volume Migration Moves to Beta.
Что дальше?
Эта миграция была основным фокусом для SIG Cloud Provider в течение последних нескольких лет. Достигнув этой важной вехи, усилия сообщества будут направлены на изучение новых и инновационных способов лучшей интеграции Kubernetes с поставщиками облачных услуг, используя внешние подсистемы, которые были созданы за эти годы. Это включает в себя повышение интеллекта Kubernetes в гибридных средах, где узлы в кластере могут работать как в публичных, так и в частных облаках, а также предоставление лучших инструментов и фреймворков для разработчиков внешних поставщиков для упрощения и оптимизации их усилий по интеграции.
При всех планируемых новых функциях, инструментах и фреймворках SIG Cloud Provider не забывает и о другой стороне уравнения: тестировании. Еще одной областью, на которой будет сосредоточена будущая деятельность SIG, является улучшение тестирования контроллеров облака для включения большего количества провайдеров. Конечной целью этих усилий является создание фреймворка тестирования, который будет включать как можно больше провайдеров, чтобы мы дали сообществу Kubernetes наивысший уровень уверенности в их средах Kubernetes.
Начиная с v1.31, облачные провайдеры будут навсегда отключены и удалены из основных компонентов Kubernetes.
Если у вас несколько микросервисов и вы не хотите тратить время на настройку CI/CD, мониторинга и эксплуатации Kubernetes, попробуйте наше облако — Amvera Cloud. Amvera — это альтернатива managed Kubernetes. У нас вы сможете обновлять ваши сервисы через простые коммиты в Git и получите почти все преимущества Kubernetes, не задумываясь об администрировании, настройки CI/CD, мониторинга, алертинга и сопутствующих сервисов. Это выйдет намного дешевле, чем классический managed k8s. Kubernetes у нас внутри, но вы полностью абстрагированы от его администрирования, достаточно просто привязать к сервису ваш Git-репозиторий и обновлять приложения командой «git push amvera master».
А если у вас сложный проект и вам нужна помощь в построении инфраструктуры на основе Kubernetes, или просто консультация, пишите мне в телеграм (Кирилл Косолапов), либо оставьте контакт для связи на странице нашей DevOps-команды. За спрос денег не берем, если это небольшая консультация или что-то простое, поможем бесплатно. А если сложное — договоримся.
