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

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

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

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

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

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

• Оповещение — оповещения о проблемах или сбоях в инфраструктуре и приложении.

• Анализ сбоев — разбивка и анализ любых сбоев, включая документацию по первопричине.

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

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

Служба работоспособности приложения

Приложение служба работоспособности (HealthService) — это компонент приложения, который находится в службе каталогов (CatalogService) и фоновом обработчике (BackgroundProcessor) в вычислительном кластере. Служба работоспособности предоставляет REST API для Azure Front Door для вызова для определения работоспособности метки. HealthService — это сложный компонент, который отражает состояние зависимостей, помимо собственного.

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

• Он пытается выполнить запрос к Azure Cosmos DB.

• Она пытается отправить сообщение в Центры событий. Сообщение отфильтровывается фоновой рабочей ролью.

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

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

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

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

Настройка

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

Параметр	Значение
HealthServiceCacheDurationSeconds	Управляет временем истечения срока действия кэша памяти в секундах.
HealthServiceStorageConnectionString	строка Подключение для учетной записи служба хранилища, в которой должен присутствовать файл состояния.
HealthServiceBlobContainerName	служба хранилища Контейнер, в котором должен присутствовать файл состояния.
HealthServiceBlobName	Имя файла состояния — проверка работоспособности будет искать этот файл.
HealthServiceOverallTimeoutSeconds	Время ожидания для всего проверка — по умолчанию — 3 секунды. Если проверка не завершается в этом интервале, служба сообщает о неработоспособном состоянии.

Внедрение

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

Результаты проверки кэшируются в памяти с помощью стандартной не распределенной ASP.NET Core MemoryCache. Срок действия кэша SysConfig.HealthServiceCacheDurationSeconds управляется и по умолчанию имеет значение 10 секунд.

Примечание.

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

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

Компонент	Проверка работоспособности
BLOB-объект учетной записи служба хранилища	В настоящее время большой двоичный объект проверка служит двумя целями: 1. Проверьте, можно ли достичь служба хранилища BLOB-объектов. Учетная запись хранения используется другими компонентами в метке и считается критически важным ресурсом. 2. Вручную отключите регион, удалив файл состояния. Было принято решение о том, что проверка будет искать только наличие файла состояния в указанном контейнере BLOB-объектов. Содержимое файла не обрабатывается. Существует возможность настроить более сложную систему, которая считывает содержимое файла и возвращает другое состояние в зависимости от содержимого файла. Примерами содержимого являются РАБОТОСПОСОБНЫЕ, НЕРАБОТОСПОСОБНЫЕ и ОБСЛУЖИВАНИЕ. Удаление файла состояния отключит метку. Убедитесь, что файл работоспособности присутствует после развертывания приложения. Отсутствие файла работоспособности приведет к тому, что служба всегда реагирует на НЕРАБОТОСПОСОБНУЮ работу. Front Door не распознает серверную часть как доступную. Файл создается Terraform и должен присутствовать после развертывания инфраструктуры.
Концентратор событий	Отчеты о работоспособности Центров событий обрабатываются EventHubProducerService. Эта служба сообщает о работоспособности, если она может отправить новое сообщение в Центры событий. Для фильтрации это сообщение содержит свойство, которое было добавлено в него HEALTHCHECK=TRUE . Это сообщение игнорируется на принимающем конце. Параметр AlwaysOn.BackgroundProcessor.EventHubProcessorService.ProcessEventHandlerAsync() конфигурации проверка для HEALTHCHECK свойства.
Azure Cosmos DB	Отчет о работоспособности Azure Cosmos DB обрабатывается отчетом CosmosDbServiceо работоспособности, если это: 1. Возможность подключиться к базе данных Azure Cosmos DB и выполнить запрос. 2. Возможность записи тестового документа в базу данных. Тестовый документ содержит короткий набор времени в реальном времени, Azure Cosmos DB автоматически удаляет его. Служба работоспособности выполняет две отдельные пробы. Если Azure Cosmos DB находится в состоянии, где операции чтения работают и записи не выполняются, два пробы гарантируют, что оповещение активируется.

Запросы Azure Cosmos DB

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

SELECT GetCurrentDateTime ()

Запрос на запись создает фиктивную с ItemRating минимальным содержимым:

