Сеть и подключение для критически важных рабочих нагрузок в Azure

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

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

Важно!

Эта статья является частью серии критически важных рабочих нагрузок Azure Well-Architected . Если вы не знакомы с этой серией, рекомендуем начать с критически важной рабочей нагрузки?

Глобальная маршрутизация трафика

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

Azure Front Door, Диспетчер трафика Azure и Azure Load Balancer (цен. категория предоставляют необходимые возможности маршрутизации для управления глобальным трафиком в приложении с несколькими регионами.

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

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

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

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

• Если рабочая нагрузка приложения охватывает управление клиентом, например с мобильными или настольными клиентскими приложениями, можно обеспечить избыточность служб в рамках логики маршрутизации клиентов.

  • Несколько технологий глобальной маршрутизации, таких как Azure Front Door и диспетчер трафика Azure, можно рассматривать параллельно для обеспечения избыточности, при этом клиенты настроены для отработки отказа на альтернативную технологию при соблюдении определенных условий сбоя. Внедрение нескольких служб глобальной маршрутизации значительно усложняет возможности пограничного кэширования и Брандмауэр веб-приложений, а также управление сертификатами для разгрузки SSL и проверки приложений для путей входящего трафика.
  • Можно также рассмотреть сторонние технологии, обеспечивающие устойчивость глобальной маршрутизации ко всем уровням сбоев платформы Azure.

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

• Azure Front Door и Диспетчер трафика Azure — это глобально распределенные службы со встроенной избыточностью и доступностью в нескольких регионах.

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

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

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

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

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

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

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

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

Azure Front Door

• Azure Front Door обеспечивает глобальную балансировку нагрузки HTTP/S и оптимизированное подключение с помощью протокола Anycast с разделением TCP для использования преимуществ глобальной магистральной сети Майкрософт.

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

• Предоставляет встроенный кэш, который обслуживает статическое содержимое с граничных узлов. Во многих случаях это также может устранить необходимость в выделенной сети доставки содержимого (CDN).

• Azure Брандмауэр веб-приложений (WAF) можно использовать в Azure Front Door. Так как она развернута в пограничных расположениях сети Azure по всему миру, каждый входящий запрос, доставляемый Front Door, проверяется на границе сети.

• Azure Front Door защищает конечные точки приложений от атак DDoS с помощью защиты от атак DDoS Azure уровня "Базовый". Azure DDoS уровня "Стандартный" предоставляет дополнительные и расширенные возможности защиты и обнаружения, а также может быть добавлен в качестве дополнительного слоя в Azure Front Door.

• Azure Front Door предлагает полностью управляемую службу сертификатов. Обеспечивает безопасность подключения TLS для конечных точек без необходимости управлять жизненным циклом сертификата.

• Azure Front Door Premium поддерживает частные конечные точки, позволяя трафику передаваться из Интернета непосредственно в виртуальные сети Azure. Это устранит необходимость использования общедоступных IP-адресов в виртуальной сети, чтобы сделать серверные части доступными через Azure Front Door Premium.

• Azure Front Door использует пробы работоспособности и конечные точки работоспособности серверной части (URL-адреса), которые вызываются на основе интервала, чтобы вернуть код состояния HTTP, отражающий, работает ли серверная часть нормально, с ответом HTTP 200 (ОК), отражающим работоспособное состояние. Как только серверная часть отражает неработоспособное состояние, с точки зрения определенного граничного узла, этот граничный узел перестанет отправлять туда запросы. Поэтому неработоспособные серверные части прозрачно удаляются из трафика без каких-либо задержек.

• Поддерживает только протоколы HTTP/S.

• WaF Azure Front Door и Шлюз приложений WAF предоставляют несколько разные наборы функций, хотя и поддерживают встроенные и настраиваемые правила и могут работать в режиме обнаружения или предотвращения.

• Пространство IP-адресов серверной части Front Door может измениться, но корпорация Майкрософт обеспечит интеграцию с диапазонами IP-адресов и тегами служб Azure. Вы можете подписаться на диапазоны IP-адресов и теги служб Azure, чтобы получать уведомления об изменениях или обновлениях.

• Azure Front Door поддерживает различные конфигурации распределения нагрузки:

  • На основе задержки: параметр по умолчанию, который направляет трафик в "ближайшую" серверную часть от клиента; на основе задержки запроса.
  • На основе приоритета: полезно для настроек "активный — пассивный", где трафик всегда должен отправляться в основную серверную часть, если он недоступен.
  • Взвешен: применяется для канареечного развертывания, в которых определенный процент трафика отправляется в определенную серверную часть. Если нескольким серверным серверам назначены одинаковые весовые коэффициенты, используется маршрутизация на основе задержки.

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

• Если ряд клиентских запросов должен обрабатываться одной и той же серверной частью, сходство сеансов можно настроить на интерфейсном интерфейсе. Он использует файл cookie на стороне клиента для отправки последующих запросов в ту же серверную часть, что и первый запрос, при условии, что серверная часть по-прежнему доступна.

Azure Traffic Manager

• Диспетчер трафика Azure — это служба перенаправления DNS.

  • Фактические полезные данные запроса не обрабатываются, но вместо этого диспетчер трафика возвращает DNS-имя одной из внутренних серверов пула на основе настроенных правил для выбранного метода маршрутизации трафика.
  • Затем DNS-имя серверной части разрешается в конечный IP-адрес, который затем вызывается клиентом напрямую.

• Ответ DNS кэшируется и повторно используется клиентом в течение указанного срока жизни (TTL), и запросы, выполненные в течение этого периода, будут отправляться непосредственно в серверную конечную точку без взаимодействия с диспетчером трафика. Исключает дополнительный шаг подключения, который обеспечивает преимущества затрат по сравнению с Front Door.

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

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

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

Azure Load Balancer уровня «Стандартный»

Важно!

Load Balancer (цен. категория между регионами доступна в предварительной версии с техническими ограничениями. Этот параметр не рекомендуется использовать для критически важных рабочих нагрузок.

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

• Используйте Azure Front Door в качестве основной глобальной службы маршрутизации трафика для сценариев HTTP/S. Azure Front Door настоятельно поддерживает рабочие нагрузки HTTP/S, так как она обеспечивает оптимизированную маршрутизацию трафика, прозрачную отработку отказа, частные серверные конечные точки (с SKU уровня "Премиум"), пограничное кэширование и интеграцию с Брандмауэр веб-приложений (WAF).

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

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

На этом изображении показана избыточная конфигурация глобальной подсистемы балансировки нагрузки с отработкой отказа клиента с использованием Azure Front Door в качестве основной глобальной подсистемы балансировки нагрузки.

Важно!

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

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

• Хотя это не рекомендуется, для рабочих нагрузок HTTP(s), использующих диспетчер трафика Azure для глобальной маршрутизации избыточности в Azure Front Door, рассмотрите возможность разгрузки Брандмауэр веб-приложений (WAF) на Шлюз приложений для приемлемого трафика, проходящего через Azure Front Door.
  • Это создаст дополнительную точку отказа для стандартного пути входящего трафика, дополнительный компонент критического пути для управления и масштабирования, а также повлечет за собой дополнительные затраты для обеспечения глобальной высокой доступности. Однако это значительно упростит сценарий сбоя, обеспечивая согласованность между допустимыми и недопустимыми путями входящего трафика через Azure Front Door и Диспетчер трафика Azure, как с точки зрения выполнения WAF, так и с точки зрения конечных точек частных приложений.
  • Потеря пограничного кэширования в сценарии сбоя повлияет на общую производительность, и это должно быть согласовано с приемлемым уровнем обслуживания или подходом к устранению рисков. Чтобы обеспечить согласованный уровень обслуживания, рассмотрите возможность разгрузки пограничного кэширования в стороннем поставщике CDN для обоих путей.

Рекомендуется рассмотреть стороннюю глобальную службу маршрутизации вместо двух глобальных служб маршрутизации Azure. Это обеспечивает максимальный уровень устранения сбоев и более простой подход к проектированию, так как большинство ведущих поставщиков CDN в отрасли предлагают пограничные возможности, которые в значительной степени соответствуют возможностям Azure Front Door.

Azure Front Door

• Используйте службу управляемых сертификатов Azure Front Door, чтобы включить TLS-подключения и устранить необходимость управления жизненным циклом сертификатов.

• Используйте azure Front Door Брандмауэр веб-приложений (WAF), чтобы обеспечить защиту на границе от распространенных веб-эксплойтов и уязвимостей, таких как внедрение кода SQL.

• Используйте встроенный кэш Azure Front Door для обслуживания статического содержимого с граничных узлов.

  • В большинстве случаев это также устраняет необходимость в выделенной сети доставки содержимого (CDN).

• Настройте точки входящего трафика платформы приложений для проверки входящих запросов с помощью фильтрации на основе заголовков с помощью X-Azure-FDID , чтобы убедиться, что весь трафик проходит через настроенный экземпляр Front Door. Также рассмотрите возможность настройки IP-управления доступом с помощью тегов службы Front Door для проверки трафика, поступающего из пространства IP-адресов серверной части Azure Front Door и служб инфраструктуры Azure. Это обеспечит передачу трафика через Azure Front Door на уровне службы, но для использования настроенного экземпляра Front Door по-прежнему потребуется фильтрация на основе заголовков.

• Определите пользовательскую конечную точку работоспособности TCP для проверки критических зависимостей в пределах региональной метки развертывания, включая реплики платформы данных, такие как Azure Cosmos DB, в примере, предоставленном базовой эталонной реализацией. Если одна или несколько зависимостей становятся неработоспособными, проба работоспособности должна отразить это в возвращенном ответе, чтобы вывести из обращения всю региональную метку.

• Убедитесь, что ответы проб работоспособности регистрируются и поглотят все операционные данные, предоставляемые Azure Front Door, в глобальную рабочую область Log Analytics, чтобы упростить единый приемник данных и единое операционное представление во всем приложении.

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

  • Для этого задайте для параметра "Чувствительность к задержке (дополнительная задержка)" значение, достаточно высокое для удовлетворения различий задержки между различными регионами серверной части. Обеспечьте допустимость для рабочей нагрузки приложения в отношении общей задержки запросов клиента.

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

Azure Traffic Manager

• Используйте диспетчер трафика для сценариев, отличных от HTTP/S, в качестве замены Azure Front Door. Различия в возможностях определяют различные проектные решения для возможностей кэша и WAF, а также управления сертификатами TLS.

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

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

• Как и в случае с Azure Front Door, необходимо определить пользовательскую конечную точку работоспособности TCP для проверки критических зависимостей в пределах региональной метки развертывания, которая должна отражаться в ответе, предоставленном конечными точками работоспособности.

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

• Следует учитывать сторонние поставщики CDN, чтобы обеспечить пограничное кэширование при использовании диспетчера трафика Azure в качестве основной глобальной службы маршрутизации. Если возможности ПОГРАНИЧНОго WAF также предоставляются сторонней службой, следует учитывать, чтобы упростить путь входящего трафика и, возможно, устранить необходимость в Шлюз приложений.

Службы доставки приложений

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

В этом разделе рассматриваются рекомендации по глобальной маршрутизации путем изучения основных возможностей доставки приложений с учетом соответствующих служб, таких как Azure Load Balancer (цен. категория , Шлюз приложений Azure и Azure Управление API.

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

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

• Брандмауэр веб-приложений обеспечивает защиту от распространенных веб-эксплойтов и уязвимостей, таких как внедрение кода SQL или межсайтовые скрипты, и имеет важное значение для достижения максимальной надежности критически важного приложения.

• Azure WAF обеспечивает защиту от 10 основных уязвимостей OWASP с помощью управляемых наборов правил.

  • Для расширения управляемого набора правил также можно добавить настраиваемые правила.
  • Azure WAF можно включить в Azure Front Door, Шлюз приложений Azure или Azure CDN (в настоящее время находится в общедоступной предварительной версии).
    • Функции, предлагаемые в каждой из служб, немного отличаются. Например, WAF Azure Front Door обеспечивает ограничение скорости, геофильтрации и защиту от ботов, которые еще не предлагаются в Шлюз приложений WAF. Однако все они поддерживают как встроенные, так и пользовательские правила и могут работать в режиме обнаружения или предотвращения.
    • Стратегия для Azure WAF обеспечит согласованный набор функций WAF во всех интеграциях служб.

• Сторонние технологии WAF, такие как NVA и расширенные контроллеры входящего трафика в Kubernetes, также можно рассматривать для обеспечения необходимой защиты от уязвимостей.

• Оптимальная конфигурация WAF обычно требует точной настройки независимо от используемой технологии.

  Azure Front Door

• Azure Front Door принимает только трафик HTTP и HTTPS и обрабатывает только запросы с известным Host заголовком. Эта блокировка протокола помогает предотвратить объемные атаки, распределенные по протоколам и портам, а также атаки с усилением DNS и атаками с отравлением TCP.

• Azure Front Door — это глобальный ресурс Azure, поэтому конфигурация развертывается глобально во всех пограничных расположениях.

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

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

• Azure Front Door автоматически сменяет управляемые сертификаты по крайней мере за 60 дней до истечения срока действия сертификата, чтобы защититься от рисков, связанных с истекшим сроком действия сертификата. Если используются самоуправляемые сертификаты, обновленные сертификаты должны быть развернуты не позднее, чем за 24 часа до истечения срока действия существующего сертификата. В противном случае клиенты могут получить ошибки с истекшим сроком действия сертификата.

• Обновление сертификата приведет к простою только в том случае, если Azure Front Door переключается между "Управляемым" и "Использовать собственный сертификат".

• Azure Front Door защищена службой "Защита от атак DDoS Azure" уровня "Базовый", которая по умолчанию интегрирована в Front Door. Это обеспечивает постоянный мониторинг трафика, устранение рисков в режиме реального времени, а также защиту от распространенных наводнений запросов DNS уровня 7 или объемных атак уровня 3/4.

  • Эти меры защиты помогают поддерживать доступность Azure Front Door даже при атаке DDoS. Распределенные атаки типа "отказ в обслуживании" (DDoS) могут сделать целевой ресурс недоступным, подавляя его незаконным трафиком.

• Azure Front Door также предоставляет возможности WAF на глобальном уровне трафика, в то время как Шлюз приложений WAF должны быть предоставлены в каждой метке регионального развертывания. Возможности включают наборы правил брандмауэра для защиты от распространенных атак, геофильтрации, блокировки адресов, ограничения скорости и сопоставления подписей.

  Azure Load Balancer

• SKU azure Basic Load Balancer не поддерживается соглашением об уровне обслуживания и имеет несколько ограничений возможностей по сравнению со стандартным SKU.

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

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

• Используйте зашифрованные подключения (например, HTTPS) от точки, в которой происходит разгрузка TLS к фактической серверной части приложения. Конечные точки приложения не будут видны конечным пользователям, поэтому управляемые домены Azure, такие как azurewebsites.net или cloudapp.net, можно использовать с управляемыми сертификатами.

• Для трафика HTTP(S) убедитесь, что возможности WAF применяются в пути входящего трафика для всех общедоступных конечных точек.

• Включение возможностей WAF в одном расположении службы( глобально с помощью Azure Front Door или в регионе с помощью Шлюз приложений Azure), так как это упрощает настройку конфигурации и оптимизирует производительность и затраты.

  Настройте WAF в режиме предотвращения, чтобы напрямую блокировать атаки. Используйте WAF только в режиме обнаружения (т. е. только ведение журнала, но не блокировка подозрительных запросов), если производительность режима предотвращения слишком высока. Подразумеваемый дополнительный риск должен быть полностью понят и согласован с конкретными требованиями сценария рабочей нагрузки.

• Приоритизируйте использование AZURE Front Door WAF, так как она предоставляет самый богатый набор функций Azure и применяет средства защиты на глобальном пограничном сервере, что упрощает общую структуру и повышает эффективность.

• Используйте Azure Управление API только при предоставлении большого количества API внешним клиентам или разным командам приложений.

• Используйте номер SKU Load Balancer (цен. категория Azure для любого сценария распределения внутреннего трафика в рабочих нагрузках микрослужбы.

  • Предоставляет соглашение об уровне обслуживания 99,99 % при развертывании в Зоны доступности.
  • Предоставляет критически важные возможности, такие как диагностика или правила для исходящего трафика.

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

Кэширование и доставка статического содержимого

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

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

• Не все содержимое, которое решение делает доступным через Интернет, создается динамически. Приложения обслуживают как статические ресурсы (изображения, JavaScript, CSS, файлы локализации и т. д.), так и динамическое содержимое.
• Рабочие нагрузки с часто используемым статическим содержимым значительно выигрывают от кэширования, так как это снижает нагрузку на внутренние службы и уменьшает задержку доступа к содержимому для конечных пользователей.
• Кэширование можно реализовать изначально в Azure с помощью Azure Front Door или сети доставки содержимого Azure (CDN).
  • Azure Front Door предоставляет встроенные в Azure возможности пограничного кэширования и функции маршрутизации для разделения статического и динамического содержимого.
    • Создав соответствующие правила маршрутизации в Azure Front Door, /static/* трафик можно прозрачно перенаправлять в статическое содержимое.
  • Более сложные сценарии кэширования можно реализовать с помощью службы Azure CDN , чтобы создать полноценную сеть доставки содержимого для значительных объемов статического содержимого.
    • Служба Azure CDN, скорее всего, будет более экономичной, но не предоставляет те же расширенные возможности маршрутизации и Брандмауэр веб-приложений (WAF), которые рекомендуются для других областей проектирования приложений. Однако она обеспечивает дополнительную гибкость для интеграции с аналогичными службами сторонних решений, таких как Akamai и Verizon.
  • При сравнении служб Azure Front Door и Azure CDN следует изучить следующие факторы принятия решений:
    • Может требоваться выполнение правил кэширования с помощью обработчика правил.
    • Размер сохраненного содержимого и связанные с ним затраты.
    • Цена в месяц за выполнение обработчика правил (взимается за запрос в Azure Front Door).
    • Требования к исходящему трафику (цена зависит от назначения).

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

• Созданное статическое содержимое, например копии файлов изображений размером, которые никогда или редко изменяются, также могут воспользоваться преимуществами кэширования. Кэширование можно настроить на основе параметров URL-адреса и с разной длительностью кэширования.
• Отделяйте доставку статического и динамического содержимого пользователям и доставляйте соответствующее содержимое из кэша, чтобы снизить нагрузку на внутренние службы, оптимизировать производительность для конечных пользователей.
• Учитывая строжную рекомендацию (область проектирования сети и подключений) использовать Azure Front Door для глобальной маршрутизации и Брандмауэр веб-приложений (WAF), рекомендуется приоритизировать использование возможностей кэширования Azure Front Door, если не существует пробелов.

Интеграция виртуальной сети

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

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

1. Общедоступное приложение без подключения к корпоративной сети.
2. Общедоступное приложение с корпоративным сетевым подключением.
3. Частное приложение с корпоративным сетевым подключением.

Внимание!

При развертывании в целевой зоне Azure конфигурация 1. должен быть развернут в целевой зоне в сети, а 2) и 3) должны быть развернуты в корпоративной подключенной целевой зоне для упрощения интеграции на уровне сети.

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

Вопросы проектирования

Нет виртуальных сетей

• Самый простой подход к проектированию — не развертывать приложение в виртуальной сети.

  • Подключение между всеми рассматриваемыми службами Azure будет полностью обеспечиваться через общедоступные конечные точки и магистраль Microsoft Azure. Подключение между общедоступными конечными точками, размещенными в Azure, будет проходить только через магистраль Майкрософт и не будет проходить через общедоступный Интернет.
  • Подключение к любым внешним системам за пределами Azure будет осуществляться через общедоступный Интернет.

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

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

Изолированные виртуальные сети

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

• Для входящих клиентских запросов по-прежнему требуется доступ к общедоступной конечной точке в Интернете, однако все последующие подключения могут осуществляться в виртуальной сети с помощью частных конечных точек. При использовании Azure Front Door уровня "Премиум" можно маршрутизировать непосредственно с граничных узлов к частным конечным точкам приложения.

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

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

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

• Бастион Azure — это полностью управляемая платформой служба PaaS, которая может быть развернута в виртуальной сети и обеспечивает безопасное подключение RDP/SSH к виртуальным машинам Azure. При подключении через Бастион Azure виртуальным машинам не требуется общедоступный IP-адрес.

• Использование виртуальных сетей приложений значительно усложняет развертывание в конвейерах CI/CD, так как для упрощения развертывания приложений требуется доступ к ресурсам, размещенным в частных сетях, как на уровне данных, так и на уровне управления.

  • Необходимо установить безопасный путь частной сети, чтобы инструменты CI/CD могли выполнять необходимые действия.
  • Частные агенты сборки можно развернуть в виртуальных сетях приложения для прокси-доступа к ресурсам, защищенным виртуальной сетью.

Подключенные виртуальные сети

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

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

• Перекрытие пространств IP-адресов в регионах Azure или локальных сетях приведет к серьезным состязаниям при учете сетевой интеграции.

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

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

  • Канал ExpressRoute может иметь размер для обеспечения пропускной способности до 100 Гбит/с.
  • Размер виртуальной частной сети (VPN) позволяет обеспечить совокупную пропускную способность до 10 Гбит/с в центральной и периферийной сетях и до 20 Гбит/с в Azure Виртуальная глобальная сеть.

Примечание

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

• Включение дополнительных сетевых путей и ресурсов повышает надежность и работоспособность приложения, чтобы обеспечить работоспособность.

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

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

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

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

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

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

  • Настоятельно рекомендуется использовать только IP-адреса из выделения адресов для частного Интернета (RFC 1918).
    • Для сред с ограниченной доступностью частных IP-адресов (RFC 1918) рекомендуется использовать IPv6.
    • Если требуется использовать общедоступный IP-адрес, убедитесь, что используются только собственные блоки адресов.
  • Согласуйтесь с планами организации по IP-адресации в Azure, чтобы обеспечить, чтобы пространство IP-адресов сети приложений не перекрывалось с другими сетями в локальных расположениях или регионах Azure.
  • Не создавайте неоправданно большие виртуальные сети приложений, чтобы пространство IP-адресов не тратилось впустую.

• Присвойте приоритет использованию Azure CNI для интеграции с сетью AKS, так как она поддерживает более широкий набор функций.

  • Рассмотрим Kubenet для сценариев с ограниченным количеством доступных IP-адресов в соответствии с приложением в ограниченном диапазоне адресов.

  • Приоритезируете использование сетевого подключаемого модуля Azure CNI для интеграции с сетью AKS и рассмотрите возможность использования Kubenet для сценариев с ограниченным диапазоном доступных IP-адресов. Дополнительные сведения см. в статье Микросемпция и политики сети Kubernetes .

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

  • Убедитесь, что уровень надежности, применяемый к Express Route или VPN, полностью соответствует требованиям приложения.
  • Следует учитывать несколько сетевых путей, чтобы обеспечить дополнительную избыточность при необходимости, например каналы ExpressRoute с перекрестным подключением или использование VPN в качестве механизма подключения отработки отказа.

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

  Примечание

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

• Используйте Бастион Azure или прокси-частные подключения для доступа к плоскости данных ресурсов Azure или выполнения операций управления.

Исходящий интернет-трафик

Исходящий интернет-трафик является базовым сетевым требованием для критически важных приложений для упрощения внешней связи в контексте:

1. Прямое взаимодействие с пользователем приложения.
2. Интеграция приложений с внешними зависимостями за пределами Azure.
3. Доступ к внешним зависимостям, необходимым службам Azure, используемым приложением.

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

Вопросы проектирования

• Многим службам Azure требуется доступ к общедоступным конечным точкам, чтобы различные функции уровня управления и управления работали должным образом.

• Azure предоставляет различные методы прямого исходящего подключения к Интернету, такие как шлюз NAT Azure или Azure Load Balancer, для виртуальных машин или вычислительных экземпляров в виртуальной сети.

• Когда трафик из виртуальной сети передается в Интернет, необходимо выполнить преобразование сетевых адресов (NAT). Это вычислительная операция, которая выполняется в сетевом стеке и, следовательно, может повлиять на производительность системы.

• Если NAT выполняется в небольшом масштабе, влияние на производительность должно быть незначительным, однако при наличии большого количества исходящих запросов могут возникнуть проблемы с сетью. Эти проблемы обычно возникают в виде нехватки портов NAT источника (или SNAT).

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

• Помимо ограничений NAT, исходящий трафик также может подвергаться необходимым проверкам безопасности.

  • Брандмауэр Azure предоставляет соответствующие возможности безопасности для защиты исходящего сетевого трафика.

  • Брандмауэр Azure (или эквивалентный NVA) можно использовать для защиты требований к исходящему трафику Kubernetes, предоставляя детализированный контроль над потоками исходящего трафика.

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

Шлюз Azure NAT

• Шлюз Azure NAT поддерживает 64 000 подключений для TCP и UDP на назначенный исходящий IP-адрес.

  • Одному шлюзу NAT можно назначить до 16 IP-адресов.
  • Время ожидания простоя TCP по умолчанию 4 минуты. Если время ожидания простоя изменится на более высокое значение, потоки будут храниться дольше, что приведет к увеличению нагрузки на инвентаризацию портов SNAT.

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

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

• Сведите к минимуму количество исходящих подключений к Интернету, так как это повлияет на производительность NAT.

  • Если требуется большое количество подключений к Интернету, рассмотрите возможность использования шлюза NAT Azure для абстрагирования потоков исходящего трафика.

• Используйте Брандмауэр Azure, где существуют требования для контроля и проверки исходящего интернет-трафика.

  • Убедитесь, что Брандмауэр Azure не используется для проверки трафика между службами Azure.

Примечание

При развертывании в целевой зоне Azure рекомендуется использовать базовую платформу Брандмауэр Azure ресурса (или эквивалентного NVA). Если зависимость взята от центрального ресурса платформы для исходящего трафика в Интернете, то уровень надежности этого ресурса и связанный сетевой путь должны быть тесно согласованы с требованиями приложения. Операционные данные из ресурса также должны быть доступны приложению для информирования о возможных операционных действиях в сценариях сбоя.

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

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

Подключение между зонами и регионами

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

Вопросы проектирования

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

• Зона доступности (AZ) — это физическое расположение центра обработки данных в регионе Azure, обеспечивающее физическую и логическую изоляцию сбоя до уровня одного центра обработки данных.

  Для обмена данными между зонами гарантируется задержка кругового пути менее 2 мс. Зоны будут иметь небольшую дисперсию задержки с учетом различных расстояний и волоконных путей между зонами.

• Подключение зоны доступности зависит от региональных характеристик, и поэтому трафик, поступающий в регион через пограничное расположение, может потребоваться маршрутизировать между зонами, чтобы добраться до места назначения. Это добавит задержку примерно в 1 мс–2 мс с учетом ограничений маршрутизации между зонами и "скорости света", но это должно иметь отношение только к гиперчувствительным рабочим нагрузкам.

• Зоны доступности рассматриваются как логические сущности в контексте одной подписки, поэтому разные подписки могут иметь разное зональное сопоставление для одного региона. Например, зона 1 в подписке A может соответствовать тому же физическому центру обработки данных, что и зона 2 в подписке B.

• При обмене данными между зонами в пределах региона взимается плата за каждый ГБ пропускной способности.

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

• При обмене данными между разными регионами Azure взимается большая плата за передачу данных за ГБ пропускной способности.

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

• Методы Express Route и VPN-подключения также можно использовать для прямого соединения разных регионов Azure в определенных сценариях или даже на разных облачных платформах.

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

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

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

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

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

• Используйте пиринг виртуальных сетей для подключения сетей в пределах региона и в разных регионах. Настоятельно рекомендуется избегать закрепления волос в Express Route.

• Используйте Приватный канал для установления связи непосредственно между службами в одном регионе или между регионами (служба в регионе A, взаимодействующая со службой в регионе Б).

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

• По возможности рассматривайте каждую метку развертывания как независимую и отключенную от других меток.

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

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

Политики микросекций и сети Kubernetes

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

Критически важное приложение может обеспечить безопасность сети на уровне приложения с помощью групп безопасности сети (NSG) на уровне подсети или сетевого интерфейса, списков контроль доступа служб (ACL) и сетевых политик при использовании Служба Azure Kubernetes (AKS).

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

Вопросы проектирования

• AKS можно развернуть в двух разных сетевых моделях:

  • Сеть Kubenet: Узлы AKS интегрированы в существующую виртуальную сеть, но модули pod существуют в виртуальной сети наложения на каждом узле. Трафик между модулями pod на разных узлах направляется через kube-proxy.
  • Сеть azure Container Networking Interface (CNI): Кластер AKS интегрирован в существующую виртуальную сеть, и его узлы, модули pod и службы получили IP-адреса из той же виртуальной сети, к которому подключены узлы кластера. Это актуально для различных сетевых сценариев, требующих прямого подключения между модулями pod и к ней. Разные пулы узлов можно развернуть в разных подсетях.

  Примечание

  Azure CNI требует больше пространства IP-адресов по сравнению с Kubenet. Требуется правильное предварительное планирование и определение размера сети. Дополнительные сведения см. в документации по Azure CNI.

• По умолчанию модули pod неизолируются и принимают трафик из любого источника и могут отправлять трафик в любое место назначения; модуль pod может взаимодействовать с каждым другим модулем pod в заданном кластере Kubernetes; Kubernetes не обеспечивает изоляцию на уровне сети и не изолирует пространства имен на уровне кластера.

• Обмен данными между модулями Pod и пространствами имен можно изолировать с помощью политик сети. Политика сети — это спецификация Kubernetes, определяющая политики доступа для обмена данными между группами pod. С помощью политик сети можно определить упорядоченный набор правил для управления отправкой и получением трафика и применить к коллекции модулей pod, соответствующих одному или нескольким селекторам меток.

  • AKS поддерживает два подключаемых модуля, реализующих политику сети: Azure и Calico. Оба подключаемых модуля используют IPTables Linux для применения указанных политик. Дополнительные сведения см. в статье Различия между политиками Azure и Calico и их возможности .
  • Сетевые политики не конфликтуют, так как они аддитивные.
  • Чтобы сетевой поток между двумя модулями pod был разрешен, как политика исходящего трафика в исходном модуле pod, так и политика входящего трафика в целевом модуле pod должны разрешить трафик.
  • Функцию политики сети можно включить только во время создания экземпляра кластера. Невозможно включить политику сети в существующем кластере AKS.
  • Доставка сетевых политик является согласованной независимо от того, используется ли Azure или Calico.
  • Calico предоставляет более широкий набор функций, включая поддержку windows-nodes и Azure CNI, а также Kubenet.

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

  • Использование пулов узлов не обеспечивает изоляцию на уровне сети.
  • Пулы узлов могут использовать разные подсети в одной виртуальной сети. Группы безопасности сети можно применять на уровне подсети для реализации микросегации между пулами узлов.

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

• Настройте группу безопасности сети во всех рассматриваемых подсетях, чтобы предоставить ACL IP для защиты путей входящего трафика и изоляции компонентов приложения на основе модели "Никому не доверяй".

  • Используйте теги службы Front Door в группах безопасности сети во всех подсетях, содержащих серверные части приложений, определенные в Azure Front Door, так как это позволит проверить, что трафик поступает из допустимого пространства IP-адресов серверной части Azure Front Door. Это обеспечит передачу трафика через Azure Front Door на уровне службы, но фильтрация на основе заголовков по-прежнему потребуется для обеспечения использования конкретного экземпляра Front Door, а также для устранения рисков безопасности ip-спуфингов.

  • Общедоступный интернет-трафик должен быть отключен на портах RDP и SSH во всех применимых группах безопасности сети.

  • Приоритезировать использование подключаемого модуля сети Azure CNI и рассмотреть Kubenet для сценариев с ограниченным диапазоном доступных IP-адресов для размещения приложения в ограниченном диапазоне адресов.

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

• Функцию Политики сети в Kubernetes следует использовать для определения правил входящего и исходящего трафика между модулями pod в кластере. Определите детализированные политики сети, чтобы ограничить и ограничить обмен данными между модулями pod.

  • Включите политику сети для Служба Azure Kubernetes во время развертывания.
  • Приоритизировать использование Calico , так как он предоставляет более широкий набор функций с более широким внедрением и поддержкой сообщества.

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

Ознакомьтесь с рекомендациями по количественной оценке и наблюдению за работоспособностью приложений.

Моделирование и наблюдаемость работоспособности