Дисциплины CI/CD и GitOps с поддержкой Azure Arc Kubernetes

  • Статья

В качестве облачной конструкции Kubernetes требует облачного подхода к развертыванию и операциям. При использовании GitOps вы объявляете требуемое состояние развертываний на основе приложений в файлах, хранящихся в репозиториях Git. У приложений есть объекты Kubernetes, которые должны выполняться, которые могут включать развертывания, горизонтальные автомасштабирование pod, службы и конфигурацию Карты. Операторы Kubernetes выполняются в кластерах и постоянно согласовывают состояние каждого кластера с требуемым состоянием, объявленным в репозитории Git. Эти операторы извлекает файлы из репозиториев Git и применяет требуемое состояние к кластерам. Операторы также постоянно гарантируют, что кластер остается в требуемом состоянии.

Реализация GitOps позволяет:

  • Улучшите общую видимость состояния и конфигурации кластера Kubernetes.
  • У вас простой журнал аудита и версии изменений в кластере с помощью журнала изменений Git, который показывает, кто вносил изменения, когда эти изменения были внесены, и почему.
  • Автоматическое исправление смещения, которое может произойти в кластере.
  • Откат конфигурации Kubernetes до предыдущей версии с помощью команд отката Git отменить изменения или Git. Повторное создание кластера для сценариев аварийного восстановления также становится быстрым и простым процессом, так как конфигурация требуемого кластера Kubernetes хранится в Git.
  • Повышение безопасности путем уменьшения количества учетных записей служб, необходимых для предоставления разрешений на развертывание в кластере.
  • Реализуйте конвейер CI/CD для развертывания приложений в кластере.

GitOps в Kubernetes с поддержкой Azure Arc использует расширение, которое реализует Flux, популярный набор инструментов с открытым кодом. Flux — это оператор, который автоматизирует развертывания конфигурации GitOps в кластере. Flux поддерживает распространенные источники файлов (репозитории Git, Helm, служба контейнеров) и типы шаблонов (YAML, Helm и Kustomize). Flux также поддерживает многотенантность и управление зависимостями развертывания среди других функций.

Архитектура

На следующих схемах показана концептуальная эталонная архитектура, которая выделяет подготовку установки расширения кластера Flux в кластере, процесс конфигурации GitOps для кластера Kubernetes с поддержкой Azure Arc и потока GitOps.

Процесс подготовки расширения кластера Flux версии 2:

Diagram that shows Flux extension installation.

Процесс настройки GitOps:

Diagram that shows how to configure GitOps.

Поток GitOps с обновлением приложения:

Diagram that shows a typical GitOps workflow.

Рекомендации по проектированию

Ознакомьтесь со следующими рекомендациями по проектированию при планировании реализации GitOps для Kubernetes с поддержкой Azure Arc.

Настройка

Рассмотрим различные уровни конфигурации в кластере Kubernetes и обязанности, связанные с их подготовкой.

Уровни конфигурации

  • Конфигурация приложения, необходимая для развертывания приложения и связанных объектов Kubernetes в кластере, таких как развертывание, служба, HPA и ресурсы ConfigMap. Конфигурации приложения обычно применяются к конфигурации GitOps на уровне пространства имен, требуя, чтобы компоненты приложения были настроены только в одном пространстве имен.
  • Конфигурация на уровне кластера для создания объектов Kubernetes, таких как Namespaces, ServiceAccounts, Roles и RoleBindings, а также другие политики на уровне кластера.
  • Компоненты на уровне кластера, такие как контроллер объекта ingress, стек мониторинга и безопасности, а также различные агенты, работающие в кластере.

Обязанности

  • Разработчики приложений отвечают за отправку исходного кода, активацию сборок и создание образов контейнеров.
  • Операторы приложений отвечают за обслуживание репозиториев приложений, конфигураций, переменных среды, диаграмм helm для конкретного приложения, Kustomizations и т. д.
  • Операторы кластера отвечают за установку базовых показателей кластера. Обычно они занимаются настройкой компонентов и политик на уровне кластера. Они обслуживают каталог репозитория Git или каталоги, содержащие общие инструменты инфраструктуры, такие как Namespaces, ServiceAccounts, RoleBindings, CRD, политики на уровне кластера, компоненты входящего трафика и т. д.

