Привет, ребята, я Луга. Сегодня мы поговорим о базовой технологии облачной экосистемы — наблюдаемости, то есть «полноканальном наблюдении Kubernetes на основе OpenTelemetry».

— 01 —

Полное изменение нашего сознания наблюдения на основе OpenTelemetry

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

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

Неспособность своевременно обеспечить возможности наблюдения в режиме реального времени приведет к увеличению среднего времени разрешения (MTTR). Это существенно повлияет на общую доступность и производительность приложения, негативно влияя на сам бизнес.

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

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

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

— 02 —

Текущие проблемы в наблюдении за Kubernetes

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

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

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

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

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

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

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

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

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

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

— 03 —

Раскрытие ключевой роли OpenTelemetry в наблюдении за Kubernetes

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

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

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

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

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

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

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

— 04 —

Передовая практика: определение ключевых целей наблюдения

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

1. Индикатор узла

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

2. Индикаторы модуля

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

3. Индикатор контейнера

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

4. Индикаторы API-сервера

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

5. Индикатор т.д.

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

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

— 05 —

Решение Kubernetes на основе OpenTelemetry

Разверните сборщик OpenTelemetry в Kubernetes, который будет отвечать за получение и обработку данных трассировки. После развертывания мы можем использовать библиотеку инструментов OTEL, предоставляемую OpenTelemetry (приложение, написанное на Go), для отправки данных трассировки сборщику.

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

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

В этом сценарии наша настройка OTEL выглядит следующим образом:

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

К ним относятся:

1. Инструменты, специфичные для Kubernetes

API-сервер Kubernetes, Etcd, Kubelet и т. д. Эти инструменты можно использовать для генерации данных телеметрии для таких операций, как создание, удаление и расширение модулей.

2. Внедрение метаданных Kubernetes

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

3. Выборка с учетом Kubernetes

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

4. Развертывание Kubernetes

OpenTelemetry можно развернуть как развертывание Kubernetes или набор демонов, что упрощает расширение компонентов OpenTelemetry и управление ими в среде Kubernetes.

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

— 05 —

Основные шаги по реализации OpenTelemetry

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

В реальных бизнес-сценариях приведены четыре простых основных шага для правильной реализации OpenTelemetry для наблюдения за средой Kubernetes. Подробности см. в разделе:

1. Установите сборщик OpenTelemetry.

Во-первых, нам нужно правильно установить OpenTelemetry Collector. Коллектор — это компонент, используемый для получения, обработки и экспорта данных телеметрии. Мы можем установить и настроить Collector в кластере Kubernetes в соответствии с инструкциями, приведенными в официальной документации.

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

[leonli@LugaLab ~ ] % kubectl apply -f https://github.com/open-telemetry/opentelemetry-operator/releases/latest/download/opentelemetry-operator.yaml

Конечно, здесь мы также можем использовать Helm Charts для установки: https://github.com/open-telemetry/opentelemetry-helm-charts/tree/main/charts/opentelemetry-operator

2. Настройте сборщик OpenTelemetry.

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

OTel поддерживает несколько серверов, включая Prometheus, Jaeger и Zipkin. Для конкретной конфигурации, пожалуйста, обратитесь к следующим примерам:

receivers:
  otlp:
    protocols:
      grpc:
exporters:
  prometheus:
    endpoint: "localhost:4444"
  jaeger:
    endpoint: "http://jaeger:14268/api/traces"
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: []
      exporters: [jaeger, prometheus]

3. Включите обнаружение OpenTelemetry в приложениях Kubernetes.

Чтобы включить инструменты OpenTelemetry в приложении Kubernetes, нам обычно необходимо добавить OpenTelemetry SDK в код приложения. SDK предоставляет API для вставки кода в ваше приложение для сбора показателей, отслеживания запросов и ведения журналов. Используя OpenTelemetry SDK в нашем приложении, мы можем собирать важные данные о производительности и контекстную информацию.

4. Отправьте данные на предпочитаемый бэкэнд.

В качестве последнего шага нам нужно настроить сборщик OpenTelemetry для отправки собранных данных в предпочитаемый серверный интерфейс. Бэкэндом могут быть различные платформы хранения и анализа данных, такие как Prometheus, Grafana, Jaeger и т. д. В зависимости от наших потребностей и среды выберите подходящий бэкэнд и настройте сборщик для экспорта данных в этот бэкэнд.

Здесь, на примере бэкэнда Jaeger, он предоставляет различные варианты визуализации, чтобы мы могли легко понять поток запросов в кластере Kubernetes, и поддерживает различные форматы отслеживания, включая OTel и т. д. Для получения подробной информации см. следующее:

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-prod
spec:
  strategy: allInOne
  allInOne:
    image: jaegertracing/all-in-one:latest
    options:
      log-level: debug

Наблюдение за Kubernetes имеет решающее значение для обеспечения производительности, надежности и доступности приложений на основе Kubernetes. OpenTelemetry предоставляет мощную платформу для наблюдения за средами Kubernetes, используя такие функции, как распределенная трассировка, метрики и ведение журналов.

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

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

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

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

Adiós !