Следить за быстрым циклом выпуска новых версий Kubernetes — это серьезная задача, особенно для разработчиков платформ, которые используют Kubernetes в качестве основы для своих систем. Kubernetes выпускает новую версию примерно каждые три месяца, и каждая версия привносит новые функции, улучшения, а иногда и критические изменения, которые могут нарушить обратную совместимость.
Чтобы решить эту проблему, я решил создать переиспользуемый шаблон для сборки Kubernetes, используя сам Kubernetes в качестве фермы для сборки.
Мы будем собрать куб-в-кубе.
Этот шаблон, описанный в документации kube-buildx-farm.md, предоставляет структурированный способ настройки и управления фермой для сборки на основе Kubernetes.
https://github.com/avkcode/k8s-release
Особое внимание в нашем решении уделяется использованию buildx с драйвером Kubernetes. Этот подход позволяет эффективно распределять задачи сборки между узлами кластера, что значительно ускоряет процесс. Одним из ключевых преимуществ является встроенная поддержка кэширования. Buildx позволяет кэшировать слои образов и промежуточные результаты сборки, что особенно полезно при повторных сборках. Это может сократить время сборки на десятки процентов, так как не требуется пересобирать уже собранные и неизменившиеся компоненты.
В данной структуре проекта видно, что система легко расширяется за счет добавления новых Dockerfile для различных компонентов. Например, если требуется добавить поддержку нового компонента Kubernetes или стороннего инструмента, достаточно создать соответствующий Dockerfile в корне проекта. Это позволяет гибко настраивать и расширять сборку, не затрагивая основную логику работы фермы сборки.
config-local.toml: Конфигурационный файл для настройки кэша buildx.config-remote.toml: Конфигурационный файл для настройки кэша buildx.docker-compose.yml: Файл конфигурации Docker Compose, к нему подключены Dockerfileы с компонентами Kubernetes.Dockerfile.etcd: Dockerfile для сборки образа etcd, ключевого компонента Kubernetes.Dockerfile.kube-apiserver: Dockerfile для сборки образа API-сервера Kubernetes.Dockerfile.kube-controller-manager: Dockerfile для сборки образа менеджера контроллеров Kubernetes.Dockerfile.kube-proxy: Dockerfile для сборки образа kube-proxy, обеспечивающего сетевую маршрутизацию.Dockerfile.kube-scheduler: Dockerfile для сборки образа планировщика Kubernetes.Dockerfile.kubectl: Dockerfile для сборки образа CLI-инструмента kubectl.Dockerfile.kubelet: Dockerfile для сборки образа kubelet, отвечающего за работу узлов.kube-buildx-farm.md: Документация о настройке фермы Buildx билдеров Kubernetes.output: Директория для хранения выходных данных или артефактов сборки.registry.yaml: Конфигурационный файл для настройки реестра контейнеров, используемого для хранения собранных образов.
Каждый Dockerfile описывает этапы сборки и зависимости для конкретного компонента, что делает процесс модульным и легко управляемым. Например, если вы хотите добавить сборку для нового инструмента или сервиса, достаточно создать для него отдельный Dockerfile, и система автоматически интегрирует его в общий процесс сборки через Makefile или другие инструменты оркестрации.
Добавить раннер GitLab или Agent Jenkins к хосту на котором установлен Docker и buildx не должно составить большого труда.
Такой подход не только упрощает поддержку и расширение проекта, но и обеспечивает согласованность и воспроизводимость сборок для всех компонентов.
Таким образом, использование Kubernetes в качестве платформы для сборки не только упрощает поддержку актуальных версий, но и значительно ускоряет процесс за счет эффективного использования ресурсов и кэширования.