Хроносфера спонсировала этот пост.
В этом отрывке из первой главы книги Мэннинга «Разработка платформ в Kubernetes» рассматривается среда Kubernetes, устанавливается пример приложения для конференций с помощью одной команды, проверяется работоспособность и изучаются базовые примитивы — развертывания, наборы реплик, сервисы и обнаружение сервисов — при этом решаются такие реальные проблемы, как нулевое время простоя, отказоустойчивость, согласованность состояния/данных, безопасность/идентификация и понимание поведения приложения. Чтобы прочитать полную главу, вы можете скачать книгу.
Распределенные системы — сложные существа, и полное понимание того, как они работают с первого дня, может помочь вам сэкономить время, когда что-то пойдет не так. Это подтолкнуло сообщества мониторинга, отслеживания и телеметрии к разработке решений, которые помогут объяснить, как все работает в любой момент времени.
Сообщество OpenTelemetry (OTel) развивалось вместе с Kubernetes и теперь может предоставить большинство инструментов, которые вам понадобятся для мониторинга работы ваших сервисов. Как указано на его веб-сайте: «Вы можете использовать его для инструментирования, генерации, сбора и экспорта данных телеметрии (метрики, журналы и трассировки) для анализа, чтобы понять производительность и поведение вашего программного обеспечения».
Метрики, журналы и трассировки
На рис. 1 показан распространенный вариант использования, когда службы передают метрики, трассировки и журналы в централизованное место, где хранится и агрегируется информация, чтобы ее можно было отображать на информационных панелях или использовать другими инструментами.
Рис. 1. Объединение наблюдаемых данных со всех сервисов в одном месте снижает когнитивную нагрузку на команды, ответственные за поддержание работоспособности приложения. (Источник: «Разработка платформ в Kubernetes».)
OpenTelemetry в Kubernetes: основные концепции для инженеров платформ
Важно отметить, что OpenTelemetry фокусируется на поведении и производительности вашего программного обеспечения, поскольку они будут влиять на ваших пользователей и их пользовательский опыт. С точки зрения поведения вы хотите убедиться, что приложение делает то, что должно. Поэтому вам нужно будет понять, какие службы вызывают какие другие службы или инфраструктуру для выполнения задач.
Использование Prometheus и Grafana позволяет нам видеть телеметрию службы и создавать панели мониторинга для конкретных доменов, чтобы выделить определенные показатели уровня приложения (например, количество одобренных или отклоненных предложений о конференциях с течением времени, как показано на рисунке 2).
Рисунок 2. Мониторинг данных телеметрии с помощью Prometheus и Grafana. (Источник: «Разработка платформ в Kubernetes».)
С точки зрения производительности вам необходимо убедиться, что службы соблюдают соглашения об уровне обслуживания (SLA), что означает, что они оперативно отвечают на запросы. Если одна из ваших служб работает некорректно и занимает больше времени, чем обычно, вы должны знать об этом.
Коллектор OpenTelemetry: шаблоны приема, обработки и экспорта
Для отслеживания вам необходимо изменить свои службы, чтобы понять внутренние операции и их производительность. OpenTelemetry предоставляет встроенные библиотеки инструментов на большинстве языков для экстернализации показателей и трассировок обслуживания.
На рис. 3 показана архитектура OpenTelemetry, включая сборщик OpenTelemetry, получающий информацию от каждого агента приложения, а также компоненты общей инфраструктуры.
Рисунок 3. Архитектура и библиотека OpenTelemetry. (Источник: документы OpenTelemetry.)
Если вы создаете ходячий скелет, убедитесь, что в него встроена OpenTelemetry. Если вы перенесете мониторинг на более поздние этапы проекта, будет слишком поздно — все пойдет не так, и выяснение того, кто несет ответственность, займет слишком много времени.
Безопасность приложений и управление идентификацией
Если вы когда-либо создавали веб-приложение, вы знаете, что обеспечение управления идентификацией (учетными записями пользователей и удостоверениями пользователей), а также аутентификацией и авторизацией — это довольно сложная задача. Простой способ сломать любое приложение (облачное или нет) — выполнить действия, которые вам не следует делать, например (используя приведенный выше пример предложений по конференции) удалить все предложенные презентации, если вы не являетесь организатором конференции.
Распространение идентификационных данных в распределенных системах и OAuth2 на границе
Распространение идентификационных данных становится сложной задачей в распределенных системах, поскольку авторизация и идентификационные данные пользователя должны распространяться между различными службами. В распределенных архитектурах довольно часто имеется компонент, который генерирует запросы от имени пользователя вместо того, чтобы предоставлять пользователю все службы для непосредственного взаимодействия.
В нашем примере этим компонентом является интерфейсная служба, куда люди подают предложения по презентациям. В большинстве случаев вы можете использовать этот внешний компонент в качестве барьера между внешними и внутренними службами. По этой причине довольно часто интерфейсную службу настраивают для подключения к поставщику авторизации и аутентификации с использованием протокола OAuth2.
На рисунке ниже показана интерфейсная служба, взаимодействующая со службой управления идентификацией, которая отвечает за подключение к поставщику удостоверений (например, Google, GitHub, вашему внутреннему серверу LDAP) для проверки учетных данных пользователя, а также для предоставления ролей или членства в группах, которые определяют, что пользователь может и не может делать в различных службах. Интерфейсная служба обрабатывает поток входа в систему (аутентификацию и авторизацию), но после этого на серверные службы передается только контекст.
Рисунок 4. Управление идентификацией: роль/группа распространяется на серверные службы. (Источник: «Разработка платформ в Kubernetes».)
Конфиденциальность, вход в социальные сети и поставщики единого входа/идентификации
Приложение, которое не обрабатывает пользователей или их данные, хорошо соответствует таким правилам, как GDPR. Но вы можете разрешить пользователям использовать свои учетные записи в социальных сетях для входа в приложение без необходимости создавать отдельные учетные записи. Обычно это называется входом в социальную сеть.
Некоторые популярные решения, такие как Keycloak и Zitadel, объединяют OAuth2 и управление идентификацией. Эти проекты с открытым исходным кодом предоставляют комплексный подход к решениям единого входа (SSO) и расширенному управлению идентификацией. Zitadel также предоставляет управляемую услугу, которую вы можете использовать, если не хотите устанавливать и поддерживать компонент единого входа и управления идентификацией внутри своей инфраструктуры.
То же самое относится и к отслеживанию и мониторингу. Планирование включения пользователей, включая SSO и управление идентификацией, в ходячий скелет заставит вас задуматься о специфике того, «кто и что сможет делать», что еще больше усовершенствует ваш вариант использования.
Узнать больше
Благодаря подключению OTel к вашему «ходячему скелету» Kubernetes у вас есть возможность быстро выявлять регрессии, проверять SLO и сокращать среднее время разрешения (MTTR) — до того, как сработает пейджер.
Если вам нужен комплексный сценарий, включающий развертывание в кластерах Kubernetes, CI/CD, шаблоны сборщиков, идентификацию, конвейеры доставки и мультиоблачную инфраструктуру, загрузите полную электронную книгу Мэннинга и продолжайте разработку.
Хроносфера — это платформа наблюдения, созданная для контроля в современном контейнерном мире. Признанная крупными аналитическими фирмами лидером, ChronSphere дает клиентам возможность сосредоточиться на данных и знаниях, которые важны для снижения сложности данных, оптимизации затрат и более быстрого устранения проблем. Узнайте больше Последние новости ChronSphere ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Маурисио Салатино — автор книги «Разработка платформ в Kubernetes». Он является инженером-программистом в Diagrid и ранее работал в VMware и Red Hat. Будучи энтузиастом открытого исходного кода, Маурисио Салатино был членом программного комитета, председателем совета… Читать далее от Маурисио Салатино