Структура репозитория

При выборе структуры репозитория Git рассмотрите возможность найти компромиссы. Выбранная структура будет определять состояние кластера Kubernetes, что включает в себя приложения и компоненты на уровне кластера. В зависимости от того, какие обязанности и роли вы определите, важно решить вопрос о необходимости совместной работы или желаемой независимости команды, требуемой для различных вариантов структуры репозитория.

Вы можете использовать любую стратегию ветвления, которую вы хотите использовать для репозиториев кода, так как она используется только процессом непрерывной интеграции (CI).

Для репозиториев конфигурации GitOps рассмотрите следующие стратегии, основанные на бизнес-потребностях, размере и инструментах вашей организации.

  • Один репозиторий (ветвь на среду):
    • Обеспечивает максимальную гибкость для управления политиками и разрешениями Git для каждой ветви, представляющей среду.
    • Недостаток заключается в том, что общий доступ к конфигурации между средами отсутствует, так как средства, такие как Kustomize , не работают с ветвями Git.
  • Один репозиторий (каталог на среду):
    • Этот подход можно реализовать с помощью таких средств, как Kustomize, что позволяет определить базовую конфигурацию для объектов Kubernetes и набор артефактов (т. е. исправлений) для вашей среды, переопределяющей конфигурации в базе.
    • Этот подход может уменьшить повторяющиеся файлы YAML для каждой среды, но также снижает разделение конфигурации между средами. Внесение одного изменения в репозиторий может повлиять на все среды одновременно, поэтому необходимо полностью осознавать влияние изменений в базовых каталогах и соблюдать осторожность.
  • Несколько репозиториев (каждый из которых служит определенной цели):
    • Это можно использовать для разделения репозиториев конфигурации для каждого приложения, команды, слоя или клиента.
    • Это позволяет командам иметь более независимый контроль, но отходить от принципа определения состояния системы в одном репозитории, чтобы улучшить центральную конфигурацию, видимость и управление развертываниями в кластере.
    • При необходимости многопользовательской работы следует рассмотреть возможность настройки нескольких репозиториев. Существует управление доступом на основе ролей (RBAC) и встроенная система безопасности для ограничения конфигурации, которую может применить команда или клиент, назначенные конкретному репозиторию, например, разрешить развертывание только в определенных пространствах имен.

Дополнительные способы структурирования репозитория см. в Руководстве по Flux.

Конфигурация приложения и платформы

Операторы платформы и операторы приложений имеют несколько вариантов управления конфигурацией Kubernetes:

  • Необработанные файлы YAML Kubernetes, представляющие спецификации YAML для каждого объекта API Kubernetes, который развертывается, может работать хорошо для отдельных сред. Недостатком использования необработанных файлов YAML является то, что настройка становится сложной при начале внедрения нескольких сред, так как вам нужно затем дублировать файлы YAML и не существует хорошего метода повторного использования.
  • Helm — это средство управления пакетами для объектов Kubernetes. Это допустимый параметр Операторы кластеров могут использовать для установки сторонних приложений вне полки. Убедитесь, что вы не используете шаблон слишком сильно в качестве средства управления конфигурацией для внутренних приложений, так как это может стать сложным для управления по мере роста шаблонов.
    • При использовании Helm Flux включает контроллер Helm, который позволяет декларативно управлять выпусками Helm Chart с манифестами Kubernetes. Для управления этим процессом можно создать объект HelmRelease .
  • Kustomize — это собственное средство управления конфигурацией Kubernetes, которое предоставляет бесплатный шаблон способ настройки конфигурации приложения.
    • При использовании Kustomize Flux включает контроллер Kustomize, который специализируется на выполнении конвейеров непрерывной доставки для инфраструктуры и рабочих нагрузок, определенных с манифестами Kubernetes и собранным с помощью Kustomize. Для управления этим процессом можно создать объект Kustomization.
  • С поддержкой Azure Arc Kubernetes вместо того, чтобы управлять жизненным циклом и поддержкой компонентов самостоятельно, можно использовать список доступных расширений, управляемых корпорацией Майкрософт и поддерживаемых им. Эти расширения управляются с помощью Azure Resource Manager. Некоторые из этих расширений, таких как поставщик секретов Azure Key Vault, имеют открытый код альтернативные варианты. Управление компонентами за пределами процесса расширения обеспечивает более контроль над компонентами, но также требует больше накладных расходов на управление поддержкой и жизненным циклом.

