Управление несколькими кластерами Kubernetes с помощью Git

Одним из ключевых решений для тех компаний, которые используют облачную архитектуру, является управление несколькими кластерами Kubernetes. Чаще всего выбор разработчиков падает на GitHub, что объясняется популярностью этой площадки и тем, что она знакома большинству ИТ-специалистов. Однако если вам нужно обеспечить по-настоящему эффективное управление несколькими кластерами Kubernetes, лучше остановить свой выбор на главном конкуренте — GitLab. И сейчас мы расскажем, почему GitLab лучше подходит для этой задачи.

В статье сосредоточим внимание на оптимизации управления кластерами через GitLab и объясним, с помощью каких инструментов можно обеспечить соблюдение структуры и улучшить взаимодействие кластеров через иерархические группы. Также рассмотрим преимущества инкапсуляции кода CI/CD, что достигается благодаря широким возможностям шаблонов GitLab.

GitLab vs GitHub

Оба этих инструмента DevOps предлагают множество полезных функций для взаимодействия с функционалом Kube, однако GitLab — лучшее решение, если мы говорим об управлении несколькими кластерами Kubernetes. GitLab обеспечивает эффективное управление манифестами в репозиториях Git, позволяя структурировать их в мультиоблачной среде.

Главное преимущество GitLab в данном случае заключается в оптимальной иерархической структуре, позволяющей определять неограниченное количество групп. В свою очередь, GitHub накладывает целый ряд ограничений, которые не дают возможности определять иерархические группы вовсе. Именно поэтому для решения мультиоблачных задач стоит выбирать именно GitLab. Теперь расскажем пошагово о том, как это делать.

Шаг 1. Подготовка

Перед тем как работать с GitLab на нашем сервере, нужно развернуть и настроить его. Для этого мы написали подробную статью по установке и настройке. При этом стоит учесть, что минимальные требования для нормальной работы GitLab на сервере (4 Гб ОЗУ и 4 ядра) могут быть увеличены в зависимости от нагрузки на поддерживаемые кластеры.

Шаг 2. Создаем иерархические группы

GitLab позволяет определять группы внутри других групп, наследуя все переменные среды родительских групп. Для этого нужно сначала определить файл Kubeconfig в родительской группе, после чего можно использовать переменные среды во всех связанных проектах. В качестве примера рассмотрим 3 кластера Kubernetes в разных средах, таких как Timeweb Cloud, Google Cloud и Azure. Сначала создаем группу и иерархию проектов.

Каждая группа представляет определенный кластер Kubernetes, и во всех наборах есть файлы манифеста, связанные с конкретными проектами. Например, мы можем создать проект с именем api-gateway в группе twc-pl-1. Таким образом, манифесты в рамках проекта будут предназначены для развертывания в нашем кластере Kubernetes (twc, то есть в облачной инфраструктуре Timeweb.Cloud), расположенном в регионе pl-1 (регион взят для примера, он может быть и другим).

Также добавим, что для просмотра кластеров Kubernetes на уровне группы, на левой боковой панели нужно выбрать Search или go to. И после этого выбираем Operate > Kubernetes.

Шаг 3. Помещаем KubeConfig в переменные среды на уровне групп

Каждому проекту в группе GitLab можно настроить доступы к общим переменным среды, установленным как в родительской группе, так и на более высоких уровнях. Для этого нужно правильно настроить конфигурационный файл Kubeconfig, в котором прописаны учетные данные для подключения к серверу API Kubernetes. Это делается в настройках группы по следующему пути: Group Name -> CI/CD Settings -> Variables -> Add Variable. Пример:

^{Источник изображения: itnext.io}

Таким образом, нам нужно поместить файлы Kubeconfig всех наших кластеров Kubernetes в те группы, которые соотносятся с ними.

Шаг 4. Разворачиваем приложение с помощью GitLab CI

Теперь внутри каждого проекта создадим файлы манифеста и развернем их с помощью конвейера GitLab CI. Вот как это делается (на нашем примере api-gateway в группе twc-pl-1):

.
├── gitlab-ci.yml
└── manifests
   ├── configmap.yaml
   ├── deployment.yaml
   └── service.yaml

Свои манифесты внутри файла gitlab-ci.yml можно развернуть таким образом:

stages:
 - deploy

deploy:
 stage: deploy
 image: bitnami/kubectl
 script: |
   for f in manifests/*
   do
       kubectl apply -f $f
   done

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

Шаг 5. Назначаем доступы

Разумеется, GitLab позволяет делегировать управление своими группами и проектами и членам команды, причем сделать это можно в соответствии с иерархией. При назначении доступа на уровне группы все проекты в группе будут наследовать единую модель доступа, что очень удобно, так как исключает изменение настроек доступа для каждого проекта. Вот как выглядит предоставление доступа уровня Maintainer для всех проектов внутри группы:

^{Источник изображения: itnext.io}

Шаг 6. Инкапсулируем код CI/CD

Здесь для нас очень полезной оказывается функция создания шаблонов — еще один козырь GitLab в сравнении с главным конкурентом. Определяем общий шаблон для своего конвейера и включаем его везде, где нужно. Теперь, если нам понадобится изменить код, внесение изменений будет глобальным, а не в каждый отдельный проект.

Для инкапсулирования кода CI/CD создаем проект для его хранения, после чего включаем его в другие проекты. Внутри проекта шаблона должен находиться файл install.yml с содержимым, соответствующим содержимому файла gitlab-ci.yml (см. пример кода в шаге 3). Теперь обновляем все наши проекты и помещаем обновленные данные в файл gitlab-ci.yml, вот так:

include:
 - project: 'cd/template'
   ref: 'main'
   file: 'install.yml'

Вот и всё, на этом настройку группы кластеров Kubernetes можно считать завершенной.

Заключение

Подведем итог. Мы научились создавать иерархические группы в GitLab, настраивать KubeConfig на уровне групп, развертывать приложение с помощью GitLab CI, назначать доступы пользователям и инкапсулировать код CI/CD для автоматизации управления проектом. Также теперь вы знаете, почему GitLab подходит для этих задач лучше, чем GitHub.