Сине-зеленое развертывание кластеров AKS

В этой статье приводятся рекомендации по реализации стратегии развертывания сине-зеленого цвета для тестирования новой версии кластера Служба Azure Kubernetes (AKS), продолжая выполнять текущую версию. После проверки новой версии изменение маршрутизации переключает трафик пользователей на него. Развертывание таким образом повышает доступность при внесении изменений, включая обновления, в кластеры AKS. В этой статье описывается проектирование и реализация сине-зеленого развертывания AKS, использующего управляемые службы Azure и собственные функции Kubernetes.

Архитектура

В этом разделе описываются архитектуры для сине-зеленого развертывания кластеров AKS. Ниже приведены два возможных варианта.

• Приложения и API являются общедоступными.
• Приложения и API являются частными.

Существует также гибридный случай, не рассмотренный здесь, в котором есть сочетание общедоступных и частных приложений и API в кластере.

На следующей схеме показана архитектура для общедоступного дела:

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

Azure Front Door и Azure DNS предоставляют механизм маршрутизации, который переключает трафик между голубыми и зелеными кластерами. Дополнительные сведения см. в статье "Сине-зеленое развертывание" с помощью Azure Front Door. С помощью Azure Front Door можно реализовать полный коммутатор или более контролируемый коммутатор, основанный на весах. Этот метод является наиболее надежным и эффективным в среде Azure. Если вы хотите использовать собственный DNS-сервер и подсистему балансировки нагрузки, необходимо убедиться, что они настроены для обеспечения безопасного и надежного коммутатора.

Шлюз приложений Azure предоставляет интерфейсные части, предназначенные для общедоступных конечных точек.

Эта схема относится к частному регистру:

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

В этом случае один экземпляр Azure DNS реализует переключение трафика между голубыми и зелеными кластерами. Это делается с помощью A и CNAME записями. Дополнительные сведения см. в разделе T3. Переключение трафика на зеленый кластер.

Шлюз приложений предоставляет интерфейсные части, предназначенные для частных конечных точек.

Рабочий процесс

В сине-зеленом развертывании существует пять этапов обновления текущей версии кластера до новой версии. В нашем описании синий кластер — текущая версия, а зеленый кластер — новый.

Вот эти этапы:

1. T0: синий кластер включен.
2. T1. Развертывание зеленого кластера.
3. T2. Синхронизация состояния Kubernetes между голубыми и зелеными кластерами.
4. T3. Переключение трафика на зеленый кластер.
5. T4: уничтожение синего кластера.

После трансляции новой версии он становится синим кластером для любого изменения или обновления.

Синие и зеленые кластеры выполняются одновременно, но только в течение ограниченного периода времени, что оптимизирует затраты и операционные усилия.

Триггеры перехода

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

• Метрики конкретных рабочих нагрузок, цели уровня обслуживания (SLOS) и соглашения об уровне обслуживания( соглашения об уровне обслуживания). Они используются главным образом на этапе T3 для проверки общего состояния кластера AKS перед переключением трафика.
• Метрики платформы Azure: они используются для оценки состояния и работоспособности рабочих нагрузок и кластера AKS. Они используются во всех переходах.

Возможность обнаружения сети кластеров

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

• Укажите записи DNS, указывающие на кластеры. Например:

  • aks-blue.contoso.com указывает на частный или общедоступный IP-адрес синего кластера.
  • aks-green.contoso.com указывает на частный или общедоступный IP-адрес зеленого кластера.

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

• Есть записи DNS, указывающие на шлюзы приложений. Например:

  • aks-blue.contoso.com указывает на частный или общедоступный IP-адрес шлюза приложений, который имеет внутренний пул частный или общедоступный IP-адрес синего кластера.
  • aks-green.contoso.com указывает на частный или общедоступный IP-адрес шлюза приложений, который имеет внутренний пул частный или общедоступный IP-адрес зеленого кластера.

T0: синий кластер включен

Начальный этап, T0, заключается в том, что синий кластер находится в режиме реального времени. На этом этапе подготавливается новая версия кластера для развертывания.

Условие триггера для этапа T1 — выпуск новой версии кластера, зеленого кластера.

T1. Развертывание зеленого кластера

На этом этапе начинается развертывание нового зеленого кластера. Синий кластер остается на месте, и динамический трафик по-прежнему направляется к нему.

Триггер для перехода на этап T2 — проверка зеленого кластера AKS на уровне платформы. Проверка использует метрики Azure Monitor и команды CLI для проверки работоспособности развертывания. Дополнительные сведения см. в разделе "Мониторинг Служба Azure Kubernetes (AKS) с справочником по данным Monitor and Monitoring AKS.

