Изменить

Поделиться через

GitOps для Службы Azure Kubernetes

Служба Azure Kubernetes (AKS)
GitHub

GitOps — это набор принципов для работы и управления системой программного обеспечения. В этой статье описываются методы использования принципов GitOps для управления кластером Служба Azure Kubernetes (AKS).

Логотипы Flux, Argo CD, OPA Gatekeeper, Kubernetes и git являются товарными знаками своих соответствующих компаний. Никакое подтверждение не подразумевается использованием этих меток.

Архитектура

Два оператора GitOps, которые можно использовать с AKS, — Flux и Argo CD. Они оба являются выпускниками проектов Cloud Native Computing Foundation (CNCF) и широко используются. В следующих сценариях показаны способы их использования.

Сценарий 1. GitOps с Flux и AKS

Схема GitOps с Flux версии 2, GitHub и AKS.

Скачайте файл Visio для этой архитектуры.

Поток данных для сценария 1

Flux — это собственное расширение кластера в AKS. Расширения кластера предоставляют платформу для установки решений и управления ими в кластере AKS. Вы можете использовать скрипты портал Azure, Azure CLI или инфраструктуры как код (IaC), такие как скрипты Terraform или Bicep, чтобы включить Flux в качестве расширения в AKS. Вы также можете использовать Политика Azure для применения конфигураций Flux версии 2 в масштабе в кластерах AKS. Дополнительные сведения см. в статье "Развертывание приложений в масштабе с помощью конфигураций Flux версии 2 и Политика Azure".

Flux может развертывать манифесты Kubernetes, диаграммы Helm и файлы Kustomization в AKS. Flux — это процесс на основе опроса, поэтому он может обнаруживать, извлекать и согласовывать изменения конфигурации без предоставления конечных точек кластера агентам сборки.

В этом сценарии администраторы Kubernetes могут изменять объекты конфигурации Kubernetes, такие как секреты и ConfigMaps, и фиксировать изменения непосредственно в репозитории GitHub.

Поток данных для этого сценария:

  1. Разработчик фиксирует изменения конфигурации в репозитории GitHub.
  2. Flux обнаруживает смещение конфигурации в репозитории Git и извлекает изменения конфигурации.
  3. Flux согласовывает состояние в кластере Kubernetes.

Альтернативные варианты для сценария 1

  • Вы можете использовать Flux с другими репозиториями Git, такими как Azure DevOps, GitLab и BitBucket.
  • Вместо репозиториев Git API контейнера Flux определяет источник для создания артефакта для объектов из таких решений хранилища, как Amazon S3 и Google Cloud Storage. Вы также можете использовать решение, которое имеет API, совместимый с S3. Два примера: Minio и Alibaba Cloud OSS, но есть и другие.
  • Вы также можете настроить Flux для контейнера Хранилище BLOB-объектов Azure в качестве источника для создания артефактов. Дополнительные сведения см . в конфигурациях GitOps Flux версии 2 с AKS и Kubernetes с поддержкой Azure Arc.

Сценарий 2. Использование GitOps с Flux, GitHub и AKS для реализации CI/CD

Схема реализации CI/CD с помощью GitOps с Flux, GitHub и AKS.

Скачайте файл Visio для этой архитектуры.

Поток данных для сценария 2

Этот сценарий представляет собой конвейер DevOps на основе по запросу для типичного веб-приложения. Конвейер использует GitHub Actions для сборки. Для развертывания он использует Flux в качестве оператора GitOps для извлечения и синхронизации приложения. Данные передаются в сценарии следующим образом:

  1. Код приложения разрабатывается с помощью интегрированной среды разработки, например Visual Studio Code.
  2. Код приложения фиксируется в репозитории GitHub.
  3. GitHub Actions создает образ контейнера из кода приложения и отправляет образ контейнера в Реестр контейнеров Azure.
  4. GitHub Actions обновляет файл развертывания манифеста Kubernetes с текущей версией образа, основанной на номере версии образа контейнера в Реестр контейнеров Azure.
  5. Оператор Flux обнаруживает смещение конфигурации в репозитории Git и извлекает изменения конфигурации.
  6. Flux использует файлы манифеста для развертывания приложения в кластере AKS.

Сценарий 3. GitOps с Argo CD, репозиторием GitHub и AKS

Схема GitOps с Argo CD, GitHub и AKS.

Скачайте файл Visio для этой архитектуры.

Поток данных для сценария 3

В этом сценарии администратор Kubernetes может изменить объекты конфигурации Kubernetes, такие как секреты и ConfigMaps, и зафиксировать изменения непосредственно в репозитории GitHub.

Поток данных для этого сценария:

  1. Администратор Kubernetes вносит изменения в конфигурацию файлов YAML и фиксирует изменения в репозитории GitHub.
  2. Argo CD извлекает изменения из репозитория Git.
  3. Argo CD согласовывает изменения конфигурации в кластере AKS.

