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 v2, GitHub и AKS. Слева разработчик фиксирует изменения конфигурации в репозитории GitHub. В центре оператор Flux в кластере AKS отслеживает репозиторий на предмет изменений. При обнаружении смещения конфигурации Flux извлекает последнюю конфигурацию из GitHub. Справа Flux примиряет требуемое состояние из репозитория с фактическим состоянием в кластере AKS и при необходимости применяет обновления. На схеме отображен поток изменений конфигурации от разработчика к GitHub, далее Flux, и, наконец, в кластер AKS, подчеркивая pull-процесс непрерывной синхронизации.

Скачайте файл 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 Bucket определяет источник для создания артефактов из таких решений для хранения данных, как Amazon S3 и Google Cloud Storage. Вы также можете использовать решение, которое имеет API, совместимый с S3. Два примера: MinIO и Alibaba Cloud Object Storage Service (OSS), но есть и другие решения.

• Вы также можете настроить Flux для контейнера Хранилище BLOB-объектов Azure в качестве источника для создания артефактов. Дополнительные сведения см . в конфигурациях GitOps Flux версии 2 с AKS и Kubernetes с поддержкой Azure Arc.

• Flux версии 2 поддерживает мультитенантность, позволяя отдельным командам развертывать рабочие нагрузки в одном общем кластере Kubernetes. Несколько репозиториев Git, представляющих отдельный клиент, можно синхронизировать с кластером. Чтобы обеспечить изоляцию рабочей нагрузки между командами, каждая команда может иметь собственное пространство имен или пространства имен в кластере AKS, к которому доступ ограничен с помощью политик управления доступом на основе ролей Kubernetes (RBAC).

• Flux может использовать один кластер для управления приложениями в одном кластере или в других кластерах. Кластер AKS концентратора с оператором Flux управляет непрерывной доставкой приложений и рабочих нагрузок инфраструктуры в несколько периферийных кластеров AKS.

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

Схема, демонстрирующая рабочий процесс CI/CD с GitOps, Flux, GitHub и AKS. Слева разработчик записывает код приложения в интегрированной среде разработки (IDE) и фиксирует его в репозитории GitHub. GitHub Actions создает образ контейнера из кода и отправляет его в реестр контейнеров Azure. GitHub Actions обновляет файл манифеста Kubernetes в репозитории с новой версией образа. В центре оператор Flux в кластере AKS отслеживает репозиторий на предмет изменений. Когда Flux обнаруживает обновленный манифест, он извлекает конфигурацию и развертывает новую версию приложения в кластере AKS. На схеме показан поток кода и конфигурации от разработчика до GitHub, через автоматизацию CI/CD, в Flux и, наконец, в кластер AKS, и подчеркивается автоматизированный процесс развертывания на основе вытягивания.

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

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

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

Следующий поток данных соответствует предыдущей схеме:

1. Код приложения разрабатывается с помощью интегрированной среды разработки (IDE), такой как Visual Studio Code.

2. Код приложения фиксируется в репозитории GitHub.

3. GitHub Actions создает образ контейнера из кода приложения и отправляет образ контейнера в Реестр контейнеров Azure.

4. GitHub Actions обновляет файл развертывания манифеста Kubernetes с текущей версией образа, основанной на номере версии образа контейнера в реестре контейнеров.

5. Оператор Flux обнаруживает смещение конфигурации в репозитории Git и извлекает изменения конфигурации.

6. Flux использует файлы манифеста для развертывания приложения в кластере AKS.

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

Схема, показывающая рабочий процесс системы GitOps с Argo CD, GitHub и AKS. Слева администратор Kubernetes изменяет файлы конфигурации и фиксирует их в репозитории GitHub. В центре Argo CD в кластере AKS отслеживает репозиторий на изменения. Когда Argo CD обнаруживает обновленную конфигурацию, она извлекает изменения и сопоставляет требуемое состояние с фактическим состоянием в кластере AKS. Схема выделяет поток конфигурации от администратора к GitHub, затем к Argo CD и далее в кластер AKS, подчеркивая основанный на pull-стратегии процесс непрерывной выверки и согласования, а также роль Argo CD в качестве контроллера, который контролирует состояние приложения.

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

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

Вы можете включить Argo CD в качестве расширения кластера в AKS. В этом сценарии администратор 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. Слева разработчик записывает код приложения и фиксирует его в репозитории GitHub. GitHub Actions создает образ контейнера, отправляет его в реестр контейнеров и обновляет файл манифеста Kubernetes в репозитории с новой версией образа. В центре Argo CD, работающий в кластере AKS, мониторит репозиторий на изменения, извлекает обновленную конфигурацию и развертывает новую версию приложения в кластере AKS. На диаграмме показан поток кода и конфигурации от разработчика через GitHub, с использованием автоматизации CI/CD, до Argo CD и, наконец, до кластера AKS, с акцентом на автоматизированный процесс развертывания на основе pull-запросов.

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

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

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

