Девайсы повсюду. Смартфоны, холодильники, дверные звонки, часы, медицинские датчики, системы безопасности и фитнес-трекеры — все это лишь некоторые из них, которые стали обычным явлением. Они постоянно записывают потенциально высокочастотную информацию и образуют сеть, известную как «Интернет вещей», или IoT, представляя обширные источники данных.

Хотя ресурсов по этой теме достаточно, немногие приводят примеры с реальными данными, доступными любому желающему. Переходя от статьи к статье, чтобы узнать о системах, управляемых событиями, и потоковых технологиях, таких как Apache Kafka, Harrison Hoffman наткнулся на приложение для смартфонов Sensor Logger, которое позволяет пользователям передавать данные с датчиков движения на свои телефоны. Такой вариант показался идеальным способом обучения, поэтому родился проект «smartphone_sensor_stream». Этот проект использует FastAPI, Kafka, QuestDB и Docker для визуализации данных датчиков в реальном времени на информационной панели.

В этой статье мы рассмотрим все основные компоненты этого проекта на продвинутом уровне. Все необходимое для локального запуска проекта доступно на GitHub, а краткая демонстрация доступна на YouTube. 

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

Серия статей состоит из следующих связанных частей:

Часть 1: Сообщение producer’а;

Часть 2: Подъем consumer’ов;

Часть 3: Смещения и как с ними справляться;

Часть 4: Мой кластер потерян! — Принятие неудачи.

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

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

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

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

С мониторингом, как с кораблем. Конечно, успех в обоих случаях зависит не только от названия. Чтобы все не потонуло, важно помнить о базовых вещах на старте.

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

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

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

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

В новой серии статей «Мир приключений по API-серверу Kubernetes» («k8s ASA») мы погрузимся во все детали работы API-сервера, получим представление о том, как они работают, а также с какими компонентами взаимодействуют. Параллельно поэкспериментируем с заменой пользовательских компонентов, создадим инструментарий и рассмотрим, как другие пользователи модифицировали его в соответствии с пользовательскими кейсами. Кто знает, возможно, даже построим наш собственный. 👀

Предсказывать системные бои становится всё сложнее. Чтобы предотвратить остановки в работе, крупные и малые компании обратились к Chaos engineering в качестве решения.

Chaos engineering позволяет прогнозировать и выявлять потенциальные сбои, намеренно внося неисправности в систему. Таким образом можно находить и устранять сбои ещё до того, как они превратятся в простои. Chaos engineering — растущая тенденция для DevOps и IT-команд.

Если вы новичок в Chaos engineering, вы пришли по верному адресу. Сегодня мы подробно познакомим вас с принципами его работы и покажем, как начать работу с Kubernetes.

Как можно изолировать поды и пространства имён? В этом нам помогут сетевые модели Kubernetes.

Сетевая модель Kubernetes определяет, что:

● Каждый под получает собственный IP-адрес.

● Поды могут взаимодействовать с любыми другими подами в кластере при помощи IP-адресов подов (без NAT).

● Изоляция (ограничение того, с чем может взаимодействовать каждый под) определяется сетевыми политиками.

Давайте создадим два пространства имён и развернём в них несколько подов, а после этого потестируем, как именно поды взаимодействуют друг с другом в кластере Kubernetes.

В этой статье мы поговорим об использовании Chaos Mesh — опенсорс-фреймворка для хаос-инжиниринга в Kubernetes. Все развёртывания из этой статьи доступны на GitLab. Клонируйте репозиторий и продолжайте читать.

Все мы знакомы с контейнерами и любим их. Контейнеры используют одно и то же ядро хоста (host kernel), что делает их довольно мобильным и лёгким решением. С другой стороны, мы бы предпочли снизить риск причинения вреда хост-машине или операционной системе, чего можно достичь при помощи sandbox-технологий, и gVisor является одной из них. В статье расскажем об этом инструменте.

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

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

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

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

Цель этой части — охватить следующее:

1.Как работает сторона consumer;

2.Как работает масштабирование групп consumerей;

3.Как работает масштабирование с помощью параллельного consumer’а;

4.Настройка, позволяющая избежать медленных consumer’ов.

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

В этой статье мы под разными углами рассмотрим управление сервисами и узнаем, как решать эти задачи с помощью service mesh, Istio, eBPF и RSocket Broker.

В кластере Kubernetes нам доступен любой сервис в любом пространстве имён, то есть по умолчанию pod открыт для любого трафика.

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

Готовиться к собеседованию можно по-разному: смотреть ролики на YouTube, читать документацию, положиться на судьбу и тд. В большинстве случаев кандидатам предложат решить одну или несколько задач. В этой статье вас ждет подробный разбор реальной задачки, рекомендации к ее решению и объяснение ожиданий интервьюера от кандидатов.

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

На рынке можно найти несколько реализаций service mesh. В этой статье мы на примере приложения о книгах поговорим об одном из самых популярных решений, а именно об Istio.

В мире потоков Kafka - это хорошо известная платформа для потоковой передачи событий. Эта серия статей предполагает некоторое базовое знакомство с Kafka —  создание producer’ов и consumer’ов — и будет сосредоточена на выстраивании лучшего понимания того, как именно Kafka работает под капотом, для лучшего проектирования и настройки ваших приложений.

Создание простого проекта потоковой обработки событий – не самая простая задача. В сегодняшней статье мы расскажем, как можно достаточно просто сделать это при помощи Kafka, BigQuery & Looker Studio.

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

Книга Google о SRE, статьи экспертов, документация и обучающие курсы дают исчерпывающие знания о том, как в идеале должен работать SRE в компаниях. Правда, ключевое здесь – «в идеале». Работа с метриками и управление инцидентами в командах может сильно различаться по ряду причин: количество людей в команде, скорость выкатки нового функционала, число микросервисов, распределение компетенций и тд.

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