Поток непрерывной интеграции и непрерывной доставки (CI/CD)

В следующих разделах приведены рекомендации по процессу обновления конвейера приложения и компонентов.

Конвейер приложений

  • Рассмотрим сборку, тестирование и проверку приложения, которые необходимо включить в процесс CI. Они могут включать в себя подстраивание и тестирование, связанные с безопасностью, интеграцией и производительностью, которая необходима для создания кандидата выпуска (RC) для развертываний среды.
  • Для мостового разрыва между образом контейнера сборки в конвейере CI и его развертыванием в кластере можно использовать традиционный метод принудительного развертывания, вызвав API Kubernetes непосредственно из конвейера развертывания.

Чтобы избежать изменений конфигурации вручную в репозитории GitOps, можно запустить конвейер CD в качестве учетной записи службы, которая имеет разрешение на открытие запросов на вытягивание (PR) или зафиксировать новый образ контейнера непосредственно в репозиторий конфигурации. Эти изменения также могут подготавливать все объекты YAML, необходимые для приложения.

На следующей схеме процесса показан традиционный процесс CI приложения, включенный в изменения, поддерживающие GitOps.

Diagram that shows the standard GitOps process.

Процесс обновления компонентов на уровне кластера

  • Операторы кластеров должны управлять компонентами на уровне кластера, поэтому это, скорее всего, не будет исходить из конвейера CD, используемого для развертывания приложений и служб. Рассмотрите возможность определения процесса продвижения, конкретного для операторов кластера, чтобы обеспечить возможность плавного перехода с одной среды на другую.
  • Если необходимо применить идентичную конфигурацию GitOps в масштабе к кластерам Kubernetes с поддержкой Azure Arc, рассмотрите возможность применения Политика Azure, которая может автоматически установить расширение Flux и применить конфигурацию GitOps к существующим кластерам Kubernetes с поддержкой Azure Arc или новым кластерам при подключении к Azure Arc.

При обновлении конфигурации, скорее всего, необходимо убедиться, что изменения были успешно применены к требуемой среде. Вы можете определить уведомления в Flux для интеграции с инструментами CI/CD, электронной почтой или средствами ChatOps и автоматически отправлять оповещения об успешных изменениях и сбоях развертывания. Вы также можете найти сведения о состоянии развертывания в портал Azure и с помощью интерфейса командной строки конфигурации k8s и API ARM.

Вопросы безопасности

Ознакомьтесь со следующими соображениями безопасности при планировании реализации GitOps для Kubernetes с поддержкой Azure Arc.

Проверка подлинности репозитория

  • Вы можете использовать общедоступный или частный репозиторий Git с GitOps, но из-за конфиденциальной природы конфигураций Kubernetes рекомендуется использовать частный репозиторий, требующий проверки подлинности по ключу SSH или ключу API. GitOps также работает с репозиториями Git, которые доступны только в частной сети, пока кластер Kubernetes может получить к нему доступ, но эта настройка ограничивает возможность использования облачных поставщиков Git, таких как Azure Repos или GitHub.
  • Протоколы HTTPS и SSH предлагают надежное и безопасное подключение, который можно использовать для подключения к средству управления версиями. Однако HTTPS часто проще настроить и использует порт, который редко требует открытия дополнительных портов в брандмауэрах.

