Сеть и подключение для критически важных рабочих нагрузок в 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 в любом случае не дает большого значения.

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

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

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

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

• Если управление клиентом невозможно, операционные средства устранения рисков можно рассмотреть для определения процесса миграции на вторичную глобальную службу маршрутизации, если глобальный сбой отключает основную службу. Миграция из одной глобальной службы маршрутизации в другую обычно является длительным процессом, длиющимся несколько часов, особенно когда рассматривается распространение 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 с помощью Azure DDoS Protection Basic. Служба "Стандартный" 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

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

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

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

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

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

  • Однако в отличие от Azure Front Door это удаление неработоспособных серверных серверов не является мгновенным, так как клиенты будут продолжать создавать подключения к неработоспособной серверной части до истечения срока действия DNS TTL, а новая серверная конечная точка запрашивается из службы Диспетчер трафика.
  • Кроме того, даже если срок действия TTL истекает, не гарантируется, что общедоступные 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, использующих Диспетчер трафика 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-ПИИD , чтобы убедиться, что весь трафик проходит через настроенный экземпляр 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Сторонние технологии WAF, такие как NVAs и расширенные контроллеры входящего трафика в 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 защищена azure DDoS Protection Basic, которая по умолчанию интегрирована в Front Door. Это обеспечивает постоянный мониторинг трафика, устранение рисков в режиме реального времени, а также защищает от распространенных наводнений DNS-запросов уровня 7 или атак уровня 3/4.

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

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

  Azure Load Balancer

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

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

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

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

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

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

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

• Определите приоритет использования WAF Azure Front Door, так как он предоставляет самый богатый набор функций 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 Premium можно направлять непосредственно из пограничных узлов в частные конечные точки приложений.

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

  • При поддержке подключения к службам платформы 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 предоставляет различные методы прямого исходящего подключения к Интернету, такие как шлюз Azure NAT или Azure Load Balancer, для виртуальных машин или вычислительных экземпляров в виртуальной сети.

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

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

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

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

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

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

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

Шлюз Azure NAT

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

• Зоны доступности рассматриваются как логические сущности в контексте одной подписки, поэтому разные подписки могут иметь другое зональное сопоставление для одного региона. Например, зона 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, взаимодействующая со службой в регионе B.

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

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

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

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

Политики сети Микро-сегментации и Kubernetes

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

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

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

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

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

  • Сеть Kubenet: узлы AKS интегрированы в существующую виртуальную сеть, но модули pod существуют в виртуальной сети наложения на каждом узле. Трафик между модулями pod на разных узлах направляется через kube-proxy.
  • Сеть интерфейса сети контейнеров Azure (CNI): кластер AKS интегрирован в существующую виртуальную сеть и ее узлы, модули pod и службы, полученные IP-адреса из той же виртуальной сети, к которому подключены узлы кластера. Это важно для различных сетевых сценариев, требующих прямого подключения между модулями pod и модулями 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, так и политике входящего трафика в целевом модуле.
  • Функция политики сети может быть включена только во время создания экземпляра кластера. Невозможно включить политику сети в существующем кластере AKS.
  • Доставка политик сети согласована независимо от того, используется ли Azure или Calico.
  • Calico предоставляет более широкий набор функций, включая поддержку узлов Windows и поддерживает Azure CNI, а также Kubenet.

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

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

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

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

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

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

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

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

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

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

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

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

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