Развёртывать микросервисы на сервере — то ещё удовольствие, даже с Kubernetes. К тому же Kubernetes не занимается коммуникациями между сервисами. Для этой задачи мы привлекаем Istio — реализацию service mesh.

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

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

В Airbnb используется сервис-ориентированная инфраструктура, состоящая из множества взаимосвязанных сервисов, которыми управляют небольшие команды. Очень важно вовремя понять, в каком сервисе сбой и кому отправлять оповещения. Мы заметили, что наши команды тратят много времени на переключение между приложениями (Slack, Pagerduty и Jira), чтобы создать инцидент, оповестить нужные команды и предоставить контекст. Эта статья посвящена тому, как Airbnb автоматизировала управление инцидентами в своём сложном и быстро развивающемся скоплении микросервисов.

Скорее всего, вы уже слышали про service mesh — в последние два-три года этот подход становится все популярнее.

Одной из распространённых моделей service mesh считается Sidecar-прокси, которые отвечают за сетевое взаимодействие, безопасность и мониторинг. Правда у этой модели помимо плюсов есть и свои минусы: падение производительности, дополнительные издержки при развертывании и др. В этой статье поговорим о том, сможет ли решить эти проблемы плагин с eBPF, а также о том, как он меняет наш подход к работе с service mesh. 

Установка SLO (Service Level Objective, целевых уровней обслуживания) — одна из базовых задач SRE. По этим показателям удобно оценивать надежность службы. Противоположность SLO — бюджет на ошибки, то есть какой уровень ненадежности считать допустимым. Когда мы определим эти показатели и установим SLO, нужно проверить их реалистичность с учетом архитектуры приложения и рабочих практик. Мы точно сможем их достичь? На что, скорее всего, уйдёт наш бюджет на ошибки?

SRE-инженеры из Google отвечают на эти вопросы при выпуске нового сервиса, когда проводят PRR (Production Readiness Review — проверку готовности продукта). Мы анализируем риски не для того, чтобы изменить SLO. Скорее, мы хотим приоритизировать риски для сервиса, чтобы прикинуть, сможем ли мы достичь наших SLO с учетом изменений сервиса или без них. Кроме того, с помощью анализа мы определим самые важные риски. Определяя и снижая риски, мы повышаем надежность сервиса.

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

В сентябре Антон Скобин, коммерческий директор Слёрма, записал два выпуска подкаста «Манул Слёрма» с Олегом Блохиным, лидером инфраструктурной команды Dodo Engineering. Поговорили о том, как выстраивается работа SRE-команд, какие функции они выполняют и в чём профит от SRE для бизнеса. В этой статье поделимся главными мыслями этой беседы.

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

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

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

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

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

Не существует набора строгих правил, следуя которым можно гарантировать надёжность продукта. В этой статье SRE-инженеры из Google расскажут о том, как оценить культуру надёжности в вашей организации и какой она должна быть.

В Kubernetes есть механизм проверки работоспособности, с помощью которого можно узнать, работает контейнер в pod’е или нет. В этой статье поговорим про 3 вида проверок работоспособности kubelet: пробу запуска (startup),пробу работоспособности (liveness) и пробу готовности (readiness).

Советы по созданию операторов уровня продакшена с помощью Kubebuilder.

В этой статье рассматривается простой пример оператора для сценария автоматического создания ServiceAccount и ClusterRoleBinding с помощьюKubebuilder.

Site Reliability Engineering (SRE) пришел в компании, чтобы прорабатывать вопросы надежности целиком всей системы без разделения на отдельные зоны ответственности, как это было при работе сисадминов и программистов до появления DevOps'ов. Однако роль SRE-инженера, которую представил Google, каждый стал трактовать по-своему. Кто-то делал все строго по книге, а кто-то добавил в работу и свое личное видение.  

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

В этой статье мы собрали самые часто встречаемые мифы и вопросы о внедрении SRE и обучении его инструментам. Ответить на них нам помог Максим Гусев, Tech Lead SRE, на счету которого тысячи выстроенных пайплайнов CI/CD и более 100 инсталляций Kubernetes в продакшен.

Из этой статьи вы узнаете, зачем нужны моки для модульного тестирования операторов Kubernetes и как их писать. Эти концепции применимы к операторам на разных языках и фреймворках. Здесь мы будем использовать Golang, controller-runtime и библиотеку testify.

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

В этой статье пойдет речь о главных инструментах Site Reliability Engineering (SRE) и о том, как они влияют на повышение надежности систем. 

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

Представим, что мы маленькая компания. Мы хотим перенести рабочие нагрузки в Kubernetes, но нас очень волнует вопрос безопасности. Мы уже создали кластеры, опираясь на рекомендации по безопасности из официальной документации Kubernetes. Бизнес растёт, и нам нужно что-то изменить, чтобы защитить среду Kubernetes и в то же время управлять действиями конечных пользователей в кластере. Мы используем встроенные возможности Kubernetes, вроде управления доступом на основе ролей (RBAC), политик безопасности pod’ов, политик сети, управления secret’ами и т. д.

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

Допустим, мы сформулировали политики. Как теперь легко и быстро применить их в среде Kubernetes? В статье мы ответим на этот вопрос.

Принципы Site Reliability Engineering (SRE) в последнее время очень популярны, отчасти благодаря знаменитой книге о SRE в Google, где говорится о золотых сигналах, за которыми нужно следить, чтобы наши системы работали быстро и безотказно в любых масштабах.

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

Если вы используете GitHub для создания приложений Apache Kafka®, наверняка вы захотите интегрировать Kafka в свою среду разработки и эксплуатации GitOps. Эта статья для тех, кто понимает принципы GitOps, ценность непрерывной интеграции и поставки (CI/CD) и важность промежуточных сред (staging).

Мы поговорим о том, как применять принципы GitOps к жизненному циклу разработки клиентского приложения Kafka с помощью GitHub Actions — для тестирования в локальной среде и Confluent Cloud, со Schema Registry и без него, и для эволюции схемы.

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

Зачем менять ZooKeeper на встроенный лог Apache Kafka® для управления метаданными? В этой статье вы узнаете, зачем нужна была эта замена, какие преимущества даёт протокол консенсуса на основе кворума, вроде Raft, и как работает контроллер кворума поверх протоколов KRaft.

Разрабатываете приложения с применением Apache Kafka? Мы собрали для вас статьи, которые помогут освоить инструмент, познакомят с рабочими кейсами с использованием ПО. Делимся пользой и свежими идеями, подборками книг и реализованными задумками.

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

О не очень стандартном использовании Apache Kafka и лайфхаках по созданию Data Lake на его основе нам рассказал Михаил Кобик, директор департамента инфраструктурных решений в SMART Technologies SOFT. В 2017 году перед командой Михаила встала непростая задачка - создать хранилище данных на 80 Tb. В распоряжении был спек, примерные нагрузки и абсолютное непонимание, что с этим делать со стороны заказчика.