Безопасность репозитория и ветви

  • Задайте разрешения и политики ветви в репозитории конфигурации. Так как репозиторий Git становится центральным элементом развертываний Kubernetes, важно настроить разрешения для управления тем, кто может читать и обновлять код в ветви, а также реализовывать политики для обеспечения качества кода и управления изменениями команды. В противном случае рабочий процесс GitOps может отправлять код, который не соответствует стандартам вашей организации.
  • Конвейеры запросов на вытягивание (PR) могут работать с политиками ветви для проверки конфигурации YAML и (или) развертывания тестовых сред по мере необходимости. Шлюзы помогают устранить ошибки конфигурации и повысить безопасность развертывания и уверенность.
  • При назначении разрешений на доступ следует учитывать, какие пользователи в организации должны иметь доступ на чтение репозитория, доступ на создание pr и доступ на утверждение pr.

Управление секретами

  • Не сохраняйте в репозитории Git обычный текст или секреты в кодировке Base64. Вместо этого рекомендуется использовать внешний поставщик секретов, например Azure Key Vault. Поставщик Azure Key Vault для CSI Driver позволяет интегрировать хранилище ключей Azure в качестве хранилища секретов с кластером Служба Azure Kubernetes (AKS) с помощью тома CSI. Эта служба доступна через расширение Kubernetes с поддержкой Azure Arc. HashiCorp Vault — это сторонняя альтернатива управляемого поставщика секретов.
  • Другим альтернативным способом управления секретами является использование запечатанных секретов Bitnami, которые работают из концепции открытых и закрытых ключей. Это позволяет операторам хранить односторонне зашифрованный секрет с помощью открытого ключа в Git, который можно расшифровать только с помощью закрытого ключа, который используется контроллером SealedSecrets, работающим в кластере.

Рекомендации по проектированию

Ознакомьтесь со следующими рекомендациями по проектированию при планировании реализации GitOps для Kubernetes с поддержкой Azure Arc.

На следующей схеме приведена эталонная архитектура, которая иллюстрирует обязанности, репозитории и конвейеры, необходимые для реализации процесса GitOps с помощью расширения Kubernetes с поддержкой Azure Arc.

Diagram that shows a GitOps Reference flow.

Репозитории

В проект включены три репозитория Git:

  • Репозиторий кода приложения
    • Этот репозиторий хранит код приложения и любые сценарии определения конвейера и конфигурации.
    • Используйте стратегию ветвления разработки, которую легко понять и ограничить количество нежелательных длительных ветвей.
  • Репозиторий конфигурации приложений
    • Этот репозиторий хранит конфигурации приложений, включая объекты Kubernetes, такие как Config Карты, Deployments, Services и HPA. Структурируйте этот репозиторий с различными каталогами для каждого приложения. Flux синхронизирует изменения из этого репозитория и целевой ветви в кластере.
    • Включите средства, упрощающие создание начальных конфигураций для разработчиков приложений и операторов для каждой среды. Операторы приложений должны определить конкретную конфигурацию приложения Kubernetes, которая использует диспетчеры пакетов, такие как Helm или средства конфигурации, такие как Kustomize, чтобы упростить настройку.
    • Создайте ветвь для представления каждого типа среды. Это позволяет точно контролировать изменения в каждой конкретной среде, например непрод и рабочих средах.
    • При развертывании приложения в определенном пространстве имен используйте функцию область пространства имен в конфигурации GitOps, чтобы применить конфигурацию только для определенного пространства имен.
  • Репозиторий конфигурации на уровне кластера
    • Определите компоненты на уровне кластера, такие как контроллер входящего трафика, пространства имен, RBAC, мониторинг и стек безопасности для управления операторами кластера. Flux синхронизирует изменения из этого репозитория и целевой ветви в кластер.
    • Структурируйте этот репозиторий с различными каталогами, представляющими различные компоненты.
    • Создайте ветвь для представления каждого типа среды. Это позволяет точно контролировать изменения в каждой конкретной среде, например непрод и рабочих средах.
    • Операторы кластеров должны использовать такие диспетчеры пакетов, как Helm или средства конфигурации, такие как наложения Kustomize, чтобы упростить настройку.