Мониторинг AKS можно разделить на разные уровни, как показано на следующей схеме:

Работоспособность кластера оценивается на уровнях 1 и 2 и на некоторых уровнях 3. Для уровня 1 можно использовать собственное представление с несколькими кластерами из Монитора для проверки работоспособности, как показано ниже.

На уровне 2 убедитесь, что сервер API Kubernetes и Kubelet работают правильно. Книгу Kubelet можно использовать в мониторе, в частности, две сетки книги, в которые отображаются ключевые показатели операционной статистики узлов:

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

Уровень 3 предназначен для объектов и приложений Kubernetes, развернутых по умолчанию в AKS, таких как omsagent, kube-proxy и т. д. Для этой проверки можно использовать представление Аналитики монитора для проверки состояния развертываний AKS:

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

После успешной проверки можно перейти на этап T2.

T2. Синхронизация состояния Kubernetes между синими и зелеными кластерами

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

Существует несколько способов синхронизации состояния Kubernetes между кластерами:

• Повторное развертывание с помощью непрерывной интеграции и непрерывной доставки (CI/CD). Обычно достаточно использовать те же конвейеры CI/CD, которые используются для нормального развертывания приложений. Распространенными инструментами для этого являются GitHub Actions, Azure DevOps и Jenkins.
• GitOps с решениями, которые продвигаются на веб-сайте Cloud Native Computing Foundation (CNCF), например Flux и ArgoCD.
• Настраиваемое решение, которое хранит конфигурации и ресурсы Kubernetes в хранилище данных. Как правило, эти решения основаны на генераторах манифестов Kubernetes, которые начинаются с определений метаданных, а затем хранят созданные манифесты Kubernetes в хранилище данных, например Azure Cosmos DB. Обычно это пользовательские решения, основанные на используемой платформе описания приложения.

На следующей схеме показан процесс синхронизации состояния Kubernetes:

Обычно во время синхронизации развертывание новых версий приложений не разрешено в динамическом кластере. Этот период времени начинается с синхронизации и завершается после завершения переключения на зеленый кластер. Способ отключения развертываний в Kubernetes может отличаться. Ниже приведены два возможных решения.

• Отключите конвейеры развертывания.

• Отключите учетную запись службы Kubernetes, которая выполняет развертывания.

  Вы можете автоматизировать отключение учетной записи службы с помощью агента Open Policy (OPA). Пока не удается использовать собственные функции AKS, так как они по-прежнему доступны в предварительной версии.

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

После завершения синхронизации требуется проверка кластера и приложений. В том числе:

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

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

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

После проверки нового кластера можно перейти к следующему этапу, чтобы переключить трафик на новый кластер.

T3. Переключение трафика на зеленый кластер

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

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

Методы, описанные в этой статье, реализуют полные коммутаторы: 100% трафика направляется в новый кластер. Это связано с тем, что маршрутизация применяется на уровне DNS с A назначением или CNAME записью, которая обновляется для указания на зеленый кластер, и для каждого кластера есть шлюз приложений.

Ниже приведен пример конфигурации для переключения частных конечных точек. Предлагаемое решение использует A записи для переключения. С точки зрения сопоставления DNS и IP ситуация выглядит следующим образом перед переключением:

• A запись aks.priv.contoso.com указывает на частный IP-адрес синего шлюза приложений.
• A запись aks-blue.priv.contoso.com указывает на частный IP-адрес синего шлюза приложений.
• A запись aks-green.priv.contoso.com указывает на частный IP-адрес зеленого шлюза приложений.

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

• A запись aks.priv.contoso.com указывает на частный IP-адрес зеленого шлюза приложений.
• A запись aks-blue.priv.contoso.com указывает на частный IP-адрес синего шлюза приложений.
• A запись aks-green.priv.contoso.com указывает на частный IP-адрес зеленого шлюза приложений.

Пользователи кластеров увидят переключатель после времени жизни (TTL) и распространения записей DNS.

Для общедоступных конечных точек рекомендуется использовать Azure Front Door и Azure DNS. Ниже приведена конфигурация перед переключением:

• CNAME запись official-aks.contoso.com указывает на запись автогенерированного домена Azure Front Door. Дополнительные сведения см. в статье Учебник. Добавление личного домена в службу Front Door.
• A запись aks.contoso.com указывает на общедоступный IP-адрес синего шлюза приложений.
• Конфигурация источника Azure Front Door указывает на aks.contoso.com имя узла. Дополнительные сведения о настройке внутренних пулов см. в разделе "Источники и группы источников" в Azure Front Door.
  • A запись aks-blue.contoso.com указывает на общедоступный IP-адрес синего шлюза приложений.
  • A запись aks-green.contoso.com указывает на общедоступный IP-адрес зеленого шлюза приложений.

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

• CNAME запись official-aks.contoso.com указывает на запись автогенерированного домена Azure Front Door.
• A запись aks.contoso.com указывает на общедоступный IP-адрес зеленого шлюза приложений.
• Конфигурация источника Azure Front Door указывает на aks.contoso.com имя узла.
  • A запись aks-blue.contoso.com указывает на общедоступный IP-адрес синего шлюза приложений.
  • A запись aks-green.contoso.com указывает на общедоступный IP-адрес зеленого шлюза приложений.

Альтернативные методы переключения, такие как частичные коммутаторы для канарных выпусков, возможны с дополнительными службами Azure, такими как Azure Front Door или Диспетчер трафика. Реализация сине-зеленого коммутатора трафика на уровне Azure Front Door см. в разделе "Сине-зеленый" развертывание с помощью Azure Front Door.

Как описано в примере, с точки зрения сети этот метод основан на определении четырех имен узлов:

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

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

Если Azure Front Door также является частью развертывания, он не влияет на параметр, так как он управляет только официальным именем узла кластера. Он предоставляет правильную абстракцию для пользователей приложения. Они не влияют на переключатель, так как запись DNS CNAME всегда указывает на Azure Front Door.

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

На этом этапе проверка основана на метриках мониторинга инфраструктуры и приложений, а также на официальном уровне SLO и SLA при наличии. Если проверка выполнена успешно, перейдите к последнему этапу, чтобы уничтожить синий кластер.

T4. Уничтожение синего кластера

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

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

Ниже приведена ситуация после уничтожения синего кластера:

Компоненты

• Шлюз приложений — это подсистема балансировки нагрузки (уровень 7 OSI), которая позволяет управлять трафиком в веб-приложения. В этом решении он используется в качестве шлюза для http-трафика для доступа к кластерам AKS.
• Служба Azure Kubernetes (AKS) — это управляемая служба Kubernetes, которую можно использовать для развертывания контейнерных приложений и управления ими. Эта платформа приложений является основным компонентом этого шаблона.
• Реестр контейнеров Azure — это управляемая служба, используемая для хранения образов контейнеров и связанных артефактов и управления ими. В этом решении используется для хранения и распространения образов контейнеров и артефактов, таких как диаграммы Helm, в кластерах AKS.
• Azure Monitor — это решение для мониторинга для сбора, анализа и реагирования на данные мониторинга из облачных и локальных сред. Он предоставляет основные функции мониторинга, необходимые для выполнения сине-зеленого развертывания. Она используется в этой архитектуре из-за интеграции с AKS и ее способностью предоставлять возможности ведения журналов, мониторинга и оповещений, которые можно использовать для управления переходами этапа.
• Azure Key Vault помогает решить следующие проблемы: управление секретами, управление ключами и управление сертификатами; оно используется для хранения секретов и сертификатов, необходимых на уровне platfomr и приложений для этого решения.
• Azure Front Door — это глобальная система балансировки нагрузки и системы управления конечными точками приложений. Он используется в этом решении в качестве общедоступной конечной точки для HTTP-приложений, размещенных в AKS. В этом решении она несет важную ответственность за управление переключением трафика между голубыми и зелеными шлюзами приложений.
• Azure DNS является службой размещения доменов DNS, осуществляющей разрешение имен на базе инфраструктуры Microsoft Azure. Он управляет именами узлов, которые используются в решении для синих и зеленых кластеров, и он играет важную роль в коммутаторах трафика, особенно для частных конечных точек.

Альтернативные варианты

• Существуют альтернативные методы реализации коммутаторов трафика, которые могут обеспечить больший контроль. Например, можно выполнить частичный коммутатор с помощью правил трафика, основанных на одном или нескольких из следующих:
  • Процент входящего трафика
  • Заголовки HTTP
  • Файлы cookie