var testRating = new ItemRating()
{
    Id = Guid.NewGuid(),
    CatalogItemId = Guid.NewGuid(), // Create some random (=non-existing) item id
    CreationDate = DateTime.UtcNow,
    Rating = 1,
    TimeToLive = 10 // will be auto-deleted after 10sec
};

await AddNewRatingAsync(testRating);

Наблюдение

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

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

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

Мониторинг: источники данных

• Параметры диагностики: все службы Azure, используемые для критически важных задач Azure, настроены для отправки всех диагностических данных, включая журналы и метрики в рабочую область Log Analytics для развертывания (глобальная или метка). Этот процесс выполняется автоматически в рамках развертывания Terraform. Новые параметры будут автоматически идентифицированы и добавлены в составе terraform apply.

• Мониторинг Kubernetes: параметры диагностики используются для отправки журналов и метрик AKS в Log Analytics. AKS настроен для использования Аналитика контейнера. Контейнер Аналитика развертывает OMSAgentForLinus с помощью DaemonSet Kubernetes на каждом узле в кластерах AKS. OMSAgentForLinux может собирать дополнительные журналы и метрики из кластера Kubernetes и отправлять их в соответствующую рабочую область Log Analytics. Эти дополнительные журналы и метрики содержат более детализированные данные о модулях pod, развертываниях, службах и общей работоспособности кластера. Чтобы получить больше аналитических сведений от различных компонентов, таких как ingress-nginx, cert-manager и другие компоненты, развернутые в Kubernetes рядом с критически важной рабочей нагрузкой, можно использовать скребок Prometheus. Очистка Prometheus настраивает OMSAgentForLinux для удаления метрик Prometheus из различных конечных точек в кластере.

• Приложение Аналитика телеметрии: Аналитика приложения используется для сбора данных телеметрии из приложения. Код был инструментирован для сбора данных о производительности приложения с помощью пакета SDK для приложений Аналитика. Собираются критически важные сведения, например результирующий код состояния и длительность вызовов зависимостей и счетчиков необработанных исключений. Эта информация используется в модели работоспособности и доступна для оповещения и устранения неполадок.

Мониторинг: тесты доступности приложений Аналитика

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

• Региональные тесты доступности: эти тесты настраиваются в экземплярах регионального приложения Аналитика и используются для мониторинга доступности меток. Эти тесты предназначены для кластеров и статических учетных записей хранения меток напрямую. Чтобы вызвать точки входящего трафика кластеров напрямую, запросы должны иметь правильный заголовок Идентификатора Front Door, в противном случае они отклоняются контроллером входящего трафика.

• Глобальный тест доступности: эти тесты настраиваются в глобальном экземпляре приложения Аналитика и используются для мониторинга доступности общего решения путем подключения Front Door. Используются два теста: один для тестирования вызова API к CatalogService и один для проверки домашней страницы веб-сайта.

Мониторинг: запросы

Azure Mission-Critical использует различные запросы язык запросов Kusto (KQL) для реализации пользовательских запросов в качестве функций для получения данных из Log Analytics. Эти запросы хранятся в виде отдельных файлов в нашем репозитории кода, разделенных для глобальных развертываний и развертываний меток. Они импортируются и применяются автоматически через Terraform в рамках каждого запуска конвейера инфраструктуры.

Этот подход отделяет логику запроса от слоя визуализации. Запросы Log Analytics вызываются непосредственно из кода, например из API HealthService. Другим примером является средство визуализации, например панели мониторинга Azure, мониторинг книг или Grafana.

Мониторинг: визуализация

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

Дополнительные сведения см. в разделе "Визуализация".

Оповещение

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

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

Дополнительные сведения см. в статье "Автоматизированное реагирование на инциденты".

Анализ сбоев

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

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

