Прим. перев.: Оригинал этого текста написал Rob Scott — ведущий SRE-инженер компании ReactiveOps, которая и стоит за разработкой анонсируемого проекта. Нам очень близка идея централизованной валидации того, что деплоится в Kubernetes, поэтому мы с интересом следим за подобными инициативами.



Рад представить Polaris — проект с открытым исходным кодом, который помогает поддерживать «здоровье» кластера Kubernetes. Мы создали Polaris для автоматизации некоторых из лучших практик, используемых в ReactiveOps для поддержания безопасной и надежной работы кластеров у большого числа клиентов. Пришло время открыть исходный код.

На прошлой неделе, 19—23 мая, в Барселоне проходила главная европейская конференция по Kubernetes и связанным технологиям, одно из крупнейших Open Source-событий в мире — KubeCon + CloudNativeCon Europe 2019. Мы впервые приняли участие в ней, став серебряным спонсором мероприятия и первой российской компанией на KubeCon со своим стендом. На него была отправлена делегация из шести сотрудников «Фланта», и вот что мы увидели…

Прим. перев.: 16 мая этого года — значимая веха в развитии менеджера пакетов для Kubernetes — Helm. В этот день был представлен первый альфа-релиз будущей крупной версии проекта — 3.0. Её выход принесёт в Helm существенные и долгожданные изменения, на которые многие в Kubernetes-сообществе возлагают большие надежды. К таковым относимся и мы сами, поскольку активно используем Helm для деплоя приложений: мы интегрировали его в свой инструмент для реализации CI/CD werf и от случая к случая вносим посильный вклад в развитие upstream. Этот перевод объединяет 7 заметок из официального блога Helm, что приурочены к первому альфа-релизу Helm 3 и рассказывают об истории проекта и основных фичах Helm 3. Их автор — Matt «bacongobbler» Fisher, сотрудник Microsoft и один из ключевых мейнтейнеров Helm.

Прим. перев.: Достойной внимания оказалась самая популярная публикация сабреддита /r/DevOps за последний месяц: «Автоматизация официально заменила меня на работе — ловушка для DevOps'ов». Её автор (из США) поведал свою историю, которая воплотила в жизнь популярную присказку о том, что автоматизация убьёт потребность в тех, кто поддерживает программные системы.


Пояснение на Urban Dictionary к уже ставшей устойчивой(?!) фразе про замену человека на скрипт

Kubernetes Dashboard — простой в работе инструмент для получения актуальных сведений о работающем кластере и минимального управления им. Начинаешь его ценить ещё больше, когда доступ к этим возможностям нужен не только администраторам/DevOps-инженерам, но и тем, кто меньше привык к консоли и/или не намерен разбираться со всеми тонкостями взаимодействия с kubectl и другими утилитами. Так случилось и у нас: разработчикам захотелось быстрого доступа к веб-интерфейсу Kubernetes, а поскольку мы используем GitLab, решение напросилось само собой.

В минувшую субботу, 18 мая, Jerry Gamblin из Kenna Security проверил 1000 самых популярных образов с Docker Hub на используемый в них пароль для пользователя root. В 19% случаев он отсутствовал.

В начале этого месяца, 3 мая, был анонсирован крупный релиз «системы управления для распределённых хранилищ данных в Kubernetes» — Rook 1.0.0. Более года назад мы уже публиковали общий обзор Rook. Тогда же нас просили рассказать об опыте его использования на практике — и вот, как раз к столь значимой вехе в истории проекта, мы рады поделиться накопленными впечатлениями.

Если кратко, Rook представляет собой набор операторов для Kubernetes, которые полностью берут под контроль развертывание, управление, автоматическое восстановление таких решений для хранения данных, как Ceph, EdgeFS, Minio, Cassandra, CockroachDB.

Прим. перев.: Сотрудники всемирно известного сервиса Tinder недавно поделились некоторыми техническими деталями миграции своей инфраструктуры на Kubernetes. Процесс занял почти два года и вылился в запуск на K8s весьма масштабной платформы, состоящей из 200 сервисов, размещённых на 48 тысячах контейнеров. С какими интересными сложностями столкнулись инженеры Tinder и к каким результатам пришли — читайте в этом переводе.

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

8 апреля на конференции Saint HighLoad++ 2019, в рамках секции «DevOps и эксплуатация», прозвучал доклад «Расширяем и дополняем Kubernetes», в создании которого участвовали три сотрудника компании «Флант». В нём мы рассказываем о многочисленных ситуациях, в которых нам хотелось расширить и дополнить возможности Kubernetes, но для чего мы не находили готового и простого решения. Необходимые решения у нас появились в виде Open Source-проектов, и им тоже посвящено это выступление.

По традиции рады представить видео с докладом (50 минут, гораздо информативнее статьи) и основную выжимку в текстовом виде. Поехали!