Argo CD не должен автоматически синхронизировать требуемое целевое состояние с кластером AKS. Он реализуется как контроллер Kubernetes, который постоянно отслеживает запущенные приложения. Он сравнивает текущее динамическое состояние кластера AKS с требуемым целевым состоянием, указанным в репозитории Git. Argo CD сообщает и визуализирует различия, предоставляя средства для автоматической или ручной синхронизации динамического состояния обратно с нужным целевым состоянием.

Argo CD предоставляет пользовательский интерфейс на основе браузера. Его можно использовать для добавления конфигураций приложений, наблюдения за состоянием синхронизации относительно кластера и инициировать синхронизацию с кластером. Для выполнения этих действий можно также использовать командную строку Argo CD. Пользовательский интерфейс и интерфейс командной строки предоставляют функции для просмотра журнала изменений конфигурации и отката к предыдущей версии.

По умолчанию пользовательский интерфейс Argo CD и сервер API не предоставляются. Для доступа к ним рекомендуется создать контроллер входящего трафика с внутренним IP-адресом. Кроме того, вы можете использовать внутреннюю подсистему балансировки нагрузки для их предоставления.

Альтернативные варианты для сценария 3

Любой репозиторий, совместимый с Git, включая Azure DevOps, может служить в качестве исходного репозитория конфигурации.

Сценарий 4. Использование GitOps с Argo CD, GitHub Actions и AKS для реализации CI/CD

Схема реализации CI/CD с помощью GitOps с Argo CD, GitHub и AKS.

Скачайте файл Visio для этой архитектуры.

Поток данных для сценария 4

Этот сценарий представляет собой конвейер DevOps на основе по запросу для типичного веб-приложения. Конвейер использует GitHub Actions для сборки. Для развертывания он использует Argo CD в качестве оператора GitOps для извлечения и синхронизации приложения. Данные передаются в сценарии следующим образом:

  1. Код приложения разрабатывается с помощью интегрированной среды разработки, например Visual Studio Code.
  2. Код приложения фиксируется в репозитории GitHub.
  3. GitHub Actions создает образ контейнера из кода приложения и отправляет образ контейнера в Реестр контейнеров Azure.
  4. GitHub Actions обновляет файл развертывания манифеста Kubernetes с текущей версией образа, основанной на номере версии образа контейнера в Реестр контейнеров Azure.
  5. Argo CD извлекает из репозитория Git.
  6. Argo CD развертывает приложение в кластере AKS.

Альтернативные варианты для сценария 4

Любой репозиторий, совместимый с Git, включая Azure DevOps, может служить в качестве исходного репозитория конфигурации.

Подробности сценария

GitOps — это набор принципов для работы и управления системой программного обеспечения.

  • Он использует управление версиями в качестве единственного источника истины для системы.
  • Она применяет такие методики разработки, как управление версиями, совместная работа, соответствие требованиям и непрерывная интеграция и непрерывное развертывание (CI/CD) к автоматизации инфраструктуры.
  • Его можно применить к любой программной системе.

GitOps часто используется для управления кластерами Kubernetes и доставки приложений. В этой статье описаны некоторые распространенные варианты использования GitOps вместе с кластером AKS.

Согласно принципам GitOps, требуемое состояние управляемой системой GitOps должно быть следующим:

  1. Декларативный: система, управляющая GitOps, должна иметь требуемое состояние, выраженное декларативно. Объявление обычно хранится в репозитории Git.
  2. Версия и неизменяемая: требуемое состояние хранится таким образом, чтобы обеспечить неизменяемость и управление версиями, а также сохраняет полный журнал версий.
  3. Вытягивание автоматически: агенты программного обеспечения автоматически извлекает требуемые объявления состояния из источника.
  4. Непрерывно согласовано: агенты программного обеспечения постоянно отслеживают фактическое состояние системы и пытаются применить требуемое состояние.

В GitOps инфраструктура как код (IaC) использует код для объявления требуемого состояния компонентов инфраструктуры, таких как виртуальные машины, сети и брандмауэры. Этот код поддерживает управление версиями и подлежит аудиту.

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

Агенты GitOps непрерывно согласовывают состояние системы с требуемым состоянием, хранящимся в репозитории кода. Некоторые агенты GitOps могут вернуть операции, выполняемые за пределами кластера, такие как ручное создание объектов Kubernetes. Контроллеры допуска, например, применяют политики к объектам во время создания, обновления и удаления операций. Их можно использовать, чтобы обеспечить изменение развертываний только в том случае, если код развертывания в исходном репозитории изменяется.

Вы можете объединить средства управления политиками и принудительного применения с GitOps для применения политик и предоставления отзывов о предлагаемых изменениях политики. Вы можете настроить уведомления для различных команд, чтобы предоставить им актуальное состояние GitOps. Например, можно отправлять уведомления об успешном развертывании и сбоях выверки.

GitOps в качестве единственного источника истины

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

Если вы хотите применить только GitOps к состоянию кластера, можно ограничить прямой доступ к кластеру. Это можно сделать различными способами, включая управление доступом на основе ролей Azure (RBAC), контроллеры допуска и другие средства.