• Еще одна альтернатива, которая обеспечивает большую защиту от проблем, вызванных изменениями, заключается в наличии цикловых развертываний. Вместо синих и зеленых кластеров можно иметь больше кластеров, называемых кольцами. Каждое кольцо достаточно большое для количества пользователей, имеющих доступ к новой версии AKS. Что касается сине-зеленого развертывания, описанного здесь, кольца можно удалить, чтобы иметь правильную оптимизацию затрат и управление.
• Возможные варианты Шлюз приложений — NGINX и HAProxy.
• Возможная альтернатива Реестру контейнеров — Гавань.
• В некоторых случаях можно использовать различные службы балансировки нагрузки и DNS для переключения трафика, а не Azure Front Door и Azure DNS.
• Это решение основано на стандартных API-интерфейсах контроллера входящего трафика Kubernetes. Если решение будет полезно вместо API шлюза, используйте Шлюз приложений для контейнеров. Он может помочь управлять балансировкой нагрузки и обрабатывать управление трафиком входящего трафика между Шлюз приложений и модулями pod. Шлюз приложений для контейнеров управляет параметрами шлюзов приложений.

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

Основными преимуществами решения являются:

• Минимальное время простоя во время развертывания.
• Плановая стратегия отката.
• Улучшено управление и операции во время выпуска и развертывания изменений и обновлений AKS.
• Тестирование необходимости выполнения процедур аварийного восстановления (DR).

Основные принципы и основные аспекты сине-зеленого развертывания рассматриваются в следующих статьях:

• Что такое инфраструктура как код (IaC)?
• Что такое неизменяемая инфраструктура?
• Что такое эластичные вычисления или эластичность облака?
• Что такое непрерывная доставка?

С точки зрения автоматизации и CI/CD решение можно реализовать несколькими способами. Рекомендации

• Bicep или Terraform для IaC.
• Действия Azure Pipelines или GitHub для CI/CD.

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

Сине-зеленое развертывание позволяет вносить изменения в кластеры, не затрагивая выполняемые приложения и рабочие нагрузки. Ниже приведены примеры изменений.

• Операционные изменения
• Активация новых функций AKS
• Изменения общих ресурсов в кластерах
• Обновление версии Kubernetes
• Изменение ресурсов и объектов Kubernetes, таких как шлюз входящего трафика, сетка служб, операторы, политики сети и т. д.
• Откат к предыдущей версии кластера AKS, который по-прежнему развернут, не затрагивая рабочие нагрузки, выполняемые в кластере.

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

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

• Развертывание blue-green может быть полностью автоматизировано, например развертывание нулевого касания. Обычно начальная реализация имеет триггеры вручную для активации этапов. На пути и с соответствующими функциями зрелости и мониторинга можно автоматизировать триггеры. Это означает, что для автоматизации триггеров существует автоматизированное тестирование и определенные метрики, соглашение об уровне обслуживания и SLO.
• Важно иметь выделенные имена узлов для голубых и зеленых кластеров, а также иметь выделенные конфигурации конечных точек на шлюзах и подсистемах балансировки нагрузки, которые находятся перед кластерами. Это крайне важно для повышения надежности и допустимости развертывания нового кластера. Таким образом, проверка развертывания выполняется с той же архитектурой и конфигурациями стандартного рабочего кластера.
• Рассмотрим ситуацию, в которой кластеры AKS являются общими ресурсами для нескольких приложений, управляемых различными бизнес-подразделениями. В таких случаях платформа AKS управляется выделенной командой, ответственной за общую операцию и жизненный цикл кластеров, а также конечную точку в кластерах для администраторов и операций. Мы рекомендуем, чтобы эти конечные точки имели выделенный контроллер входящего трафика в кластерах AKS для правильного разделения проблем и надежности.
• Сине-зеленое развертывание полезно для реализации и тестирования решений непрерывности бизнес-процессов и аварийного восстановления (BC/DR) для AKS и связанных рабочих нагрузок. В частности, он предоставляет основные структуры для управления несколькими кластерами, включая случаи, в которых кластеры распределяются между несколькими регионами.
• Успешное развертывание с сине-зеленым цветом зависит от применения всех аспектов реализации, таких как автоматизация, мониторинг и проверка, не только к платформе AKS, но и к рабочим нагрузкам и приложениям, развернутым на платформе. Это помогает получить максимальное преимущество от сине-зеленого развертывания.
• В предлагаемом решении существует два Шлюз приложений для каждого сценария общедоступной и частной, поэтому в общей сложности четыре. Это решение заключается в применении сине-зеленого развертывания на уровне Шлюз приложений Azure, чтобы избежать простоя, вызванного неправильной настройкой шлюзов. Основным недостатком этого решения является стоимость, так как существует четыре Шлюз приложений экземпляров. Они выполняются параллельно только за период времени, в течение которого существуют соответствующие изменения в конфигурации Шлюз приложений, такие как политики WAF или конфигурация масштабирования. Для дальнейшей оптимизации затрат можно выбрать один Шлюз приложений для каждого сценария, это означает два Шлюз приложений в общей сложности. Для этого потребуется переместить синюю и зеленую логику в шлюз приложений вместо Azure Front Door. Таким образом, вместо управления Azure Front Door необходимо Шлюз приложений.

