Моделирование работоспособности для критически важных рабочих нагрузок
Мониторинг приложений и инфраструктуры является важной частью любого развертывания инфраструктуры. Для критически важной рабочей нагрузки мониторинг является важной частью развертывания. Мониторинг работоспособности приложений и ключевых метрик ресурсов Azure помогает понять, работает ли среда должным образом.
Чтобы полностью понять эти метрики и оценить общую работоспособность рабочей нагрузки, требуется комплексное понимание всех отслеживаемых данных. Модель здоровья может помочь в оценке общего состояния здоровья, отображая ясное представление о состоянии рабочей нагрузки вместо необработанных показателей. Состояние часто отображается как светофорные индикаторы, такие как красный, зеленый или желтый. Представление модели работоспособности с четкими индикаторами позволяет оператору понять общую работоспособность рабочей нагрузки и быстро реагировать на возникающие проблемы.
Моделирование здоровья можно расширить на следующие операционные задачи для критически важного развертывания:
Служба контроля работоспособности приложения — компонент приложения в вычислительном кластере, предоставляющий API для определения работоспособности системы.
Мониторинг — коллекция счетчиков производительности и приложений, которые оценивают работоспособность и производительность приложения и инфраструктуры.
Оповещения — действенные оповещения о проблемах и сбоях в инфраструктуре и приложении.
Анализ сбоев — разбивка и анализ любых сбоев, включая документацию по первопричине.
Эти задачи составляют комплексную модель работоспособности для критически важной инфраструктуры. Разработка модели здоровья может и должна быть исчерпывающей и неотъемлемой частью любого критически важного развертывания.
Дополнительные сведения см. в статье " Моделирование работоспособности и наблюдаемость критически важных рабочих нагрузок в Azure".
Служба контроля состояния приложения
Служба работоспособности приложения (HealthService) — это компонент приложения, который взаимодействует с службой каталогов (CatalogService) и фоновым процессором (BackgroundProcessor) в рамках вычислительного кластера. Служба HealthService предоставляет REST API для Azure Front Door, чтобы вызывать его для определения состояния кластера. HealthService — это сложный компонент, который отражает состояние зависимостей, помимо собственного.
Если вычислительный кластер отключен, служба работоспособности не отвечает. Когда службы запущены и работают, выполняются периодические проверки для следующих компонентов в составе инфраструктуры:
Он пытается выполнить запрос к Azure Cosmos DB.
Она пытается отправить сообщение в Центры событий. Фоновый рабочий процесс фильтрует сообщение.
Он ищет файл состояния в учетной записи облачного хранилища. Этот файл можно использовать для отключения региона, даже если другие проверки по-прежнему работают правильно. Этот файл можно использовать для взаимодействия с другими процессами. Например, если метка должна быть освобождена в целях обслуживания, файл может быть удален для принудительного неработоспособного состояния и перенаправки трафика.
Он запрашивает модель работоспособности, чтобы определить, находятся ли все операционные метрики в предопределенных пороговых значениях. Если модель работоспособности указывает, что метка неработоспособна, трафик не должен направляться на метку, даже если другие тесты healthService успешно возвращаются. Модель работоспособности принимает более полное представление о состоянии работоспособности.
Все результаты проверки работоспособности кэшируются в памяти для настраиваемого количества секунд по умолчанию 10. Эта операция потенциально добавляет небольшую задержку при обнаружении сбоев, но она гарантирует, что не каждый запрос HealthService требует внутренних вызовов, что снижает нагрузку на кластер и подчиненные службы.
Этот шаблон кэширования важен, поскольку количество запросов к Health Service значительно увеличивается при использовании такого глобального маршрутизатора, как Azure Front Door: каждый граничный узел в каждом центре обработки данных Azure, который обслуживает запросы, обращается к Health Service, чтобы определить, имеет ли он функциональное подключение к внутренним системам. Кэширование результатов снижает дополнительную нагрузку на кластер, созданную проверками работоспособности.
Настройка
HealthService и CatalogService имеют общие параметры конфигурации между компонентами, за исключением следующих параметров, используемых исключительно службой HealthService:
| Настройки | Значение |
|---|---|
HealthServiceCacheDurationSeconds |
Управляет временем истечения срока действия кэша памяти в секундах. |
HealthServiceStorageConnectionString |
Строка подключения для учетной записи хранения, в которой должен присутствовать файл состояния. |
HealthServiceBlobContainerName |
Контейнер хранилища, в котором должен присутствовать файл состояния. |
HealthServiceBlobName |
Имя файла состояния; проверка системы ищет этот файл. |
HealthServiceOverallTimeoutSeconds |
Время ожидания для всей проверки по умолчанию - 3 секунды. Если проверка не завершится в этом интервале, служба сообщает о неработоспособном состоянии. |
Внедрение
Все проверки выполняются асинхронно и параллельно. Если любой из них завершается сбоем, то вся метка будет считаться недоступной.
Результаты проверки кэшируются в памяти с использованием стандартной, нераспределенной ASP.NET Core MemoryCache.
SysConfig.HealthServiceCacheDurationSeconds управляет истечением срока действия кэша. Значение по умолчанию — 10 секунд.
Примечание.
Параметр конфигурации SysConfig.HealthServiceCacheDurationSeconds уменьшает дополнительную нагрузку, созданную проверками работоспособности, так как не каждый запрос приводит к вызову подчиненных служб.
В следующей таблице описаны проверки работоспособности компонентов в инфраструктуре:
| Компонент | Проверка состояния здоровья |
|---|---|
| Учетная запись для Blob-хранилища | В настоящее время проверка блоба служит двумя целями: 1. Проверьте, возможно ли подключиться к Blob Storage. Учетная запись хранения используется другими компонентами в инфраструктуре и считается критически важным ресурсом. 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 автоматически удаляет его. Служба HealthService выполняет два отдельных запроса. Если в 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 Insights используется для всех данных мониторинга приложений. Каждая метка в инфраструктуре имеет выделенную рабочую область Log Analytics и экземпляр Application Insights. Отдельная рабочая область Log Analytics используется для глобальных общих ресурсов, таких как Front Door и Azure Cosmos DB.
Все марки недолговечны и постоянно заменяются с каждым новым выпуском. Рабочие области Log Analytics для каждой метки развертываются как глобальный ресурс в отдельной группе ресурсов мониторинга в качестве ресурсов Log Analytics. Эти ресурсы не используют жизненный цикл метки.
Дополнительные сведения см. в статье Унифицированный приемник данных для коррелированного анализа.
Мониторинг: источники данных
Параметры диагностики: все службы Azure, используемые для Azure Mission-Critical, настроены на отправку всех своих диагностических данных, включая журналы и метрики, в рабочую область Log Analytics, специфичную для развертывания (глобальную или метки). Этот процесс выполняется автоматически в рамках развертывания Terraform. Новые опции определяются автоматически и добавляются как часть
terraform apply.Мониторинг Kubernetes: параметры диагностики используются для отправки журналов и метрик из Службы Azure Kubernetes (AKS) в Log Analytics. AKS настраивается для использования Container Insights. Container Insights развертывает OMSAgentForLinus с помощью DaemonSet Kubernetes на каждом узле в кластерах AKS. OMSAgentForLinux может собирать дополнительные журналы и метрики из кластера Kubernetes и отправлять их в соответствующую рабочую область Log Analytics. Эти дополнительные логи и метрики содержат более детализированные данные о модулях, развертываниях, службах и общей работоспособности кластера. Чтобы получить больше аналитических сведений от различных компонентов, таких как ingress-nginx, cert-manager и другие компоненты, развернутые в Kubernetes рядом с критически важной рабочей нагрузкой, можно использовать сбор данных Prometheus. Конфигурация сбора данных Prometheus настраивает OMSAgentForLinux для сбора метрик Prometheus с различных конечных точек в кластере.
мониторинг данных с помощью Application Insights: Application Insights используется для сбора и мониторинга данных из приложения. Код инструментируется для сбора данных о производительности приложения с помощью пакета SDK Application Insights. Собираются критически важные сведения, такие как результирующий код состояния, длительность вызовов зависимостей, и счетчики необработанных исключений. Эта информация используется в модели работоспособности и доступна для оповещения и устранения неполадок.
Мониторинг: тесты доступности Application Insights
Для мониторинга доступности отдельных штампов и общего решения с внешней точки зрения тесты доступности Application Insights настраиваются в двух местах.
Региональные тесты доступности: эти тесты настраиваются в региональных экземплярах Application Insights и используются для мониторинга доступности меток. Эти тесты направлены непосредственно на кластеры и статические учетные записи хранения стемпов. Чтобы обратиться к точкам входа в кластеры напрямую, запросы должны содержать правильный заголовок "Front Door ID", в противном случае ингресс-контроллер отклоняет запросы.
Глобальный тест на доступность: Эти тесты настраиваются в глобальном экземпляре Application Insights и используются для мониторинга доступности всего решения посредством опроса Front Door. Используются два теста: один для тестирования вызова API к CatalogService и один для проверки домашней страницы веб-сайта.
Мониторинг: запросы
Azure Mission-Critical использует различные запросы на языке запросов Kusto (KQL) для реализации пользовательских запросов в качестве функций для получения данных из Log Analytics. Эти запросы хранятся в виде отдельных файлов в нашем репозитории кода, разделённых на глобальные и маркированные развертывания. Они импортируются и применяются автоматически через Terraform в рамках каждого запуска конвейера инфраструктуры.
Этот подход отделяет логику запроса от слоя визуализации. Запросы Log Analytics вызываются непосредственно из кода, например из API HealthService. Другим примером является средство визуализации, такое как Azure Dashboards, рабочие книги для мониторинга или Grafana.
Мониторинг: визуализация
Мы используем Grafana для визуализации результатов запросов состояния здоровья Log Analytics в эталонной реализации. Grafana показывает результаты запросов Log Analytics и не содержит логики. Мы выпускаем стек Grafana отдельно от жизненного цикла развертывания решения.
Дополнительные сведения см. в разделе "Визуализация".
Оповещение
Оповещения являются важной частью общей стратегии операций. Упреждающий мониторинг, например использование панелей мониторинга, следует использовать с оповещениями, которые вызывают непосредственное внимание к проблемам.
Эти оповещения образуют расширение модели работоспособности, оповещав оператора об изменении состояния работоспособности, либо на пониженное или желтое состояние, либо на неработоспособное или красное состояние. Задав оповещение для корневого узла модели работы, оператор немедленно узнаёт о любом влиянии на бизнес-уровне, которое сказывается на состоянии решения. Ведь этот корневой узел станет жёлтым или красным, если любой из используемых потоков пользователей или ресурсов сообщает о жёлтых или красных метриках. Оператор может направить свое внимание на визуализацию модели работоспособности для устранения неполадок.
Дополнительные сведения см. в статье "Автоматизированное реагирование на инциденты".
Анализ отказов
Составление анализа сбоев в основном представляет собой теоретическое планирование. Это теоретическое упражнение следует использовать в качестве входных данных для автоматических внедрений сбоев, которые являются частью процесса непрерывной валидации. Симуляя режимы сбоя, определенные здесь, мы можем проверить устойчивость решения от этих сбоев, чтобы свести к минимуму сбои.
В следующей таблице перечислены примеры случаев сбоя различных компонентов эталонной реализации Azure для критически важных задач.
| Услуга | Риск | Влияние/Смягчение/Комментарий | Перебой |
|---|---|---|---|
| Microsoft Entra ID | Идентификатор 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 Mission-Critical включает возможность записи в нескольких регионах. Если при чтении или записи произошел сбой, клиент повторяет текущую операцию. Все будущие операции окончательно направляются в следующий регион в порядке предпочтения. Если в списке предпочтений есть одна запись (или пустая), но у учетной записи есть другие регионы, она будет направляться в следующий регион в списке учетных записей. | Нет |
| Azure Cosmos DB | Обширное регулирование из-за отсутствия ЕЗ. | В зависимости от числа RUs и распределения нагрузки на уровне Front Door, некоторые отметки могут испытывать высокую загрузку на Azure Cosmos DB, в то время как другие отметки могут обрабатывать большее количество запросов. Снижение нагрузки: лучшее распределение нагрузки или больше RUs. | Нет |
| Azure Cosmos DB | Переполнен раздел | Ограничение размера логического раздела Azure Cosmos DB составляет 20 ГБ. Если данные для ключа секции в контейнере достигают этого размера, дополнительные запросы на запись завершаются ошибкой "Ключ секции достиг максимального размера". | Частично (запись в базу данных отключена) |
| Реестр контейнеров Azure; | Сбой в регионе | Реестр контейнеров использует Диспетчер трафика для отработки отказа между регионами реплики. Любой запрос должен быть автоматически перенаправлен в другой регион. В худшем случае узлы AKS не загружают образы Docker в течение нескольких минут, пока происходит переключение на резервный DNS. | Нет |
| Реестр контейнеров Azure; | Изображение или изображения удалены | Изображения не могут быть извлечены. Этот сбой должен влиять только на вновь созданные или перезагруженные узлы. Существующие узлы должны кэшировать образы. **Устранение рисков. Если обнаружено быстрое повторное выполнение последних конвейеров сборки, образы должны вернуться в реестр. | Нет |
| Реестр контейнеров Azure; | Регулирование | Ограничение скорости может отложить операции горизонтального масштабирования, что может привести к временному снижению производительности. Смягчение: Azure Mission-Critical использует SKU уровня "Премиум", который предоставляет 10 тысяч операций чтения в минуту. Образы контейнеров оптимизированы и имеют только небольшое количество слоев. Политика ImagePullPolicy установлена на IfNotPresent, чтобы сначала использовать версии, сохраненные в локальном кэше. Примечание. Извлечение образа контейнера состоит из нескольких операций чтения в зависимости от количества слоев. Количество операций чтения в минуту ограничено и зависит от размера SKU ACR. | Нет |
| Служба Azure Kubernetes | Сбой обновления кластера | Обновления узлов AKS должны выполняться в различное время в разных кластерах. Если одно обновление завершается сбоем, другой кластер не должен быть затронут. Обновления кластера должны развертываться в последовательном режиме между узлами, чтобы предотвратить недоступность всех узлов. | Нет |
| Служба Azure Kubernetes | Модуль pod приложения убит при обслуживании запроса. | Этот результат может привести к возникновению ошибок для конечного пользователя и плохого пользовательского опыта. Устранение рисков: Kubernetes по умолчанию удаляет модули pod в корректном режиме. Модули Pod удаляются из служб сначала, а рабочая нагрузка получает SIGTERM с льготным периодом, чтобы завершить открытые запросы и записать данные перед завершением. Код приложения должен правильно обрабатывать SIGTERM, а льготный период может потребоваться изменить, если завершение рабочей нагрузки занимает больше времени. | Нет |
| Служба Azure Kubernetes | Емкость вычислений недоступна в регионе для добавления дополнительных узлов. | Сбой операций масштабирования вверх/вниз не должен влиять на существующие узлы и их функционирование. В идеале трафик должен автоматически перемещаться в другие регионы для балансировки нагрузки. | Нет |
| Служба Azure Kubernetes | Подписка исчерпала квоту ядер ЦП для добавления новых узлов. | Сбой операций масштабирования вверх/вниз не должен влиять на существующие узлы и их функционирование. В идеале трафик должен автоматически перемещаться в другие регионы для балансировки нагрузки. | Нет |
| Служба Azure Kubernetes | Давайте зашифруем TLS/SSL-сертификаты не могут быть выданы или продлены. | Кластер должен сообщать о неполадках в Front Door, и трафик должен перейти на другие стемпы. Смягчение последствий: исследование основной причины проблемы или сбоя. | Нет |
| Служба Azure Kubernetes | Если запросы и ограничения ресурсов настроены неправильно, pod могут достигать 100 % использования ЦП, и запросы могут не выполняться. Механизм повторных попыток приложения должен иметь возможность восстановить неудачные запросы. Повторные попытки могут привести к более длительному запросу, без сообщения об ошибке клиенту. Чрезмерная нагрузка в конечном итоге приводит к сбою. | Нет (если загрузка не чрезмерна) | |
| Служба Azure Kubernetes | Сторонние образы контейнеров и реестр недоступны | Для некоторых компонентов, таких как cert-manager и ingress-nginx, требуется скачивание образов контейнеров и Helm charts из внешних реестров контейнеров (исходящий трафик). Если один или несколько из этих репозиториев или образов недоступны, новые экземпляры на новых узлах (где образ еще не кэширован) могут не запускаться. Возможное смягчение последствий: В некоторых сценариях может быть целесообразно импортировать образы контейнеров от сторонних поставщиков в реестр контейнеров для отдельного решения. Этот сценарий добавляет дополнительную сложность и следует тщательно планировать и выполнять операции. | Частично (во время операций масштабирования и обновления/модернизации) |
| Концентратор событий | Сообщения не могут отправляться в Центры событий | Метка становится неиспользуемой для операций записи. Служба здравоохранения должна автоматически обнаруживать это и убирать штамп из оборота. | Нет |
| Концентратор событий | Сообщения не могут быть прочитаны фоновым обработчиком | Сообщения накапливаются. Сообщения не должны быть потеряны, так как они сохраняются. В настоящее время этот недостаток не покрывается службой здравоохранения. Для обнаружения ошибок при чтении сообщений следует настроить систему мониторинга и оповещения. Устранение неполадок. Метка должна быть отключена вручную, пока проблема не будет устранена. | Нет |
| Учетная запись хранения | Учетная запись хранения становится недоступной для рабочей роли при регистрации контрольных точек "Центров событий" | Штамп не обрабатывает сообщения из Центров событий. Учетная запись хранения также используется HealthService. Служба здоровья обнаруживает проблемы с хранилищем и должна вывести штамп из оборота. Можно ожидать, что другие службы в системе затрагиваются одновременно. | Нет |
| Учетная запись хранения | Статический веб-сайт сталкивается с проблемами. | Если статический веб-сайт сталкивается с проблемами, Front Door обнаруживает этот сбой. Трафик не отправляется в эту учетную запись хранения. Кэширование в системе Front Door также может облегчить эту проблему. | Нет |
| Хранилище ключей | Key Vault недоступен для операций GetSecret. |
В начале работы новых pod, драйвер AKS CSI извлекает все секреты из Key Vault и терпит неудачу. Не удается запустить модули Pod. Автоматическое обновление в настоящее время выполняется каждые 5 минут. Обновление не удаётся. Ошибки должны отображаться в kubectl describe pod, но pod продолжает работать. |
Нет |
| Хранилище ключей | Key Vault недоступно для операций GetSecret или SetSecret. |
Не удается выполнить новые развертывания. В настоящее время этот сбой может привести к остановке всего конвейера развертывания, даже если затрагивается только один регион. | Нет |
| Хранилище ключей | Регулирование Key Vault | Key Vault имеет ограничение в 1000 операций за 10 секунд. Из-за автоматического обновления секретов вы в теории могли бы достичь этого предела, если у вас было много (тысячи) капсул в stamp. Возможное решение: еще сильнее уменьшить частоту обновления или полностью отключить её. | Нет |
| Приложение | Неправильные настройки | Неверные строки подключения или секреты, которые внедрены в приложение. Смягчается за счет автоматического развертывания (конвейер автоматически управляет конфигурацией) и обновлений методом «blue-green». | Нет |
| Приложение | Истекшие учетные данные (ресурс штампа) | Например, если маркер SAS концентратора событий или ключ учетной записи хранения был изменен, но их не обновили в хранилище ключей Key Vault, так что узлы не могут их использовать, соответствующий компонент приложения выходит из строя. Этот сбой должен повлиять на службу здравоохранения, и метка должна быть снята из обращения автоматически. Устранение рисков. Используйте проверку подлинности на основе идентификатора Microsoft Entra для всех служб, поддерживающих ее. AKS требует, чтобы поды прошли проверку подлинности с помощью идентификатора рабочей нагрузки Microsoft Entra (предварительная версия). Использование Pod Identity было рассмотрено в эталонной реализации. Было обнаружено, что удостоверение Pod в настоящее время недостаточно стабильно, и было решено отказаться от его использования в текущей эталонной архитектуре. Удостоверение Pod может быть решением в будущем. | Нет |
| Приложение | Истекшие учетные данные (глобальный общий ресурс) | Если, например, ключ API Azure Cosmos DB был изменен без должного обновления во всех связанных хранилищах ключей, и модули pod не могут их использовать, соответствующие компоненты приложения терпят неудачу. Сбой приведет к одновременному падению всех штампов и вызовет перебои в работе всей нагрузки. Возможный способ решения необходимости использования ключей и секретов с помощью проверки подлинности Microsoft Entra см. в предыдущем элементе. | Полностью |
| Виртуальная сеть | Пространство IP-адресов подсети исчерпано | Если пространство IP-адресов в подсети исчерпано, операции горизонтального масштабирования, такие как создание узлов или подов AKS, не могут произойти. Сбой не возникает, но может снизить производительность и повлиять на пользовательский опыт. Устранение рисков: увеличьте пространство IP -адресов (при возможности). Если это не вариант, возможно, стоит увеличить ресурсы на узел (более крупные SKU виртуальных машин) или на pod (больше ЦП или памяти), чтобы каждый pod мог обрабатывать больше трафика, тем самым уменьшая потребность в масштабировании. | Нет |
Следующие шаги
Разверните эталонную реализацию, чтобы получить полное представление о ресурсах и их конфигурации, используемой в этой архитектуре.