Процесс обновления CI/CD и конфигурации

Обновления образа CI/CD и контейнера

  • Конвейер CI
    • Команды разработчиков должны определить конвейер CI с помощью процесса, включающего сборку, подстраивание, тестирование и отправку приложения в реестр контейнеров.
  • Конвейер CD
    • Создайте конвейер CD, который запускает скрипт, предназначенный для изменений в репозитории конфигурации приложения. Этот скрипт создает временную ветвь, исходную из целевой среды, вносит изменения в версию тега изображения, фиксирует изменение и открывает запрос на вытягивание в целевой ветви среды. Этот конвейер CD может иметь этапы среды с соответствующими переменными среды для целевого репозитория и ветви конфигурации GitOps.
    • Определите этапы утверждения вручную для этапов среды, чтобы ограничить нежелательные запросы на вытягивание во всех средах.
  • Включите политики ветви в репозитории конфигурации приложения, чтобы применить одноранговую проверку или утверждения для сред. Это может включать минимальное количество обязательных проверок или автоматическое утверждение для более низких сред. Кроме того, следует учитывать сторонние интеграции и утверждения в соответствии со стандартами вашей организации.

Обновления конфигурации кластера и приложений

  • Операторы кластера и операторы приложений определяют конфигурацию в соответствующих репозиториях конфигурации. Для отправки конфигураций эти пользователи не требуют средства конвейера. Вместо этого они используют собственные процессы фиксации Git и PR для определения конфигурации и отправки изменений в ветвь, представляющую среду.
  • Для новых определений конфигурации сначала определите конфигурацию в более низких средах, например Dev, а затем повысить уровень сред с помощью слияний и запросов на вытягивание. При необходимости обновления конфигурации вишни, относящиеся к определенным средам.

Отзывы и оповещения

  • Настройте уведомления Flux для оповещения, если конфигурации GitOps не могут синхронизироваться или возникают ошибки. Операторы приложений должны настроить оповещения для определения успешного развертывания приложения и работоспособности. Операторы кластеров должны настроить оповещения, чтобы определить, когда сверка компонентов на уровне кластера завершилась сбоем, а также при возникновении проблем с синхронизацией с репозиторием Git.
  • Реализуйте GitOps Подключение or для интеграции обратной связи агента Flux с инструментами CI/CD.

Рекомендации по обеспечению безопасности

  • Ознакомьтесь с рекомендациями по управлению и безопасности для кластеров Kubernetes с поддержкой Azure Arc.
  • Избегайте нежелательного доступа к любой конфигурации кластера с помощью частного репозитория Git с проверкой подлинности и авторизацией, которую можно использовать для определения любого репозитория конфигурации.
  • Доступ к репозиторию Git через протокол SSH и ключ SSH, если поставщик Git поддерживает его. Если SSH недоступен из-за ограничений исходящего подключения или если поставщик Git не поддерживает необходимые библиотеки SSH, используйте выделенную учетную запись службы и свяжите ключ API с этой учетной записью для использования Flux. Если вам нужна альтернатива SSH при использовании GitHub, можно создать личный маркер доступа для проверки подлинности.
  • Настройте политики и разрешения филиалов, соответствующие обязанностям кластера. Задайте минимальное количество рецензентов для утверждения изменений.
  • Настройте конвейер PR для проверки конфигураций и синтаксиса YAML и при необходимости разверните тестовый кластер Kubernetes. Настройте политику ветви, требующую успешного выполнения этого конвейера перед принятием любого слияния.
  • Реализуйте секреты с помощью поставщика Azure Key Vault для драйвера CSI хранилища секретов, что позволит интегрировать Azure Key Vault в качестве хранилища секретов с кластером Kubernetes с поддержкой Azure Arc через том CSI.
  • Расширение Flux поддерживает конфигурации пространства имен и кластера область. Выберите пространство имен область, если конфигурация не должна иметь доступ за пределами одного пространства имен.

Следующие шаги

Дополнительные сведения о гибридном и многооблачном облаке см. в следующих статьях.