Надежность

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

• Развертывание blue-green имеет прямое и положительное влияние на доступность платформы AKS и рабочих нагрузок. В частности, она повышает доступность во время развертывания изменений платформы AKS. Существует мало простоя, если сеансы пользователей управляются хорошо.
• Сине-зеленое развертывание обеспечивает покрытие надежности во время развертывания, так как по умолчанию есть возможность отката до предыдущей версии кластера AKS, если что-то не так в новой версии кластера.

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

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

• Развертывание blue-green широко применяется в Azure из-за собственной эластичности, предоставляемой облаком. Это позволяет оптимизировать затраты в рамках операций и потребления ресурсов. Большая часть экономии от удаления кластера, который больше не нужен после успешного развертывания новой версии кластера.
• При развертывании новой версии обычно размещается как синий, так и зеленый кластеры в одной подсети, чтобы продолжать иметь одинаковые базовые показатели затрат. Все сетевые подключения и доступ к ресурсам и службам одинаковы для двух кластеров, а все службы и ресурсы Azure остаются одинаковыми.

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

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

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

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

Пример реализации сине-зеленого развертывания, описанного в этом руководстве, см . в акселераторе целевой зоны AKS.

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

Рекомендации по регионам

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

• Выделенная виртуальная сеть и подсеть для AKS и шлюза приложений.
• Подключение к службам резервного копирования, таким как Monitor, Реестр контейнеров и Key Vault.
• Видимость Шлюза приложений в Azure Front Door.

Необходимые условия для развертывания в одном регионе:

• Виртуальные сети и подсети должны иметь размер для размещения двух кластеров.
• Подписка Azure должна обеспечить достаточную емкость для двух кластеров.

Развертывание контроллера входящего трафика и внешних подсистем балансировки нагрузки

Существуют различные подходы к развертыванию контроллера входящего трафика и внешних подсистем балансировки нагрузки:

• У вас может быть один контроллер входящего трафика с выделенным внешним балансировщиком нагрузки, например эталонной реализацией архитектуры, описанной в этом руководстве. AGIC — это приложение Kubernetes, которое позволяет использовать подсистему балансировки нагрузки Шлюз приложений L7 для предоставления облачного программного обеспечения в Интернете. В некоторых сценариях есть конечные точки администратора в кластерах AKS в дополнение к конечным точкам приложения. Конечные точки администратора предназначены для выполнения операционных задач в приложениях или для задач конфигурации, таких как обновление карт конфигурации, секретов, политик сети и манифестов.
• Вы можете использовать один внешний балансировщик нагрузки, который обслуживает несколько контроллеров входящего трафика, развернутых в одном кластере или в нескольких кластерах. Этот подход не рассматривается в эталонной реализации. В этом сценарии рекомендуется использовать отдельные шлюзы приложений для общедоступных конечных точек и частных.
• Результирующая архитектура, предлагаемая и показанная в этом руководстве, основана на стандартном контроллере входящего трафика, развернутом в составе кластера AKS, например NGINX и Envoy . В эталонной реализации мы используем AGIC, что означает, что между шлюзом приложений и модулями pod AKS есть прямое подключение, но это не влияет на общую сине-зеленую архитектуру.

Соавторы

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

Основные авторы:

• Винченцо Морра | Архитектор инкубации SAO

Другие участники:

• Оскар Альварес | Архитектор доменных решений

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

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

• Что такое инфраструктура как код (IaC)?
• Развертывание blue-green (Мартин Фаулер)
• Документация AKS
• Документация по мониторингу
• Акселератор целевой зоны AKS для развертывания сине-зеленого цвета
• Шаблон архитектуры для критически важных рабочих нагрузок в Azure
• Службы Azure для защиты сетевого подключения
• Microsoft Cloud Adoption Framework для Azure

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

• Базовые показатели AKS для кластеров с несколькими агрегатами
• Обзор критически важных задач Azure
• Развертывания с критически важным временем простоя Azure
• Непрерывная проверка критически важной задачи Azure