Прим. перев.: Автор статьи — Reuven Harrison — имеет более 20 лет опыта в разработке программного обеспечения, а на сегодняшний день является техническим директором и соучредителем компании Tufin, создающей решения для управления политиками безопасности. Рассматривая сетевые политики Kubernetes как достаточно мощное средство для сегментации сети в кластере, он в то же время считает, что они не так просты в применении на практике. Данный материал (довольно объёмный) призван улучшить осведомлённость специалистов в этом вопросе и помочь им в создании необходимых конфигураций.

Представитель нашего клиента, стек приложений которого обитает в облаке от Microsoft (Azure), обратился с проблемой: с недавнего времени часть запросов некоторых клиентов из Европы стала завершаться ошибкой 400 (Bad Request). Все приложения написаны на .NET, развёрнуты в Kubernetes…

Нас все чаще спрашивают про разработку микросервисов в Kubernetes. Разработчики, особенно интерпретируемых языков, хотят быстро поправить код в любимой IDE и без ожидания сборки/деплоя увидеть результат — по простому нажатию на F5. И когда речь шла про монолитное приложение, достаточно было локально поднять базу данных и веб-сервер (в Docker, VirtualBox…), после чего — сразу же наслаждаться разработкой. С распиливанием монолитов на микросервисы и приходом Kubernetes, с появлением зависимостей друг от друга, всё стало немного сложнее. Чем больше этих микросервисов, тем больше проблем. Чтобы вновь насладиться разработкой, нужно поднять уже не один и не два Docker-контейнера, а иногда — даже не один десяток… В общем, на всё это может уходить достаточно много времени, поскольку требуется ещё и поддерживать в актуальном состоянии.

В нашем блоге уже были статьи, рассказывающие про возможности операторов в Kubernetes и о том, как написать простой оператор самому. На этот раз хотим представить вашему вниманию наше Open Source-решение, которое выводит создание операторов на суперлёгкий уровень, — познакомьтесь с shell-operator!

Зачем?

Идея shell-operator довольно проста: подписаться на события от объектов Kubernetes, а при получении этих событий запустить внешнюю программу, предоставив ей информацию о событии:

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

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

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

Прим. перев.: Первая часть этого цикла была посвящена знакомству с возможностями Istio и их демонстрации в действии, вторая — тонко настраиваемой маршрутизации и управлению сетевым трафиком. Теперь же речь пойдёт про безопасность: для демонстрации связанных с ней базовых функций автор использует identity-сервис Auth0, однако по аналогии с ним могут настраиваться и другие провайдеры.

Мы настроили Kubernetes-кластер, в котором развернули Istio и пример микросервисного приложения Sentiment Analysis, — так были продемонстрированы возможности Istio.

С помощью Istio нам удалось сохранить небольшой размер сервисов, поскольку они не нуждаются в реализации таких «слоёв», как повторные попытки подключения (Retries), таймауты (Timeouts), автоматический выключатели (Circuit Breakers), трассировка (Tracing), мониторинг (Monitoring). Кроме того, мы задействовали техники продвинутого тестирования и деплоя: A/B-тестирование, зеркалирование и канареечные выкаты.

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

Информация, использованная для подготовки этого материала, взята из таблицы Kubernetes enhancements tracking, CHANGELOG-1.14 и сооветствующих issues, pull requests, Kubernetes Enhancement Proposals (KEP). UPDATE (26 марта): в блоге K8s появился и официальный анонс релиза.

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

У этих классических отношений есть вариации — опционы, проценты, бонусы, которые немного напоминают, что владельцы и сотрудники в одной лодке. Но бывают и менее типичные ситуации.

Компания Флант состоит из нескольких команд девопосов, которые обслуживают чужие продакшены под ключ. Они выросли из банды студентов-энтузиастов и фанатов Linux, а сейчас построили структуру «бизнесов внутри бизнеса», просто потому что так комфортнее и честнее. Дима Столяров и Саша Баталов рассказали нам, как это устроено.

Флант попал в рейтинг лучших ИТ-работодателей 2018 со средней оценкой 4.68. Судя по оценкам компании на «Моём круге», сотрудники верят, что компания делает мир лучше, а ещё ценят Флант за интересные задачи, хорошие отношения в коллективе, современные технологии и связь с топ-менеджментом.

На прошлой неделе организация The Linux Foundation во время своего мероприятия Open Source Leadership Summit объявила о создании нового фонда для Open Source-проектов. Очередной независимый институт по развитию открытых [и востребованных в индустрии] технологий призван объединить в себе инструменты для DevOps-инженеров, а если быть точнее — для организации и реализации процессов непрерывной доставки, пайплайнов CI/CD. Организацию так и назвали: The Continuous Delivery Foundation (CDF).