Следующий поток данных соответствует предыдущей схеме:

1. Код приложения разрабатывается с помощью интегрированной среды разработки, например Visual Studio Code.

2. Код приложения фиксируется в репозитории GitHub.

3. GitHub Actions создает образ контейнера из кода приложения и отправляет образ контейнера в реестр контейнеров.

4. GitHub Actions обновляет файл развертывания манифеста Kubernetes с текущей версией образа, основанной на номере версии образа контейнера в реестре контейнеров.

5. Argo CD извлекает из репозитория Git.

6. Argo CD развертывает приложение в кластере AKS.

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

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

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

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

• Он использует управление версиями в качестве единственного источника истины для системы.

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

• Его можно применить к любой программной системе.

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

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

• Декларативный: Система, управляющая GitOps, должна иметь требуемое состояние, выраженное декларативно. Объявление обычно хранится в репозитории Git.

• Версионированность и неизменяемость: Требуемое состояние хранится таким образом, чтобы обеспечить его неизменяемость и версионирование, и сохраняет полный журнал версий.

• Вытягивается автоматически: Агенты программного обеспечения автоматически извлекают декларации желаемого состояния из источника.

• Непрерывно согласовано: Программные агенты постоянно отслеживают фактическое состояние системы и пытаются применить желаемое состояние.

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

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

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

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

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

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

Чтобы применить GitOps в качестве единственного метода для изменения состояния кластера, ограничьте прямой доступ к кластеру. Чтобы задать эту конфигурацию, используйте управление доступом на основе ролей Azure (Azure RBAC), контроллеры допуска или другие средства.

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

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

• Надстройки AKS, такие как идентификатор рабочей нагрузки Microsoft Entra и поставщик Azure Key Vault для драйвера CSI хранилища секретов

• Средства партнеров, такие как Prisma Cloud Defender

• Средства с открытым кодом, такие как автомасштабирование на основе событий Kubernetes (KEDA),ExternalDNS и Cert-manager

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

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

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

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

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

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

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

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

Надежность

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

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

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

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

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

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

• Защита ветвей. Защитите ветви, которые представляют состояние кластеров Kubernetes, от непосредственной отправки в них изменений. Используйте запросы на вытягивание (PR) для внесения изменений и попросите, чтобы по крайней мере один другой пользователь проверил каждый запрос на вытягивание. Также используйте PR для автоматической проверки.

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

• Неизменяемый журнал. Можно разрешить только новые фиксации поверх существующих изменений. Неизменяемый журнал особенно важен для аудита.

• Дополнительные меры безопасности: требуется, чтобы пользователи GitHub активировали двухфакторную проверку подлинности. Допускаются только подписанные коммиты, чтобы предотвратить несанкционированные изменения.

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

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

• Бесплатный уровень AKS предоставляет бесплатное управление кластерами. Затраты ограничены вычислительными, хранилищами и сетевыми ресурсами, которые AKS использует для размещения узлов. Бесплатный уровень AKS не включает соглашение об уровне обслуживания (SLA) и не рекомендуется для продуктивных нагрузок.

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

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

• Для оценки затрат используйте калькулятор цен Azure.

Операционное превосходство

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

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

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

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

Дополнительные сведения о развертывании пяти сценариев см. в следующих ресурсах:

• Сценарий 1. Инструкции по использованию GitOps с Flux версии 2 для развертывания приложений в AKS см. в руководстве по развертыванию приложений с помощью GitOps с Flux версии 2. Пример использования расширения Flux для начального развертывания кластера AKS см . в справочной реализации базового плана AKS.

• Сценарий 2. Инструкции по использованию GitOps с Flux версии 2 в AKS для развертывания приложений и реализации CI/CD см. в руководстве по реализации CI/CD с помощью GitOps (Flux версии 2).

• Сценарии 3 и 4: Пошаговые инструкции по развертыванию примера рабочей нагрузки с помощью Argo CD и AKS можно найти в сценарии pull-based CI/CD, который приведен в базовой автоматизации AKS.

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

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

• Фрэнсис Сими Назарет | Архитектор основных облачных решений

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

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

• Развертывание приложений с помощью GitOps с Flux v2
• Развертывание приложений с помощью GitOps с Argo CD
• Реализация CI/CD с помощью GitOps (Flux версии 2)
• Документация по Argo CD
• Документация по Flux CD
• GitOps с Jenkins X
• Что такое Azure RBAC?

Связанные ресурсы

