Наблюдаемость служб для Kubernetes с поддержкой Azure Arc

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

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

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

Реализация решения для обеспечения наблюдаемости служб поможет вам:

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

Kubernetes с поддержкой Azure Arc предоставляет два интегрированных варианта расширения для обеспечения наблюдаемости служб: открытие сетки служб и локального шлюза Управление API. Эти параметры подробно рассматриваются в следующих разделах по проектированию.

Архитектура

На следующей схеме показаны три основных аспекта наблюдаемости служб с воздействием на объем данных.

На следующей схеме показаны различные компоненты Сетки Open Service, работающие в кластере Kubernetes с поддержкой Arc. В нем также показан пример приложения, включенного в сетке служб, которая автоматически настраивается с контейнером бокового автомобиля Envoy.

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

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

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

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

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

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

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

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

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

Характеристика коллекции	Метрики	Журналы	Распределенная трассировка
Учетные записи для каждой транзакции	Да	Да	Нет (пример)
Защита от проблем с кратностью	No	Да	Да
Себестоимость	Низкий	Высокий	Низкая

Существуют различные способы достижения наблюдаемости службы. Вы можете использовать сетку службы, чтобы сделать это на уровне платформы, где приложение не знает и не изменяется. Вы также можете инструментирование приложения с библиотекой, которая обычно выполняется с помощью средства application Монитор производительности ing (APM), например Application Insights. Шлюзы API обеспечивают наблюдаемость в трафике на север-юг, но не хватает наблюдаемости в pod для обмена данными и простотой настройки в масштабе.

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

Сетка служб

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

• Kubernetes с поддержкой Azure Arc поддерживает проект Open Service Mesh (OSM), проект Cloud Native Computing Foundation (CNCF), который развертывается в качестве расширения. Open Service Mesh — это упрощенная, расширяемая, облачная сетка служб, которая позволяет пользователям равномерно управлять, защищать и получать встроенные функции наблюдения для высокодинамых сред микрослужб.
• Другие популярные сетки служб, требующие поддержки поставщиков, включают Istio, Consul Connect и Linkerd.
• В зависимости от того, какие функции используются при реализации сетки служб, дополнительные обязанности могут быть поставлены операторам приложений для определения конфигурации для каждой службы (например, правил доступа и служб подключения). Кроме того, операторы кластера должны управлять контроллером сетки служб и учитывать их. Из-за того, как сетка служб использует шаблон бокового автомобиля, при отладке исходящего трафика и входящего трафика требуются журналы доступа из плоскости управления сеткой службы и боковой кареты.

Наблюдаемость сетки служб

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

• Создание метрик, включая четыре золотых сигнала: задержка, трафик, ошибки и насыщенность.
• Метод RED (Rates-call/sec, Errors, Duration-call latencies), который является подмножеством четырех золотых сигналов и используется для измерения служб. Сетка служб должна предоставлять стандартный способ сбора метрик RED, трассировок и т. д.
• Повышение наблюдаемости увеличивается, от увеличения охвата всех служб, входящих в сетку служб.
• Функции, повышающие внедрение наблюдаемости путем автоматического инструментирования всех служб.
• Строгой интеграции с основными компонентами наблюдаемости службы. Сетка служб должна иметь возможность сломать метрики и собирать журналы, которые отображаются в решении мониторинга. Убедитесь, что сбор данных телеметрии сетки службы поддерживает бизнес-потребности и хорошо интегрируется с существующим решением мониторинга.

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

Локальный шлюз управления API

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

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

Дополнительные сведения см. в обзоре локального шлюза

Управление API наблюдаемость локального шлюза

Локальный шлюз выдает метрики, журналы stdout и журналы stderr. Выдается метрика, которую можно настроить с помощью ConfigMap в кластере. Дополнительные сведения о расширенном мониторинге с помощью Управление API см. в разделе "Расширенный мониторинг".

Учетные записи отслеживания локального шлюза для внешнего трафика (северо-юг), поступающих в кластер, но не обеспечивают наблюдаемость для трафика pod-to-pod в кластере (на востоке- западе).

Облачные метрики и журналы: метрики по умолчанию создаются в Azure Monitor. Log Analytics позволяет собирать и просматривать журналы контейнеров локального шлюза с помощью Azure Monitor для контейнеров. Дополнительные сведения см. в разделе "Настройка локальных метрик и журналов" для локального шлюза Azure Управление API.