Использование GitOps для начальной настройки начальной загрузки

Возможно, потребуется развернуть кластеры AKS в рамках базовой конфигурации. Например, перед развертыванием рабочих нагрузок необходимо развернуть набор общих служб или конфигурацию. Эти общие службы могут настраивать надстройки AKS, такие как:

Вы можете включить Flux в качестве расширения, применяемого при создании кластера AKS. Затем Flux может загрузить базовую конфигурацию кластера. Базовая архитектура кластера AKS предлагает использовать GitOps для начальной загрузки. Если вы используете расширение Flux, вы можете загрузить кластеры в ближайшее время после развертывания.

Другие средства и надстройки GitOps

Описанные сценарии можно расширить на другие средства GitOps. Jenkins X — это другое средство GitOps, которое предоставляет инструкции по интеграции с Azure. Для постепенного перемещения рабочих нагрузок, развернутых с помощью GitOps, можно использовать прогрессивные средства доставки, такие как Flagger .

Потенциальные варианты использования

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

GitOps защищает разработчика от сложностей управления средой контейнера. Разработчики могут продолжать работать с знакомыми инструментами, такими как Git для управления обновлениями и новыми функциями. Таким образом, GitOps повышает производительность разработчиков.

Рекомендации

Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая представляет собой набор руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.

Надежность

Надежность гарантирует, что ваше приложение может выполнять обязательства, которые вы выполняете вашим клиентам. Дополнительные сведения см. в разделе "Обзор основы надежности".

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

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и злоупотребления ценными данными и системами. Дополнительные сведения см. в разделе "Общие сведения о компоненте безопасности".

В рамках подхода GitOps отдельные разработчики и администраторы не обращаются напрямую к кластерам Kubernetes для применения изменений или обновлений. Вместо этого пользователи помещают изменения в репозиторий Git, а оператор GitOps (Flux или Argo CD) считывает изменения и применяет их к кластеру. Этот подход соответствует принципу минимальных привилегий, так как группам DevOps не предоставляются разрешения на запись в API Kubernetes. В сценариях диагностики и устранения неполадок разрешения на доступ к кластеру могут быть предоставлены на ограниченное время в каждом конкретном случае.

Помимо настройки разрешений на доступ к репозиторию, вы также можете реализовать следующие меры безопасности в репозиториях Git, которые синхронизируются с кластерами AKS:

  • Защита ветвей. Защитите ветви, которые представляют состояние кластеров Kubernetes, от непосредственной отправки в них изменений. Используйте PR для внесения изменений и по крайней мере один другой пользователь просматривает каждый PR. Кроме того, используйте PRs для автоматической проверки.
  • Проверка запроса на извлечение. У запроса на извлечение должен быть хотя один проверяющий, чтобы обеспечить соблюдение принципа двойной проверки. Вы также можете использовать функцию владельцев кода GitHub, позволяющую назначить отдельных пользователей или группы, которые отвечают за проверку определенных файлов в репозитории.
  • Неизменяемый журнал. Можно разрешить только новые фиксации поверх существующих изменений. Неизменяемый журнал особенно важен для аудита.
  • Дополнительные меры безопасности: требуется, чтобы пользователи GitHub активировали двухфакторную проверку подлинности. Кроме того, разрешать только фиксации, подписанные, чтобы предотвратить изменения.

Оптимизация затрат

Оптимизация затрат заключается в поиске способов уменьшения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в разделе Обзор критерия "Оптимизация затрат".

  • На бесплатном уровне AKS предлагает бесплатное управление кластерами. Затраты ограничены вычислительными, хранилищами и сетевыми ресурсами, которые AKS использует для размещения узлов.
  • Служба GitHub предлагается бесплатно, однако для использования расширенных функций, связанных с безопасностью, таких как владельцы кода или обязательные рецензенты, потребуется план для команды. Дополнительные сведения см. на странице цен на GitHub.
  • Azure DevOps предлагает бесплатный уровень, который можно использовать для некоторых сценариев.
  • Для оценки затрат используйте калькулятор цен Azure.

Эффективность работы

Оперативное превосходство охватывает процессы операций, которые развертывают приложение и продолжают работать в рабочей среде. Дополнительные сведения см. в разделе "Общие сведения о принципах эффективности работы".

GitOps позволяет повысить производительность процессов DevOps. Одна из наиболее полезных функций — возможность быстро откатить непредсказуемые изменения просто с помощью операций Git. Граф фиксации, как и прежде, содержит все операции фиксации и помогает при последующем анализе.

Команды GitOps часто управляют несколькими средами для одного приложения. Обычно это несколько этапов приложения, развернутого в разных кластерах Или пространствах имен Kubernetes. Репозиторий Git, который является единым источником достоверных данных, показывает, какие версии приложений в настоящее время развернуты в кластере.

Развертывание сценария

В следующем списке приведены ссылки на сведения о развертывании пяти сценариев:

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Автор субъекта:

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

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