• Базовая архитектура кластера AKS
• Базовые показатели AKS для кластеров с несколькими агрегатами
• DevSecOps в AKS
• DevSecOps для IaC

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 v2, GitHub и AKS. Слева разработчик фиксирует изменения конфигурации в репозитории GitHub. В центре оператор Flux в кластере AKS отслеживает репозиторий на предмет изменений. При обнаружении смещения конфигурации Flux извлекает последнюю конфигурацию из GitHub. Справа Flux примиряет требуемое состояние из репозитория с фактическим состоянием в кластере AKS и при необходимости применяет обновления. На схеме отображен поток изменений конфигурации от разработчика к GitHub, далее Flux, и, наконец, в кластер AKS, подчеркивая pull-процесс непрерывной синхронизации.

Скачайте файл 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 Bucket определяет источник для создания артефактов из таких решений для хранения данных, как Amazon S3 и Google Cloud Storage. Вы также можете использовать решение, которое имеет API, совместимый с S3. Два примера: MinIO и Alibaba Cloud Object Storage Service (OSS), но есть и другие решения.

• Вы также можете настроить Flux для контейнера Хранилище BLOB-объектов Azure в качестве источника для создания артефактов. Дополнительные сведения см . в конфигурациях GitOps Flux версии 2 с AKS и Kubernetes с поддержкой Azure Arc.

• Flux версии 2 поддерживает мультитенантность, позволяя отдельным командам развертывать рабочие нагрузки в одном общем кластере Kubernetes. Несколько репозиториев Git, представляющих отдельный клиент, можно синхронизировать с кластером. Чтобы обеспечить изоляцию рабочей нагрузки между командами, каждая команда может иметь собственное пространство имен или пространства имен в кластере AKS, к которому доступ ограничен с помощью политик управления доступом на основе ролей Kubernetes (RBAC).

• Flux может использовать один кластер для управления приложениями в одном кластере или в других кластерах. Кластер AKS концентратора с оператором Flux управляет непрерывной доставкой приложений и рабочих нагрузок инфраструктуры в несколько периферийных кластеров AKS.

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

Схема, демонстрирующая рабочий процесс CI/CD с GitOps, Flux, GitHub и AKS. Слева разработчик записывает код приложения в интегрированной среде разработки (IDE) и фиксирует его в репозитории GitHub. GitHub Actions создает образ контейнера из кода и отправляет его в реестр контейнеров Azure. GitHub Actions обновляет файл манифеста Kubernetes в репозитории с новой версией образа. В центре оператор Flux в кластере AKS отслеживает репозиторий на предмет изменений. Когда Flux обнаруживает обновленный манифест, он извлекает конфигурацию и развертывает новую версию приложения в кластере AKS. На схеме показан поток кода и конфигурации от разработчика до GitHub, через автоматизацию CI/CD, в Flux и, наконец, в кластер AKS, и подчеркивается автоматизированный процесс развертывания на основе вытягивания.

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

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

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

Следующий поток данных соответствует предыдущей схеме:

1. Код приложения разрабатывается с помощью интегрированной среды разработки (IDE), такой как Visual Studio Code.

2. Код приложения фиксируется в репозитории GitHub.

3. GitHub Actions создает образ контейнера из кода приложения и отправляет образ контейнера в Реестр контейнеров Azure.

4. GitHub Actions обновляет файл развертывания манифеста Kubernetes с текущей версией образа, основанной на номере версии образа контейнера в реестре контейнеров.

5. Оператор Flux обнаруживает смещение конфигурации в репозитории Git и извлекает изменения конфигурации.

6. Flux использует файлы манифеста для развертывания приложения в кластере AKS.

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

Схема, показывающая рабочий процесс системы GitOps с Argo CD, GitHub и AKS. Слева администратор Kubernetes изменяет файлы конфигурации и фиксирует их в репозитории GitHub. В центре Argo CD в кластере AKS отслеживает репозиторий на изменения. Когда Argo CD обнаруживает обновленную конфигурацию, она извлекает изменения и сопоставляет требуемое состояние с фактическим состоянием в кластере AKS. Схема выделяет поток конфигурации от администратора к GitHub, затем к Argo CD и далее в кластер AKS, подчеркивая основанный на pull-стратегии процесс непрерывной выверки и согласования, а также роль Argo CD в качестве контроллера, который контролирует состояние приложения.

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

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

Вы можете включить Argo CD в качестве расширения кластера в AKS. В этом сценарии администратор 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. Слева разработчик записывает код приложения и фиксирует его в репозитории GitHub. GitHub Actions создает образ контейнера, отправляет его в реестр контейнеров и обновляет файл манифеста Kubernetes в репозитории с новой версией образа. В центре Argo CD, работающий в кластере AKS, мониторит репозиторий на изменения, извлекает обновленную конфигурацию и развертывает новую версию приложения в кластере AKS. На диаграмме показан поток кода и конфигурации от разработчика через GitHub, с использованием автоматизации CI/CD, до Argo CD и, наконец, до кластера AKS, с акцентом на автоматизированный процесс развертывания на основе pull-запросов.

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

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

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

