Заглядываем под капот OpenShift и разгадываем секрет репозитория Origin

Если вы работали с OpenShift или ставили его бесплатную дистрибуцию OKD, репозиторий openshift/origin вам точно попадался. В эпохи OpenShift 3 и ранних релизов 4.x именно здесь находилось ядро всей платформы. Разработчики склонировали сюда огромную часть кодовой базы Kubernetes и поверх строили свои компоненты.

Но если зайти в этот репозиторий сегодня, прежней структуры вы там не увидите. Нет привычных файлов контроллеров, нет исходников бинарника hyperkube. Куда всё делось и зачем Red Hat хранит проект с почти девятью тысячами звёзд?

Куда исчез исходный код OpenShift

Летом 2020 года, перед выходом релиза OpenShift 4.6, команда разработки провела реорганизацию. Монолитный подход стал мешать: синхронизировать изменения с апстримом Kubernetes в одном месте с собственными тестами стало слишком сложно.

В итоге кодовую базу разделили:

• Вся работа с форком Kubernetes и сборкой бинарников вроде hyperkube переехала в репозиторий openshift/kubernetes.
• Репозиторий openshift/origin превратили в специализированный тестовый хаб.

Сейчас главная задача Origin — быть домом для бинарника openshift-tests и набора e2e-сценариев, которые проверяют соответствие кластера стандартам OpenShift и Kubernetes.

Как устроено сквозное тестирование в openshift-tests

Сборка тестов в проекте не имеет ничего общего с обычным прогоном go test. Здесь собирается полноценный бинарник openshift-tests, внутри которого упакованы сотни интеграционных и e2e-сценариев.

У команды OpenShift есть жесткое правило к написанию e2e-тестов. Два разных теста не должны дублировать функциональность друг друга более чем на 10%. Забудьте про скрупулёзную проверку каждой ошибки валидации в API. Задача этих тестов — пройти реальный путь пользователя от начала до конца: развернуть приложение, проверить работу сетевых политик, убедиться в корректности роутинга и собрать метрики.

Скомпилировать тестовый инструмент можно одной командой из корня проекта:

make

Полученный бинарник умеет запускать как стандартные conformance-тесты Kubernetes, так и узкоспециализированные проверки для компонентов Red Hat.

Селекторы окружения вместо аннотаций

Раньше, чтобы пропустить несовместимый тест на определенной конфигурации кластера, инженеры навешивали аннотации прямо в Go-коде. Это порождало хаос при обновлениях.

В современных ветках Origin от аннотаций избавились. Теперь фильтрацией управляют так называемые селекторы окружения (environment selectors). Фреймворк перед запуском смотрит на параметры целевого кластера (например, тип сетевого провайдера или облачную платформу) и на лету отсекает не подходящие тесты.

Логику исключений разделили на два уровня:

• Исключения для стандартных тестов Kubernetes находятся в openshift/kubernetes в файлах environment_selectors.go и disabled_tests.go.
• Правила для специфичных тестов OpenShift живут прямо в Origin в каталоге pkg/test/extensions.

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

Синхронизация зависимостей и грабли с Go checksum

Так как origin зависит от форка openshift/kubernetes, разработчикам приходится постоянно обновлять Go-модули. Чтобы не делать это вручную, в проект добавили скрипт hack/update-kube-vendor.sh.

Запустить обновление вендоринга под конкретную ветку или SHA-коммит можно так:

./hack/update-kube-vendor.sh master

Скрипт умеет подтягивать изменения даже из невлитых пулл-реквестов. Для этого вторым аргументом передают адрес своего форка:

./hack/update-kube-vendor.sh my-feature-branch github.com/myname/kubernetes

При работе с этим скриптом легко поймать неприятную ошибку. Прокси-сервер контрольных сумм Go (sum.golang.org) иногда возвращает 410 Gone, если коммит был создан только что и база сумм еще не успела его проиндексировать.

Выглядит это так:

go: k8s.io/kubernetes@v1.21.1 ... 410 Gone
        server response: not found

Решение здесь простое — принудительно отключить проверку базы сумм на время обновления вендоров:

GOSUMDB=off hack/update-kube-vendor.sh master

Быстрый запуск внешних примеров

Помимо тестов в репозитории остался полезный скрипт hack/update-external-example.sh. Он скачивает актуальные манифесты приложений и быстрые старты из сторонних репозиториев экосистемы и складывает их в папку examples.

Если вам нужны заведомо рабочие примеры Deployment, Route или StatefulSet для OpenShift, имеет смысл заглянуть в папку examples/quickstarts — там содержатся проверенные конфигурации.

Кому полезен репозиторий Origin сегодня

Если вы просто эксплуатируете кластер OpenShift, залезать в код Origin каждый день не потребуется. Но проект станет отличным подспорьем в трех случаях:

• Вы пишете собственные операторы или расширения платформы и хотите гонять официальные e2e-проверки в своем CI/CD pipeline.
• Вы участвуете в разработке OKD или отлаживаете кастомную сборку Kubernetes под специфическое железо.
• Вы хотите посмотреть, как устроена архитектура тестирования распределенных систем на Go в масштабных коммерческих проектах.

Репозиторий открыт под лицензией Apache 2.0, активное сообщество поддерживает ветки под все актуальные версии платформы.