Service	Риск	Влияние, устранение рисков и комментарий	Отказ
Идентификатор Microsoft Entra	Идентификатор Microsoft Entra становится недоступным.	В настоящее время нет возможных мер по устранению рисков. Подход с несколькими регионами не будет устранять какие-либо сбои, так как это глобальная служба. Эта служба является жесткой зависимостью. Идентификатор Microsoft Entra используется для операций уровня управления, таких как создание новых узлов AKS, извлечение образов контейнеров из ACR или доступ к Key Vault при запуске pod. Ожидается, что существующие, работающие компоненты должны поддерживать работу при возникновении проблем с идентификатором Microsoft Entra. Скорее всего, новые модули pod или узлы AKS не смогут создаваться. В операциях масштабирования в течение этого времени это может привести к снижению взаимодействия с пользователем и потенциально сбоям.	Частично
Azure DNS	Azure DNS становится недоступным, и разрешение DNS завершается ошибкой.	Если Azure DNS становится недоступным, разрешение DNS для запросов пользователей и между различными компонентами приложения, скорее всего, завершится ошибкой. В настоящее время никаких возможных мер по устранению рисков для этого сценария невозможно. Подход с несколькими регионами не будет устранять какие-либо сбои, так как это глобальная служба. Azure DNS — это жесткая зависимость. Внешние службы DNS в качестве резервного копирования не помогут, так как все компоненты PaaS, используемые в Azure DNS. Обход DNS путем переключения на IP-адрес не является вариантом. У служб Azure нет статических, гарантированных IP-адресов.	Полный
Front Door	Общий сбой Front Door.	Если Front Door выходит из строя полностью, нет никаких мер по устранению рисков. Эта служба является жесткой зависимостью.	Да
Front Door	Ошибки конфигурации маршрутизации, внешнего интерфейса или серверной части.	Может произойти из-за несоответствия конфигурации при развертывании. Необходимо поймать на этапах тестирования. Конфигурация внешнего интерфейса с DNS зависит от каждой среды. Устранение неполадок: откат к предыдущей конфигурации должен устранить большинство проблем. Так как изменения занимают несколько минут в Front Door для развертывания, это приведет к сбою.	Полный
Front Door	Удаляется управляемый TLS/SSL-сертификат.	Может произойти из-за несоответствия конфигурации при развертывании. Необходимо поймать на этапах тестирования. Технически сайт по-прежнему будет работать, но ошибки сертификатов TLS/SSL помогут предотвратить доступ пользователей к нему. Устранение рисков. Повторное выдача сертификата может занять около 20 минут, а также исправление и повторное выполнение конвейера.	Полный
Azure Cosmos DB	База данных или коллекция переименована.	Может произойти из-за несоответствия конфигурации при развертывании — Terraform перезаписывает всю базу данных, что может привести к потере данных. Потери данных можно предотвратить с помощью блокировок уровня базы данных или коллекции. Приложение не сможет получить доступ к данным. Необходимо обновить конфигурацию приложения и перезапустить модули pod.	Да
Azure Cosmos DB	Сбой в регионе	Служба "Критически важный для Azure" включает записи в нескольких регионах. Если на чтение или запись произошел сбой, клиент повторите текущую операцию. Все будущие операции окончательно направляются в следующий регион в порядке предпочтения. Если в списке предпочтений есть одна запись (или пустая), но у учетной записи есть другие регионы, она будет направляться в следующий регион в списке учетных записей.	No
Azure Cosmos DB	Обширное регулирование из-за отсутствия ЕЗ.	В зависимости от количества единиц запросов и балансировки нагрузки, используемых на уровне Front Door, некоторые метки могут запускаться горяче в использовании Azure Cosmos DB, а другие метки могут обслуживать больше запросов. Устранение рисков. Лучшее распределение нагрузки или больше единиц запросов.	No
Azure Cosmos DB	Полная секция	Ограничение размера логического раздела Azure Cosmos DB составляет 20 ГБ. Если данные для ключа секции в контейнере достигают этого размера, дополнительные запросы записи завершаются ошибкой "Ключ секции достиг максимального размера".	Частично (отключено запись базы данных)
Реестр контейнеров Azure;	Сбой в регионе	Реестр контейнеров использует Диспетчер трафика для отработки отказа между регионами реплика. Любой запрос должен быть автоматически перенаправлен в другой регион. В худшем случае образы Docker не могут быть извлечены в течение нескольких минут узлами AKS в то время как отработка отказа DNS происходит.	No
Реестр контейнеров Azure;	Удаленные изображения	Изображения не могут быть извлечены. Этот сбой должен влиять только на вновь созданные или перезагруженные узлы. Существующие узлы должны кэшировать образы. **Устранение рисков. Если обнаружено быстрое повторное выполнение последних конвейеров сборки, образы должны вернуться в реестр.	No
Реестр контейнеров Azure;	Регулирование	Регулирование может отложить операции горизонтального масштабирования, которые могут привести к временному снижению производительности. Устранение рисков. Служба "Критически важный для Azure" использует номер SKU уровня "Премиум", который предоставляет 10 тысяч операций чтения в минуту. Образы контейнеров оптимизированы и имеют только небольшое количество слоев. ImagePullPolicy имеет значение IfNotPresent, чтобы сначала использовать локально кэшированные версии. Примечание. Извлечение образа контейнера состоит из нескольких операций чтения в зависимости от количества слоев. Количество операций чтения в минуту ограничено и зависит от размера SKU ACR.	No
Служба Azure Kubernetes (AKS)	Сбой обновления кластера	Обновления узлов AKS должны выполняться в разные периоды между метками. Если одно обновление завершается сбоем, другой кластер не должен быть затронут. Обновления кластера должны развертываться в последовательном режиме между узлами, чтобы предотвратить недоступность всех узлов.	No
Служба Azure Kubernetes (AKS)	Модуль pod приложения убит при обслуживании запроса.	Это может привести к ошибкам конечного пользователя и плохому интерфейсу пользователя. Устранение рисков: Kubernetes по умолчанию удаляет модули pod в корректном режиме. Модули Pod удаляются из служб сначала, а рабочая нагрузка получает SIGTERM с льготным периодом, чтобы завершить открытые запросы и записать данные перед завершением. Код приложения должен понимать SIGTERM, а льготный период может потребоваться изменить, если рабочая нагрузка занимает больше времени для завершения работы.	No
Служба Azure Kubernetes (AKS)	Емкость вычислений недоступна в регионе для добавления дополнительных узлов.	Операции увеличения и увеличения масштаба завершаются ошибкой, но не должны влиять на существующие узлы и их операции. В идеале трафик должен автоматически перемещаться в другие регионы для балансировки нагрузки.	No
Служба Azure Kubernetes (AKS)	Подписка достигает квоты ядра ЦП для добавления новых узлов.	Операции увеличения и увеличения масштаба завершаются ошибкой, но не должны влиять на существующие узлы и их операции. В идеале трафик должен автоматически перемещаться в другие регионы для балансировки нагрузки.	No
Служба Azure Kubernetes (AKS)	Давайте зашифруем TLS/SSL-сертификаты не могут быть выданы или продлены.	Кластер должен сообщать о неработоспособном направлении в Front Door и трафик должен перейти на другие метки. Устранение неполадок. Изучение первопричин проблемы или обновления сбоя.	No
Служба Azure Kubernetes (AKS)	Если запросы и ограничения ресурсов настроены неправильно, модули pod могут достигать 100 % использования ЦП и неудачных запросов. Механизм повторных попыток приложения должен иметь возможность восстановить неудачные запросы. Повторные попытки могут привести к более длительной продолжительности запроса, не отображая ошибку клиенту. Чрезмерная нагрузка в конечном итоге приведет к сбою.	Нет (если загрузка не чрезмерна)
Служба Azure Kubernetes (AKS)	3-сторонние образы контейнеров / реестр недоступны	Для некоторых компонентов, таких как cert-manager и ingress-nginx, требуется скачивание образов контейнеров и диаграмм helm из внешних реестров контейнеров (исходящий трафик). Если один или несколько из этих репозиториев или образов недоступны, новые экземпляры на новых узлах (где образ еще не кэширован) могут не запускаться. Возможное устранение рисков. В некоторых сценариях может быть целесообразно импортировать 3-сторонние образы контейнеров в реестр контейнеров для каждого решения. Это добавляет дополнительную сложность и следует тщательно планировать и выполнять операции.	Частично (во время операций масштабирования и обновления и обновления)
Концентратор событий	Сообщения не могут отправляться в Центры событий	Метка становится неиспользуемой для операций записи. Служба работоспособности должна автоматически обнаруживать это и принимать метку из поворота.	No
Концентратор событий	Сообщения не могут быть прочитаны фоновым обработчиком	Сообщения будут в очереди. Сообщения не должны быть потеряны, так как они сохраняются. В настоящее время этот сбой не охватывается служба работоспособности. Для обнаружения ошибок в считывающих сообщениях следует выполнять мониторинг и оповещения. Устранение неполадок. Метка должна быть отключена вручную, пока проблема не будет устранена.	No
Учетная запись хранения	служба хранилища учетная запись становится неиспользуемой рабочей ролью для центров событий проверка	Метка не обрабатывает сообщения из Центров событий. Учетная запись хранения также используется Службой работоспособности. Ожидаемые проблемы с хранилищем должны быть обнаружены службой работоспособности, и метка должна быть снята из смены. Можно ожидать, что другие службы в метке будут затронуты одновременно.	No
Учетная запись хранения	Статический веб-сайт сталкивается с проблемами.	Если обслуживание статического веб-сайта сталкивается с проблемами, эта ошибка должна быть обнаружена Front Door. Трафик не будет отправлен в эту учетную запись хранения. Кэширование в Front Door также может облегчить эту проблему.	No
Хранилище ключей	Key Vault недоступно для GetSecret операций.	В начале новых модулей pod драйвер AKS CSI получит все секреты из Key Vault и завершится сбоем. Модули Pod не смогут запускаться. Автоматическое обновление в настоящее время выполняется каждые 5 минут. Обновление завершится ошибкой. Ошибки должны отображаться, kubectl describe pod но модуль pod продолжает работать.	No
Хранилище ключей	Key Vault недоступно для GetSecret операций или SetSecret операций.	Не удается выполнить новые развертывания. В настоящее время этот сбой может привести к остановке всего конвейера развертывания, даже если затрагивается только один регион.	No
Хранилище ключей	Регулирование Key Vault	Key Vault имеет ограничение в 1000 операций в 10 секунд. Из-за автоматического обновления секретов вы могли бы в теории ударить это ограничение, если у вас было много (тысячи) модулей pod в метке. Возможное устранение рисков: уменьшение частоты обновления еще больше или полностью отключает его.	No
Приложение	Неправильные настройки	Неверные строка подключения или секреты, внедренные в приложение. Следует устранить с помощью автоматического развертывания (автоматическая настройка конвейера) и сине-зеленого развертывания обновлений.	No
Приложение	Истекшие учетные данные (ресурс метки)	Например, если маркер SAS концентратора событий или ключ учетной записи хранения был изменен без правильного обновления их в Key Vault, чтобы модули pod могли их использовать, соответствующий компонент приложения завершится ошибкой. Затем этот сбой должен повлиять на служба работоспособности, и метка должна быть снята из поворота автоматически. Устранение рисков. Используйте проверку подлинности на основе идентификатора Microsoft Entra для всех служб, поддерживающих ее. AKS требует, чтобы модули pod прошли проверку подлинности с помощью Идентификация рабочей нагрузки Microsoft Entra (предварительная версия). Использование удостоверений Pod было рассмотрено в эталонной реализации. Было обнаружено, что удостоверение Pod было недостаточно стабильным в настоящее время и было принято решение об использовании для текущей эталонной архитектуры. Удостоверение Pod может быть решением в будущем.	No
Приложение	Истекшие учетные данные (глобальный общий ресурс)	Если например, ключ API Azure Cosmos DB был изменен без правильного обновления его во всех хранилищах ключей меток, чтобы модули pod могли использовать их, соответствующие компоненты приложения завершаются ошибкой. Сбой приведет ко всем меткам одновременно и приведет к сбою на уровне рабочей нагрузки. Возможный способ решения необходимости использования ключей и секретов с помощью проверки подлинности Microsoft Entra см. в предыдущем элементе.	Полный
Виртуальная сеть	Пространство IP-адресов подсети исчерпано	Если пространство IP-адресов в подсети исчерпано, операции горизонтального масштабирования, такие как создание новых узлов или модулей pod AKS, могут произойти. Это не приведет к сбою, но может снизить производительность и повлиять на взаимодействие с пользователем. Устранение рисков: увеличьте пространство IP -адресов (при возможности). Если это не вариант, это может помочь увеличить ресурсы на узел (более крупные номера SKU виртуальных машин) или на модуль pod (больше ЦП или памяти), чтобы каждый модуль pod мог обрабатывать больше трафика, тем самым уменьшая потребность в горизонтальном масштабировании.	No

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

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

Реализация: критически важный интернет