Следующий поток данных соответствует предыдущей схеме:

1. Код приложения разрабатывается с помощью интегрированной среды разработки, например Visual Studio Code.

2. Код приложения фиксируется в репозитории GitHub.

3. GitHub Actions создает образ контейнера из кода приложения и отправляет образ контейнера в реестр контейнеров.

4. GitHub Actions обновляет файл развертывания манифеста Kubernetes с текущей версией образа, основанной на номере версии образа контейнера в реестре контейнеров.

5. Argo CD извлекает из репозитория Git.

6. Argo CD развертывает приложение в кластере AKS.

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

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

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

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

• Он использует управление версиями в качестве единственного источника истины для системы.

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

• Его можно применить к любой программной системе.

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

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

• Декларативный: Система, управляющая GitOps, должна иметь требуемое состояние, выраженное декларативно. Объявление обычно хранится в репозитории Git.

• Версионированность и неизменяемость: Требуемое состояние хранится таким образом, чтобы обеспечить его неизменяемость и версионирование, и сохраняет полный журнал версий.

• Вытягивается автоматически: Агенты программного обеспечения автоматически извлекают декларации желаемого состояния из источника.

• Непрерывно согласовано: Программные агенты постоянно отслеживают фактическое состояние системы и пытаются применить желаемое состояние.

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

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

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

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

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

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

Чтобы применить GitOps в качестве единственного метода для изменения состояния кластера, ограничьте прямой доступ к кластеру. Чтобы задать эту конфигурацию, используйте управление доступом на основе ролей Azure (Azure RBAC), контроллеры допуска или другие средства.

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

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

• Надстройки AKS, такие как идентификатор рабочей нагрузки Microsoft Entra и поставщик Azure Key Vault для драйвера CSI хранилища секретов

• Средства партнеров, такие как Prisma Cloud Defender

• Средства с открытым кодом, такие как автомасштабирование на основе событий Kubernetes (KEDA),ExternalDNS и Cert-manager

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

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

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

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

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

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

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

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

Надежность

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

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

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

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

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

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

• Защита ветвей. Защитите ветви, которые представляют состояние кластеров Kubernetes, от непосредственной отправки в них изменений. Используйте запросы на вытягивание (PR) для внесения изменений и попросите, чтобы по крайней мере один другой пользователь проверил каждый запрос на вытягивание. Также используйте PR для автоматической проверки.

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

• Неизменяемый журнал. Можно разрешить только новые фиксации поверх существующих изменений. Неизменяемый журнал особенно важен для аудита.

• Дополнительные меры безопасности: требуется, чтобы пользователи GitHub активировали двухфакторную проверку подлинности. Допускаются только подписанные коммиты, чтобы предотвратить несанкционированные изменения.

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

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

• Бесплатный уровень AKS предоставляет бесплатное управление кластерами. Затраты ограничены вычислительными, хранилищами и сетевыми ресурсами, которые AKS использует для размещения узлов. Бесплатный уровень AKS не включает соглашение об уровне обслуживания (SLA) и не рекомендуется для продуктивных нагрузок.

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

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

• Для оценки затрат используйте калькулятор цен Azure.

Операционное превосходство

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

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

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

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

Дополнительные сведения о развертывании пяти сценариев см. в следующих ресурсах:

• Сценарий 1. Инструкции по использованию GitOps с Flux версии 2 для развертывания приложений в AKS см. в руководстве по развертыванию приложений с помощью GitOps с Flux версии 2. Пример использования расширения Flux для начального развертывания кластера AKS см . в справочной реализации базового плана AKS.

• Сценарий 2. Инструкции по использованию GitOps с Flux версии 2 в AKS для развертывания приложений и реализации CI/CD см. в руководстве по реализации CI/CD с помощью GitOps (Flux версии 2).

• Сценарии 3 и 4: Пошаговые инструкции по развертыванию примера рабочей нагрузки с помощью Argo CD и AKS можно найти в сценарии pull-based CI/CD, который приведен в базовой автоматизации AKS.

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

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

• Фрэнсис Сими Назарет | Архитектор основных облачных решений

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

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

• Развертывание приложений с помощью GitOps с Flux v2
• Развертывание приложений с помощью GitOps с Argo CD
• Реализация CI/CD с помощью GitOps (Flux версии 2)
• Документация по Argo CD
• Документация по Flux CD
• GitOps с Jenkins X
• Что такое Azure RBAC?

Связанные ресурсы

• Базовая архитектура кластера AKS
• Базовые показатели AKS для кластеров с несколькими агрегатами
• DevSecOps в AKS
• DevSecOps для IaC