Локальные метрики и журналы: метрики и журналы из локально размещенного шлюза можно интегрировать с локальным инструментом мониторинга или выдаваться картой конфигурации. Метрики можно настроить для публикации на серверах метрик. Журналы шлюза по умолчанию создаются для stdout и stderr. Дополнительные сведения см. в разделе "Настройка локальных метрик и журналов" для локального шлюза Azure Управление API.

Таблица сравнения технологий

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

Возможность	Сетка служб	Наблюдение за производительностью приложений	Локальный шлюз API
Поддерживаемый трафик "Восток-Запад"	Да	Да	Нет
Возможности метрик	Да	Да	Да
Возможность ведения журнала	Да	Да	Настраиваемая реализация
Возможности распределенных трассировок	Да	Да	Да
Уровень реализации	Network	Приложение	Network
Поддерживаемые протоколы	HTTP(S), TCP, gRPC	Н/П	HTTP(S), websockets
Ответственность за конфигурацию	Операторы кластера	Разработчики приложений	Операторы приложений и операторы кластера
Сложность конфигурации для наблюдаемости	Низкий	Высокий	Средняя

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

Реализуйте сетку Open Service, чтобы получить наблюдаемость в работоспособности и производительности служб. Open Service Mesh использует серверные прокси-серверы, внедренные как отдельный контейнер в те же модули pod, что и рабочие нагрузки для получения данных телеметрии. Эти прокси-серверы перехватывают весь входящий и исходящий HTTP-трафик в рабочие нагрузки и сообщают данные в Open Service Mesh. С помощью этой системы разработчикам служб не нужно инструментировать свой код для сбора данных телеметрии.

Включите open Service Mesh с помощью возможности расширения кластера Kubernetes с поддержкой Azure Arc, которая позволяет Корпорации Майкрософт управлять плоскостью управления. Дополнительные сведения см. в статье "Развертывание сетки Open Service с поддержкой Azure Arc (предварительная версия)".

Чтобы максимально повысить доступность и производительность приложений и служб, включите Azure Monitor Container Insights. Он предоставляет комплексное решение для сбора, анализа и выполнения данных телеметрии из облачных и локальных сред. Сетка Open Service с поддержкой Azure Arc тесно интегрируется с Azure Monitor, обеспечивая простой способ просмотра и реагирования на критически важные ключевые показатели эффективности, предоставляемые метриками OSM и журналами контейнеров приложений. Метрики OSM можно включить, выполнив следующие действия. Для распределенной трассировки рекомендуется Jaeger, который может интегрироваться с уровнем управления OSM.

Open Service Mesh также предоставляет документированные интеграции наблюдаемости для метрик с Prometheus и Grafana, трассировки с помощью Jaeger и пересылки журналов с помощью Fluent Bit. Эти интеграции предоставляют альтернативные варианты, если вы не используете решения для мониторинга Azure. Эти интеграции можно использовать для расширения других встроенных средств мониторинга по мере необходимости.

Как минимум, необходимо определить следующие три метрики RED и измерить их для всех служб:

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

Open Service Mesh предоставляет несколько предварительно настроенных книг служб в Azure Monitor, поэтому вам не нужно вручную настраивать панели мониторинга и диаграммы. Эта подробная телеметрия позволяет наблюдать за поведением службы и позволяет устранять неполадки, поддерживать и оптимизировать приложения. Использование книги мониторинга OSM в Azure Monitor позволяет:

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

Используйте визуализации из пользовательского интерфейса Jaeger:

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

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

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

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

• Просмотрите предварительные требования для Kubernetes с поддержкой Azure Arc.
• Просмотрите проверенные дистрибутивы Kubernetes для Kubernetes с поддержкой Azure Arc.
• Узнайте, как управлять гибридными и многооблачными средами.
• Дополнительные сведения о сетке Open Service с поддержкой Azure Arc см. в следующем разделе:
  • Разверните сетку Open Service (предварительная версия) с поддержкой Azure Arc.
  • Откройте надстройку AKS сетки службы.
  • Документация по запуску сетки служб
• Узнайте, как настроить мониторинг и наблюдаемость с помощью сетки Open Service в Служба Azure Kubernetes (AKS)
• Сведения об управлении и мониторинге для Kubernetes с поддержкой Azure Arc.
• Сведения о сетках служб.
• Запустите Kubernetes с поддержкой Azure Arc с расширением "Сетка open Service" из Azure Arc Jumpstart.
• Дополнительные сведения о Azure Arc см. в схеме обучения Azure Arc.
• Ознакомьтесь с часто задаваемыми вопросами. С поддержкой Azure Arc можно найти ответы на наиболее распространенные вопросы.